š
Original date posted:2015-11-24
š Original message:
If I understand your question, it's that the both Alice and Bob must revoke
their previous transaction states and share their revocations, but someone
has to go first.
I don't think there's a good way to make this atomic (fair exchange schemes
based on hash functions instead of signatures *sounds* sortof impossible,
but who knows). But in practice there's not really an attack, in that
every update of a channel state has an initiator.
All the payments are "push" payments; if Alice wants to allocate more to
Bob, she initiates, and if Bob wants to allocate more to Alice, he
initiates. With revocations, the user initiating the channel state change
goes first.
In the case where Alice is sending more coin to Bob:
Alice signs new state, sends half signed tx to Bob.
Bob signs new state, sends half signed tx to Alice.
Alice revokes old state by sending preimage to Bob.
Bob revokes old state by sending preimage to Alice.
Done.
If Bob fails to perform the last step, the payment can be considered to not
have gone through. But Bob doesn't have much motivation to fail there. He
can leave the channel in an indeterminate state by failing to revoke with
Alice, but that indeterminate state is worse for him than a fully
determined state where he has more money.
TLDR It's not atomic so payer goes first.
Hope this helps! If not, let me know, say a bit more about what you think
the attack would be.
-Tadge
On Mon, Nov 23, 2015 at 6:36 PM, Nicolas Dorier <nicolas.dorier at gmail.com>
wrote:
> I am still learrning about Lightning Network, slowly but surely.
> As I was reviewing bip 112 (
> https://github.com/btcdrak/bips/blob/bip112sync/bip-0112.mediawiki) I
> noticed that HLTC seems to have a potential attack.
>
> When both parties want to revoke a commitment, they need to send one to
> another the revocation preimage.
> However, if not done atomically, Alice intentionally not send her
> revocation after receiving Bob's thus preventing Bob to withdraw his funds.
>
> Am I missing something ?
>
> The only way I see of fixing as is, is to require a third party expecting
> he does not collude, but this defeat the whole purpose.
>
> Nicolas,
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151123/fc57500a/attachment.html>;
Tadge Dryja [ARCHIVE] /
npub1v5ā¦6l74f
2023-06-09 12:45:13
in reply to nevent1qā¦4r0g
Author Public Key
npub1v5856g02zudlkawxh4ut5kc6at8z5evt77lwxeaaudekq4dlfckst6l74fPublished at
2023-06-09 12:45:13Event JSON
{
"id": "750b24984933759f938aaa3cf6171ae65c8344576736758b2b9495acdf439c2e",
"pubkey": "650f4d21ea171bfb75c6bd78ba5b1aeace2a658bf7bee367bde3736055bf4e2d",
"created_at": 1686314713,
"kind": 1,
"tags": [
[
"e",
"bc3fd40457aeb75eb5ecd2b658f953602e0752e677a704fa42ce64607de50fa8",
"",
"root"
],
[
"e",
"7842218bed39a12c0fbe3ab098adc3c5825e83332fbc0d8889e65fa569cfdcb4",
"",
"reply"
],
[
"p",
"bf0548dc0ad239e9e1e0bba3c969632ded402a68091cde1b21a0895e90bc9a57"
]
],
"content": "š
Original date posted:2015-11-24\nš Original message:\nIf I understand your question, it's that the both Alice and Bob must revoke\ntheir previous transaction states and share their revocations, but someone\nhas to go first.\n\nI don't think there's a good way to make this atomic (fair exchange schemes\nbased on hash functions instead of signatures *sounds* sortof impossible,\nbut who knows). But in practice there's not really an attack, in that\nevery update of a channel state has an initiator.\n\nAll the payments are \"push\" payments; if Alice wants to allocate more to\nBob, she initiates, and if Bob wants to allocate more to Alice, he\ninitiates. With revocations, the user initiating the channel state change\ngoes first.\n\nIn the case where Alice is sending more coin to Bob:\n\nAlice signs new state, sends half signed tx to Bob.\nBob signs new state, sends half signed tx to Alice.\nAlice revokes old state by sending preimage to Bob.\nBob revokes old state by sending preimage to Alice.\nDone.\n\nIf Bob fails to perform the last step, the payment can be considered to not\nhave gone through. But Bob doesn't have much motivation to fail there. He\ncan leave the channel in an indeterminate state by failing to revoke with\nAlice, but that indeterminate state is worse for him than a fully\ndetermined state where he has more money.\n\nTLDR It's not atomic so payer goes first.\n\nHope this helps! If not, let me know, say a bit more about what you think\nthe attack would be.\n\n-Tadge\n\nOn Mon, Nov 23, 2015 at 6:36 PM, Nicolas Dorier \u003cnicolas.dorier at gmail.com\u003e\nwrote:\n\n\u003e I am still learrning about Lightning Network, slowly but surely.\n\u003e As I was reviewing bip 112 (\n\u003e https://github.com/btcdrak/bips/blob/bip112sync/bip-0112.mediawiki) I\n\u003e noticed that HLTC seems to have a potential attack.\n\u003e\n\u003e When both parties want to revoke a commitment, they need to send one to\n\u003e another the revocation preimage.\n\u003e However, if not done atomically, Alice intentionally not send her\n\u003e revocation after receiving Bob's thus preventing Bob to withdraw his funds.\n\u003e\n\u003e Am I missing something ?\n\u003e\n\u003e The only way I see of fixing as is, is to require a third party expecting\n\u003e he does not collude, but this defeat the whole purpose.\n\u003e\n\u003e Nicolas,\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151123/fc57500a/attachment.html\u003e",
"sig": "3c20ccbe1f0fe530d4b6520491f6dc55a6dd610353ede7bcbd290087b55f1c187e8c2e2fe4c19d2605c9167abab4ce23463d54c872cee3d186b731b71234a792"
}