From rusty at rustcorp.com.au Fri Aug 12 03:24:52 2016 From: rusty at rustcorp.com.au (Rusty Russell) Date: Fri, 12 Aug 2016 12:54:52 +0930 Subject: [Lightning-dev] Blinded channel observation In-Reply-To: <20160811074926.GA9007@lightning.network> References: <87a8gmpkde.fsf@rustcorp.com.au> <20160809192814.GA22477@lightning.network> <877fbpps8s.fsf@rustcorp.com.au> <20160809222938.GA25606@lightning.network> <87oa50oqkp.fsf@rustcorp.com.au> <87inv8nk6f.fsf@rustcorp.com.au> <20160811074926.GA9007@lightning.network> Message-ID: <87eg5uoeij.fsf@rustcorp.com.au> Joseph Poon writes: > On Thu, Aug 11, 2016 at 11:25:36AM +0930, Rusty Russell wrote: >> Tadge Dryja writes: >> > The method of using a revocation key is compatible with shachain/elkrem so >> > has log(n) storage; I'll describe what I developed which omits hashing in >> > the commit script and uses only signature verification. If Laolu has made >> > a different key revocation scheme I'm not aware, but please do post if so. >> >> Oh, I blamed Laolu because he told me about it; sorry for misattribution. > > I came up with it a long time ago, and worked out the > details/optimizations /w Laolu more recently (I think he told you that > night when everything was finalized). I mentioned the general > construction to you a LONG time ago too when you were in the Bay Area, > but I probably didn't explain it properly (I was comparing with > Vanitygen, if that helps). I think Tadge was the first to implement it > though, not sure. > >> The property I was *hoping* for was the ability for Alice (and Bob) to >> independently predict each others' future revocation hashes/pubkeys. >> That would neatly allow an arbitrary number of commitment transactions >> in flight each way at once. Naively, seems like that should be >> possible. > > I'm not inclined to think an increase in complexity is helpful (if this > is necessary), but there are probably some things you can do if you're > looking down these paths. > > It's possible to get the same *bandwidth* optimization you want, except > opposite. The idea with "predicting the future revocation > hashes/pubkeys" is you only need to send revocations. Instead, it's > possible to only send revocation hashes/pubkeys and not send > revocations. In other words, instead of predicting each others' future > revocation hashes/pubkeys, it's possible to revoke as *part of* giving > the next revocation hash/pubkey. Yeah, I do that already. We give the N+1th hash when we send the revocation for N: // Complete the update. message update_revocation { // Hash preimage which revokes old commitment tx. required sha256_hash revocation_preimage = 1; // Revocation hash for my next commit transaction required sha256_hash next_revocation_hash = 2; } The trivial extension is to make in the N+Mth revocation hash, and instead of sending the first two revocation hashes on establishment, send the first M+1. I just wanted to make sure there wasn't some clever alternative I was missing. Greg Maxwell and Pieter Wuille tell me there isn't an obvious one. > Not sure how useful this is, though. Seems a lot of complexity for some > small bandwidth savings, not really that interested in doing all that, > but it's the closest I can get to what you want. This is off the top of > my head/memory, I didn't write any notes on this, so parts of this (or > entirety) might be wrong... Yeah, agreed. Hash trees are nice and simple, so unless we get a signficiant win, let's stick with that? Cheers, Rusty.