--- Log opened Sat Aug 24 00:00:36 2013
19:48 < gmaxwell> oh.. forum, you amuse me so.
19:49 < gmaxwell> "These are computer scientists with the desire, knowledge and expertise to create bitcoin. [...] They have access and knowledge of LaTeX [...] LaTeX was used to publish the bitcoin white paper"
19:49 < gmaxwell> Access and knoweldge of LaTeX!
19:49 < Luke-Jr> lololol
19:49  * gmaxwell imagines that in court. ... "BUT! you had knoweldge of LaTeX! didn't you!?!"
19:50 < gmaxwell> of course, you'd have to be absent of knoweldge of LaTeX to think the bitcoin whitepaper was typeset in it.
19:51 < Luke-Jr> I am absent knowledge of LaTeX!
19:54 < gmaxwell> it's just a full just openoffice document. There are a bunch of indicators. Including the fact that not every third line is hyphenated. (TeX is way to jumpy with the hyphens, unless you go and modify the weights in the justification search)
21:32 < gmaxwell> Anyone see a merkle signature scheme where a CSPRNG with a matching tree structure was used to generate the private keys instead of a straight random access CSPRNG?
21:32 < midnightmagic> gmaxwell: do you get the feeling it's "over" for the bitcoin devs? There's a half-mil in funding, that's like..   ten guys for a year man!
21:32 < gmaxwell> midnightmagic: hah.
21:33 < midnightmagic> TEN GUYS IS MORE THAN ..  uh..  SEVEN!
21:34 < gmaxwell> The reason I ask about tree strcutured CSPRNG, consider how you can compress a lamport signature when there is a dyadic partitioning with all 0's or all 1s... you can avoid revealing the indivigual 1s or 0s preimage and just reveal a hash branch up. But you still have to reveal the indivigual private keys.
21:34 < gmaxwell> But if the private keys are tree structured, you could instead reveal a private key root to reveal all the child private keys.
21:35 < gmaxwell> this doubles the compression that prior compression scheme gives.
21:36 < gmaxwell> midnightmagic: did you see the thread, "oh that was just a placeholder" ... sheesh.
21:36 < gmaxwell> So much for opensourcing their code... who's going to bother auditing it if their respond is to claim that every flaw is a placeholder.
21:38 < gmaxwell> midnightmagic: They say that the effectiveness of competent software developers has a range over more than 10:1. (e.g. you have some guys who are 10x more valuable than some others).
21:38 < gmaxwell> I can only imagine that the range of people working on this stuff is greater.
21:39 < gmaxwell> I am not the smartest, or most productive man.  ... But I turned their POW into quivering jelly with little more than a glance. I'd hate to see what someone really good at this stuff would do to their codebase (er, or bitcoinds... !)
22:11 < amiller> gmaxwell, yeah that kind of hash signature is worked on
22:11 < amiller> there's this confusing paper http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.6964&rep=rep1&type=pdf Optimal Tree-based One-time Digital Signatures Schemes
22:43 < gmaxwell> hahah. see, this is why I don't publish anything in this space. It's a simple idea, and not hard to work out the expected sizes, I couldn't bring myself to obfuscate it so much.
22:55 < gmaxwell> amiller: know of anyone writing on tree signature schemes where the prior distribution of number of items signed is not uniform?  E.g. few-time use is more likely, so you construct an unbalanced tree so that the public keys are shorter if you only sign a few times? :)
22:57 < amiller> hm, actually no i've not heard of that
22:57 < amiller> cool idea
22:58 < amiller> i know someone trying to work on a stateless multi-signature one
22:59 < gmaxwell> yea, for bitcoin we'd want a tree with probablities like 0.5 {0.5 {{}{}}} or something. super cheap for one time use, still cheap for two time use, and then uniform probablity (log n()) after that. But whatever, the shape of the tree is the huffman coding problem, so any dyadic probabilities you can express can get a tree.
--- Log closed Sun Aug 25 00:00:38 2013