📅 Original date posted:2019-12-04
📝 Original message:
(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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:57:34
in reply to nevent1q…t4xx
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:57:34Event JSON
{
"id": "8c163d5c16669512088f129142ddf7099e1f8d5b7ea1bd81e7e1bf2276e92059",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315454,
"kind": 1,
"tags": [
[
"e",
"4c9eebfb07afa82296aae9348e1049e58998072c2cbd84edcebce5b362e0df8f",
"",
"root"
],
[
"e",
"15f04b4e5c777efdc30a782020e30586a37bae0e088db3c9a9f71b1d04b4c94c",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2019-12-04\n📝 Original message:\n(I wrote this a couple of days ago but forgot to send it, sorry for that)\n\nHi Conner,\n\nthanks for looking into this. I hadn't really thought too much about\nwatchtowers while writing the paper, so there might definitely be things\nI hadn't considered. I fail to see where the watchtower needs to\ngenerate the witness script if he's given the update transaction and the\nmatching settlement transaction (see deployment option 2 below).\n\nThere are a couple of deployment options for watchtowers, from simple\nforward ratchetting to fully settling watchtowers. As you correctly\npoint out if the watchtower just ratchets forward the state, all it\nneeds is the latest update transaction that is bindable to any prior\nupdate transaction and therefore the per-channel state is a single\nupdate transaction. The channel operator would then come back at a later\ntime, when the watchtower has ratchetted forward and prevented any cheat\nattempt by the counterparty and just release the latest settlement tx.\n\nThis is the model I had in mind when writing since it has constant\nper-channel state on the watchtower independent of the number of updates\nand of the size of the state (HTLCs, simple outputs, ...) attached to\nthat settlement. This is safe since the operator knows when it has to\ncheck back in at the latest in order to settle HTLCs built on top since\nthey have absolute locktimes (this is not true if we start building\nrelative locktime things on top of eltoo channels, but let's keep it\nsimple for now).\n\nThe second deployment option is to give the watchtower the settlement\ntransaction along with the update transaction. The settlement\ntransaction is fully signed and uses noinput/anyprevout to bind to the\nupdate, so the bundle of update and settlement transactions is\nbroadcastable right away, no need to produce any scripts or\nsignatures. This ensures that we at least drop the correct state\non-chain, but comes at the cost of the watchtower learning intermediate\nstates, or at least the size of the state (number of outputs) if we\nencrypt it.\n\nA third deployment option would be to allow the watchtower the ability\nto further settle things we built on top of the base eltoo contract,\nsuch as HTLCs, but at that point we are leaking a lot of information,\nwatchtowers become very complex and we lose the flexibility of having\nclear layering. If we are aiming for this third option indeed the\nwatchtower would also need the ability to bind the HTLC settlement or\nwhatever we build on top of eltoo, which implies they'd also use\nnoinput/anyprevout, but that's hardly an issue, as long as the binding\nis unique.\n\nCheers,\nChristian\n\nConner Fromknecht \u003cconner at lightning.engineering\u003e writes:\n\u003e Hi all,\n\u003e\n\u003e I recently revisited the eltoo paper and noticed some things related\n\u003e watchtowers that might affect channel construction.\n\u003e\n\u003e Due to NOINPUT, any update transaction _can_ spend from any other, so\n\u003e in theory the tower only needs the most recent update txn to resolve\n\u003e any dispute.\n\u003e\n\u003e In order to spend, however, the tower must also produce a witness\n\u003e script which when hashed matches the witness program of the input. To\n\u003e ensure settlement txns can only spend from exactly one update txn,\n\u003e each update txn uses unique keys for the settlement clause, meaning\n\u003e that each state has a _unique_ witness program.\n\u003e\n\u003e Naively then a tower could store settlement keys for all states,\n\u003e permitting it to reconstruct arbitrary witness scripts for any given\n\u003e sequence of confirmed update txns.\n\u003e\n\u003e So far, the only work around I’ve come up with to avoid this is to\n\u003e give the tower an extended parent pubkey for each party, and then\n\u003e derive non-hardened settlement keys on demand given the state numbers\n\u003e that get confirmed. It's not the most satisfactory solution though,\n\u003e since leaking one hot settlement key now compromises all sibling\n\u003e settlement keys.\n\u003e\n\u003e Spending the unique witness programs is mentioned somewhat in section\n\u003e 4.1.4, which refers to deriving keys via state numbers, but to me it\n\u003e reads mostly from the PoV of the counterparties and not a third-party\n\u003e service. Is requiring non-hardened keys a known consequence of the\n\u003e construction? Are there any alternative approaches folks are aware of?\n\u003e\n\u003e Cheers,\n\u003e Conner\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "d6f9034ff1c6aedff63795a988a9eefa4a86c27a6ba411bbc5830728bd0c73ab53ab312097fda0d911db13a55bba28109412a9310dbc64fc9d515930ed945799"
}