From joseph at lightning.network Tue Aug 9 22:29:38 2016 From: joseph at lightning.network (Joseph Poon) Date: Tue, 9 Aug 2016 15:29:38 -0700 Subject: [Lightning-dev] Blinded channel observation In-Reply-To: <877fbpps8s.fsf@rustcorp.com.au> References: <87a8gmpkde.fsf@rustcorp.com.au> <20160809192814.GA22477@lightning.network> <877fbpps8s.fsf@rustcorp.com.au> Message-ID: <20160809222938.GA25606@lightning.network> On Wed, Aug 10, 2016 at 06:36:11AM +0930, Rusty Russell wrote: > 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. For #1, the HMAC would be pre-computed by the outsourcer. So the flow looks like: 1. The outsourcer takes the txid, HMAC(txid+salt1) and encrypts the blob 2. The outsourcer gives the 32-byte hmac and blob to the watcher 3. The watcher adds the 32-byte hmac and the blob to a key-value store (the watcher can optionally truncate or whatever) 4. When the watcher receives a new block, they HMAC(txid+salt1) all transactions and compare against the key-value store This method does not require significant computation upon receiving a new block and checking against the datastore. I forgot to note, that the salt2 is sort of unnecessary, it can just be the pure txid as the key but was there for superstition and aid in understanding what's going on. I was just making a point that there needs to be some kind of "hint"/key to look for. > > 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 was referring to the non-witness txid when making that comment, but there should be sufficient entropy from the revocation hash (whose P2WSH is part of the Commitment outputs). > 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? Yeah! I like this idea to use one's own input sig as the key for the encrypted blob too. If Alice is the one outsourcing the Commitment which Bob can broadcast, Bob can only broadcast it using the sig Alice gave Bob as it's spending from a 2-of-2. If Alice is outsourcing Bob's Commitment broadcasts, a hash of her input signature is a solid way to derive a key as well without malleability concerns. I also like that it "encourages" more nodes to download witness data; ignoring witnesses is a concern of mine which this helps with :^) -- Joseph Poon