Joseph Poon [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-09 📝 Original message: On Wed, Aug 10, 2016 at ...

📅 Original date posted:2016-08-09
📝 Original message:
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