1 2013-09-22 01:14:12 <_Sam--> hi, i got a new miner and was mining away fine.  my power went out for longer than my battery backup, and now my bfgminer just shows "requested work update" repeatedly, but my bfl is idle.  any tips?
  2 2013-09-22 01:22:54 <jgarzik> _Sam--, wrong channel.  try #bitcoin-mining
  3 2013-09-22 01:23:16 <_Sam--> thank you.
  4 2013-09-22 03:50:23 <gmaxwell> sipa: fpgaminer posted a short python script that derives all secp256k1's parameters except the generator. :)
  5 2013-09-22 04:47:52 <warren> If you already downloaded protobuf-2.5.0.tar.bz2 could you please provide sha256sum?
  6 2013-09-22 04:47:58 <warren> Just checking against elsewhere.
  7 2013-09-22 04:48:48 <warren> 
ACTION is trying to upgrade gitian win32 to 12.04, will submit PR if it works

  8 2013-09-22 05:21:25 <warren> <wumpus> [23:05:38] "i686-w64-mingw32" is the target name now (yes, it's confusing, but its's windows 32 bit :-)
  9 2013-09-22 05:21:51 <warren> wumpus: you mean the gitian VM should be amd64 12.04 and build the win32 binary from there?
 10 2013-09-22 06:09:23 <wumpus> warren: no, that's not needed, it can be done from a 32 bit system just as well
 11 2013-09-22 06:09:51 <wumpus> warren: it's just that the package is called 'mingw-w64' now, even though the target can be either 32 or 64 bit windows
 12 2013-09-22 06:10:05 <wumpus> warren: the host system doesn't matter when cross compiling
 13 2013-09-22 09:38:11 <Polyatomic> $t$1Polyatomic%O $2looks
 14 2013-09-22 12:58:32 <fling> ERROR: DisconnectBlock() : added transaction mismatch? database corrupted ERROR: VerifyDB() : *** coin database inconsistencies found (last 116 blocks, 22575 good transactions before that)
 15 2013-09-22 12:58:37 <fling> This is what it asking me > Do you want to rebuild the block database now?
 16 2013-09-22 12:58:50 <fling> what should I do to fix this?
 17 2013-09-22 13:17:52 <fling> probably fixed with -reindex
 18 2013-09-22 13:17:53 <fling> thanks
 19 2013-09-22 17:21:36 <kuzetsa> so uhm...
 20 2013-09-22 17:22:04 <kuzetsa> philisophical rhetoric appears to be "gospel" / "treated as official" for the purposes of the channel topic
 21 2013-09-22 17:22:42 <kuzetsa> "from" (sending from) address does exist, it's just that sometimes it was a combination of sources signing to release the bitcoin, or a coinbase transaction
 22 2013-09-22 17:23:30 <gmaxwell> kuzetsa: That really isn't true. Go look at the serialization of a transaction. There is no "from address" in it in any way shape or form.
 23 2013-09-22 17:23:53 <gmaxwell> kuzetsa: Misunderstandings on this have caused bitcoin to be lost many times.
 24 2013-09-22 17:24:28 <kuzetsa> uhm...
 25 2013-09-22 17:24:47 <kuzetsa> "serialization of a transaction" <-- is that a routine in the source? or what?
 26 2013-09-22 17:25:04 <gmaxwell> While you can guess at where a coin might have come from based on where that value had previously been assigned to, that prior to is not always the proximal from. May not be a working address anymore, may not even be convertable into an address, and could even have nothing to do with the party paying you at all.
 27 2013-09-22 17:25:29 <gmaxwell> kuzetsa: a transaction, converted to a string of bytes— e.g. how its sent out between nodes.
 28 2013-09-22 17:25:30 <kuzetsa> exactly
 29 2013-09-22 17:25:50 <kuzetsa> the from address might not always be easily identified
 30 2013-09-22 17:25:53 <kuzetsa> but it exists
 31 2013-09-22 17:25:58 <gmaxwell> It doesn't.
 32 2013-09-22 17:26:13 <gmaxwell> Where a transaction was previously sent to is not a from. And tx prior tx out may have no address possible at all.
 33 2013-09-22 17:26:47 <kuzetsa> that's philisophical rhetoric, and merely opinion
 34 2013-09-22 17:26:53 <kuzetsa> it really is FROM there
 35 2013-09-22 17:27:00 <kuzetsa> even if it can't ever be sent back
 36 2013-09-22 17:27:33 <gmaxwell> No, it isn't necessarily, it even could be an unrelated party.
 37 2013-09-22 17:27:38 <kuzetsa> "Where a transaction was previously sent to" <-- after it gets signed to be sent elsewhere, that is where it came from, literally.
 38 2013-09-22 17:28:18 <kuzetsa> "the sending of funds was handled by a third party" doesn't mean it wasn't from that address
 39 2013-09-22 17:28:38 <gmaxwell> And "Where a transaction was previously sent to"  is not part of the transaction in any case. It's something you can go digging through the blockchain to obtain.
 40 2013-09-22 17:29:24 <gmaxwell> kuzetsa: It doesn't have to be because "handled by a third party", for example. I can go pluck an ANYONE_CAN_PAY transaction off the network and add some additional coin to it, is that transaction now "from" me?
 41 2013-09-22 17:30:09 <michagogo> cloud|kuzetsa: Say I send bitcoins to a script of "anyone who figures out this math problem"
 42 2013-09-22 17:30:52 <michagogo> cloud|I challenge you to show me the "from address" of the transaction spending those coins
 43 2013-09-22 17:31:07 <kuzetsa> michagogo: right, because I guess not all transactions are sent using a signature check... sure
 44 2013-09-22 17:31:18 <kuzetsa> edge use case doesn't mean the most common usage doesn't exist
 45 2013-09-22 17:31:41 <kuzetsa> "there are exceptions" is not the same as saying "this thing doesn't ever exist at all (because exceptions)"
 46 2013-09-22 17:31:54 <kuzetsa> "there is no / none" <-- that's not the same thing at all
 47 2013-09-22 17:32:01 <kuzetsa> usually, there is.
 48 2013-09-22 17:32:15 <michagogo> cloud|An address does not exist on the level of the bitcoin network
 49 2013-09-22 17:32:25 <kuzetsa> true
 50 2013-09-22 17:32:37 <gmaxwell> kuzetsa: here is a transaction,
 51 2013-09-22 17:32:37 <michagogo> cloud|You have a pubkey hash
 52 2013-09-22 17:32:38 <gmaxwell> 01000000010c0e314bd7bb14721b3cfd8e487cd6866173354f87ca2cf4d13c8d3feb4301a6000000004a483045022100d92e4b61452d91a473a43cde4b469a472467c0ba0cbd5ebba0834e4f4762810402204802b76b7783db57ac1f61d2992799810e173e91055938750815b6d8a675902e014fffffffff0140548900000000001976a914a86e8ee2a05a44613904e18132e49b2448adc4e688ac00000000
 53 2013-09-22 17:32:48 <gmaxwell> which bytes are the 'from address'?
 54 2013-09-22 17:33:10 <michagogo> cloud|gmaxwell: Could you decoderawtransaction | pastebin that?
 55 2013-09-22 17:33:18 <kuzetsa> the transaction stuffs is in a weirdo non-turing-complete script format, and doesn't neccessarily have anything to do with signautre based on the hash of a ECC key
 56 2013-09-22 17:33:24 <gmaxwell> michagogo|cloud: No.
 57 2013-09-22 17:33:24 <michagogo> cloud|
