ZmnSCPxj via Lightning-dev <lightning-dev@lists.linuxfoundation.org> writes: > Good morning Rusty, > >> ZmnSCPxj zmnsc...@protonmail.com writes: >> >> > Good morning Rusty, >> > >> > > > Hi all, >> > > > I recently revisited the eltoo paper and noticed some things related >> > > > watchtowers that might affect channel construction. >> > > > Due to NOINPUT, any update transaction can spend from any other, so >> > > > in theory the tower only needs the most recent update txn to resolve >> > > > any dispute. >> > > > In order to spend, however, the tower must also produce a witness >> > > > script which when hashed matches the witness program of the input. To >> > > > ensure settlement txns can only spend from exactly one update txn, >> > > > each update txn uses unique keys for the settlement clause, meaning >> > > > that each state has a unique witness program. >> > > >> > > I didn't think this was the design. The update transaction can spend >> > > any prior, with a fixed script, due to NOINPUT. >> > > The settlement transaction does not use NOINPUT, and thus can only >> > > spend the matching update. >> > >> > My understanding is that this is not logically possible? >> >> You're right, no wonder I missed this problem :( >> >> OK, so we need to change the key(s) every time. Can we tweak it based >> on something the watchtower will know, i.e. something in the update tx >> itself? Obviously not the output, as that would create a circular >> dependency. Is there some taproot thing we can use to insert some >> noise in the input? > > You could always add a taproot branch with a `OP_RETURN <randomness>` > tapscript, which can never be used (thus has no effect on the overall > security), but can inject randomness to the outer taproot key. > This *is* secure, since bip-schnorr indicates that `e` is `h(R | P | m)`, > with `P` being the pubkey itself, so that should be enough. > > Or why not BIP32 derivation? > This should be just as secure.
I still fail to see the issue, update_tx and settlement_tx are self-contained, and there is no need to recover the prevout scriptPubKey or any value therein. Are we talking about things built on top of eltoo? If that's the case, we need to use noinput/anyprevout anyway, so why not just replicate the same logic and ship them bound correctly to the watchtower? I'd also argue that it's not a watchtower's job to finalize the entire off-chain contract. It's main job is to watch the blockchain and react should anything trigger it, while anything we build on top likely has absolute locktimes (HTLCs have absolute timeouts), so it the client that knows when it has to check back in and settle anything that happened. Cheers, Christian _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
