ZmnSCPxj <zmnsc...@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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev