Ugam Kamat [ARCHIVE] on Nostr: 📅 Original date posted:2019-06-26 📝 Original message: Hey ZmnSCPxj, Really ...
📅 Original date posted:2019-06-26
📝 Original message:
Hey ZmnSCPxj,
Really appreciate your efforts in going through the proposal in depth. The two choices you mentioned for the proposal are a really fair analysis of how an attack can be launched on such forked away payments. In the current scheme, it seems it will create problems rather than solve it. I'll try to do some more work and see if I can come up with a more solid way in order to achieve this. Thanks again.
Ugam
-----Original Message-----
From: ZmnSCPxj <ZmnSCPxj at protonmail.com>
Sent: Wednesday, June 26, 2019 4:35 AM
To: ZmnSCPxj <ZmnSCPxj at protonmail.com>
Cc: René Pickhardt <r.pickhardt at googlemail.com>; Ugam Kamat <ugamkamat1 at gmail.com>; lightning-dev <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] [PROPOSAL]: FAST - Forked Away Simultaneous Transactions
Good morning Ugam,
> In any case, this is effectively simply creation of fork points and join points along a multipart path.
> That the payment does not later join is merely a detail, especially once we get to "high" AMP (which requires payment points / scalars).
> We decided at previous dev summit not to implement this due to complexity-of-implementation for payers, as well as how to resolve when one branch fails while the other branch claims the payment.
On reflection, that there is no later join means that this scheme allows attack.
We have two choices:
1. Both forked branches have to succeed in order for the fork node to claim its incoming payment.
2. Either forked branch can succeed and the fork node can claim its incoming payment.
If we go with 1:
* Fork nodes can be attacked by routing a self-payment through a fork node, with the other branch going nowhere (give it an unuseable preimage).
Claim the branch that goes to yourself, then wait for your outgoing payment to lapse.
The fork node is forced to pay one branch but is unable to claim its incoming payment.
Attacker earns free money.
If we go with 2:
* Fork nodes can attack opportunistically, by only paying out to the smaller-valued branch.
Once the smaller-valued branch succeeds, the fork node can claim its incoming payment and forget about the other branch of the payment.
* This is the choice made for multipart payments.
However, note that in multipart, there is always a later join (most likely at the ultimate, *single* destination).
The join will not succeed unless both incoming payments arrive, so fork nodes cannot perform this attack opportunistically.
A plausible fix for your scheme would be to take choice 2 (either branch succeeding lets fork node claim incoming payment).
Then Eric and Grace need to cooperate and only take incoming payment if both of them receive incoming payments.
This implies Eric and Grace must trust each other to coordinate.
Regards,
ZmnSCPxj
📝 Original message:
Hey ZmnSCPxj,
Really appreciate your efforts in going through the proposal in depth. The two choices you mentioned for the proposal are a really fair analysis of how an attack can be launched on such forked away payments. In the current scheme, it seems it will create problems rather than solve it. I'll try to do some more work and see if I can come up with a more solid way in order to achieve this. Thanks again.
Ugam
-----Original Message-----
From: ZmnSCPxj <ZmnSCPxj at protonmail.com>
Sent: Wednesday, June 26, 2019 4:35 AM
To: ZmnSCPxj <ZmnSCPxj at protonmail.com>
Cc: René Pickhardt <r.pickhardt at googlemail.com>; Ugam Kamat <ugamkamat1 at gmail.com>; lightning-dev <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] [PROPOSAL]: FAST - Forked Away Simultaneous Transactions
Good morning Ugam,
> In any case, this is effectively simply creation of fork points and join points along a multipart path.
> That the payment does not later join is merely a detail, especially once we get to "high" AMP (which requires payment points / scalars).
> We decided at previous dev summit not to implement this due to complexity-of-implementation for payers, as well as how to resolve when one branch fails while the other branch claims the payment.
On reflection, that there is no later join means that this scheme allows attack.
We have two choices:
1. Both forked branches have to succeed in order for the fork node to claim its incoming payment.
2. Either forked branch can succeed and the fork node can claim its incoming payment.
If we go with 1:
* Fork nodes can be attacked by routing a self-payment through a fork node, with the other branch going nowhere (give it an unuseable preimage).
Claim the branch that goes to yourself, then wait for your outgoing payment to lapse.
The fork node is forced to pay one branch but is unable to claim its incoming payment.
Attacker earns free money.
If we go with 2:
* Fork nodes can attack opportunistically, by only paying out to the smaller-valued branch.
Once the smaller-valued branch succeeds, the fork node can claim its incoming payment and forget about the other branch of the payment.
* This is the choice made for multipart payments.
However, note that in multipart, there is always a later join (most likely at the ultimate, *single* destination).
The join will not succeed unless both incoming payments arrive, so fork nodes cannot perform this attack opportunistically.
A plausible fix for your scheme would be to take choice 2 (either branch succeeding lets fork node claim incoming payment).
Then Eric and Grace need to cooperate and only take incoming payment if both of them receive incoming payments.
This implies Eric and Grace must trust each other to coordinate.
Regards,
ZmnSCPxj