[Lightning-dev] eltoo towers and implications for settlement key derivation
ZmnSCPxj at protonmail.com
Tue Dec 3 04:43:27 UTC 2019
Good morning Rusty,
> ZmnSCPxj ZmnSCPxj at 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.
More information about the Lightning-dev