From rusty at rustcorp.com.au Fri Aug 12 03:47:52 2016 From: rusty at rustcorp.com.au (Rusty Russell) Date: Fri, 12 Aug 2016 13:17:52 +0930 Subject: [Lightning-dev] Blinded channel observation In-Reply-To: <20160811041626.GA8114@lightning.network> References: <87a8gmpkde.fsf@rustcorp.com.au> <20160809192814.GA22477@lightning.network> <877fbpps8s.fsf@rustcorp.com.au> <20160809222938.GA25606@lightning.network> <87wpjpnzwd.fsf@rustcorp.com.au> <20160811041626.GA8114@lightning.network> Message-ID: <87d1leodg7.fsf@rustcorp.com.au> Joseph Poon writes: > On Wed, Aug 10, 2016 at 11:33:46AM +0930, Rusty Russell wrote: >> Unfortunately, watcher knows revocation preimage N, so it can figure out >> some or all previous revocation preimages (and thus hashes). > > If you take the results then HMAC it as the final step in > shachain/elkrem (to establish a single leaf), should be fine even if > revocation hashes are used in lieu of a revocation pubkey. Sure, or just SHA the leaf again. But such schemes prevent the watcher from using the elkrem/shachain space-savings themselves, which is kind of painful. (Though see below...) Let's look at space & comms requirements, per new commitment tx, for different schemes. Let's say we have N htlcs in the current HTLC. Bytes Bytes Communicated Stored (per tx) Naive (whole steal tx) ~300 * (N+1) ~300 * (N+1) rhash+sig+HTLCdata 32 + 32 + 24*N 32 + 32 + 24*N +shachain/elkrem 32 + 32 + 24*N 32 + 24*N +SIG_NOINPUT 32 + 24*N 24*N +Dual-scriptpubkey MAST 32 0 The ultimate is shachain/elkrem, SIG_NOINPUT and a MAST scheme which places two scripthashes into the scriptpubkey, either of which would allow spending. In that case, we'd simply send a series of SIG_NOINPUT signed steal txs with 1, 2, 3 ... inputs at the beginning, and then send each new revocation preimage as we learned it. The storage overhead is basically constant (technically, log(N) for the shachain). Interestingly, MAST by itself buys us nothing (bytewise): the 32 bytes we'd need to send for the other branch of MAST is larger than the 24 bytes for the HTLC description. Revealing the preimages seems a win, BUT if we give them unencrypted to the watcher we need some other way of avoiding guessable prior commitment txs. Which implies we change at least one key in some way, which means we need to send that key to the watcher to store, which costs as much as they save using shachain/elkrem! The other win is sharing HTLCs across transactions somehow (which reduces N to the "number of new HTLCs" instead of "number of HTLCs"). I can't come up with anything very good here, though :( >> But it rests on the assumption that there are no unknown malleability >> issues on signatures, which I believe makes crypto people nervous. I've >> asked some, though, as that's above my pay grade! >> >> It also assumes they can't set up the witness such that our sig is not >> 2nd or 3rd in the witness element. I think that's true... > > Yeah, good point. Perhaps it could be better to keep it simple and just > use an HMAC of the non-witness transaction. There shouldn't be stuff > that's easily mutatable, and the exposure is not expanded (since that > would break LN's child transactions anyway). I still don't understand why use an HMAC-of-tx instead of just the txid? What does it gain? Thanks! Rusty.