{"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-13\n📝 Original message:\nGood morning Rusty,\n\nSomeone pointed out to me that `intended_payment_amount` is unnecessary.\nOn reflection, this is correct.\nBoth intermediate nodes and the payee node need not have `intended_payment_amount`.\n\nTherefore....\n\n\u003e \u003e I propose the below to support Base AMP.\n\u003e\n\u003e I think the complexity outweighs the benefits for the moment. The\n\u003e sender would have to make the onions identical past the merge point (so\n\u003e any one of them could be used), the merge point has to now create a\n\u003e many:1 map for HTLC redemption.\n\u003e\n\u003e For the moment, I think we should stick with:\n\u003e\n\u003e BOLT #4:\n\u003e\n\u003e 1.  type: `per_hop`\n\u003e 2.  data:\n\u003e     -   [`8`:`short_channel_id`]\n\u003e     -   [`8`:`amt_to_forward`]\n\u003e     -   [`4`:`outgoing_cltv_value`]\n\u003e\n\u003e -   -   [`12`:`padding`]\n\u003e\n\u003e -   -   [`1`:`flags`]\n\u003e -   -   [`11`:`padding`]\n\u003e\n\u003e         And define bit 0 of `flags` as `incomplete_payment`. For the moment, it\n\u003e         is only allowed for final nodes, and only if they put it in their BOLT11\n\u003e         field.\n\u003e\n\nWe can do something even simpler.\n\nIf `amt_to_forward` plus the fees charged by this node is greater than the actual incoming HTLC, this is an AMP attempt.\nNo additional flag needs to be added.\nFor final payment nodes, if the `amt_to_forward` is greater than the incoming HTLC value, this is an AMP attempt.\n\nThe 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\n---\n\nOf course, an explicit flag is more sensible as it is more explicit.\n\nFor 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.\nA 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.\nSo 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\nAn 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.\"\nAnother 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\nRegards,\nZmnSCPxj"}