Bitcoin dev IRC log dumps

fi6?
22:45 < warren> jgarzik: if you aren't near one of the consulates there are some companies that will charge you money to do it...
22:47 < HM3> gmaxwell, the schnorr construction is just cleaner algebraically, and I like that you can't do public key recovery
22:48 < gmaxwell> ::shrugs:: Not really more than anything else that does the same thing, and its compatible.
22:48 < gmaxwell> HM3: yea, sure, I like schnorr too, but randomness isn't an argument for it.
22:49 < HM3> the lack of a need for a perfect RNG during signing is
22:50 < gmaxwell> HM3: DSA and Schnorr are the same in that regard. You derandomize them both under the same method
22:50 < HM3> sure but schnorr requires that construction to work
22:51 < gmaxwell> HM3: no they don't, go look at the schnorr patent. It's described using a random k.
22:52 < HM3> no I mean Schnorr is H(m||rG) and during verification you have to compute the candidate rG and recalculate H(m||rG)
22:52 < warren> "go look at the * patent" told to another engineer is wise?
22:53 < HM3> in DSA you just check, if i remember correctly, that sG is correct
22:53 < gmaxwell> warren: it's expired. Also, you need to go turn in your JD if you think it's not, see in re seagate. :)
22:54 < gmaxwell> (otherwise my response would have been "forget about it, it's patented")
22:55 < HM3> anyway. keeping DSA has no more merit than replacing it if you you plan on breaking compatibility anyway. but it's a fair point that you can derandomize DSA if you don't
22:55 < jgarzik> warren, yep, like Travisa ;p
22:55 < jgarzik> warren, communist state was never destined to make life easy and efficient
22:55 < warren> jgarzik: oh, they do F visas?  didn't see that option
22:56 < warren> jgarzik: I like how easy and efficient things are here.
22:57 < gmaxwell> HM3: hm, why do you say that recovery isn't possible in Schnorr? I believe it is, in fact.
22:57 < HM3> doubtful
22:58 < HM3> sipa agreed with me months ago when i asked him as well :P
22:58 < HM3> Appeal to authority! appeal to authority
22:59 < HM3> s = k - xe
22:59 < HM3> sG = kG - xeG
22:59 < HM3> you know eG and sG but not kG (which is r)
23:00 < HM3> and you know e = H(M||r)
23:00 < HM3> and obviously not xG (the key you're trying to recover)
23:01 < gmaxwell> HM3: You know r.
23:01 < HM3> nah, r isn't part of the sig
23:01 < gmaxwell> pray tell how you compute H(M||r) without it in the verifier?
23:02 < HM3> you calculate candidate r
23:02 < HM3> then compute H(M||r) and compare with e, which = H(M||r)
23:02 < warren> Don't worry, only *hard* math is patentable subject matter.  Not abstract ideas.
23:02 < HM3> I don't know why Wikipedia uses such silly letters
23:03 < HM3> r should be for the randomly selected number damnit
23:03 < gmaxwell> HM3: ah right, you recover r.
23:03 < HM3> gmaxwell, right, but you need the public key you're verifying against to do it
23:04 < HM3> in DSA you s = (1/k) * (H(M) + xr)
23:04 < HM3> and r = kG anyway
23:04 < gmaxwell> well thats a bummer then, minus one for Schnorr signatures. :P
23:04 < HM3> so it's fairly redundant
23:04 < HM3> gmaxwell, but DSA is broken if there's a collision on your hash function :P
23:06 < gmaxwell> so is schnorr, I take your signature and rebind it onto M' where H(M'||r) == H(M||r). :P
2b\f
T ]o
)yZ7
H!@jKu
23:06 < HM3> if you were stupid and used a raw SHA instead of HMAC, then trick you in to signing 2 length extended messages such that there was a collision,  I can work out your privy
23:06 < HM3> gmaxwell, yes but it wouldn't reveal the private key like DSA would
23:07 < HM3> even your derandomized DSA would if you used H(priv || H(M)) instead of H(priv || M) for the rerandomization bit
23:08 < gmaxwell> Fair enough. I'm not going to argue that you don't need to bother with the private key if you can just rebind, because, I realize that collisions in reality are never quite that freeform. :)
23:09 < HM3> nobody has broken anything decent collision wise yet anyway have they?
23:09 < warren> gmaxwell: thanks for in re seagate, not sure how I didn't see this before.
23:11 < gmaxwell> HM3: sure, md5, though not second-preimages on a arbritaryly selected input.
23:12 < gmaxwell> HM3: I'm busy chastizing myself because I'm usually irritated by people who refuse to distinguish theoretical security from pratical security, and I did almost make that counterargument to you in earnest.
23:13 < HM3> I saw that SHA-3 got knocked down a bit during recent standardisation
23:14 < gmaxwell> HM3: IIRC Schnorr also has nice threshold signatures, alas.
23:14 < HM3> they cut some bit lengths
x.LC
23:14 < gmaxwell> HM3: yea, they changed the input rate. Which was kinda surprising, because capacity was specifically cited as a reason to exclude cubehash from the final round.
23:15 < HM3> did they give a reason?
23:15 < gmaxwell> Sure, speed.
23:15 < HM3> Pish
23:15 < gmaxwell> Its not entirely unreasonable.
23:15 < gmaxwell> But I was surprised.
23:16 < gmaxwell> DJB did some saber rattling on the NIST list to adjust the capacity to a fixed 576 bits (so a constant 1024 bit input rate)
which is sort of a middle ground (more security for the orignal proposal at 256 bits output, less than the original proposal for 512 bit output). Doesn't sound like NIST or the Keccak team like the proposal. .. but NIST went quiet
with the government shutdown.
23:17 < gmaxwell> For small inputs (e.g. <1024 bits) it doesn't matter.
23:19 < HM3> maybe when they reopen they'll forget they made the change
23:19 < gmaxwell> it's kinda irritating that the NIST list is closed-access. I see that the wikipedia sha-3 article mentions this discussion but has no citation.
23:19 < gmaxwell> well the change apparently was proposed by the Keccak team, which is totally believable the original capacity was the minimum nist required.
23:19 < gmaxwell> DJB basically said FUCK YOU to that requirement and refused to meet it in his proposal, and... well. :P
lNeRC
&#'[_,
dN$I
5? q)fEs
23:20 < gmaxwell> the other hashes met the requirement but many of then whined.
23:20 < HM3> Good old DJB
23:20 < HM3> I find his written material very accessible
23:21 < gmaxwell> esp having 512 bits of preimage security for the 512 bit hash required >1024 bits of state (in addition to the update state) which was getting a bit burdensome.
23:22 < gmaxwell> the DJB proposed modification to sha3 would have the nice side effect of making it always process 1024 bits at a time, regardless of the output size.  On that basis I like it.
23:22 < HM3> and presumably that allows for optimisation
23:23 < gmaxwell> (currently it does something like 1344 bits at a time for 256 bit output, and 1088 bits at a time for 512 bit output)
23:23 < gmaxwell> well it simplifies implementations at least, might also make hardware versions that do both sizes easier.
23:24 < HM3> 1337 bits would have been better
23:24 < gmaxwell> I am imagining millions of duck sized engineers stabbing you in the foot.
23:26 < HM3> ah well, i must retire to bed
23:26 < HM3> i'll take that duck sized engineer thing with me
--- Log closed Tue Oct 15 00:00:11 2013
--- Log opened Tue Oct 15 00:00:11 2013
02:12 < warren> sipa: http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/2000/300/2318/2318.strip.gif
02:16 < sipa> let me guess
02:16 < sipa> yup :)
>39u
};j&
R.Dz
02:26 < warren> sipa: just as likely as my one time pad
05:36 < wumpus> https://github.com/bitcoin/bitcoin/issues/3090 CodeBug : should compare return value from memcmp with zero.
05:36 < wumpus> wrong channel
08:45 < HM3> since Bitcoin already uses boost you could use boost array instead of 'vch' in CKey
08:45 < HM3> would have got operator== for free
09:56 < petertodd> BlueMatt: from the point of view of a SPV node, verifying that a block header is correct is verifying it fully, so relaying that header (or even full block) to other SPV nodes does no harm.
09:57 < sipa> well, you would at least want to announce that you did not verify transactions in that case
09:57 < petertodd> BlueMatt: anyway, I put that in the BIP to show how NODE_BLOOM should be thought of "I'm willing to apply bloom filters to stuff I relay to you" and nothing more
09:57 < petertodd> sipa: which you do because you didn't set NODE_NETWORK (in that case)
09:58 < sipa> right, NODE_BLOOM is orthogonal to what you are relaying
09:58 < petertodd> sipa: exactly
09:59 < petertodd> You could (uselessly) say NODE_BLOOM and !NODE_* just means I'm willing to apply bloom filters to the nothingness I will relay to you; if you implement this I suggest you apply for an art grant.
09:59 < sipa> perhaps apply it to addr or alert messages :p
10:00 < petertodd> With an extended NODE_BLOOM definition that makes a lot of sense.
14:41 < gmaxwell> uh. Michael Gronager has ... um. not quite sure what to call it: https://bitcointalk.org/index.php?topic=310954
14:43 < petertodd> looks fixable to me, though ugly
14:44 < gmaxwell> yea, it's apparently already fixed.
14:45 < gmaxwell> 50% drop in namecoin exchange rate though.
14:45 < petertodd> good example of how blockchains can separate proof-of-data distribution, global consensus on ordering, and the actual rules themselves...
14:45 < petertodd> ha, yeah, I should have quickly bought some at the low point :P
15:07 < warren> amusing to see the deniers in the thread
15:10 < amiller> does anyone know who first created namecoin
15:10 < sipa> vinced?
15:15 < K1773R> gmaxwell: (namecoin) holy, thats horrible... i wonder why nobody looked at it :S
15:16 < sipa> i suppose because nobody competent cared? *ducks*
15:16 < amiller> but no one has heard from vinced in a long time?
15:17 < petertodd> K1773R: namecoin isn't getting used for anything yet; it just hasn't caught on
15:17 < petertodd> K1773R: well, other than speculators...
15:18 < K1773R> petertodd: i used it as backup solution for important stuff
15:18 < sipa> eh?
15:18 < petertodd> K1773R: backup? how so?
15:18 < K1773R> your aware its just a simple key/value storage?
15:19 < sipa> yes
15:19 < sipa> but there are certainly easier ways
1N[dA