📅 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
Conner Fromknecht [ARCHIVE] /
npub1za…uua2a
2023-06-09 12:57:28
in reply to nevent1q…5ay2
Author Public Key
npub1za0a9afyj7um5feva0d5xmhfsah3zxm252hna2duq0numa952frqvuua2aPublished at
2023-06-09 12:57:28Event JSON
{
"id": "49026ea0fdac2af9df6b0ed4b7f833384fb3f6cca3b92b0f4654eeb796f6ad34",
"pubkey": "175fd2f52497b9ba272cebdb436ee9876f111b6aa2af3ea9bc03e7cdf4b45246",
"created_at": 1686315448,
"kind": 1,
"tags": [
[
"e",
"85bacf74fefe6603c45947a8b836f222d8476c082b7b0a6bddd9344c8457659c",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2019-11-26\n📝 Original message:\nHi all,\n\nI recently revisited the eltoo paper and noticed some things related\nwatchtowers that might affect channel construction.\n\nDue to NOINPUT, any update transaction _can_ spend from any other, so\nin theory the tower only needs the most recent update txn to resolve\nany dispute.\n\nIn order to spend, however, the tower must also produce a witness\nscript which when hashed matches the witness program of the input. To\nensure settlement txns can only spend from exactly one update txn,\neach update txn uses unique keys for the settlement clause, meaning\nthat each state has a _unique_ witness program.\n\nNaively then a tower could store settlement keys for all states,\npermitting it to reconstruct arbitrary witness scripts for any given\nsequence of confirmed update txns.\n\nSo far, the only work around I’ve come up with to avoid this is to\ngive the tower an extended parent pubkey for each party, and then\nderive non-hardened settlement keys on demand given the state numbers\nthat get confirmed. It's not the most satisfactory solution though,\nsince leaking one hot settlement key now compromises all sibling\nsettlement keys.\n\nSpending the unique witness programs is mentioned somewhat in section\n4.1.4, which refers to deriving keys via state numbers, but to me it\nreads mostly from the PoV of the counterparties and not a third-party\nservice. Is requiring non-hardened keys a known consequence of the\nconstruction? Are there any alternative approaches folks are aware of?\n\nCheers,\nConner",
"sig": "9006dbcf92f96e1baf9b3dd66c36837535a05f1f190c36bd092d739c6b17ba27556a4dea357d11e76dc2ff1870daf63822705e2551704d447214da0638e4ab03"
}