{"type":"rich","version":"1.0","title":"ZmnSCPxj [ARCHIVE] wrote","author_name":"ZmnSCPxj [ARCHIVE] (npub1g5…3ms3l)","author_url":"https://yabu.me/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2018-11-14\n📝 Original message:\nGood morning list,\n\nIn case it was not noticed, I made a pull request for Base AMP: https://github.com/lightningnetwork/lightning-rfc/pull/511\n\nThis is primarily based on what Rusty suggested on-list, with sufficient MUST and SHOULD.\n\nRegards,\nZmnSCPxj\n\n\nSent with ProtonMail Secure Email.\n\n‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐\nOn Wednesday, November 14, 2018 9:59 AM, ZmnSCPxj via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning Rusty,\n\u003e\n\u003e Someone pointed out to me that `intended_payment_amount` is unnecessary.\n\u003e On reflection, this is correct.\n\u003e Both intermediate nodes and the payee node need not have `intended_payment_amount`.\n\u003e\n\u003e Therefore....\n\u003e\n\u003e \u003e \u003e I propose the below to support Base AMP.\n\u003e \u003e\n\u003e \u003e I think the complexity outweighs the benefits for the moment. The\n\u003e \u003e sender would have to make the onions identical past the merge point (so\n\u003e \u003e any one of them could be used), the merge point has to now create a\n\u003e \u003e many:1 map for HTLC redemption.\n\u003e \u003e For the moment, I think we should stick with:\n\u003e \u003e BOLT #4:\n\u003e \u003e\n\u003e \u003e 1.  type: `per_hop`\n\u003e \u003e 2.  data:\n\u003e \u003e     -   [`8`:`short_channel_id`]\n\u003e \u003e     -   [`8`:`amt_to_forward`]\n\u003e \u003e     -   [`4`:`outgoing_cltv_value`]\n\u003e \u003e\n\u003e \u003e -   -   [`12`:`padding`]\n\u003e \u003e -   -   [`1`:`flags`]\n\u003e \u003e -   -   [`11`:`padding`]\n\u003e \u003e         And define bit 0 of `flags` as `incomplete_payment`. For the moment, it\n\u003e \u003e         is only allowed for final nodes, and only if they put it in their BOLT11\n\u003e \u003e         field.\n\u003e \u003e\n\u003e\n\u003e We can do something even simpler.\n\u003e\n\u003e If `amt_to_forward` plus the fees charged by this node is greater than the actual incoming HTLC, this is an AMP attempt.\n\u003e No additional flag needs to be added.\n\u003e For final payment nodes, if the `amt_to_forward` is greater than the incoming HTLC value, this is an AMP attempt.\n\u003e\n\u003e 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.\n\u003e\n\u003e --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\n\u003e\n\u003e Of course, an explicit flag is more sensible as it is more explicit.\n\u003e\n\u003e 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.\n\u003e 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.\n\u003e 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\".\n\u003e\n\u003e 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.\"\n\u003e 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.\"\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev"}