From pete at petertodd.org Tue Aug 15 11:06:26 2023 From: pete at petertodd.org (Peter Todd) Date: Tue, 15 Aug 2023 11:06:26 +0000 Subject: [Lightning-dev] Backing up channel state with counterparties In-Reply-To: <0f84f9be-b68e-47db-46b6-3230e4509811@electrum.org> References: <0f84f9be-b68e-47db-46b6-3230e4509811@electrum.org> Message-ID: On Mon, Aug 14, 2023 at 02:59:16PM +0200, Thomas Voegtlin wrote: > Resumable channels using OP_CHECKSIGFROMSTACK > ============================================= > > > In order to resume the activity of a Lightning channel, one needs a > backup that contains all the information about the current channel > state. The need to perform channel backups has plagued user > experience, with many implementations reverting to static backups, > which can be used to recover funds, but not to resume channel > operations. > > Asking your channel counterparty to store your channel state has the > advantage to make backup operations atomic. However, there is no > guarantee that this is safe. Indeed, if the other party suspects that > you have lost your state (for example, because you have been offline > for a long time, or if they can see that you requested blockchain > information following a certain pattern), they can try to send you a > revoked state, and there is no way to punish them for doing that. As we discussed on Signal, it'd be most useful for me to write up my counter-arguement to this part of your proposal here for others to read as well. I believe backing up channel state with your counterparty is both useful, and significantly less risky than it initially appears. The basic reason why is that client can make fraud uneconomical by checking the backup each time they connect, and immediately closing the channel if the wrong backup is provided. # Definitions Let's say Alice has a private channel open with Bob, and Alice is also storing a channel state backup with Bob. Define V_h as the honest lifetime value of the channel to Bob. By "honest lifetime value" we mean the value of the channel in terms of expected fees. Since this is a private channel, Bob can expect no other benefits (Bob can't route through the channel). Define V_f as the value Bob can fraudulently obtain by giving Alice an incorrect backup. Define P_d as the probability of data loss since the last time Alice connected to Bob. # Protocol ## Normal Operation Each time Alice connects to Bob, Alice asks Bob for a copy of the most recent channel state backup. If the backup is incorrect, Alice immediately force closes the channel. ## Recovery Alice asks Bob for a copy of the most recent channel state backup, in exactly the same fashion as in Normal Operation. The only difference is Alice now uses that backup. # Analysis Bob can profit from fraudulently giving Alice an incorrect backup if: V_f * P_d > V_h So, what does this mean? First of all, note that V_f is non-zero only when the channel balance from Alice's perspective has increased: there needs to be a previous valid channel balance where Alice had less funds than now. Secondly, note that P_d is a probability that Bob wants to estimate, based on the information Bob has at hand. For example, if Alice typically connects to Bob once an hour, but has been offline for a week, Bob might suppose that it's more likely that Alice has lost data than otherwise. On the other hand, if Alice('s) regularly go a few days without connecting, a delay of a few days is not evidence of data loss. Suppose that Alice goes a few days without connecting to Bob 10 times per year, and this particular connection attempt is an example of that 10/year event. Suppose that Alice has a 1% chance of data loss per year that **requires her to use Bob's channel state backup**, and suppose that with 100% certainty, in the event of data loss Alice would take a few days to attempt recovery. That means that this particular connection event represents a 1% / 10 = 0.1% probability event, and P_d = 0.1% Let's suppose that at some point in the channel's history Alice has completely drained her channel, and at this point it has been totally refilled. That means that V_f is equal to the balance of her channel, as Bob could give Alice a channel state backup corresponding to the state when Alice had zero balance, while her balance now is 100%. Recall that V_h is the revenue Bob expects to get from the channel in the future. For example, if Bob makes on average 0.2% fees, and reasonably expects Alice to drain the channel one more time over the future life of the channel, it's not rational for Bob to attempt channel state fraud because: V_f * 0.1% < V_f * 0.2% # Conclusion I believe these numbers are reasonable estimates for a reasonable worst-case scenario. They strongly suggest that storing channel backups with peers is valuable, and that in many - possibly most - cases fraud would not be economically rational. Of course, with encryption we can also store channel backups redundantly, across multiple channel peers. And supporting watchtowers in addition further improves this situation by reducing the probability of actual data loss, and decreasing the chance of a succesful fraud. -- https://petertodd.org 'peter'[:-1]@petertodd.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: