Regarding your proposal to make peer backups symmetric, with a first message that commits to the current state, and then a second message that reveals the state: I think it could work, but I see the following issue:
If Alice reveals that she has lost her state, Bob might be tempted to disconnect, because he expects that Alice will forget his already sent state commitment. For example this would happen if the user is frustrated and uninstalls/re-installs the app, or if she decides to try from another device because the first device "failed" to restore her wallet). Thus, Bob could try to send a different commitment the next time. A possible way to prevent that: Alice could, if Bob does not reveal his state, write Bob's state commitment on-chain, in an OP_RETURN. That way, Bob cannot expect her to have forgotten his state commitment. Thomas On 17.08.23 20:43, SomberNight wrote:
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
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
