RFC-3: What does a receiver do if they receive a transfer where the conditions in the transfer frame and the ILP packet are different?

[adrianhopebailie]

Do they fulfill both if they can? They are only incentivized to fulfill the one that gets them paid which means the one in the transfer frame.

The implication is that if any connector changes the condition in the transfer frame to be different then it's unlikely any downstream connector will change it back because they are financially disincentivised to do so.

We should have language in the spec that details this scenario and provides normative language for expected behavior (which should align with incentives, i.e. fulfill the condition in the transfer frame).

[justmoon]

This is a bit of a closer call than #74, but I would still say:

Receivers SHOULD reject the incoming transfer with the error "condition mismatch". Reason here is more around - there is probably something fishy going on if the ILP packet doesn't match the transfer. Again, "SHOULD" in case they know more than we do.

[adrianhopebailie]

If they do fulfill one of these which would it be?

Also, do we recommend that if they can fulfill both that they SHOULD?

Is there a protocol where a payment could be split over multiple routes?

[sharafian]

If the receiver tries to fulfill a condition that matches the ILP packet but not any local transfers, then their ledger will just reject the fulfillment.

[adrianhopebailie]

If the receiver tries to fulfill a condition that matches the ILP packet but not any local transfers, then their ledger will just reject the fulfillment.

Good point, so it's either both or just the one from the transfer.

[emschwartz]

@bensharaf is right. That also means there's no point fulfilling both because the one from the packet would be rejected by the ledger. So it should be the receiver either fulfills neither or only the one in the transfer.

[adrianhopebailie]

Conclusion is to remove condition from packet. Receiver will only ever get a single condition