From ZmnSCPxj at protonmail.com  Tue Dec  3 04:43:27 2019
From: ZmnSCPxj at protonmail.com (ZmnSCPxj)
Date: Tue, 03 Dec 2019 04:43:27 +0000
Subject: [Lightning-dev] eltoo towers and implications for settlement
	key derivation
In-Reply-To: <87wobejbxx.fsf@rustcorp.com.au>
References: <CAFfwr8Gy+x4SRMCgOibbo8Kbh-ZeJ6BYt9jW9W320OMhFGVKVQ@mail.gmail.com>
 <87d0d6mgiq.fsf@rustcorp.com.au>
 <VT7iAW-ON5UwR3lLWip6BBFvay2e5spPTUrnYMjXtdrRuNcuuN5yKZSVEuoOQgrq2Mu4Z3SetH3OTKz6SKWf3t1QDe8TXP-ObSxs5fnxAX0=@protonmail.com>
 <87wobejbxx.fsf@rustcorp.com.au>
Message-ID: <755Q5WeOMgLjTEvx6en97njBkiMpv4mcITmHC04CXte72wzUuFwXIAqG0tynH65AQ1gAS3WVbaCxxngcMhxUg0U_QAO5sqGxEdVu9qbeOSM=@protonmail.com>

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.

Regards,
ZmnSCPxj