From rusty at rustcorp.com.au Thu Aug 11 01:55:36 2016 From: rusty at rustcorp.com.au (Rusty Russell) Date: Thu, 11 Aug 2016 11:25:36 +0930 Subject: [Lightning-dev] Blinded channel observation In-Reply-To: References: <87a8gmpkde.fsf@rustcorp.com.au> <20160809192814.GA22477@lightning.network> <877fbpps8s.fsf@rustcorp.com.au> <20160809222938.GA25606@lightning.network> <87oa50oqkp.fsf@rustcorp.com.au> Message-ID: <87inv8nk6f.fsf@rustcorp.com.au> 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. > The script is: > > DUP > [Revocable Pubkey] > CHECKSIG > NOTIF > [Timeout Pubkey] > CHECKSIGVERIFY > [timeout period] > CHECKSEQUENCEVERIFY > ENDIF OK, so far so good. > 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? > The result, (RPub n = BP + EPn), is the revocable pubkey for state n. > At state n+1, Alice sends Bob EHn. Bob can then compute the private > key for Rpub n, as it's just their commitment private key plus EHn, > modulo the order of the curve. 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. > A similar procedure is used for the timeout key; Alice adds a point to > their own timeout key, which seems kindof pointless because they know both > scalars. It obscures the commitment script by making both pubkeys > different each state, as they're all generated from the hash tree. Bob > only needs to keep track of the most recent "elkrem points" and the hash > tree itself. 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? > Hope this is clear and sorry if I'm describing something completely > different than what you're asking about! It's all good; this is a big space and sometimes I don't even know what I don't know... Thanks! Rusty.