{"type":"rich","version":"1.0","title":"Rusty Russell [ARCHIVE] wrote","author_name":"Rusty Russell [ARCHIVE] (npub1zw…hkhpx)","author_url":"https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2018-11-13\n📝 Original message:\nZmnSCPxj via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e writes:\n\u003e Good morning list,\n\u003e\n\u003e I propose the below to support Base AMP.\n\nI think the complexity outweighs the benefits for the moment.  The\nsender would have to make the onions identical past the merge point (so\nany one of them could be used), the merge point has to now create a\nmany:1 map for HTLC redemption.\n\nFor the moment, I think we should stick with:\n\nBOLT #4:\n1. type: `per_hop`\n2. data:\n   * [`8`:`short_channel_id`]\n   * [`8`:`amt_to_forward`]\n   * [`4`:`outgoing_cltv_value`]\n-  * [`12`:`padding`]\n+  * [`1`:`flags`]\n+  * [`11`:`padding`]\n\nAnd define bit 0 of `flags` as `incomplete_payment`.  For the moment, it\nis only allowed for final nodes, and only if they put it in their BOLT11\nfield.\n\nBOLT #11:\n\n   * `9` (5): `data_length` variable.  Features supported for receiving\n     this payment.  Currently only `wait_on_incomplete` (bit 1) is defined.\n\n...\n\n-A writer SHOULD use the minimum `data_length` possible for `x` and `c` fields.\n+A writer SHOULD use the minimum `data_length` possible for `x`, `c` and\n`9` fields, omitting the field entirely if possible.\n...\n\nA payer MUST ignore unknown odd bits are set in the `9` field, and\nNOT try to make a payment if unknown even bits are set in the `9` field.\n\nCheers,\nRusty."}