📅 Original date posted:2021-07-14
📝 Original message:
Not quite sure if this issue is unique to eltoo tbh. While in LN-penalty
loss-of-state equates to loss-of-funds, in eltoo this is reduced to
impact only funds that are in a PTLC at the time of the loss-of-state.
We have a couple of options here, that don't touch the blockchain, and
are therefore rather lightweight:
1) Do nothing and keep the incentive to keep up to date backups. It
still is a reduction in risk w.r.t. LN-penalty, since this is just an
append only log of secrets, and old secrets don't harm you like
attempting to close with an old commitment would.
2) Use the peer-storage idea, where we deposit an encrypted bundle with
our peers, and which we expect the peers to return. by hiding the fact
that we forgot some state, until the data has been exchanged we can
ensure that peers always return the latest snapshot of whatever we gave
them.
The latter is the encrypted-blob idea that Rusty has been proposing for
a while now.
Cheers,
Christian
Anthony Towns <aj at erisian.com.au> writes:
> Hello world,
>
> Suppose you have some payments going from Alice to Bob to Carol with
> eltoo channels. Bob's lightning node crashes, and he recovers from an
> old backup, and Alice and Carol end up dropping newer channel states
> onto the blockchain.
>
> Suppose the timeout for the payments is a few hours away, while the
> channels have specified a week long CSV delay to rectify any problems
> on-chain.
>
> Then I think that that means that:
>
> 1) Carol will reveal the point preimages on-chain via adaptor
> signatures, but Bob won't be able to decode those adaptor signatures
> because those signatures will need to change for each state
>
> 2) Even if Bob knows the point preimages, he won't be able to
> claim the PTLC payments on-chain, for the same reason: he needs
> newer adaptor signatures that he'll have lost with the state update
>
> 3) For any payments that timeout, Carol doesn't have any particular
> incentive to make it easy for Bob to claim the refund, and Bob won't
> have the adaptor signatures for the latest state to do so
>
> 4) But Alice will be able to claim refunds easily. This is working how
> it's meant to, at least!
>
> I think you could fix (3) by giving Carol (who does have all the adaptor
> signatures for the latest state) the ability to steal funds that are
> meant to have been refunded, provided she gives Bob the option of claiming
> them first.
>
> However fixing (1) and (2) aren't really going against Alice or Carol's
> interests, so maybe you can just ask: Carol loses nothing by allowing
> Bob to claim funds from Alice; and Alice has already indicated that
> knowing P is worth more to her than the PTLC's funds -- otherwise she
> wouldn't have forwarded the PTLC to Bob in the first place.
>
> Likewise, everyone's probably incentivised to negotiate cooperative
> closes instead of going on-chain -- better privacy, less fees, and less
> delay before the funds can be used elsewhere.
>
> FWIW, I think a similar flaw exists even in the original eltoo spec --
> Alice could simply decline to publish the settlement transaction until
> the timeout has been reached, preventing Bob from revealing the HTLC
> preimage before Alice can claim the refund.
>
> So I think that adds up to:
>
> a) Nodes should share state on reconnection; if you find a node that
> doesn't do this, close the channel and put the node on your enemies
> list. If you disagree on what the current state is, share your most
> recent state, and if the other guy's state is more recent, and all
> the signatures verify, update your state to match theirs.
>
> b) Always negotiate a mutual/cooperative close if possible, to avoid
> actually using the eltoo protocol on-chain.
>
> c) If you want to allow continuing the channel after restoring an old
> state from backup, set the channel state index based on the real time,
> eg (real_time-start_time)*(max_updates_per_second). That way your
> first update after a restore from backup will ensure that any old
> states that your channel partner may not have told you about are
> invalidated.
>
> d) Accept that if you lose connectivity to a channel partner, you will
> have to pay any PTLCs that were going to them, and won't be able
> to claim the PTLCs that were funding them. Perhaps limit the total
> value of inbound PTLCs for forwarding that you're willing to accept
> at any one itme?
>
> Also, layered commitments seem like they make channel factories
> complicated too. Nobody came up with a way to avoid layered commitments
> while I wasn't watching did they?
>
> Cheers,
> aj
> _______________________________________________
> 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 13:03:09
in reply to nevent1q…wh8t
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 13:03:09Event JSON
{
"id": "5e8048d32e078f02547ed2fd2d1054faca15c710d206fb15d5672e42e880ddd5",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315789,
"kind": 1,
"tags": [
[
"e",
"8a0e1cf8bfd207b00d21258bc21868551465e91d678978834dc2fb7ceb2cdcbd",
"",
"root"
],
[
"e",
"2ab110c75fa8e93ba744314c42f5cc5f7a99ebf8ca86620383c2f64530e37c85",
"",
"reply"
],
[
"p",
"01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4"
]
],
"content": "📅 Original date posted:2021-07-14\n📝 Original message:\nNot quite sure if this issue is unique to eltoo tbh. While in LN-penalty\nloss-of-state equates to loss-of-funds, in eltoo this is reduced to\nimpact only funds that are in a PTLC at the time of the loss-of-state.\n\nWe have a couple of options here, that don't touch the blockchain, and\nare therefore rather lightweight:\n\n 1) Do nothing and keep the incentive to keep up to date backups. It\n still is a reduction in risk w.r.t. LN-penalty, since this is just an\n append only log of secrets, and old secrets don't harm you like\n attempting to close with an old commitment would.\n 2) Use the peer-storage idea, where we deposit an encrypted bundle with\n our peers, and which we expect the peers to return. by hiding the fact\n that we forgot some state, until the data has been exchanged we can\n ensure that peers always return the latest snapshot of whatever we gave\n them.\n\nThe latter is the encrypted-blob idea that Rusty has been proposing for\na while now.\n\nCheers,\nChristian\n\nAnthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e Hello world,\n\u003e\n\u003e Suppose you have some payments going from Alice to Bob to Carol with\n\u003e eltoo channels. Bob's lightning node crashes, and he recovers from an\n\u003e old backup, and Alice and Carol end up dropping newer channel states\n\u003e onto the blockchain.\n\u003e\n\u003e Suppose the timeout for the payments is a few hours away, while the\n\u003e channels have specified a week long CSV delay to rectify any problems\n\u003e on-chain.\n\u003e\n\u003e Then I think that that means that:\n\u003e\n\u003e 1) Carol will reveal the point preimages on-chain via adaptor\n\u003e signatures, but Bob won't be able to decode those adaptor signatures\n\u003e because those signatures will need to change for each state\n\u003e\n\u003e 2) Even if Bob knows the point preimages, he won't be able to\n\u003e claim the PTLC payments on-chain, for the same reason: he needs\n\u003e newer adaptor signatures that he'll have lost with the state update\n\u003e\n\u003e 3) For any payments that timeout, Carol doesn't have any particular\n\u003e incentive to make it easy for Bob to claim the refund, and Bob won't\n\u003e have the adaptor signatures for the latest state to do so\n\u003e\n\u003e 4) But Alice will be able to claim refunds easily. This is working how\n\u003e it's meant to, at least!\n\u003e\n\u003e I think you could fix (3) by giving Carol (who does have all the adaptor\n\u003e signatures for the latest state) the ability to steal funds that are\n\u003e meant to have been refunded, provided she gives Bob the option of claiming\n\u003e them first.\n\u003e\n\u003e However fixing (1) and (2) aren't really going against Alice or Carol's\n\u003e interests, so maybe you can just ask: Carol loses nothing by allowing\n\u003e Bob to claim funds from Alice; and Alice has already indicated that\n\u003e knowing P is worth more to her than the PTLC's funds -- otherwise she\n\u003e wouldn't have forwarded the PTLC to Bob in the first place.\n\u003e\n\u003e Likewise, everyone's probably incentivised to negotiate cooperative\n\u003e closes instead of going on-chain -- better privacy, less fees, and less\n\u003e delay before the funds can be used elsewhere.\n\u003e\n\u003e FWIW, I think a similar flaw exists even in the original eltoo spec --\n\u003e Alice could simply decline to publish the settlement transaction until\n\u003e the timeout has been reached, preventing Bob from revealing the HTLC\n\u003e preimage before Alice can claim the refund.\n\u003e\n\u003e So I think that adds up to:\n\u003e\n\u003e a) Nodes should share state on reconnection; if you find a node that\n\u003e doesn't do this, close the channel and put the node on your enemies\n\u003e list. If you disagree on what the current state is, share your most\n\u003e recent state, and if the other guy's state is more recent, and all\n\u003e the signatures verify, update your state to match theirs.\n\u003e\n\u003e b) Always negotiate a mutual/cooperative close if possible, to avoid\n\u003e actually using the eltoo protocol on-chain.\n\u003e\n\u003e c) If you want to allow continuing the channel after restoring an old\n\u003e state from backup, set the channel state index based on the real time,\n\u003e eg (real_time-start_time)*(max_updates_per_second). That way your\n\u003e first update after a restore from backup will ensure that any old\n\u003e states that your channel partner may not have told you about are\n\u003e invalidated.\n\u003e\n\u003e d) Accept that if you lose connectivity to a channel partner, you will\n\u003e have to pay any PTLCs that were going to them, and won't be able\n\u003e to claim the PTLCs that were funding them. Perhaps limit the total\n\u003e value of inbound PTLCs for forwarding that you're willing to accept\n\u003e at any one itme?\n\u003e\n\u003e Also, layered commitments seem like they make channel factories\n\u003e complicated too. Nobody came up with a way to avoid layered commitments\n\u003e while I wasn't watching did they?\n\u003e\n\u003e Cheers,\n\u003e aj\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": "4b5f48d5c860b5654873cf5a9733012c26f73af47fdffe846eef4060474267506a56c17427e102d0126d7a3183163caa72d2dc4186ecd1c0954de27eae205174"
}