Thomas Voegtlin [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-17 🗒️ Summary of this message: Bastien is not ...
📅 Original date posted:2023-08-17
🗒️ Summary of this message: Bastien is not interested in fraud proofs, but Thomas argues they are not dangerous and suggests using existing messages for backup data.
📝 Original message:
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
🗒️ Summary of this message: Bastien is not interested in fraud proofs, but Thomas argues they are not dangerous and suggests using existing messages for backup data.
📝 Original message:
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