[Lightning-dev] Blinded channel observation

[Rusty Russell]

Joseph Poon <joseph at lightning.network> writes:
> 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

Ah OK!  I am in sync now, sorry for the noise!

>> 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).

Unfortunately, watcher knows revocation preimage N, so it can figure out
some or all previous revocation preimages (and thus hashes).  That's
true with shachain, and I think elkrem has similar properties (it's kind
of what we were after!).

>> 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.

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...

> I also like that it "encourages" more nodes to download witness data;
> ignoring witnesses is a concern of mine which this helps with :^)

Good point!

Cheers,
Rusty.