From tadge at lightning.network Thu Aug 11 03:12:59 2016 From: tadge at lightning.network (Tadge Dryja) Date: Wed, 10 Aug 2016 23:12:59 -0400 Subject: [Lightning-dev] Blinded channel observation In-Reply-To: <87inv8nk6f.fsf@rustcorp.com.au> 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> Message-ID: Hi, this is very interesting idea that I hadn't thought of! > Oh, I blamed Laolu because he told me about it; sorry for misattribution. Heh not at all, I don't know who's coming up with what either. > > To build the revocable pubkey, Alice takes their elkrem sender hash from > > state n, which we'll call EHn. Alice multiples EHn * G, getting a point > > EPn. (Elkrem point n) Alice sends EPn to Bob, who adds their commitment > > pubkey (BP, which is never seen raw) to EPn. > > "never seen raw on-chain" I assume, since Bob will send it to Alice in > setup? Right; Alice and Bob share these base points when they're funding the channel but if never shows up on-chain. > So, AFACIT this scheme gives us a slightly smaller script and makes > previous commit transactions underivable. > > 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. > That... is a very cool idea which I had not considered. Sketching it out, it seems like you'd need some kind of bi-directional trap door function. RSA comes to mind where repeated exponentiation to the e can be reversed by exponentiation to the d. But in RSA "private keys" (d) and "public keys" (e) are the same thing (scalars) but here they're different. My gut feeling is that with secp256k1 it's not possible though. Setting up a homomorphic relationship such that Pubkey0 lets you compute Pubkey1 seems like it would also allow you to compute from Scalar0 to Scalar1 -- just perform whatever additions and multiplications you did to the point on the scalar. Definitely something to think about though, because it'd be very cool. (In practice it doesn't really affect storage, and reduces data on the wire a somewhat, so not a huge difference scalability-wise, but still would be really cool if possible) > I think changing the timeout key is harmless, but gratuitous; changing > the revocation key is sufficient for each commitment script unguessably > different from the last one, no? Yeah, I didn't alter the timeout key initially, but I put it in because it helps keep the channel private from the observer in the case where you just send them signatures. If the timeout key is unchanging, they'd see it when the channel close un-cooperatively and recognize the channel they were monitoring. For privacy, the points you add to the timeout key and revocable key also need to be *different* points. If you add the same point to both, an observer who knows the base points can try subtracting the timeout and revocable base points from the observed pubkeys. If the result for both is the same, they'll know they've found the channel they're looking for. Thanks for the new idea to stew over on the train! -Tadge -------------- next part -------------- An HTML attachment was scrubbed... URL: