Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2019-12-04 📝 Original message: ZmnSCPxj via ...

📅 Original date posted:2019-12-04
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
> 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.

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