ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-06-25 📝 Original message: Good morning Ugam, > In ...
📅 Original date posted:2019-06-25
📝 Original message:
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:
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