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