Thomas Voegtlin [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-30 🗒️ Summary of this message: Proposal for ...
📅 Original date posted:2023-08-30
🗒️ Summary of this message: Proposal for symmetric peer backups in resumable channels. Issue: if Alice loses state, Bob may disconnect. Solution: Alice writes Bob's state commitment on-chain to prevent forgetting.
📝 Original message:
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
🗒️ Summary of this message: Proposal for symmetric peer backups in resumable channels. Issue: if Alice loses state, Bob may disconnect. Solution: Alice writes Bob's state commitment on-chain to prevent forgetting.
📝 Original message:
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