ACTION is wondering what that transaction is

 58 2013-09-22 17:33:28 <michagogo> cloud|K
 59 2013-09-22 17:33:41 <kuzetsa> but usually, it has to do with the ECC keys we're currently using
 60 2013-09-22 17:34:07 <gmaxwell> kuzetsa: Why are you arguing about this in here, in any case?
 61 2013-09-22 17:34:39 <gmaxwell> (1) this belongs in some bitcoin for newbies channel, not here. (2) it seems that you're just trying to start an arguement
 62 2013-09-22 17:34:40 <kuzetsa> "I'm able to put in funny transactions if I use the console or manually create raw transactions" <-- that's a silly argument, when the default behavior uses addresses in base58 for everything
 63 2013-09-22 17:35:04 <gmaxwell> kuzetsa: you keep ignoring arguments that don't facilitate your trolling.
 64 2013-09-22 17:35:04 <michagogo> cloud|"Default behavior"
 65 2013-09-22 17:35:47 <gmaxwell> kuzetsa: Come back when you're ready to identify the bytes in a transaction specifying "the from address".
 66 2013-09-22 17:36:07 <kuzetsa> sec, lemme pass it through decode raw transaction
 67 2013-09-22 17:38:01 <michagogo> cloud|kuzetsa: Hint: the block of data that is a transaction has no "from" address
 68 2013-09-22 17:38:49 <Luke-Jr> michagogo|cloud: no transaction does
 69 2013-09-22 17:39:13 <michagogo> cloud|The closest you can get is the pubkey in the scriptsig, iff the txout you're spending  is p2pkh
 70 2013-09-22 17:39:23 <gmaxwell> Yea, as I said, you can go figure out where coin being spent was previously to, though it may have no address. But that is a forensic analysis, and may have jack shit to do with anything someone actually wants to know the "from" for, and this misunderstanding has lost lots of people coin in the past.
 71 2013-09-22 17:39:25 <michagogo> cloud|Luke-Jr: I know
 72 2013-09-22 17:40:23 <michagogo> cloud|Do pay to pubkey transactions pass isstandard?
 73 2013-09-22 17:40:31 <gmaxwell> Because explorer sites show their guestimated from addresses it's been relatively hard to convince people that there is no reliable "from" that they can refund money to in a transaction. People think of transactions like letters with return addresses on them.  Thus the subject.
 74 2013-09-22 17:40:34 <michagogo> cloud|(Not pubkeyhash)
 75 2013-09-22 17:40:36 <gmaxwell> michagogo|cloud: sure.
 76 2013-09-22 17:41:39 <michagogo> cloud|I wonder how mtgox (e.g.)'s code handles btc sent to their addresses
 77 2013-09-22 17:42:32 <Luke-Jr> michagogo|cloud: income :p
 78 2013-09-22 17:42:32 <michagogo> cloud|Does it just get marked as a profit, or does it float around, not accounted for in or known by their systems, until it's cleaned up manually?
 79 2013-09-22 17:42:42 <Luke-Jr> at least, I've paid MtGox that way
 80 2013-09-22 17:42:51 <michagogo> cloud|Lol?
 81 2013-09-22 17:52:53 <kuzetsa> interesting... it kinda looks like the "transaction details" feature on bitcoin-qt no longer displays "from" address as it once did
 82 2013-09-22 17:53:19 <Luke-Jr> it never did
 83 2013-09-22 17:53:33 <kuzetsa> you mean it always said "unknown" for the "from" section?
 84 2013-09-22 17:53:35 <Luke-Jr> yes
 85 2013-09-22 17:53:41 <kuzetsa> odd
 86 2013-09-22 17:54:00 <Luke-Jr> it's for future use
 87 2013-09-22 17:54:04 <Luke-Jr> when we create requests
 88 2013-09-22 17:54:26 <sipa> gmaxwell: 3.8k reachable now
 89 2013-09-22 17:55:02 <Luke-Jr> actually, it looks like From used to do something for IP transactions
 90 2013-09-22 17:55:18 <Luke-Jr> but here is the relevant part of Bitcoin-Qt 0.5.0 (first release): strHTML += tr("<b>From:</b> ") + tr("unknown") + "<br>";
 91 2013-09-22 17:56:18 <sipa> it may neve rhave been completely ported to Qt
 92 2013-09-22 17:56:19 <Luke-Jr> and even wxBitcoin 0.1.5: strDescription += "From: unknown, To: ";
 93 2013-09-22 17:56:45 <sipa> or maybe satoshi planned to extend the ip transactions protocol to include from information in it
 94 2013-09-22 17:56:53 <michagogo> cloud|sipa: /me wonders if that number includes him
 95 2013-09-22 17:56:55 <sipa> (which makes sense, if it's something decided by the sender)
 96 2013-09-22 17:57:30 <sipa> gmaxwell: nice, the secp256k1's parameters are easily reproducible
 97 2013-09-22 17:57:55 <Cusipzzz> i doubt most of the 'from address' people are think of IP transactions, most people don't even remember them
 98 2013-09-22 17:58:46 <gmaxwell> sipa: except the generator, alas. I spent a little while trying to come up with it.
 99 2013-09-22 17:59:03 <sipa> gmaxwell: that's unfortunate, but hardly worrying
100 2013-09-22 17:59:11 <gmaxwell> e.g. curve.lift_x(1)*n for varrious n..  No, not worrying at all.
101 2013-09-22 18:00:13 <sipa> is there a point with x=0?
102 2013-09-22 18:50:46 <jgarzik> 19,141,092 MicroSD cards will fit in a 2014 Chevy Suburban.  That's over 1.2 billion GB, or 1168 PB or 1.14 EB
103 2013-09-22 18:50:54 <michagogo> lol
104 2013-09-22 18:51:21 <michagogo> Assuming you can get 19,141,092 microSD cards :-P
105 2013-09-22 18:51:30 <michagogo> (also, with that many, some are sure to fail)
106 2013-09-22 18:51:49 <jgarzik> And find enough humans or build enough machines to fill them with data, then pack them
107 2013-09-22 18:52:20 <jgarzik> Wonder how many years it would take  (random)  10 people to fill those cards, then pack the suburban.  :)
108 2013-09-22 18:52:30 <michagogo> Depends on the class of the cards, too
109 2013-09-22 18:52:45 <michagogo> (and on how many readers they have to use at once)
110 2013-09-22 18:52:52 <michagogo> (and on what they're copying data from)
111 2013-09-22 18:52:53 <michagogo> (etc)
112 2013-09-22 18:55:02 <jgarzik> assuming those problems are solved, driving the Chevy Suburban across the USA, from New York to LA, is 2790 mi in 40 hours.
113 2013-09-22 18:55:07 <jgarzik> That's 68,057 Gbps
114 2013-09-22 18:55:12 <jgarzik> per Suburban
115 2013-09-22 18:58:37 <Cusipzzz> the bigger problem is the suburban would break down within 20 hours, lol chevy :)
116 2013-09-22 18:58:51 <weex> also there's going to be some leakage as microsd cards would flow into the various holes in the interior
117 2013-09-22 18:59:06 <jgarzik> hah
118 2013-09-22 18:59:17 <sipa> oh no, a memory leak
119 2013-09-22 19:08:46 <michagogo> 
ACTION wonders if petertodd is around

