From bastien at acinq.fr Fri Aug 18 07:30:19 2023 From: bastien at acinq.fr (Bastien TEINTURIER) Date: Fri, 18 Aug 2023 09:30:19 +0200 Subject: [Lightning-dev] Resumable channels using OP_CHECKSIGFROMSTACK In-Reply-To: References: <0f84f9be-b68e-47db-46b6-3230e4509811@electrum.org> Message-ID: Hi ghost, > Note that the "reputation loss" argument does not hold up that well if > you let Bob connect to arbitrary nodes. That's true, in that case such nodes don't care as much about their reputation and could have an incentive to cheat. But even in that case, the user will detect it easily (because again, the backup provider doesn't know when the wallet has lost state) and in that case they shouldn't ignore it but should rather close their channel. By itself, this is an incentive to not cheat, because even though the wallet user lost money in on-chain fees, the backup provider loses potential routing fees and has a very small chance of successfully stealing funds from the user. But I agree that in that case, a more complex protocol like what you and Thomas suggest could make sense. But I'd still be wary about the additional complexity it would add compared to the benefits it brings. Thanks, Bastien Le jeu. 17 ao?t 2023 ? 20:43, SomberNight a ?crit : > > Hi Bastien, > > > 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. > > It would be nice to have a peer backup solution that can be provided by > ~any node, and reasonably used without trust by ~any node [0]. To be more > precise (and practical), imagine providing the backup "service" by > default if you run a public forwarding node. E.g. if Alice runs eclair > on their server and have some public channels, the default config of > eclair could result in Alice signalling the "backup-provider" feature > bit. Then, if Bob uses a phone-wallet, and opens to Alice (chosen by Bob > arbitrarily), Bob could store their backups with her. > > Note that the "reputation loss" argument does not hold up that well if > you let Bob connect to arbitrary nodes. Something stronger, such as > actual confiscation of funds via Thomas' idea seems more applicable. > Afterall, what does a random node have to lose if they tried to replay > an old backup? You said in another email Phoenix atm simply ignores the > stale backup. I wonder, does the client happily keep using the channel > after a reconnect? If so, what is there to lose by attempting to replay > old states? Random nodes don't really have an easy concept of > reputation. > > Obviously the ACINQ node is not random - being hardcoded in your case > it is anything but. Of course, in the case of an LSP/wallet combo > such as Phoenix, the reputation argument is sufficient, I agree. > > ----- > > [0]: I think the whole backup provicer idea could be made symmetric. > I had previously thought that it is inherently asymmetric but after > some more thought I think I was wrong: > > Symmetric resumable channels > ---------------------------- > > Alice and Bob could have a channel where they both provide state backups > to each other. Regarding who goes first in channel_reestablish, we need > an extra preliminary round where both Alice and Bob commit to what they > will send in channel_reestablish: > > Round 1: > 1. Alice sends hashA = hash(bobs_backup, nonceA) > 2. Bob sends hashB = hash(alices_backup, nonceB) > > Alice persists hashB to disk upon receiving it, and enforces that even > if there is a disconnection, Bob cannot arbitrarily send a different > commitment next time. (if the channel gets reestablished fully and > Alice sends a new backup to Bob, the stored hashB can be cleared) > > Round 2: > 3. Alice sends channel_reestablish containing bobs_backup, and nonceA > 4. Bob sends channel_reestablish containing alices_backup, and nonceB > > Alice checks that the commitment received from Bob in round1 matches > what was received in round2. > > Regarding the opening post OP_CHECKSIGFROMSTACK on-chain enforcement, > that can be made symmetric as well! The channel funding output script > needs one taproot branch each for both Alice and Bob lying. The protocol > needs to be tweaked a bit so as to allow a party to legitimately admit > having lost state and commit to the hash of that in round1, and then > reveal they lost state in round2 (e.g. send null data). In which case > the other party would not be able to use the fraud proof taproot branch. > > Though note that user-error and manual copying/restoring of DBs could > lead to catastrophic failure with the on-chain enforcement: > if you restore an old db and launch your client, the client won't know > it is running an old state and happily participate in the two round > dance, giving a fraud proof to the counterparty in the process. > > Regards, > ghost43 -------------- next part -------------- An HTML attachment was scrubbed... URL: