From thomasv at electrum.org Thu Aug 17 10:52:26 2023 From: thomasv at electrum.org (Thomas Voegtlin) Date: Thu, 17 Aug 2023 12:52:26 +0200 Subject: [Lightning-dev] Resumable channels using OP_CHECKSIGFROMSTACK In-Reply-To: References: <0f84f9be-b68e-47db-46b6-3230e4509811@electrum.org> Message-ID: 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 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