From somber.night at protonmail.com Thu Aug 17 18:43:22 2023 From: somber.night at protonmail.com (SomberNight) Date: Thu, 17 Aug 2023 18:43:22 +0000 Subject: [Lightning-dev] Resumable channels using OP_CHECKSIGFROMSTACK In-Reply-To: References: <0f84f9be-b68e-47db-46b6-3230e4509811@electrum.org> Message-ID: 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