Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-09 📝 Original message: Joseph Poon <joseph at ...
📅 Original date posted:2016-08-09
📝 Original message:
Joseph Poon <joseph at lightning.network> 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.
📝 Original message:
Joseph Poon <joseph at lightning.network> 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.