Conner Fromknecht [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-26 📝 Original message: Hi all, I recently ...
📅 Original date posted:2019-11-26
📝 Original message:
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
📝 Original message:
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