{"type":"rich","version":"1.0","author_name":"npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","author_url":"https://nostr.ae/npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-02-06\n📝 Original message:\nHi ZmnSCPxj,\n\n\u003e This is excellent work!\n\nThanks!\n\n\u003e I think, a `globalfeatures` odd bit could be used for this.  As it is\n\u003e end-ot-end, `localfeatures` is not appropriate.\n\nYep, it would need to be a global feature bit. In the case that we're\nsending to a destination which isn't publicly advertised, then perhaps an\nextension to BOLT-11 could be made to signal receiver support.\n\n\u003e I believe, currently, fees have not this super-linear component\n\nYep they don't. Arguably, we should also have a component that scales\naccording to the proposed CLTV value of the outgoing HTLC. At Scaling\nBitcoin Stanford, Aviv Zohar gave a talked titled \"How to Charge Lightning\"\nwhere the authors analyzed the possible evolution of fees on the network\n(and also suggested adding this super-linear component to extend the\nlifetime of channels).  However, the talk itself focused on a very simple\n\"mega super duper hub\" topology. Towards the end he alluded to a forthcoming\npaper that had more comprehensive analysis of more complex topologies. I\nlook forward to the publication of their finalized work.\n\n\u003e Indeed, the existence of per-hop fees (`fee_base_msat`) means, splitting\n\u003e the payment over multiple flows will be, very likely, more expensive,\n\u003e compared to using a single flow.\n\nWell it's still to be seen how the fee structure on mainnet emerges once the\nnetwork is still fully bootstrapped. AFAIK, most running on mainnet atm are\nusing the default fee schedules for their respective implementations. For\nexample, the default fee_base_msat for lnd is 1000 msat (1 satoshi).\n\n\u003e I believe the `realm` byte is intended for this.\n\nThe realm byte is meant to signal \"forward this to the dogecoin channel\".\nATM, we just default to 0 as \"Bitcoin\". However, the byte itself only really\nneed significance between the sender and the intermediate node. So there\nisn't necessarily pressure to have a globally synchronized set of realm\nbytes.\n\n\u003e Thus, you can route over nodes that are unaware of AMP, and only provide\n\u003e an AMP realm byte to the destination node, who, is able to reconstruct\nthis\n\u003e your AMP data as per your algorithm.\n\nYes, the intermediate nodes don't need to be aware of the end-to-end\nprotocol. For the final hop, there are actually 53 free bytes (before one\nneeds to signal the existence of EOBs):\n\n  * 1 byte realm\n  * 8 bytes next addr (all zeroes to signal final dest)\n  * 32 bytes hmac (also all zeroes for the final dest)\n  * 12 bytes padding\n\nSo any combo of these bytes can be used to signal more advanced protocols to\nthe final destination.\n\n\nA correction from the prior email description:\n\n\u003e We can further modify our usage of the per-hop payloads to send\n\u003e (H(BP), s_i) to consume most of the EOB sent from sender to receiver.\n\nThis should actually be (H(s_0 || s_1 || ...), s_i). So we still allow them\nto check this finger print to see if they have all the final shares, but\ndon't allow them to preemptively pull all the payments.\n\n\n-- Laolu\n\n\nOn Mon, Feb 5, 2018 at 11:12 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning Laolu,\n\u003e\n\u003e This is excellent work!\n\u003e\n\u003e Some minor comments...\n\u003e\n\u003e\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\n\u003e changes\n\u003e to the protocol as is now, as the negotiation is strictly *end-to-end*\n\u003e between sender and receiver.\n\u003e\n\u003e\n\u003e I think, a `globalfeatures` odd bit could be used for this.  As it is\n\u003e end-ot-end, `localfeatures` is not appropriate.\n\u003e\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\u003e\n\u003e\n\u003e I believe, currently, fees have not this super-linear component.  Indeed,\n\u003e the existence of per-hop fees (`fee_base_msat`) means, splitting the\n\u003e payment over multiple flows will be, very likely, more expensive, compared\n\u003e to using a single flow.  Tiny roundoffs in computing the proportional fees\n\u003e (`fee_proportional_millionths`) may make smaller flows give a slight fee\n\u003e advantage, but I think the multiplication of per-hop fees will dominate.\n\u003e\n\u003e\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\u003e\n\u003e\n\u003e Strongly agree!\n\u003e\n\u003e\n\u003e In order to include the three tuple within the per-hop payload for the\n\u003e 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\u003e\n\u003e\n\u003e I believe the `realm` byte is intended for this.  Intermediate nodes do\n\u003e not need to understand realm bytes that are understood by other nodes in\n\u003e the route, including the realm bytes understood by the final destination,\n\u003e as intermediate nodes cannot, indeed, read the hop data of other nodes.\n\u003e Thus, you can route over nodes that are unaware of AMP, and only provide an\n\u003e AMP realm byte to the destination node, who, is able to reconstruct this\n\u003e your AMP data as per your algorithm.\n\u003e\n\u003e Indeed, the `realm` byte controls the interpretation of the rest of the\n\u003e 65-byte packet.  If you define, instead, a separate `realm` that is\n\u003e understood by the destination node, you can redefine the entire 64 bytes of\n\u003e the final hop data as you wish.\n\u003e\n\u003e If we support AMP only at final payees, we can completely redefine the 64\n\u003e bytes in the final hop data for the new AMP `realm`, and not consume the\n\u003e next hop (which would reduce route length by 1).\n\u003e\n\u003e (If we want to support multiple routes converging to an intermediate node,\n\u003e then continue routing to a different final node after routes have merged\n\u003e (i.e. A-\u003eB-\u003eC-\u003eD, and A-\u003eE-\u003eC-\u003eD, with the payment being merged by C, who\n\u003e forwards the combination to D), then we need to follow the current hop data\n\u003e format, but I think supporting AMP at final payees is actually enough...\n\u003e AMP at intermediate nodes might not be used often enough by senders for it\n\u003e to matter, as taking advantage of that seems more complex than just asking\n\u003e your routing algo to provide you multiple routes to a destination, which\n\u003e you are probably already doing)\n\u003e\n\u003e ----\n\u003e\n\u003e Overall, good work I think.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180207/3e9cf18e/attachment.html\u003e"}