120 2013-09-22 19:10:21 <petertodd> michagogo: hi possible person :P
121 2013-09-22 19:10:26 <michagogo> lol
122 2013-09-22 19:10:51 <michagogo> What you say does make sense
123 2013-09-22 19:11:06 <michagogo> I've seen someone (in here, I think?) explain it like this
124 2013-09-22 19:11:18 <petertodd> Yeah, I mean, you may have devs convinced you are someone, but, how is a third-party supposed to know?
125 2013-09-22 19:11:22 <jgarzik> Distributed consensus!  32 discordant metronomes achieve synchrony:  http://io9.com/5947112/watch-32-discordant-metronomes-achieve-synchrony-in-a-matter-of-minutes?action_type_map=%7B%2210153226568265094%22%3A%22og.likes%22%7D&fb_action_types=og.likes&fb_source=other_multiline&action_object_map=%7B%2210153226568265094%22%3A159320750875948%7D&action_ref_map&fb_action_ids=10153226568265094   </mostly OT>
126 2013-09-22 19:11:48 <petertodd> jgarzik: pff, that's so centralized via the table
127 2013-09-22 19:12:02 <warren> sipa: don't worry, garbage collection will take care of it... although it might collect the entire suburban.
128 2013-09-22 19:12:06 <sipa> also, it's not particularly DoS-resistant
129 2013-09-22 19:12:14 <petertodd> sipa: lol
130 2013-09-22 19:12:19 <sipa> one evil metronome could probably disturb the whole thing
131 2013-09-22 19:12:23 <michagogo> petertodd: Oh, I'd misinterpreted what you were saying
132 2013-09-22 19:12:36 <Cusipzzz> african or european metronomes?
133 2013-09-22 19:12:40 <jgarzik> rofl
134 2013-09-22 19:12:59 <petertodd> sipa: Although the ability of each metronome to disturb the whole thing is at least proportional to the power each metronome has.
135 2013-09-22 19:13:14 <sipa> petertodd: we always assume an uberpowerful attacker anyway
136 2013-09-22 19:13:43 <petertodd> sipa: Sure, but that metronome would at least need to be a 10% attacker.
137 2013-09-22 19:14:26 <michagogo> petertodd: That's a good question. Hmm.
138 2013-09-22 19:14:47 <petertodd> michagogo: My main concern is that given that the output of a gitian sig isn't a proof-of-work, you really don't want it to be possible to get more than your share of gitian weight by anything virtual.
139 2013-09-22 19:15:04 <michagogo> I see.
140 2013-09-22 19:15:09 <petertodd> michagogo: (IE, you can't know if someone just copies the gitian output)
141 2013-09-22 19:15:26 <michagogo> (well, you can see that the input manifests are different)
142 2013-09-22 19:15:38 <michagogo> But yeah, that's true
143 2013-09-22 19:17:04 <michagogo> petertodd: Would you consider me identifying myself to a few users in private, who could state that I've done so, meaningful?
144 2013-09-22 19:17:05 <petertodd> michagogo: When I saw your commit I briefly had you confused with mikegogulski, whose twitter account may have been just hacked, FWIW.
145 2013-09-22 19:17:12 <michagogo> Who?
146 2013-09-22 19:17:19 <petertodd> michagogo: No, because I as a third-party can't verify that.
147 2013-09-22 19:18:04 <petertodd> michagogo: Now if you contributed some code, via gpg signed git commits, I could at least verify that code existed easily. (git log --show-signature)
148 2013-09-22 19:18:08 <michagogo> Well, you couldn't verify that a name and email address that I attached to the key weren't sockpuppets either
149 2013-09-22 19:18:24 <petertodd> michagogo: Not directly, but I could google you more easily.
150 2013-09-22 19:18:35 <michagogo> If I were googlable, sure
151 2013-09-22 19:18:37 <michagogo> (I don't suppose commits can be retroactively signed?)
152 2013-09-22 19:19:13 <petertodd> michagogo: Nope
153 2013-09-22 19:20:12 <michagogo> 
ACTION checks and sees he has 3 commits in the bitcoin repo

154 2013-09-22 19:20:28 <michagogo> 
ACTION switches to IRCCloud on his phone

155 2013-09-22 19:20:49 <gmaxwell> sipa: No, x=0 is not on the curve.
156 2013-09-22 19:22:23 <petertodd> michagogo: whereas if you look up pete@petertodd.org you get plenty of results, even more if you look up pete@petertodd.ca, my old address (which I still control)
157 2013-09-22 19:22:37 <gmaxwell> 2,3,4,6,8,12... all are, and I tried doubling all of them.
158 2013-09-22 19:22:50 <petertodd> michagogo: for instance something I wrote for the linux journal in 2002: http://www.linuxjournal.com/article/5963
159 2013-09-22 19:23:31 <gmaxwell> Aww. Just a wittle baby boy in the picture. :P
160 2013-09-22 19:24:03 <petertodd> lol
161 2013-09-22 19:24:21 <michagogo> cloud|petertodd: Well, I don't know that publicizing my name would make much turn up in Google...
162 2013-09-22 19:25:07 <petertodd> michagogo: Yeah, which is a problem. Look at it another way: what do you have to lose by releasing bad gitian sigs if you don't have a public reputation?
163 2013-09-22 19:25:21 <michagogo> cloud|I see.
164 2013-09-22 19:27:06 <michagogo> cloud|petertodd: Well, there's more connected to this name than to my real one, a quick search suggests
165 2013-09-22 19:27:51 <petertodd> michagogo: such as?
166 2013-09-22 19:28:06 <michagogo> cloud|Plus, there are more false positives (people with the same name) with my real name
167 2013-09-22 19:28:46 <petertodd> michagogo: Sure - note how I said google for my email, not my name.
168 2013-09-22 19:29:22 <petertodd> michagogo: Google for my name and you might think I shouldn't be on gitian because I'm a serial killer...
169 2013-09-22 19:29:42 <michagogo> cloud|petertodd: lol
170 2013-09-22 19:29:43 <Cusipzzz> ted bundy?
171 2013-09-22 19:29:57 <petertodd> http://cjaye57.wordpress.com/2010/01/20/james-todd-twin-brother-of-peter-todd-the-jessica-foster-case/
172 2013-09-22 19:30:08 <michagogo> cloud|Also, searching for my email address turns up even fewer relevant things :-/
173 2013-09-22 19:30:52 <michagogo> cloud|Some posts on some yahoo group from over half a decade ago
174 2013-09-22 19:31:14 <petertodd> michagogo: well, set weight to 1 like you had before and leave it at that. After all, having people verify the sigs, even if we can't verify who they are, is still valuable because anyone can blow the whistle.
175 2013-09-22 19:32:01 <michagogo> cloud|petertodd: That's kinda what I was thinking, I think
176 2013-09-22 19:32:12 <petertodd> michagogo: Yeah, I'd be happy with that.
177 2013-09-22 19:32:23 <michagogo> cloud|
ACTION was following Gavin's suggestion

178 2013-09-22 19:33:13 <michagogo> cloud|Also, I was thinking maybe the action weight could be something besides a multiple of 40
179 2013-09-22 19:33:39 <michagogo> cloud|At its most basic, it could be, say, 121
180 2013-09-22 19:34:05 <michagogo> cloud|Which ATM would be "at least 3 core devs, plus one more person"
181 2013-09-22 19:34:21 <michagogo> cloud|Or 81, or whatever
182 2013-09-22 19:34:36 <petertodd> michagogo: Not a bad idea really, although an objection there is how hard a time we've had getting gitian sigs.
183 2013-09-22 19:34:57 <petertodd> not that I'm helping...
184 2013-09-22 19:35:43 <michagogo> cloud|(If someone ever gets around to drawing up a hierarchy or list of weight meanings or whatever, action weight could easily be recalculated however we want)
185 2013-09-22 19:36:56 <petertodd> michagogo: yup
186 2013-09-22 19:36:59 <michagogo> cloud|Also, right now the action weight means nothing at all, until the point when (if?) gitian-downloader happens
187 2013-09-22 19:37:35 <petertodd> michagogo: yup, and eventually we're going to want negative weights too to say "THE DEV TEAMS ALL BEEN COMPROMISED!"
188 2013-09-22 19:37:38 <warren> there's a bug in the gitian sigs procedure
189 2013-09-22 19:37:49 <michagogo> cloud|warren: What kind of bug?
190 2013-09-22 19:37:53 <warren> somehow it adds an extra newline between each line
191 2013-09-22 19:37:55 <warren> randomly
192 2013-09-22 19:37:58 <michagogo> cloud|Hmm?
193 2013-09-22 19:38:06 <gmaxwell> Yea, negative weights will be good. That models the way we expect the security to work... "if something bad happens, someone sounds an alarm."
194 2013-09-22 19:38:08 <warren> I see it in sigs made by people but not consistently
195 2013-09-22 19:38:42 <michagogo> cloud|gmaxwell: So what, people will have two keys in the system?
196 2013-09-22 19:39:06 <petertodd> michagogo: No, just a way to make a signature saying "this release is bad"
197 2013-09-22 19:39:31 <gmaxwell> michagogo|cloud: huh? No. I mean there would be people who cannot add positive karma (or only limited positive karma) but could add lots of negative karma.
198 2013-09-22 19:39:32 <michagogo> cloud|Maybe I'm not aware of gitian's full potential
199 2013-09-22 19:39:37 <petertodd> michagogo: Or, actually, more like "further releases by these keys are bad"
200 2013-09-22 19:39:49 <warren> the biggest problem here is there is no way to prove that someone actually built it
201 2013-09-22 19:40:00 <michagogo> cloud|But wouldn't a negative-weight sig need a
202 2013-09-22 19:40:04 <michagogo> cloud|Build?
203 2013-09-22 19:40:49 <petertodd> warren: Yeah, best you can do is no-one releases their signatures until some set time in the future and you timestamp you gitian-sigs when you make them.
204 2013-09-22 19:40:59 <warren> wait
205 2013-09-22 19:41:02 <warren> there might be a simpler way
206 2013-09-22 19:41:07 <petertodd> warren: ?
207 2013-09-22 19:41:13 <michagogo> cloud|So if, say, Gavin, luke, warren, laanwj, sipa, and whoever else decide to collude to steal coins, you'd need to reproduce their build
208 2013-09-22 19:42:03 <michagogo> cloud|Which you couldn't do because they could be using a patch you don't have
209 2013-09-22 19:42:17 <warren> petertodd: everyone can publish a hash that is compromised of the hashes of all the key output builds.  Then challenge each other for hashes of random portions of those inputs.
210 2013-09-22 19:42:49 <petertodd> warren: Problem is they could just copy the whole intermediate build process.
211 2013-09-22 19:43:11 <petertodd> warren: Certainely makes it harder to without someone elses co-operation though.
212 2013-09-22 19:43:22 <michagogo> cloud|Also there are only 2 (?) files that might change
213 2013-09-22 19:43:30 <michagogo> cloud|Or 3 for windows
214 2013-09-22 19:43:32 <warren> petertodd: isn't this a zero knowledge approach?
215 2013-09-22 19:43:37 <warren> 
ACTION reads the definition of zero knowledge.

216 2013-09-22 19:43:58 <gmaxwell> petertodd: You can make a non-trivally hash. Though anyone who could verify it could clone it.
217 2013-09-22 19:44:39 <petertodd> warren: My point is if I want to make a gitian sig but don't want to do the actual work if you're willing to co-operate with me I trivially can.
218 2013-09-22 19:44:49 <warren> If you made your own build, you can use it to verify that someone else has the same outputs without revealing the hashes of those outputs directly.
219 2013-09-22 19:44:51 <petertodd> warren: Zero-knowledge doesn't help.
220 2013-09-22 19:45:07 <michagogo> cloud|Unless I'm kidding something here, the problem is that the expected result is that everyone has identical builds
221 2013-09-22 19:45:09 <gmaxwell> e.g. (PubKey * hash) is non-clonable by someone who doesn't know hash. but trivally verifyable.
222 2013-09-22 19:45:09 <warren> It doesn't help to prove the two people you ask didn't collude.
223 2013-09-22 19:45:13 <michagogo> cloud|Missing*
224 2013-09-22 19:45:25 <gmaxwell> michagogo|cloud: Thats the point, how can you say it's a problem?
225 2013-09-22 19:46:09 <warren> petertodd: this is at least a meaningful improvement.  You know at least YOUR build is supposed to be good, and you reveal nothing about it in verifying with <others>.
226 2013-09-22 19:46:11 <petertodd> warren: Actually, I think you've got a good point there: this is an advantage over just timestamping because it makes it possible to verify a build done by someone after the gitian sigs have been released.
227 2013-09-22 19:46:21 <gmaxwell> (or even just H(pubkey || H(build)) for that matter)
228 2013-09-22 19:46:47 <gmaxwell> warren: it really doesn't, because you can go grab someone elses build compute the hash and sign that, — doesn't mean you built it.
229 2013-09-22 19:46:52 <petertodd> warren: So if I miss the deadline, I can still contribute my sig and other builders can verify that I did so honestly. (assuming no-one has given their intermediates to me)
230 2013-09-22 19:47:06 <petertodd> warren: Not a huge improvement, but an improvement.
231 2013-09-22 19:47:34 <gmaxwell> petertodd: oh you mean ZKPing the non-distributed intermediaries? meh, no one but another builder can verify that.
232 2013-09-22 19:48:01 <warren> gmaxwell: it doesn't prevent collusion, but it at least helps an individual provide information without revealing anything that can be copied.
233 2013-09-22 19:48:03 <petertodd> gmaxwell: Sure, but as I say, that is an improvement over the simple timestamp version.
234 2013-09-22 19:48:19 <gmaxwell> warren: if you can verify it you can copy it under any of these schemes.
235 2013-09-22 19:48:28 <petertodd> gmaxwell: IE, I timestamp my gitian sigs, and we all release the sigs after some deadline passes.
236 2013-09-22 19:48:30 <michagogo> cloud|I mean, in theory, you could use something like remote-attest with a TPM :-D
237 2013-09-22 19:49:04 <warren> gmaxwell: you provide only the hash of all hashes, then challenge random parts of the outputs that lead to that hash.  yes, doesn't solve all problems, but better than we have today.
238 2013-09-22 19:49:06 <gmaxwell> I think you're chasing your tail. If a signer is malicious then they can just directly cooperate with a badguy.
239 2013-09-22 19:49:35 <gmaxwell> warren: What attack does it solve?  J-random-user can't tell if the challenge result is worthless garbage or not.
240 2013-09-22 19:49:48 <petertodd> gmaxwell: Yes, but I'm still protecting against signers only being a little evil and getting lazy; that's a very real human failing that we might see.
241 2013-09-22 19:49:58 <warren> gmaxwell: it solves the "this guy just copied my hashes and signed it" problem.
242 2013-09-22 19:50:03 <gmaxwell> E.g. I compute a bunch of fake build stuff, and take petertodd's binaries, then I produce one of these challenge hashes. No one but another builder could tell it was bogus.
243 2013-09-22 19:50:18 <gmaxwell> petertodd: I'd worry if we were paying signers— otherwise?
244 2013-09-22 19:50:52 <gmaxwell> warren: I don't believe it solves that at all, since no one but another builder could distinguish a fake signature from a correct one.
245 2013-09-22 19:50:57 <petertodd> gmaxwell: Yup, and right now we have enough problems getting gitian sigs to always match first try... but it's an easy thing to do at least.
246 2013-09-22 19:51:15 <warren> the gitian process needs to be better documented and automated, allowing more random people to provide the top hash
247 2013-09-22 19:51:45 <petertodd> warren: yeah, I tried and couldn't even get it to run on my computer :( something about bios issues with the VM supposedly
248 2013-09-22 19:52:51 <michagogo> petertodd: You want your CPU and BIOS to support hardware virtualization
249 2013-09-22 19:53:10 <warren> petertodd: what CPU?  it's been supported for years already ...
250 2013-09-22 19:53:11 <michagogo> (Intel VT-x or AMD-V)
251 2013-09-22 19:53:32 <gmaxwell> sadly intel product differentiates the nested virtualization stuff.
252 2013-09-22 19:53:37 <michagogo> gmaxwell: ?
253 2013-09-22 19:53:38 <gmaxwell> You can buy a brand new cpu without it. :(
254 2013-09-22 19:53:42 <michagogo> Ah
255 2013-09-22 19:53:49 <petertodd> michagogo: Yeah, I checked that virtualization was turned on, which it was, and it still didn't work. Apparently it's a known problem with my motherboard. :(
256 2013-09-22 19:54:03 <michagogo> :-(
257 2013-09-22 19:54:55 <michagogo> It'd be nice if gitian worked on Windows
258 2013-09-22 19:54:59 <warren> the current gitian documetation also points at input URL's that are dead
259 2013-09-22 19:55:13 <gmaxwell> warren: open pull requests!
260 2013-09-22 19:55:19 <Luke-Jr> michagogo: gitian supports VirtualBox on Windows IIRC
261 2013-09-22 19:55:19 <warren> I intend to
262 2013-09-22 19:55:25 <warren> gmaxwell: I'm working on 12.04 win32 gitian now
263 2013-09-22 19:55:30 <michagogo> (though at the moment, I seem to have some kind of borked-nedd going on with gpg)
264 2013-09-22 19:55:35 <michagogo> borked-ness*
265 2013-09-22 19:55:52 <michagogo> At some point I had it installed on my previous computer or something
266 2013-09-22 19:55:58 <gmaxwell> petertodd: the real use for being able to prove people did the build themselves would be to bounty/lottery performing the act, but sadly sound _no_ system (not even SCIP) could prevent cloning. The best you could do is remote attest to some trusted hardware.
267 2013-09-22 19:56:11 <michagogo> And accidentally carried some files over to this computer
268 2013-09-22 19:56:17 <petertodd> gmaxwell: Yeah, and with trusted hardware, why do it more than once?
269 2013-09-22 19:56:46 <michagogo> I don't know what's wrong exactly, but I've never managed to get gpg working on my computer :-/
270 2013-09-22 19:56:50 <warren> I'd like to improve gitian to provide a hash at the top of all the key outputs.  Some of the other files below it are non-deterministic but that doesn't effect determinism in the final outputs.
271 2013-09-22 19:56:52 <gmaxwell> petertodd: There are degrees of trust, but indeed, thats not worth paying for. :)
272 2013-09-22 19:57:10 <michagogo> (correction: on the Windows installation on the internal harddrive of my computer)
273 2013-09-22 19:57:29 <gmaxwell> warren: uh. aren't all the binaries hashed?
274 2013-09-22 19:57:55 <gmaxwell> replace that question. What _isn't_ included in the hash right now?
275 2013-09-22 19:58:15 <warren> gmaxwell: hash of all hashes that matter, just to conveniently report a single hash to compare against other people
276 2013-09-22 19:58:22 <michagogo> warren: Well, something that I realized after the first or second time that I compared gitian asserts for identicalness is that you only really need the first 2 or 3 lines
277 2013-09-22 19:59:24 <michagogo> Oh, my numbers were a bit off
278 2013-09-22 19:59:32 <michagogo> it's 4 lines of linux and 3 of windows
279 2013-09-22 19:59:46 <michagogo> fba3b61d22e98a3bfa17e193fdf2ff68c018794ff5d7a1b3aef41c9a56d4606d  bin/32/bitcoin-qt    56bbd66e8fd42e6340b1f9e86fb9dd5ba23543a0684376b3c2b518c0f5e512da  bin/32/bitcoind    8baf63fd318582cc2553d89ee07e5fe21874ee6a7d948ed81a2d32349e99070c  bin/64/bitcoin-qt    f7643b298de044c20f6e629f8c0c179eb5f35efa0edcadb0895124d2b4f59cf2  bin/64/bitcoind
280 2013-09-22 19:59:59 <michagogo> and dbfbb6eeb74bf1aa59679f122439d33d8b9d98fa0d9bb97a103140b682e514fc  bitcoin-0.8.5-win32-setup.exe    d1212680e0cd4382d514d407d3494284b8ebd7e8028a8f22179c108767420264  bitcoin-qt.exe    05af7e22721d0d1ca01c4375291f94f0248d06fdada0a9503a4597af0ca262e7  daemon/bitcoind.exe
281 2013-09-22 20:00:25 <sipa> of setup.exe matches, everything matches
282 2013-09-22 20:00:29 <sipa> *if
283 2013-09-22 20:00:31 <warren> sure
284 2013-09-22 20:00:43 <michagogo> sipa: Oh, right -- good point
285 2013-09-22 20:00:48 <warren> linux it's four files
286 2013-09-22 20:01:14 <warren> do we ever plan on doing arm and arm64 gitian?
287 2013-09-22 20:01:23 <michagogo> But yeah, it wouldn't hurt for gitian to hash the out manifest block
288 2013-09-22 20:01:26 <warren> protobuf needs patches to build on archs not intended by Google
289 2013-09-22 20:02:09 <michagogo> In our specific case we may not need it, but with some other projects there may be more actual build artifacts that need comparing
290 2013-09-22 20:03:11 <gmaxwell> protobuf needs patches on ARM? thats pretty crappy.
291 2013-09-22 20:03:14 <gmaxwell> ::sigh::
292 2013-09-22 20:03:37 <warren> gmaxwell: yeah, a giant patch, replacement autogen.sh and autoconf-2.69 to redo everything
293 2013-09-22 20:03:46 <sipa> orly?
294 2013-09-22 20:04:01 <warren> gmaxwell: i was going to propose it for contrib/ but I realized we have maybe two users on arm
295 2013-09-22 20:04:10 <sipa> wait, what is the problem with arm onprotobuf?
296 2013-09-22 20:04:17 <warren> 
ACTION finds URL

297 2013-09-22 20:04:21 <michagogo> 
ACTION wonders if gavinandresen was serious about "Michagogo should have weight eleven"

298 2013-09-22 20:04:41 <sipa> warren: all of which build from souce, i guess :p
299 2013-09-22 20:04:57 <sipa> or run onlybitcoind
300 2013-09-22 20:05:02 <warren> sipa: this only matters to us if we want to do a gitian-like arm and arm64 build
301 2013-09-22 20:05:19 <gmaxwell> warren: I expect that arm will eventually be an officially supported platform for us... someday. But that doesn't mean we need to worry about it now.  Though I think the non-portablity speaks pretty negatively about protobuf.
302 2013-09-22 20:05:26 <sipa> so what is the problem?
303 2013-09-22 20:05:32 <warren> https://bugzilla.redhat.com/show_bug.cgi?id=926374   and patches available here http://pkgs.fedoraproject.org/cgit/protobuf.git/tree
304 2013-09-22 20:06:21 <gmaxwell> protobuff has memory barrier code?
305 2013-09-22 20:06:23 <michagogo> petertodd: I'd update the PR with weight: 1, except that I'd like to hear gavinandresen's explanation for his suggestion of 11
306 2013-09-22 20:06:24 <warren> gmaxwell: apparently 0.8 works just fine on arm linux right now, we have one user who reports that its "slow"
307 2013-09-22 20:06:44 <michagogo> I mean, simply whether there was some reason behind it or if he was just throwing it out there
308 2013-09-22 20:06:50 <gmaxwell> warren: "arm" is a little vague.  And yes, it works, I have it running on arm. So does bluematt.
309 2013-09-22 20:06:52 <gribble> gavinandresen was last seen in #bitcoin-dev 2 days, 14 hours, 14 minutes, and 17 seconds ago: <gavinandresen> cfields: running make -j 1 seems to be working better, I think there is some parallelism issue with the make check with blocktester rules
310 2013-09-22 20:06:52 <michagogo> ;;seen gavinandresen
311 2013-09-22 20:07:03 <warren> petertodd: I think 3 signers is not enough. It should be more
312 2013-09-22 20:08:12 <warren> gmaxwell: I could submit these patches as part of the gitian process, which makes no difference for our current gitian builds, but it serves as example for future other-archs that want to copy it.
313 2013-09-22 20:08:17 <Luke-Jr> warren: that's ARM64
314 2013-09-22 20:08:50 <Bkil> Is there an IRC channel for testnet discussion? Thanks
315 2013-09-22 20:08:59 <sipa> this one will do fine
316 2013-09-22 20:09:18 <Luke-Jr> unless you want to monetise testnet..
317 2013-09-22 20:09:35 <sipa> gmaxwell,warren: meh, it should be trivial to compile protobuf to pure C/C++ without dependencies, for just the basic stuff
318 2013-09-22 20:10:06 <Bkil> Does anyone have the current block number of the testnet? Blockexplorer.com has it at 103332 but that hasn't updated since August 29. Looking to use the testnet to test a project for school :)
319 2013-09-22 20:10:08 <gmaxwell> Luke-Jr: even then. :)
320 2013-09-22 20:10:37 <jgarzik> I bet "Spinal Tap" is Gavin's favorite movie
321 2013-09-22 20:10:39 <jgarzik> (RE 11)
322 2013-09-22 20:10:46 <warren> Luke-Jr: one exchange put testnet on as an alt coin ...
323 2013-09-22 20:10:59 <sipa> jgarzik: or Ocean's Elevent
324 2013-09-22 20:11:01 <petertodd> warren: Realisticly I suspect github is a more likely vector to malicious code than gitian builds at this point.
325 2013-09-22 20:11:05 <gmaxwell> warren: fantastic! which exchange?
326 2013-09-22 20:11:05 <gribble> Error: "testnet,blocks" is not a valid command.
327 2013-09-22 20:11:05 <michagogo> ;;testnet,blocks
328 2013-09-22 20:11:10 <warren> 
ACTION finds

329 2013-09-22 20:11:16 <nkuttler> Bkil: my wallet says 107148
330 2013-09-22 20:11:17 <gmaxwell> I'm gonna be super rick!
331 2013-09-22 20:11:21 <gmaxwell> er rich!
332 2013-09-22 20:11:23 <jgarzik> heh
333 2013-09-22 20:11:25 <nkuttler> Bkil: but just run getinfo..
334 2013-09-22 20:11:29 <Luke-Jr> warren: tell me before gmaxwell!
335 2013-09-22 20:11:37 <michagogo> my node has 107150
336 2013-09-22 20:11:39 <jgarzik> honestly, I do think we should reset testnet once a year
337 2013-09-22 20:11:50 <Luke-Jr> jgarzik: auto-reset? :D
338 2013-09-22 20:12:12 <jgarzik> prevents the incentive of using it as an alternate data stream
339 2013-09-22 20:12:17 <gmaxwell> No reason to have a schedule about it.
340 2013-09-22 20:12:17 <warren> gmaxwell: Luke-Jr: https://twitter.com/coinkite/status/381067888552976384
341 2013-09-22 20:12:19 <sipa> now that we have explicit network parameters, even just adding a testnet4 without deleting 3 is easy
342 2013-09-22 20:12:30 <jgarzik> it's not the mainnet blockchain, but it's still a common, shared database
343 2013-09-22 20:12:54 <jgarzik> too much incentive to abuse, if not reset regularly, IMO
344 2013-09-22 20:12:57 <sipa> i would like to remove all explicit mentions of TestNet() in the code though, and replace them by boolean chain param properties
345 2013-09-22 20:12:58 <nkuttler> i'd like to be able to spin up private testnets. for unit testing, being able to mine with results, etc
346 2013-09-22 20:13:00 <Luke-Jr> warren: ok, that doesn't look too bad, but they're doing it wrong
347 2013-09-22 20:13:01 <jgarzik> like this exchange thing
348 2013-09-22 20:13:09 <jgarzik> sipa, ACK
349 2013-09-22 20:13:18 <gmaxwell> I dunno that an exchange thing alone is an incentive to abuse.
350 2013-09-22 20:13:23 <warren> petertodd: if only someone were to invent a decentralized source control mechanism...
351 2013-09-22 20:13:26 <Luke-Jr> pfft @ requiring a login to view FAQ
352 2013-09-22 20:13:37 <gmaxwell> I tried to get mtgox for a long time to setup an exchange where you could trade testusd for testnetbtc.
353 2013-09-22 20:13:38 <petertodd> Luke-Jr: ?
354 2013-09-22 20:13:44 <Luke-Jr> gmaxwell: it looks like they're suggesting it actually for testing
355 2013-09-22 20:13:48 <Luke-Jr> petertodd: that Coinkite exchange
356 2013-09-22 20:13:52 <warren> gmaxwell: and they refused?
357 2013-09-22 20:14:10 <gmaxwell> IIRC they said they would but never got around to it.
358 2013-09-22 20:14:10 <petertodd> warren: careful, I'll make a git plugin that uploads patches to the blockchain
359 2013-09-22 20:14:15 <jgarzik> exchange thing just a side issue.  my  main worry is that simple lack of regular reset, on any schedule, opens the door to botnet comm channels, wikileaks cable data storage, etc.
360 2013-09-22 20:14:29 <jgarzik> as costs remain offloaded
361 2013-09-22 20:14:31 <Luke-Jr> warren: like git?
362 2013-09-22 20:14:33 <warren> gmaxwell: for an authentic experience, it also has testusd wires delayed by 2 months
363 2013-09-22 20:14:38 <gmaxwell> jgarzik: yea, it's fine to reset. I agree.
364 2013-09-22 20:14:41 <jgarzik> warren, rofl
365 2013-09-22 20:14:42 <Bkil> nkuttler: thanks was syncing a new node and wanted to see how long it would take. Looks like it is done now, thanks: )
366 2013-09-22 20:14:55 <petertodd> jgarzik: I suspect data storage will always be secondary to data distribution in terms of usefulness actually
367 2013-09-22 20:15:06 <gmaxwell> warren: "How can you tell mtgoxusd from testusd?"  "The value of testusd is known"
368 2013-09-22 20:15:18 <warren> lol
369 2013-09-22 20:15:29 <Luke-Jr> warren: I think I've been waiting over 2 months for my wire
370 2013-09-22 20:16:04 <michagogo> Also, who mines the testusd?
371 2013-09-22 20:16:09 <warren> testfed
372 2013-09-22 20:16:11 <gmaxwell> michagogo: mtgox would, of course.
373 2013-09-22 20:16:11 <Luke-Jr> mines?
374 2013-09-22 20:16:12 <jgarzik> 
ACTION made several BTC at mtgox couple days ago, dep btc -> sell for mtgoxusd -> buy at a lower price -> withdraw btc

375 2013-09-22 20:16:18 <Luke-Jr> you just make a deposit and it fabricates
376 2013-09-22 20:16:21 <Luke-Jr> like in the real world
377 2013-09-22 20:16:25 <jgarzik> made  5.19 BTC
378 2013-09-22 20:16:32 <jgarzik> in 48 hours
379 2013-09-22 20:16:39 <michagogo> Luke-Jr: Well, what do you expect from a line that advances at the take of 10 users per day on the biggest bitcoin exchange there is?
380 2013-09-22 20:16:45 <Bkil> nkuttler: testnet in a box should allow for private testnets
381 2013-09-22 20:16:57 <petertodd> jgarzik: that's called trading, and adds liquidity...
382 2013-09-22 20:16:58 <jgarzik> testnet in a box is a private testnet
383 2013-09-22 20:17:13 <warren> make it long enough and reorg the entire testnet!
384 2013-09-22 20:17:23 <nkuttler> Bkil: yeah, i know, i just have to build my own for altcoins.. </ot>
385 2013-09-22 20:17:38 <gmaxwell> man, you don't want to know how I misread " Coinkite " :(
386 2013-09-22 20:18:06 <Luke-Jr> gmaxwell: then don't tell us! :P
387 2013-09-22 20:18:07 <petertodd> gmaxwell: cronkite <- yeah that's pretty bad
388 2013-09-22 20:18:09 <jgarzik> So for those purposes, any mtgoxusd value is useful, as movements are not necessarily correlated to btc movement ;p
389 2013-09-22 20:18:37 <Bkil> I tried to use it today,  but using a .3 M hash a second CPU makes it slow
390 2013-09-22 20:18:42 <michagogo> [23:17:04] <warren> make it long enough and reorg the entire testnet!
391 2013-09-22 20:18:42 <michagogo> If it weren't for the fact that best chain is set by the amount of work and not purely the number of blocks, that would be much easier on testnet than on mainnet
392 2013-09-22 20:18:50 <Luke-Jr> Bkil: so get a decent CPU
393 2013-09-22 20:19:02 <Luke-Jr> Bkil: or one of those cheap Bitfountain miners
394 2013-09-22 20:19:09 <gmaxwell> michagogo: number of blocks would be trivially insecure! :)
395 2013-09-22 20:19:10 <michagogo> (because of testnet's 20 minute rule)
396 2013-09-22 20:19:20 <michagogo> gmaxwell: Right, of course
397 2013-09-22 20:19:41 <Bkil> Free computer at work, laptop at home is much better but I didn't bring it today
398 2013-09-22 20:19:45 <Luke-Jr> value testnet blocks by time (inverse) rather than work..
399 2013-09-22 20:19:48 <michagogo> But it's really easy to mine a few testnet blocks at any time, no matter what difficulty is at, if you need to
400 2013-09-22 20:20:01 <Luke-Jr> Bkil: so stop doing non-work stuff at work
401 2013-09-22 20:20:07 <michagogo> Just set your clock forwards 20 minutes
402 2013-09-22 20:20:33 <gmaxwell> michagogo: a few... I wish there were some charts of testnet hashrate based on testnet timestamps, they'd be halarious.
403 2013-09-22 20:20:35 <michagogo> That works for up to 6 consecutive blocks by you
404 2013-09-22 20:20:51 <michagogo> gmaxwell: 6 in a row, to be precise
405 2013-09-22 20:21:00 <Bkil> Yeah, was thinking of getting a cheap usb miner for testnet. But that then makes it harder for others to use
406 2013-09-22 20:21:06 <gmaxwell> michagogo: more if you cut the chain back and mine ahead.
407 2013-09-22 20:21:17 <michagogo> cut the chain back and mine ahead?
408 2013-09-22 20:21:33 <gmaxwell> michagogo: if the prior blocks were also 20m blocks you can replace them.
409 2013-09-22 20:21:51 <michagogo> Meh -- more work involved there :-P
410 2013-09-22 20:22:04 <gmaxwell> not much, like one line of code change and a reindex. :P
411 2013-09-22 20:22:12 <michagogo> Right
412 2013-09-22 20:22:22 <gmaxwell> michagogo: I replaced most of testnet3 at one point.
413 2013-09-22 20:22:24 <Bkil> Luke-Jr: basically nothing happened today, the joy of working a small ISP Support
414 2013-09-22 20:22:24 <michagogo> My way doesn't require any code change at all
415 2013-09-22 20:22:38 <Luke-Jr> petertodd: git finds no signatures..
416 2013-09-22 20:22:47 <sipa> blacklustblock RPC FTW
417 2013-09-22 20:22:55 <Luke-Jr> petertodd: nm, logging master helps
418 2013-09-22 20:22:55 <sipa> blacklist
419 2013-09-22 20:23:00 <gmaxwell> "blocklust"
420 2013-09-22 20:23:03 <petertodd> Luke-Jr: heh
421 2013-09-22 20:25:25 <Luke-Jr> petertodd: now that I know it won't pollute git log with ASCII armor, I might sign mine XD
422 2013-09-22 20:25:49 <petertodd> Luke-Jr: ha, yeah it's nice and easy. merges work too: git merge -S
423 2013-09-22 20:26:20 <sipa> the question is: what is the signature intended to sign?
424 2013-09-22 20:26:32 <sipa> technically,.it sigms.tje.entore histpry
425 2013-09-22 20:26:42 <michagogo> o_O
426 2013-09-22 20:26:44 <sipa> grr,.3.2" keybords
427 2013-09-22 20:26:53 <michagogo> 
ACTION gives sipa a bottle of cat remover

428 2013-09-22 20:26:57 <petertodd> sipa: The commit of course. Sure it signs prior ones, but you know at minimum the person intended to sign the one commit.
429 2013-09-22 20:27:20 <sipa> petertodd: right, that is what i mean
430 2013-09-22 20:27:57 <sipa> the intended meaning is likely the patch effectuated by that code on the source
431 2013-09-22 20:28:02 <michagogo> One of these days I should try to work out what the hell I have lingering on my system that's making it impossible for me to get a gpg up and running
432 2013-09-22 20:28:16 <petertodd> sipa: The more important thing is to have a culture where master will always consist of git signed commits/merges so end-users can assume that if they don't see such a commit github is playing games...
433 2013-09-22 20:28:33 <sipa> right
434 2013-09-22 20:28:37 <petertodd> michagogo: The NSA on the other hand would rather you don't know...
435 2013-09-22 20:28:47 <michagogo> lol
436 2013-09-22 20:29:03 <michagogo> Does github show when commits are signed?
437 2013-09-22 20:29:09 <sipa> the problem is that the merge.commits.created by.github aren't signed
438 2013-09-22 20:29:12 <petertodd> sipa: Yeah, main problem is github integration: you'd have to git pull your merge and then do git commit --amend -S and finally git push -f Kinda ugly.
439 2013-09-22 20:29:26 <petertodd> michagogo: No, and it'd be misleading if it did.
440 2013-09-22 20:29:30 <michagogo> (and, will a signed commit on a fork stay signed when pulled?)
441 2013-09-22 20:29:38 <sipa> yes
442 2013-09-22 20:30:07 <michagogo> Anyway, it's 23:30, and I might need to wake up earlyish
443 2013-09-22 20:30:11 <gmaxwell> petertodd: yea, it's kinda lame that github's conflict resolution is much more powerful than anything in git itself.
444 2013-09-22 20:30:21 <Luke-Jr> gmaxwell: it is?
445 2013-09-22 20:30:24 <michagogo> I'll still have irccloud in here and possibly pop in, but...
446 2013-09-22 20:30:26 <michagogo> goodnight
447 2013-09-22 20:30:41 <Luke-Jr> 
ACTION has never seen GitHub resolve a conflict that git couldn't O.o

448 2013-09-22 20:30:48 <sipa> same
449 2013-09-22 20:30:49 <gmaxwell> Luke-Jr: yes. At least thats my expirence. It will happily merge stuff that git's three way just throws its arms up for me.
450 2013-09-22 20:30:57 <sipa> hmm
451 2013-09-22 20:31:24 <petertodd> gmaxwell: Oh, it just calls Amazon Mechanical Turk on the backend when git's merge fails.
452 2013-09-22 20:31:30 <gmaxwell> hahaha
453 2013-09-22 20:32:18 <Luke-Jr> my bitcoind .git is 305 MB :o
454 2013-09-22 20:32:21 <Luke-Jr> after gc
455 2013-09-22 20:34:04 <sipa> 76 here
456 2013-09-22 20:37:06 <petertodd> sipa: speaking of signing, you still need to make a PGP signed message for your part in the coinjoin fund
457 2013-09-22 20:37:23 <sipa> right!
458 2013-09-22 20:37:34 <petertodd> sipa: and sign my key
459 2013-09-22 20:38:05 <sipa> not ho
460 2013-09-22 20:38:06 <Luke-Jr> lol
461 2013-09-22 20:38:18 <sipa> not home right now
462 2013-09-22 20:38:30 <sipa> i'll be back on wednesday
463 2013-09-22 20:38:33 <petertodd> sipa: too bad, so you are a ho then?
464 2013-09-22 20:39:43 <sipa> 
ACTION recently learnt that americans pronounce "hoegaarden" as "ho garden"

465 2013-09-22 20:39:56 <petertodd> ha, yeah...
466 2013-09-22 20:40:18 <petertodd> but we like to say things the way we want them to be
467 2013-09-22 20:40:30 <Luke-Jr> 
ACTION interpreted it as "not happening online" :P

468 2013-09-22 20:40:38 <sipa> (it's much closer to "who harden", in dutch")
469 2013-09-22 20:40:50 <petertodd> Luke-Jr: what are you, a Catholic?
470 2013-09-22 20:40:57 <Luke-Jr> petertodd: huh?
471 2013-09-22 20:41:17 <petertodd> Luke-Jr: You're obviously of a clean mind. :)
472 2013-09-22 20:41:53 <Luke-Jr> :p
473 2013-09-22 21:16:39 <warren> wumpus: I'll propose the standard win32 gitian to be amd64-hosted, it is likely to be faster than i386 hosted, and can be reused for win64 builds
474 2013-09-22 21:18:56 <michagogo> cloud|Are there CPUs that do hardware-assisted virtualization but not 64-bit?
475 2013-09-22 21:19:07 <warren> michagogo|cloud: very very  rare
476 2013-09-22 21:19:11 <warren> michagogo|cloud: and screw them
477 2013-09-22 21:19:19 <Luke-Jr> they exist? :o
478 2013-09-22 21:19:22 <warren> es
479 2013-09-22 21:19:23 <warren> yes
480 2013-09-22 21:19:29 <Luke-Jr> 64-bit was like 3 years before hw virt XD
481 2013-09-22 21:19:55 <michagogo> cloud|Also: what about people who have 32-bit installed?
482 2013-09-22 21:20:15 <warren> michagogo|cloud: too bad, I think
483 2013-09-22 21:20:27 <michagogo> cloud|Hmm...
484 2013-09-22 21:20:28 <warren> michagogo|cloud: htey already can't do gitian linux64
485 2013-09-22 21:20:34 <warren> so they aren't that useful
486 2013-09-22 21:20:42 <gmaxwell> ... why not?
487 2013-09-22 21:21:01 <gmaxwell> I've cross compiled to x86_64 from i386 before.
488 2013-09-22 21:21:03 <warren> does debootstrap run any of the payload when it installs the chroot?
489 2013-09-22 21:21:10 <michagogo> cloud|warren: they could be if 32 and 64 were split into 2 descriptors
490 2013-09-22 21:21:11 <warren> gmaxwell: he's complaining about the opposite
491 2013-09-22 21:21:29 <gmaxwell> I was responding to "htey already can't do gitian linux64"
492 2013-09-22 21:21:46 <michagogo> cloud|warren: Wait, what?
493 2013-09-22 21:21:49 <warren> gmaxwell: 32bit kernel host
494 2013-09-22 21:21:55 <gmaxwell> warren: so?
495 2013-09-22 21:22:09 <warren> michagogo|cloud: maybe I misunderstood you, but you are asking about things that are not important.
496 2013-09-22 21:22:21 <michagogo> cloud|I'm saying, "what about people who have a 32-bit OS installed?
497 2013-09-22 21:22:29 <Luke-Jr> 32-bit userspace can run 64-bit KVM target just fine with hw accel
498 2013-09-22 21:22:36 <michagogo> cloud|Oh
499 2013-09-22 21:22:39 <michagogo> cloud|Really?
500 2013-09-22 21:22:42 <gmaxwell> warren: at least in theory you should be able to compile the 64 bit binaries from i386.
501 2013-09-22 21:22:45 <warren> Luke-Jr: only if the host kernel is 64bit
502 2013-09-22 21:22:47 <Luke-Jr> just need a 64-bit kernel
503 2013-09-22 21:22:51 <Luke-Jr> which you should have anyway
504 2013-09-22 21:23:02 <warren> what distro ships that way?
505 2013-09-22 21:23:10 <Luke-Jr> warren: what distro doesn't? :p
506 2013-09-22 21:23:11 <gmaxwell> michagogo|cloud: but I don't think we give a crap about 32 bit hosts running gitian in any case.
507 2013-09-22 21:23:15 <warren> Luke-Jr: x86-64 doesn't benefit as much from 32bit userspace like older archs
508 2013-09-22 21:23:18 <gmaxwell> warren: fedora, for example.
509 2013-09-22 21:23:25 <warren> gmaxwell: eh?
510 2013-09-22 21:23:34 <Luke-Jr> warren: on the contrary, 32-bit userspace is preferable IMO
511 2013-09-22 21:23:40 <michagogo> cloud|Do any Linux distorts ship 64-bit kernel and 32-bit userland?
512 2013-09-22 21:23:44 <warren> gmaxwell: the multiarch userspace on x86-64 fedora is incomplete
513 2013-09-22 21:23:51 <warren> gmaxwell: only enough to build stuff against
514 2013-09-22 21:23:52 <michagogo> cloud|(-autocowrecks)
515 2013-09-22 21:23:54 <gmaxwell> wtf are you talking about?
516 2013-09-22 21:24:02 <gmaxwell> warren: IIRC i686 fedora uses an x86_64 kernel since F17
517 2013-09-22 21:24:03 <Luke-Jr> michagogo|cloud: yes
518 2013-09-22 21:24:21 <michagogo> cloud|Which?
519 2013-09-22 21:24:26 <Luke-Jr> michagogo|cloud: Debian does, Gentoo supports it (all kernels are manually compiled on Gentoo)
520 2013-09-22 21:24:30 <Luke-Jr> apparently Fedora too
521 2013-09-22 21:24:30 <warren> gmaxwell: ok... I totally wasn't aware of that.  I guess it picks the correct kernel during install?
522 2013-09-22 21:25:05 <gmaxwell> warren: /me checking to see if they actually made the change (I argued against it)
523 2013-09-22 21:25:20 <michagogo> cloud|Am I thinking about something else, or did gitian-builder recommend Ununtu?
524 2013-09-22 21:25:24 <michagogo> cloud|Unintu*
525 2013-09-22 21:25:27 <michagogo> cloud|Bah
526 2013-09-22 21:25:34 <warren> gmaxwell: I did a fedora 19 32bit install recently and got a i686 kernel
527 2013-09-22 21:25:38 <Luke-Jr> michagogo|cloud: Ubuntu is just a Debian knockoff anyway
528 2013-09-22 21:25:50 <michagogo> cloud|;;google site:github.com inurl:gitian-builder
529 2013-09-22 21:25:51 <gribble> devrandom/gitian-builder · GitHub: <https://github.com/devrandom/gitian-builder>; devrandom/gitian-builder - GitHub: <https://github.com/devrandom/gitian-builder/pull/27>; freicoin/contrib/vagrant/patch/gitian-builder-69bd6a53.patch at ...: <https://github.com/freicoin/freicoin/blob/master/contrib/vagrant/patch/gitian-builder-69bd6a53.patch>
530 2013-09-22 21:26:05 <warren> michagogo|cloud: works with anything that has dpkg, debootstrap, apt-cacher-ng, etc.
531 2013-09-22 21:26:09 <warren> michagogo|cloud: ported to Fedora and Gentoo
532 2013-09-22 21:27:00 <warren> Luke-Jr: I vaguely recall us doing benchmarks of <various things> with x86-64 kernel with 32bit vs 64bit userspace and performance wasn't better with 32bit userspace, maybe a little memory savings.
533 2013-09-22 21:27:41 <gavinandresen> jgarzik: Spinal Tap is a great movie, but not my favorite. michagogo : I told you why 'weight 11' -- because eleven is my favorite number.
534 2013-09-22 21:27:41 <sipa> warren: try bitcoin signature verification on 32 and 64 bit :)
535 2013-09-22 21:27:42 <Luke-Jr> warren: performance isn't better, correct
536 2013-09-22 21:27:57 <Luke-Jr> warren: pointers use up half the memory though
537 2013-09-22 21:28:10 <warren> Luke-Jr: in bitcoin?
538 2013-09-22 21:28:14 <Luke-Jr> in 32-bit
539 2013-09-22 21:28:35 <gavinandresen> all: RE: gitian signature weights, real identities, etc-- go nuts painting that shed.  I don't care.
540 2013-09-22 21:28:35 <Luke-Jr> for performance, you need to distinguish between i386, i686, and x32
541 2013-09-22 21:28:39 <warren> 
ACTION still hasn't figured out why bitcoind uses like 100-200MB more RAM on fedora than ubuntu.

542 2013-09-22 21:29:08 <Luke-Jr> sipa: does libsecpwhatever support x32 properly? :P
543 2013-09-22 21:29:14 <gmaxwell> warren: please stop saying that!
544 2013-09-22 21:29:22 <warren> gmaxwell: it's true
545 2013-09-22 21:29:39 <gmaxwell> warren:  1679 gmaxwell  20   0 1828888 192456   6020 S   1.3  2.4  16:16.15 bitcoind
546 2013-09-22 21:29:44 <gmaxwell> IT IS NOT TRUE.
547 2013-09-22 21:30:06 <warren> huh
548 2013-09-22 21:30:14 <warren> bitcoind never uses anywhere near that amount of RAM here
549 2013-09-22 21:30:22 <warren> it's like 400-500MB here
550 2013-09-22 21:30:31 <Luke-Jr> bitcoind or litecoind?
551 2013-09-22 21:30:33 <warren> gmaxwell: is that a local build or gitian?
552 2013-09-22 21:30:36 <warren> Luke-Jr: both
553 2013-09-22 21:30:37 <gmaxwell> the gitian static builds use more. The specification matters. I watched someone tell someone else not to run bitcoin on fedora the other day on the basis of your comments!
554 2013-09-22 21:30:56 <bizoro> lol
555 2013-09-22 21:31:07 <michagogo> cloud|gavinandresen: Is there an actual reason to put it at 11, besides personal preference? :-P
556 2013-09-22 21:31:20 <gavinandresen> michagogo|cloud: "feels about right" ???
557 2013-09-22 21:31:26 <Luke-Jr> if only we had someone willing to maintain a Fedora repo for native bitcoind/-qt builds :P
558 2013-09-22 21:31:37 <gmaxwell> It's something thats a side effect of the gitian process, I'd guess some bug in bdb or boost thats patched in fedora triggering libc or pthreads misbehavior that only exists in fedora.
559 2013-09-22 21:31:55 <gmaxwell> Luke-Jr: Not really viable so long as it requires patching openssl.
560 2013-09-22 21:32:01 <Luke-Jr> michagogo|cloud: I think Gavin is trying to convey "it's not that important" :p
561 2013-09-22 21:32:04 <gmaxwell> Luke-Jr: Otherwise I'd be doing it.
562 2013-09-22 21:32:05 <warren> Luke-Jr: none of us is willing to maintain a repo with the requisite openssl, and secp256k1 to replace it isn't ready
563 2013-09-22 21:32:12 <Luke-Jr> gmaxwell: can't static link just the EC?
564 2013-09-22 21:32:33 <gribble> Skinnkavaj was last seen in #bitcoin-dev 1 week, 4 days, 23 hours, 41 minutes, and 30 seconds ago: <skinnkavaj> gmaxwell: ihas NSA planted a backdoor in SHA256?
565 2013-09-22 21:32:33 <rdymac> !seen Skinnkavaj
566 2013-09-22 21:32:42 <warren> Luke-Jr: I made such a stripped down EC-only lib before but then secp256k1 happened
567 2013-09-22 21:32:43 <michagogo> cloud|gavinandresen: Idk -- it's an interesting question. petertodd does have a good point, in that there's not a lot of me all over the Internet
568 2013-09-22 21:32:50 <gmaxwell> Luke-Jr: could statically link openssl, but thats pretty ugly.
569 2013-09-22 21:33:47 <Luke-Jr> would Fedora make a patch that adds EC back in minus only the actually-patented stuff? <.<
570 2013-09-22 21:33:49 <Luke-Jr> take*
571 2013-09-22 21:33:58 <gmaxwell> warren: incidentally, I'm incorrect, looks like Fedora dropped the move to x86_64 kernels on i585 during a beta. https://fedoraproject.org/w/index.php?title=Features/ArchitectureSupport&oldid=82905
572 2013-09-22 21:34:20 <warren> ok