Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2020-09-22 📝 Original message: ZmnSCPxj <ZmnSCPxj at ...
📅 Original date posted:2020-09-22
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> I am almost certain that a Smart Contract Unchained Escrowed
> Decker-Russell-Osuntokun channel factory can merge the watchtower and
> escrow functionality as well, using the above basic sketch, with
> additional overlay network to allow for federated escrows. The issue
> is really the increased complexity of the `(halftxid, encrypted_blob)`
> scheme with Decker-Russell-Osuntokun.
>
> (To my knowledge, Decker-Russell-Osuntokun only simplifies watchtowers
> if the watchtower knows the funding outpoint, which is information we
> should really prefer the watchtower to not know unless an attack
> occurs; with an unknown-funding-outpoint, `(halftxid, encrypted_blob)`
> scheme, Decker-Russell-Osuntokun is actually more complicated, since
> hiding the funding outpoint prevents having a simple key for the
> watchtower to replace.)
Just a minor comment on this: for eltoo the watchtower does not need to
know the funding outpoint, instead any information that'd allow a
watchtower to collate (encrypted) updates would be sufficient for it to
be able to discard earlier ones. I'm thinking in particular about the
session-based collation that the lnd watchtower protocol uses can be one
such collation key. Alternatively we can still use the Poon-Dryja style
encryption with the trigger transaction hash (which admittedly isn't
very prominently described in the eltoo paper) as the encryption
key. That transaction being the first step towards closing a channel
unilaterally forces any cheating party to reveal the decryption key for
the update txs that'll override its actions.
Furthermore, while encrypting all the reactions with the same encryption
key may appear to leak information, it is only the update transaction
that is passed to the watchtower, not the actual state (direct outputs
and HTLCs) which is attached to the settlement transaction, kept by the
endpoint. So all the watchtower gets from decrypting all prior update
transactions is a set of semantically identical 1-input-1-output update
transactions from which it can at most learn how many updates were
performed. This last leak can also be addressed by simply randomizing
the increment step for state numbers and not passing every state update
to the watchtower (since the watchtower will only ever need the last one
we can coalesce multiple updates and flush them to the watchtower after
some time).
Cheers,
Christian
[1]: https://github.com/lightningnetwork/lnd/blob/master/docs/watchtower.md
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> I am almost certain that a Smart Contract Unchained Escrowed
> Decker-Russell-Osuntokun channel factory can merge the watchtower and
> escrow functionality as well, using the above basic sketch, with
> additional overlay network to allow for federated escrows. The issue
> is really the increased complexity of the `(halftxid, encrypted_blob)`
> scheme with Decker-Russell-Osuntokun.
>
> (To my knowledge, Decker-Russell-Osuntokun only simplifies watchtowers
> if the watchtower knows the funding outpoint, which is information we
> should really prefer the watchtower to not know unless an attack
> occurs; with an unknown-funding-outpoint, `(halftxid, encrypted_blob)`
> scheme, Decker-Russell-Osuntokun is actually more complicated, since
> hiding the funding outpoint prevents having a simple key for the
> watchtower to replace.)
Just a minor comment on this: for eltoo the watchtower does not need to
know the funding outpoint, instead any information that'd allow a
watchtower to collate (encrypted) updates would be sufficient for it to
be able to discard earlier ones. I'm thinking in particular about the
session-based collation that the lnd watchtower protocol uses can be one
such collation key. Alternatively we can still use the Poon-Dryja style
encryption with the trigger transaction hash (which admittedly isn't
very prominently described in the eltoo paper) as the encryption
key. That transaction being the first step towards closing a channel
unilaterally forces any cheating party to reveal the decryption key for
the update txs that'll override its actions.
Furthermore, while encrypting all the reactions with the same encryption
key may appear to leak information, it is only the update transaction
that is passed to the watchtower, not the actual state (direct outputs
and HTLCs) which is attached to the settlement transaction, kept by the
endpoint. So all the watchtower gets from decrypting all prior update
transactions is a set of semantically identical 1-input-1-output update
transactions from which it can at most learn how many updates were
performed. This last leak can also be addressed by simply randomizing
the increment step for state numbers and not passing every state update
to the watchtower (since the watchtower will only ever need the last one
we can coalesce multiple updates and flush them to the watchtower after
some time).
Cheers,
Christian
[1]: https://github.com/lightningnetwork/lnd/blob/master/docs/watchtower.md