(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 <conner@lightning.engineering> 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
