SomberNight [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-17 🗒️ Summary of this message: Mobile wallet ...

📅 Original date posted:2023-08-17
🗒️ Summary of this message: Mobile wallet providers are unlikely to cheat because the mobile wallet can check for any attempts and the provider risks reputation loss. A peer backup solution could be implemented by any node, allowing users to store backups with them. The reputation argument may not hold up for random nodes, but for hardcoded nodes like ACINQ, it is sufficient. The idea of symmetric resumable channels is also proposed.
📝 Original message:
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