Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-12 📝 Original message: Joseph Poon <joseph at ...
📅 Original date posted:2016-08-12
📝 Original message:
Joseph Poon <joseph at lightning.network> writes:
> On Wed, Aug 10, 2016 at 11:33:46AM +0930, Rusty Russell wrote:
>> Unfortunately, watcher knows revocation preimage N, so it can figure out
>> some or all previous revocation preimages (and thus hashes).
>
> If you take the results then HMAC it as the final step in
> shachain/elkrem (to establish a single leaf), should be fine even if
> revocation hashes are used in lieu of a revocation pubkey.
Sure, or just SHA the leaf again. But such schemes prevent the watcher
from using the elkrem/shachain space-savings themselves, which is kind
of painful. (Though see below...)
Let's look at space & comms requirements, per new commitment tx, for
different schemes. Let's say we have N htlcs in the current HTLC.
Bytes Bytes
Communicated Stored (per tx)
Naive (whole steal tx) ~300 * (N+1) ~300 * (N+1)
rhash+sig+HTLCdata 32 + 32 + 24*N 32 + 32 + 24*N
+shachain/elkrem 32 + 32 + 24*N 32 + 24*N
+SIG_NOINPUT 32 + 24*N 24*N
+Dual-scriptpubkey MAST 32 0
The ultimate is shachain/elkrem, SIG_NOINPUT and a MAST scheme which
places two scripthashes into the scriptpubkey, either of which would
allow spending. In that case, we'd simply send a series of SIG_NOINPUT
signed steal txs with 1, 2, 3 ... inputs at the beginning, and then send
each new revocation preimage as we learned it. The storage overhead is
basically constant (technically, log(N) for the shachain).
Interestingly, MAST by itself buys us nothing (bytewise): the 32 bytes
we'd need to send for the other branch of MAST is larger than the 24
bytes for the HTLC description.
Revealing the preimages seems a win, BUT if we give them unencrypted to
the watcher we need some other way of avoiding guessable prior
commitment txs. Which implies we change at least one key in some way,
which means we need to send that key to the watcher to store, which
costs as much as they save using shachain/elkrem!
The other win is sharing HTLCs across transactions somehow (which
reduces N to the "number of new HTLCs" instead of "number of HTLCs").
I can't come up with anything very good here, though :(
>> 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...
>
> Yeah, good point. Perhaps it could be better to keep it simple and just
> use an HMAC of the non-witness transaction. There shouldn't be stuff
> that's easily mutatable, and the exposure is not expanded (since that
> would break LN's child transactions anyway).
I still don't understand why use an HMAC-of-tx instead of just the txid?
What does it gain?
Thanks!
Rusty.
📝 Original message:
Joseph Poon <joseph at lightning.network> writes:
> On Wed, Aug 10, 2016 at 11:33:46AM +0930, Rusty Russell wrote:
>> Unfortunately, watcher knows revocation preimage N, so it can figure out
>> some or all previous revocation preimages (and thus hashes).
>
> If you take the results then HMAC it as the final step in
> shachain/elkrem (to establish a single leaf), should be fine even if
> revocation hashes are used in lieu of a revocation pubkey.
Sure, or just SHA the leaf again. But such schemes prevent the watcher
from using the elkrem/shachain space-savings themselves, which is kind
of painful. (Though see below...)
Let's look at space & comms requirements, per new commitment tx, for
different schemes. Let's say we have N htlcs in the current HTLC.
Bytes Bytes
Communicated Stored (per tx)
Naive (whole steal tx) ~300 * (N+1) ~300 * (N+1)
rhash+sig+HTLCdata 32 + 32 + 24*N 32 + 32 + 24*N
+shachain/elkrem 32 + 32 + 24*N 32 + 24*N
+SIG_NOINPUT 32 + 24*N 24*N
+Dual-scriptpubkey MAST 32 0
The ultimate is shachain/elkrem, SIG_NOINPUT and a MAST scheme which
places two scripthashes into the scriptpubkey, either of which would
allow spending. In that case, we'd simply send a series of SIG_NOINPUT
signed steal txs with 1, 2, 3 ... inputs at the beginning, and then send
each new revocation preimage as we learned it. The storage overhead is
basically constant (technically, log(N) for the shachain).
Interestingly, MAST by itself buys us nothing (bytewise): the 32 bytes
we'd need to send for the other branch of MAST is larger than the 24
bytes for the HTLC description.
Revealing the preimages seems a win, BUT if we give them unencrypted to
the watcher we need some other way of avoiding guessable prior
commitment txs. Which implies we change at least one key in some way,
which means we need to send that key to the watcher to store, which
costs as much as they save using shachain/elkrem!
The other win is sharing HTLCs across transactions somehow (which
reduces N to the "number of new HTLCs" instead of "number of HTLCs").
I can't come up with anything very good here, though :(
>> 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...
>
> Yeah, good point. Perhaps it could be better to keep it simple and just
> use an HMAC of the non-witness transaction. There shouldn't be stuff
> that's easily mutatable, and the exposure is not expanded (since that
> would break LN's child transactions anyway).
I still don't understand why use an HMAC-of-tx instead of just the txid?
What does it gain?
Thanks!
Rusty.