--- Log opened Tue Jul 09 00:00:22 2013
10:48 < petertodd> gmaxwell, amiller: powers back - Toronto just broke the record for most rain in a single day in history, 126mm, vs. the previous of 121mm during hurricane hazel in the 50's... the creek behind my apartment rose about 15ft, although fortunately the engineering is pretty good and houses are set back enough that other than a flooded school it was just some basements here and there flooded.
10:53 < amiller> ahh... hopefully your basement wasn't affected!
10:53 < amiller> according to my logs you did not miss any conversation :)
10:54 < petertodd> I'm on the twelfth floor :)
10:54 < petertodd> thought my legs are killing me... the backup power for the elevators and lights died, and I spent a few hours helping people up to their apartments who didn't have lights...
11:16 < gmaxwell> 'here is a flashlight, drop it down the garbage chute when you make it'
12:38 < petertodd> gmaxwell: clever
15:08 < gmaxwell> petertodd: have you pondered the implications of replacing chaum tokens in a chaumian bank with zerocoin?  I think it lets you make the signing oracle memoryless (well, enough to verify ZC proofs).
15:09 < petertodd> gmaxwell: That's a good idea actually
15:10 < petertodd> gmaxwell: Although right now I'm convinced the right way to go is with a proof-of-sacrifice blockchain.
15:10 < gmaxwell> Further reducing the scale of the part that has to be trustworthy and resistant to regulator weirdness.  Also, if we had a more scalable group signature scheme, the bank could be pretty massively distributed.
15:11 < petertodd> gmaxwell: Auditing the signing oracle would be really easy too.
15:12 < petertodd> gmaxwell: Oh hang on though, you still need consensus about the state of the zerocoin accumulator, so it's not memoryless
15:12 < gmaxwell> petertodd: no you don't.
15:12 < petertodd> How does that work?
15:12 < gmaxwell> it signs the last proof it saw.
15:13 < gmaxwell> and then you just present that proof with your next update.
15:13 < gmaxwell> same way a storageless full miner could still add transactions with the help of a client that has the utxo.
15:13 < petertodd> Yes, but it needs to know the height of the last proof signed. That's not totally memoryless
15:14 < gmaxwell> Fair point. In the case where its not distributed it still reduces it to a counter.
15:14  * jgarzik listens -- this might have application on my idea for a network of bots that enable off-chain transactions, with some level of prove-they-are-not-cheating
15:14 < petertodd> A chaumian bank could just as easily encrypt it's database and give that to the client in the same way.
15:14 < gmaxwell> petertodd: true but you'd have to transfer the whole thing each time.
15:15 < petertodd> But you still have to transfer the list of spent tokens with zerocoin
15:16 < gmaxwell> oh darn, right the accumulator update proof still requires you to have the accumultor.
15:16 < petertodd> Yup
15:16 < petertodd> in zerocoin the accumulator size doesn't grow IIRC, but the spent tokens do
15:17 < petertodd> also if I understand it with zerocoin the witness required to prove a coin is actually related to the accumulator at a given state - if you want to apply the witness to the most recent accumulator you need to apply every transaction to that witness
16:28 < gmaxwell> hey. So. Lamport signature.  Say your private key is 16384 256 bit values. The public key is hash tree root over 16384 256 bit hashes of those values.
16:30 < gmaxwell> To sign, you hash the message and the public key. And you use the results to uniformly pick 9 of the 16384 secrets to reveal.
16:30 < gmaxwell> You reveal hem along with the fragments that connect them to the root.
16:31 < gmaxwell> so the signature size is 4.3kbytes or so. Why is this not secure?
16:38 < sipa> is there any reason to assume it's not secure?
16:38 < gmaxwell> I mean, I'm suggesting a variation on lamport which is smaller and which should be more secure under multiple signatures with the same key.
16:40 < gmaxwell> Classical lamport with a tree public key has the signature disclose 256 preimages and 256 hash secrets. I propose instead to disclose only a few, controlled by the hash of the key and the message. And prove that they're the right ones by showing that they're part of the key's hashtree.
16:57 < gmaxwell> ah. okay so that proposal has only 64 bits of security against a rebinding attack by a quantum attacker.
--- Log closed Wed Jul 10 00:00:25 2013