From ZmnSCPxj at protonmail.com  Wed Nov 14 23:35:30 2018
From: ZmnSCPxj at protonmail.com (ZmnSCPxj)
Date: Wed, 14 Nov 2018 23:35:30 +0000
Subject: [Lightning-dev] Base AMP
In-Reply-To: <6l_O3yiAtE29jt_yQM7YgLDK1tJporWTYfFSo66ShgerplJ5DZD3bjZOxecx_61OvVGNdlV4XCahzWzLiAoEWQwitkW4PG6pDbNHWb4RY1E=@protonmail.com>
References: <RIltvk7eDURKE0wl7VdQs7Y1Rx_DoccGaxe1q5NgwWouzqzbwkX2jXx3rVDSgtSL33ZF2VFmO_bntGSrHUOtFSl7ta3-PTDAHgHQeyeSVEw=@protonmail.com>
	<87k1lgh5xx.fsf@rustcorp.com.au>
	<6l_O3yiAtE29jt_yQM7YgLDK1tJporWTYfFSo66ShgerplJ5DZD3bjZOxecx_61OvVGNdlV4XCahzWzLiAoEWQwitkW4PG6pDbNHWb4RY1E=@protonmail.com>
Message-ID: <DZaPsDY_HskxbmLZh1VrxFUSAXfFaKdguOOkfn6J8qgwhWopL8jvJdSauKjSKxgSWNz8tqBctH6Bbk11pTcRrrIfR8VNFKbLtGNOdfj8WVU=@protonmail.com>

Good morning list,

In case it was not noticed, I made a pull request for Base AMP: https://github.com/lightningnetwork/lightning-rfc/pull/511

This is primarily based on what Rusty suggested on-list, with sufficient MUST and SHOULD.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

??????? Original Message ???????
On Wednesday, November 14, 2018 9:59 AM, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:

> Good morning Rusty,
>
> Someone pointed out to me that `intended_payment_amount` is unnecessary.
> On reflection, this is correct.
> Both intermediate nodes and the payee node need not have `intended_payment_amount`.
>
> Therefore....
>
> > > I propose the below to support Base AMP.
> >
> > I think the complexity outweighs the benefits for the moment. The
> > sender would have to make the onions identical past the merge point (so
> > any one of them could be used), the merge point has to now create a
> > many:1 map for HTLC redemption.
> > For the moment, I think we should stick with:
> > BOLT #4:
> >
> > 1.  type: `per_hop`
> > 2.  data:
> >     -   [`8`:`short_channel_id`]
> >     -   [`8`:`amt_to_forward`]
> >     -   [`4`:`outgoing_cltv_value`]
> >
> > -   -   [`12`:`padding`]
> > -   -   [`1`:`flags`]
> > -   -   [`11`:`padding`]
> >         And define bit 0 of `flags` as `incomplete_payment`. For the moment, it
> >         is only allowed for final nodes, and only if they put it in their BOLT11
> >         field.
> >
>
> We can do something even simpler.
>
> If `amt_to_forward` plus the fees charged by this node is greater than the actual incoming HTLC, this is an AMP attempt.
> No additional flag needs to be added.
> For final payment nodes, if the `amt_to_forward` is greater than the incoming HTLC value, this is an AMP attempt.
>
> The previous node could try to probe this by offering a smaller amount than it was instructed to give, but cannot differentiate between a stall because the payee is waiting for an AMP, or a stall due to some other unrelated error.
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Of course, an explicit flag is more sensible as it is more explicit.
>
> For myself, I would rather a new `per_hop_type`, but whether to use a separate `per_hop_type` vs a byte in padding is largely a bikeshed issue and either is fine with me.
> A concern is that nothing in our current spec requires that `padding` be all 0, such that reinterpreting byte 0 to be flags could cause interoperability problems.
> So perhaps a new `per_hop_type` which has a 2-byte `flags` (for more future expansion) and a `padding` of 10 bytes which MUST be explicitly specced as "MUST be all 0".
>
> An explicit flags field would also allow delivery of higher-layer application data in each payment, for whatever purpose a higher-layer application may want. E.g. bit 1 could mean "the next hop 65 bytes is actually a 32-byte application ID and a 33-byte payload; this flag is valid only if this is the last hop."
> Another bit can also be used to provide spontaneous payment, so e.g. bit 2 could mean "this hop is the final hop (even if HMAC is nonzero); the HMAC of this hop is really the preimage to claim this payment."
>
> Regards,
> ZmnSCPxj
>
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev