(I wrote this a couple of days ago but forgot to send it, sorry for that)
Hi Conner,
thanks for looking into this. I hadn't really thought too much about
watchtowers while writing the paper, so there might definitely be things
I hadn't considered. I fail to see where the watchtower needs to
generate the witness script if he's given the update transaction and the
matching settlement transaction (see deployment option 2 below).
There are a couple of deployment options for watchtowers, from simple
forward ratchetting to fully settling watchtowers. As you correctly
point out if the watchtower just ratchets forward the state, all it
needs is the latest update transaction that is bindable to any prior
update transaction and therefore the per-channel state is a single
update transaction. The channel operator would then come back at a later
time, when the watchtower has ratchetted forward and prevented any cheat
attempt by the counterparty and just release the latest settlement tx.
This is the model I had in mind when writing since it has constant
per-channel state on the watchtower independent of the number of updates
and of the size of the state (HTLCs, simple outputs, ...) attached to
that settlement. This is safe since the operator knows when it has to
check back in at the latest in order to settle HTLCs built on top since
they have absolute locktimes (this is not true if we start building
relative locktime things on top of eltoo channels, but let's keep it
simple for now).
The second deployment option is to give the watchtower the settlement
transaction along with the update transaction. The settlement
transaction is fully signed and uses noinput/anyprevout to bind to the
update, so the bundle of update and settlement transactions is
broadcastable right away, no need to produce any scripts or
signatures. This ensures that we at least drop the correct state
on-chain, but comes at the cost of the watchtower learning intermediate
states, or at least the size of the state (number of outputs) if we
encrypt it.
A third deployment option would be to allow the watchtower the ability
to further settle things we built on top of the base eltoo contract,
such as HTLCs, but at that point we are leaking a lot of information,
watchtowers become very complex and we lose the flexibility of having
clear layering. If we are aiming for this third option indeed the
watchtower would also need the ability to bind the HTLC settlement or
whatever we build on top of eltoo, which implies they'd also use
noinput/anyprevout, but that's hardly an issue, as long as the binding
is unique.
Cheers,
Christian
Conner Fromknecht writes:
> 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.
>
> Naively then a tower could store settlement keys for all states,
> permitting it to reconstruct arbitrary witness scripts for any given
> sequence of confirmed update txns.
>
> So far, the only work around I’ve come up with to avoid this is to
> give the tower an extended parent pubkey for each party, and then
> derive non-hardened settlement keys on demand given the state numbers
> that get confirmed. It's not the most satisfactory solution though,
> since leaking one hot settlement key now compromises all sibling
> settlement keys.
>
> Spending the unique witness programs is mentioned somewhat in section
> 4.1.4, which refers to deriving keys via state numbers, but to me it
> reads mostly from the PoV of the counterparties and not a third-party
> service. Is requiring non-hardened keys a known consequence of the
> construction? Are there any alternative approaches folks are aware of?
>
> Cheers,
> Conner
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
