Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-17 🗒️ Summary of this message: The sender is ...
📅 Original date posted:2023-08-17
🗒️ Summary of this message: The sender is disappointed that the recipient is not interested in fraud proofs for a mobile wallet. They discuss the dangers and complexities involved in implementing this feature.
📝 Original message:
Hi Thomas,
> That's a pity. I would have expected you to be interested, given that
> Phoenix could benefit from that feature.
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.
So for this specific backup use case, I think it would simply be adding
complexity to solve an issue that doesn't matter in practice.
> How are the fraud proofs I described more dangerous than revoked states?
> There is no "toxic data" in here.
I didn't say they were more dangerous than revoked states?
What I meant is that signing those "commitments" by the wallet provider
is dangerous for their reputation if that service is only best-effort,
because there are race conditions in the lightning protocol for which
the wallet provider may not have the mobile wallet's latest state (it
is not entirely trivial to keep track of that state).
> Perhaps that PR could benefit from my idea of sending backup data as new
> fields of existing messages? I see that update_channel_backup needs to be
> sent *before* the corresponding change of state. I think using the
existing
> messages would be more elegant, because it makes things atomic.
That was the main thing discussed in that PR. See [1] for the end of
that discussion (the earlier comments contain a lot of details on that
design choice). Sending data in existing messages has a length issue,
because `commitment_signed` for example may already fill up the message
which doesn't leave any room for an additional backup.
Cheers,
Bastien
[1] https://github.com/lightning/bolts/pull/881#issuecomment-1132698926
Le jeu. 17 août 2023 à 12:52, Thomas Voegtlin <thomasv at electrum.org> a
écrit :
>
> Hello Bastien
>
> > I don't think those fraud proofs are necessary at all.
>
> That's a pity. I would have expected you to be interested, given that
> Phoenix could benefit from that feature.
>
> Anyway, since my proposal requires new opcodes, I think of it more as
> a theoretical discussion, rather than a concrete proposal.
>
> > They're also
> > dangerous, because they impose a hard penalty on LSPs for something
> > that should be best effort (and could get desynchronized by connection
> > issues, especially with flaky mobile connections).
> >
>
> How are the fraud proofs I described more dangerous than revoked states?
> There is no "toxic data" in here.
>
> The server must not sign (ctn1, t1), (ctn2, t2) with ctn1>ctn2 and t1<t2.
> That is the only constraint, and it does not depend on flaky connections.
>
> All the server needs to do is remember the value of the highest timestamp
> signed so far. And, if they need to subtract leap seconds to their clock,
> wait a little bit before resuming the channel. That does not sound too
hard...
>
>
> > I'm surprised that you don't mention the BOLT PR we created for those
> > backups in [1], I believe that is sufficient. It should probably be
> > moved to a blip instead of a BOLT once we've implemented this version
> > (the approach we use in Phoenix currently is slightly different), but
> > apart from that it contains all the mechanisms necessary to achieve
> > this today.
> >
>
> Sorry, I had seen that PR a few years ago, but in the meantime I had
> forgotten about it. I just had a new look at it now.
>
> Perhaps that PR could benefit from my idea of sending backup data as new
> fields of existing messages? I see that update_channel_backup needs to be
> sent *before* the corresponding change of state. I think using the
existing
> messages would be more elegant, because it makes things atomic.
>
> Note that in practice, the client would only need to send his signature
> of the backup, and not the backup itself, which should be reconstructed
> by the server on each new state (see section 'saving bandwidth').
>
> cheers
>
> Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230817/09860a94/attachment.html>;
🗒️ Summary of this message: The sender is disappointed that the recipient is not interested in fraud proofs for a mobile wallet. They discuss the dangers and complexities involved in implementing this feature.
📝 Original message:
Hi Thomas,
> That's a pity. I would have expected you to be interested, given that
> Phoenix could benefit from that feature.
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.
So for this specific backup use case, I think it would simply be adding
complexity to solve an issue that doesn't matter in practice.
> How are the fraud proofs I described more dangerous than revoked states?
> There is no "toxic data" in here.
I didn't say they were more dangerous than revoked states?
What I meant is that signing those "commitments" by the wallet provider
is dangerous for their reputation if that service is only best-effort,
because there are race conditions in the lightning protocol for which
the wallet provider may not have the mobile wallet's latest state (it
is not entirely trivial to keep track of that state).
> Perhaps that PR could benefit from my idea of sending backup data as new
> fields of existing messages? I see that update_channel_backup needs to be
> sent *before* the corresponding change of state. I think using the
existing
> messages would be more elegant, because it makes things atomic.
That was the main thing discussed in that PR. See [1] for the end of
that discussion (the earlier comments contain a lot of details on that
design choice). Sending data in existing messages has a length issue,
because `commitment_signed` for example may already fill up the message
which doesn't leave any room for an additional backup.
Cheers,
Bastien
[1] https://github.com/lightning/bolts/pull/881#issuecomment-1132698926
Le jeu. 17 août 2023 à 12:52, Thomas Voegtlin <thomasv at electrum.org> a
écrit :
>
> Hello Bastien
>
> > I don't think those fraud proofs are necessary at all.
>
> That's a pity. I would have expected you to be interested, given that
> Phoenix could benefit from that feature.
>
> Anyway, since my proposal requires new opcodes, I think of it more as
> a theoretical discussion, rather than a concrete proposal.
>
> > They're also
> > dangerous, because they impose a hard penalty on LSPs for something
> > that should be best effort (and could get desynchronized by connection
> > issues, especially with flaky mobile connections).
> >
>
> How are the fraud proofs I described more dangerous than revoked states?
> There is no "toxic data" in here.
>
> The server must not sign (ctn1, t1), (ctn2, t2) with ctn1>ctn2 and t1<t2.
> That is the only constraint, and it does not depend on flaky connections.
>
> All the server needs to do is remember the value of the highest timestamp
> signed so far. And, if they need to subtract leap seconds to their clock,
> wait a little bit before resuming the channel. That does not sound too
hard...
>
>
> > I'm surprised that you don't mention the BOLT PR we created for those
> > backups in [1], I believe that is sufficient. It should probably be
> > moved to a blip instead of a BOLT once we've implemented this version
> > (the approach we use in Phoenix currently is slightly different), but
> > apart from that it contains all the mechanisms necessary to achieve
> > this today.
> >
>
> Sorry, I had seen that PR a few years ago, but in the meantime I had
> forgotten about it. I just had a new look at it now.
>
> Perhaps that PR could benefit from my idea of sending backup data as new
> fields of existing messages? I see that update_channel_backup needs to be
> sent *before* the corresponding change of state. I think using the
existing
> messages would be more elegant, because it makes things atomic.
>
> Note that in practice, the client would only need to send his signature
> of the backup, and not the backup itself, which should be reconstructed
> by the server on each new state (see section 'saving bandwidth').
>
> cheers
>
> Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230817/09860a94/attachment.html>;