📅 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>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-08-21 09:48:48
in reply to nevent1q…mr5r
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-08-21 09:48:48Event JSON
{
"id": "614da26cca8b06a89b28239e24b3ce2f466c0658783402e474ee440b3a5d6de3",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1692611328,
"kind": 1,
"tags": [
[
"e",
"a326d465876144c0b60f5186966248e965bd554a8674674b5753301c75bbe219",
"",
"root"
],
[
"e",
"b79893610698e51fd3b068b9c57eeaac285718442d47637779fda2e5ed30d60a",
"",
"reply"
],
[
"p",
"7a4ba40070e54012212867182c66beef592603fe7c7284b72ffaafce9da20c05"
]
],
"content": "📅 Original date posted:2023-08-17\n🗒️ 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.\n📝 Original message:\nHi Thomas,\n\n\u003e That's a pity. I would have expected you to be interested, given that\n\u003e Phoenix could benefit from that feature.\n\nI don't think this is an attack wallet providers can reasonably attempt.\nThe mobile wallet can check at every connection that the provider isn't\ntrying to cheat, and the provider doesn't have any way of knowing when\nthe mobile wallet has lost data: it would thus be a very risky move to\ntry to cheat, because it is very unlikely to succeed and will result in\nreputation loss for the provider.\n\nSo for this specific backup use case, I think it would simply be adding\ncomplexity to solve an issue that doesn't matter in practice.\n\n\u003e How are the fraud proofs I described more dangerous than revoked states?\n\u003e There is no \"toxic data\" in here.\n\nI didn't say they were more dangerous than revoked states?\nWhat I meant is that signing those \"commitments\" by the wallet provider\nis dangerous for their reputation if that service is only best-effort,\nbecause there are race conditions in the lightning protocol for which\nthe wallet provider may not have the mobile wallet's latest state (it\nis not entirely trivial to keep track of that state).\n\n\u003e Perhaps that PR could benefit from my idea of sending backup data as new\n\u003e fields of existing messages? I see that update_channel_backup needs to be\n\u003e sent *before* the corresponding change of state. I think using the\nexisting\n\u003e messages would be more elegant, because it makes things atomic.\n\nThat was the main thing discussed in that PR. See [1] for the end of\nthat discussion (the earlier comments contain a lot of details on that\ndesign choice). Sending data in existing messages has a length issue,\nbecause `commitment_signed` for example may already fill up the message\nwhich doesn't leave any room for an additional backup.\n\nCheers,\nBastien\n\n[1] https://github.com/lightning/bolts/pull/881#issuecomment-1132698926\n\nLe jeu. 17 août 2023 à 12:52, Thomas Voegtlin \u003cthomasv at electrum.org\u003e a\nécrit :\n\u003e\n\u003e Hello Bastien\n\u003e\n\u003e \u003e I don't think those fraud proofs are necessary at all.\n\u003e\n\u003e That's a pity. I would have expected you to be interested, given that\n\u003e Phoenix could benefit from that feature.\n\u003e\n\u003e Anyway, since my proposal requires new opcodes, I think of it more as\n\u003e a theoretical discussion, rather than a concrete proposal.\n\u003e\n\u003e \u003e They're also\n\u003e \u003e dangerous, because they impose a hard penalty on LSPs for something\n\u003e \u003e that should be best effort (and could get desynchronized by connection\n\u003e \u003e issues, especially with flaky mobile connections).\n\u003e \u003e\n\u003e\n\u003e How are the fraud proofs I described more dangerous than revoked states?\n\u003e There is no \"toxic data\" in here.\n\u003e\n\u003e The server must not sign (ctn1, t1), (ctn2, t2) with ctn1\u003ectn2 and t1\u003ct2.\n\u003e That is the only constraint, and it does not depend on flaky connections.\n\u003e\n\u003e All the server needs to do is remember the value of the highest timestamp\n\u003e signed so far. And, if they need to subtract leap seconds to their clock,\n\u003e wait a little bit before resuming the channel. That does not sound too\nhard...\n\u003e\n\u003e\n\u003e \u003e I'm surprised that you don't mention the BOLT PR we created for those\n\u003e \u003e backups in [1], I believe that is sufficient. It should probably be\n\u003e \u003e moved to a blip instead of a BOLT once we've implemented this version\n\u003e \u003e (the approach we use in Phoenix currently is slightly different), but\n\u003e \u003e apart from that it contains all the mechanisms necessary to achieve\n\u003e \u003e this today.\n\u003e \u003e\n\u003e\n\u003e Sorry, I had seen that PR a few years ago, but in the meantime I had\n\u003e forgotten about it. I just had a new look at it now.\n\u003e\n\u003e Perhaps that PR could benefit from my idea of sending backup data as new\n\u003e fields of existing messages? I see that update_channel_backup needs to be\n\u003e sent *before* the corresponding change of state. I think using the\nexisting\n\u003e messages would be more elegant, because it makes things atomic.\n\u003e\n\u003e Note that in practice, the client would only need to send his signature\n\u003e of the backup, and not the backup itself, which should be reconstructed\n\u003e by the server on each new state (see section 'saving bandwidth').\n\u003e\n\u003e cheers\n\u003e\n\u003e Thomas\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230817/09860a94/attachment.html\u003e",
"sig": "3dbd25d4ab469f2088c2cd5287c98453a4acb7395d67e56159e97c85f546d3ff7f2ccc64cd5e1ca5c959b4f1612991443be669d5993289733a636dace29e27f5"
}