rich1.0npub186h7xm74e8dqvz64kzhx8aq3j47lwf3emlxl7w8j0d0thrth65vs9y2s83https://nostr.ae/npub186h7xm74e8dqvz64kzhx8aq3j47lwf3emlxl7w8j0d0thrth65vs9y2s83njumphttps://nostr.ae📅 Original date posted:2021-07-15 📝 Original message: What would happen in 2) if the node has data but the peer returned an incorrect state? On Wed, Jul 14, 2021, 20:13 Christian Decker <decker.christian at gmail.com> wrote: > 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 > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210715/54d800a3/attachment.html>