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
signature.asc
Description: PGP signature
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
