{"type":"rich","version":"1.0","author_name":"npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","author_url":"https://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-02-06\n📝 Original message:\nGood morning Laolu,\n\nThis is excellent work!\n\nSome minor comments...\n\n\u003e (Atomic Multi-path Payments). It can be experimented with on Lightning\n\u003e *today* with the addition of a new feature bit to gate this new\n\u003e feature. The beauty of the scheme is that it requires no fundamental changes\n\u003e to the protocol as is now, as the negotiation is strictly *end-to-end*\n\u003e between sender and receiver.\n\nI think, a `globalfeatures` odd bit could be used for this.  As it is end-ot-end, `localfeatures` is not appropriate.\n\n\u003e   - Potential fee savings for larger payments, contingent on there being a\n\u003e     super-linear component to routed fees. It's possible that with\n\u003e     modifications to the fee schedule, it's actually *cheaper* to send\n\u003e     payments over multiple flows rather than one giant flow.\n\nI believe, currently, fees have not this super-linear component.  Indeed, the existence of per-hop fees (`fee_base_msat`) means, splitting the payment over multiple flows will be, very likely, more expensive, compared to using a single flow.  Tiny roundoffs in computing the proportional fees (`fee_proportional_millionths`) may make smaller flows give a slight fee advantage, but I think the multiplication of per-hop fees will dominate.\n\n\u003e   - Using smaller payments increases the set of possible paths a partial\n\u003e     payment could have taken, which reduces the effectiveness of static\n\u003e     analysis techniques involving channel capacities and the plaintext\n\u003e     values being forwarded.\n\nStrongly agree!\n\n\u003e In order to include the three tuple within the per-hop payload for the final\n\u003e destination, we repurpose the _first_ byte of the un-used padding bytes in\n\u003e the payload to signal version 0x01 of the AMP protocol (note this is a PoC\n\u003e outline, we would need to standardize signalling of these 12 bytes to\n\u003e support other protocols).\n\nI believe the `realm` byte is intended for this.  Intermediate nodes do not need to understand realm bytes that are understood by other nodes in the route, including the realm bytes understood by the final destination, as intermediate nodes cannot, indeed, read the hop data of other nodes.  Thus, you can route over nodes that are unaware of AMP, and only provide an AMP realm byte to the destination node, who, is able to reconstruct this your AMP data as per your algorithm.\n\nIndeed, the `realm` byte controls the interpretation of the rest of the 65-byte packet.  If you define, instead, a separate `realm` that is understood by the destination node, you can redefine the entire 64 bytes of the final hop data as you wish.\n\nIf we support AMP only at final payees, we can completely redefine the 64 bytes in the final hop data for the new AMP `realm`, and not consume the next hop (which would reduce route length by 1).\n\n(If we want to support multiple routes converging to an intermediate node, then continue routing to a different final node after routes have merged (i.e. A-\u003eB-\u003eC-\u003eD, and A-\u003eE-\u003eC-\u003eD, with the payment being merged by C, who forwards the combination to D), then we need to follow the current hop data format, but I think supporting AMP at final payees is actually enough... AMP at intermediate nodes might not be used often enough by senders for it to matter, as taking advantage of that seems more complex than just asking your routing algo to provide you multiple routes to a destination, which you are probably already doing)\n\n----\n\nOverall, good work I think.\n\nRegards,\nZmnSCPxj\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180206/3dcd9d0b/attachment.html\u003e"}