From rusty at rustcorp.com.au Tue Aug 9 21:06:11 2016 From: rusty at rustcorp.com.au (Rusty Russell) Date: Wed, 10 Aug 2016 06:36:11 +0930 Subject: [Lightning-dev] Blinded channel observation In-Reply-To: <20160809192814.GA22477@lightning.network> References: <87a8gmpkde.fsf@rustcorp.com.au> <20160809192814.GA22477@lightning.network> Message-ID: <877fbpps8s.fsf@rustcorp.com.au> Joseph Poon writes: > Hi Rusty, > > On Tue, Aug 09, 2016 at 03:13:57PM +0930, Rusty Russell wrote: >> We send the observer the "steal" tx every update (not really: we only >> need to send the to-us/to-them amounts, pubkeys, HTLCs info and sig). >> This gets encrypted+HMAC with the txid of the commit tx (or, if that's >> too guessable, the SHA256() of our signature on the commit tx). >> >> [snip] >> >> If we want to obscure our funding tx, we can simply use a txid qualifier >> the same way you did (and maybe use the sha256(txid) as the encryption >> key to avoid weakening that). > > I think it may be necessary to identify when the transaction occurs as > an index for outsourcing services, so the key can't be dervied directly > from the txid with a single HMAC/sha256. It's possible there are > millions of transactions to compare, and an index based on txid is > necessary. The two options I can see are: This is fun! Yes, I think we agree some "filter hint" is needed to avoid a crazy amount of outsourcing work (eg. first 8/16 bytes of txid). I don't think an HMAC check per registered commitment is quite fast enough. But there's a problem with most naive filters, if you can guess commitment tx N-1 from commitment tx N. If the outsourcing service sees an old commit they can guess at previous commitment txs using that. Probably unroll the whole channel history if they can guess enough HTLCs. > 2. HMAC the transaction itself (not txid) as the secret key (or anything > part of the transaction, as long as it isn't SHA256(tx) for obvious > reasons). I like something along these lines better than option #1. > Whatever computational cost there is will be extremely low, as the > operations are constrained by block size. If we include the witness in that HMAC we risk reintroducing malleability. If we don't, we risk txs being predictable. I can think of a few fixes: insert some randomness in the tx (OP_RETURN? Different addresses each time?), or try to extract the input signature from the witness, which is unguessable, as our filter? What's simplest? Rusty.