Hi Thomas, > That's a pity. I would have expected you to be interested, given that > Phoenix could benefit from that feature.
I don't think this is an attack wallet providers can reasonably attempt. The mobile wallet can check at every connection that the provider isn't trying to cheat, and the provider doesn't have any way of knowing when the mobile wallet has lost data: it would thus be a very risky move to try to cheat, because it is very unlikely to succeed and will result in reputation loss for the provider. So for this specific backup use case, I think it would simply be adding complexity to solve an issue that doesn't matter in practice. > How are the fraud proofs I described more dangerous than revoked states? > There is no "toxic data" in here. I didn't say they were more dangerous than revoked states? What I meant is that signing those "commitments" by the wallet provider is dangerous for their reputation if that service is only best-effort, because there are race conditions in the lightning protocol for which the wallet provider may not have the mobile wallet's latest state (it is not entirely trivial to keep track of that state). > Perhaps that PR could benefit from my idea of sending backup data as new > fields of existing messages? I see that update_channel_backup needs to be > sent *before* the corresponding change of state. I think using the existing > messages would be more elegant, because it makes things atomic. That was the main thing discussed in that PR. See [1] for the end of that discussion (the earlier comments contain a lot of details on that design choice). Sending data in existing messages has a length issue, because `commitment_signed` for example may already fill up the message which doesn't leave any room for an additional backup. Cheers, Bastien [1] https://github.com/lightning/bolts/pull/881#issuecomment-1132698926 Le jeu. 17 août 2023 à 12:52, Thomas Voegtlin <thom...@electrum.org> a écrit : > > Hello Bastien > > > I don't think those fraud proofs are necessary at all. > > That's a pity. I would have expected you to be interested, given that > Phoenix could benefit from that feature. > > Anyway, since my proposal requires new opcodes, I think of it more as > a theoretical discussion, rather than a concrete proposal. > > > They're also > > dangerous, because they impose a hard penalty on LSPs for something > > that should be best effort (and could get desynchronized by connection > > issues, especially with flaky mobile connections). > > > > How are the fraud proofs I described more dangerous than revoked states? > There is no "toxic data" in here. > > The server must not sign (ctn1, t1), (ctn2, t2) with ctn1>ctn2 and t1<t2. > That is the only constraint, and it does not depend on flaky connections. > > All the server needs to do is remember the value of the highest timestamp > signed so far. And, if they need to subtract leap seconds to their clock, > wait a little bit before resuming the channel. That does not sound too hard... > > > > I'm surprised that you don't mention the BOLT PR we created for those > > backups in [1], I believe that is sufficient. It should probably be > > moved to a blip instead of a BOLT once we've implemented this version > > (the approach we use in Phoenix currently is slightly different), but > > apart from that it contains all the mechanisms necessary to achieve > > this today. > > > > Sorry, I had seen that PR a few years ago, but in the meantime I had > forgotten about it. I just had a new look at it now. > > Perhaps that PR could benefit from my idea of sending backup data as new > fields of existing messages? I see that update_channel_backup needs to be > sent *before* the corresponding change of state. I think using the existing > messages would be more elegant, because it makes things atomic. > > Note that in practice, the client would only need to send his signature > of the backup, and not the backup itself, which should be reconstructed > by the server on each new state (see section 'saving bandwidth'). > > cheers > > Thomas
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
