ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-13 📝 Original message: Good morning Johan, Merge ...
📅 Original date posted:2018-11-13
📝 Original message:
Good morning Johan,
Merge nodes will prefer to wait until the entire payment is available and committed to as HTLCs, before doing any claims.
I believe it was mentioned that one of us figured it out (prior to the summit) that such a thing was what a merge point would rationally want.
We assume the proof-of-payment is valuable (an example being the "Vending machine" I recorded on the list, where release of a proof-of-payment triggers release of product from vending machine).
If the ultimate payee has not received all payments, then it would be very irrational of it to claim a partial payment, since it would release the proof-of-payment for a value less than the value implied by the invoice.
Similarly, if an intermediate node is a merge point for an AMP, it would forward a value.
If that value is greater than the current total value merging into it, it would be very irrational of it to forward the value until it has assurances it can claim all values in a commitment transaction.
The atomicity here is only "economically rational atomicity" and not "information theoretical atomicity", but it *is* atomicity.
Regards,
ZmnSCPxj
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, November 14, 2018 12:33 AM, Johan Torås Halseth <johanth at gmail.com> wrote:
> Good evening Z and list,
>
> I'm wondering, since these payments are no longer atomic, should we name it accordingly?
>
> Cheers,
> Johan
>
> On Tue, Nov 13, 2018 at 1:28 PM ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
>> Good morning list,
>>
>> I propose the below to support Base AMP.
>>
>> The below would allow arbitrary merges of paths, but not arbitrary splits. I am uncertain about the safety of arbitrary splits.
>>
>> ### The `multipath_merge_per_hop` type (`option_base_amp`)
>>
>> This indicates that payment has been split by the sender using Base AMP, and that the receiver should wait for the total intended payment before forwarding or claiming the payment.
>> In case the receiving node is not the last node in the path, then succeeding hops MUST be the same across all splits.
>>
>> 1. type: 1 (`termination_per_hop`)
>> 2. data:
>> * [`8` : `short_channel_id`]
>> * [`8` : `amt_to_forward`]
>> * [`4` : `outgoing_cltv_value`]
>> * [`8` : `intended_total_payment`]
>> * [`4` : `zeros`]
>>
>> The contents of this hop will be the same across all paths of the Base AMP.
>> The `payment_hash` of the incoming HTLCs will also be the same across all paths of the Base AMP.
>>
>> `intended_total_payment` is the total amount of money that this node should expect to receive in all incoming paths to the same `payment_hash`.
>>
>> This may be the last hop of a payment onion, in which case the `HMAC` for this hop will be `0` (the same rule as for `per_hop_type` 0).
>>
>> The receiver:
>>
>> * MUST impose a reasonable timeout for waiting to receive all component paths, and fail all incoming HTLC offers for the `payment_hash` if they have not totalled equal to `intended_total_payment`.
>> * MUST NOT forward (if an intermediate node) or claim (if the final node) unless it has received a total greater or equal to `intended_total_payment` in all incoming HTLCs for the same `payment_hash`.
>>
>> The sender:
>>
>> * MUST use the same `payment_hash` for all paths of a single multipath payment.
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> 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/20181113/89fe254e/attachment.html>;
📝 Original message:
Good morning Johan,
Merge nodes will prefer to wait until the entire payment is available and committed to as HTLCs, before doing any claims.
I believe it was mentioned that one of us figured it out (prior to the summit) that such a thing was what a merge point would rationally want.
We assume the proof-of-payment is valuable (an example being the "Vending machine" I recorded on the list, where release of a proof-of-payment triggers release of product from vending machine).
If the ultimate payee has not received all payments, then it would be very irrational of it to claim a partial payment, since it would release the proof-of-payment for a value less than the value implied by the invoice.
Similarly, if an intermediate node is a merge point for an AMP, it would forward a value.
If that value is greater than the current total value merging into it, it would be very irrational of it to forward the value until it has assurances it can claim all values in a commitment transaction.
The atomicity here is only "economically rational atomicity" and not "information theoretical atomicity", but it *is* atomicity.
Regards,
ZmnSCPxj
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, November 14, 2018 12:33 AM, Johan Torås Halseth <johanth at gmail.com> wrote:
> Good evening Z and list,
>
> I'm wondering, since these payments are no longer atomic, should we name it accordingly?
>
> Cheers,
> Johan
>
> On Tue, Nov 13, 2018 at 1:28 PM ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
>> Good morning list,
>>
>> I propose the below to support Base AMP.
>>
>> The below would allow arbitrary merges of paths, but not arbitrary splits. I am uncertain about the safety of arbitrary splits.
>>
>> ### The `multipath_merge_per_hop` type (`option_base_amp`)
>>
>> This indicates that payment has been split by the sender using Base AMP, and that the receiver should wait for the total intended payment before forwarding or claiming the payment.
>> In case the receiving node is not the last node in the path, then succeeding hops MUST be the same across all splits.
>>
>> 1. type: 1 (`termination_per_hop`)
>> 2. data:
>> * [`8` : `short_channel_id`]
>> * [`8` : `amt_to_forward`]
>> * [`4` : `outgoing_cltv_value`]
>> * [`8` : `intended_total_payment`]
>> * [`4` : `zeros`]
>>
>> The contents of this hop will be the same across all paths of the Base AMP.
>> The `payment_hash` of the incoming HTLCs will also be the same across all paths of the Base AMP.
>>
>> `intended_total_payment` is the total amount of money that this node should expect to receive in all incoming paths to the same `payment_hash`.
>>
>> This may be the last hop of a payment onion, in which case the `HMAC` for this hop will be `0` (the same rule as for `per_hop_type` 0).
>>
>> The receiver:
>>
>> * MUST impose a reasonable timeout for waiting to receive all component paths, and fail all incoming HTLC offers for the `payment_hash` if they have not totalled equal to `intended_total_payment`.
>> * MUST NOT forward (if an intermediate node) or claim (if the final node) unless it has received a total greater or equal to `intended_total_payment` in all incoming HTLCs for the same `payment_hash`.
>>
>> The sender:
>>
>> * MUST use the same `payment_hash` for all paths of a single multipath payment.
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> 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/20181113/89fe254e/attachment.html>;