{"type":"rich","version":"1.0","author_name":"npub1ncnj8arudstdxzfhxk7k4nwgkrw3hyw8sgt0wqqmm5hh2c4knmgs2lqt2n","author_url":"https://nostr.ae/npub1ncnj8arudstdxzfhxk7k4nwgkrw3hyw8sgt0wqqmm5hh2c4knmgs2lqt2n","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-02-07\n📝 Original message:\nThis is a really neat idea.\n\nThis is a question about non-interactive payments in general, but is there\nany way to get a proof of payment? With regular invoices, knowledge of the\npreimage serves as cryptographic proof that the payment was delivered.\n\nOn Feb 6, 2018 6:26 PM, \"Conner Fromknecht\" \u003cconner at lightning.engineering\u003e\nwrote:\n\n\u003e\n\u003e Hi ZmnSCPxj and Laolu,\n\u003e\n\u003e \u003e  Indeed, the existence of per-hop fees (`fee_base_msat`) means,\n\u003e splitting the\n\u003e \u003e  payment over multiple flows will be, very likely, more expensive,\n\u003e compared to\n\u003e \u003e  using a single flow.\n\u003e\n\u003e As Laolu pointed out, we have yet to see how fees evolve on mainnet or\n\u003e what will\n\u003e emerge as a sane, default fee schedules. I agree that if the same\n\u003e proportional\n\u003e fee is used across all partial payments, then it could certainly be more\n\u003e expensive.\n\u003e\n\u003e However, it could also be the case that you were paying a needlessly high\n\u003e proportional fee to begin with, because paths of sufficient capacity to the\n\u003e destination were scarce. In an AMP world, there will be an abundance of\n\u003e channels\n\u003e that can route small, partial payments, which may itself drive down the\n\u003e competitive fee rate for smaller payments. Just a hypothesis, we shall see\n\u003e where\n\u003e supply meets demand!\n\u003e\n\u003e At the end of the day, the user can always fall back to regular payment if\n\u003e they\n\u003e expect to end up paying more fees using an AMP.\n\u003e\n\u003e \u003e (If we want to support multiple routes converging to an intermediate\n\u003e node,\n\u003e \u003e then continue routing to a different final node after routes have merged\n\u003e (i.e.\n\u003e \u003e A-\u003eB-\u003eC-\u003eD, and A-\u003eE-\u003eC-\u003eD, with the payment being merged by C, who\n\u003e forwards\n\u003e \u003e the combination to D), then we need to follow the current hop data\n\u003e format, but\n\u003e \u003e I think supporting AMP at final payees is actually enough...\n\u003e\n\u003e I think this is an interesting idea, sounds maybe like a\n\u003e recursive/hierarchical\n\u003e AMP? The ability to merge the payments seems like it would result in a\n\u003e decent privacy\n\u003e leak, as I believe an intermediary would have enough evidence to prove\n\u003e that two\n\u003e payments were merged/correlated. Simple traffic analysis would also reveal\n\u003e a\n\u003e discrepancy in the number of incoming and outgoing packets, and possibly\n\u003e other\n\u003e observable differences in routing (some) AMPs vs regular payments.\n\u003e\n\u003e FWIW the current proposal allows the paths of partial payments to overlap,\n\u003e in such a scenario C would just forward the HTLCs independently. One could\n\u003e send\n\u003e them all along the same path if they desired! I'm assuming the intent here\n\u003e is to\n\u003e try and reduce total fees?\n\u003e\n\u003e Minor correction^2:\n\u003e\n\u003e \u003e This should actually be (H(s_0 || s_1 || ...), s_i).\n\u003e\n\u003e This assumes the receiver knows the indexes of each share. Without this\n\u003e knowledge they would have to brute force all orderings to check the\n\u003e fingerprint.\n\u003e\n\u003e To maintain order invariance on the receiving end, I would propose sending\n\u003e (0, s_i) for the first n-1 partial payments, and then (n, s_i) on the\n\u003e final one.\n\u003e As in the description of the basic AMP scheme, the receiver maintains a\n\u003e persistent count of how many partial payments have been received for ID.\n\u003e If the\n\u003e receiver does not get the last payment last, the receiver just waits until\n\u003e all n\n\u003e have been received before deciding that its reconstructed value is BP.\n\u003e\n\u003e The receiver can verify they've received the correct BP and n by\n\u003e rederiving the\n\u003e partial preimages r_i = H(BP || i) and checking that there are n\n\u003e outstanding\n\u003e payments, one for each h_i = H(r_i). This also saves the receiving node n\n\u003e additional hash invocations.\n\u003e\n\u003e -Conner\n\u003e\n\u003e On Tue, Feb 6, 2018 at 4:04 PM Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Hi ZmnSCPxj,\n\u003e\u003e\n\u003e\u003e \u003e This is excellent work!\n\u003e\u003e\n\u003e\u003e Thanks!\n\u003e\u003e\n\u003e\u003e \u003e I think, a `globalfeatures` odd bit could be used for this.  As it is\n\u003e\u003e \u003e end-ot-end, `localfeatures` is not appropriate.\n\u003e\u003e\n\u003e\u003e Yep, it would need to be a global feature bit. In the case that we're\n\u003e\u003e sending to a destination which isn't publicly advertised, then perhaps an\n\u003e\u003e extension to BOLT-11 could be made to signal receiver support.\n\u003e\u003e\n\u003e\u003e \u003e I believe, currently, fees have not this super-linear component\n\u003e\u003e\n\u003e\u003e Yep they don't. Arguably, we should also have a component that scales\n\u003e\u003e according to the proposed CLTV value of the outgoing HTLC. At Scaling\n\u003e\u003e Bitcoin Stanford, Aviv Zohar gave a talked titled \"How to Charge\n\u003e\u003e Lightning\"\n\u003e\u003e where the authors analyzed the possible evolution of fees on the network\n\u003e\u003e (and also suggested adding this super-linear component to extend the\n\u003e\u003e lifetime of channels).  However, the talk itself focused on a very simple\n\u003e\u003e \"mega super duper hub\" topology. Towards the end he alluded to a\n\u003e\u003e forthcoming\n\u003e\u003e paper that had more comprehensive analysis of more complex topologies. I\n\u003e\u003e look forward to the publication of their finalized work.\n\u003e\u003e\n\u003e\u003e \u003e Indeed, the existence of per-hop fees (`fee_base_msat`) means, splitting\n\u003e\u003e \u003e the payment over multiple flows will be, very likely, more expensive,\n\u003e\u003e \u003e compared to using a single flow.\n\u003e\u003e\n\u003e\u003e Well it's still to be seen how the fee structure on mainnet emerges once\n\u003e\u003e the\n\u003e\u003e network is still fully bootstrapped. AFAIK, most running on mainnet atm\n\u003e\u003e are\n\u003e\u003e using the default fee schedules for their respective implementations. For\n\u003e\u003e example, the default fee_base_msat for lnd is 1000 msat (1 satoshi).\n\u003e\u003e\n\u003e\u003e \u003e I believe the `realm` byte is intended for this.\n\u003e\u003e\n\u003e\u003e The realm byte is meant to signal \"forward this to the dogecoin channel\".\n\u003e\u003e ATM, we just default to 0 as \"Bitcoin\". However, the byte itself only\n\u003e\u003e really\n\u003e\u003e need significance between the sender and the intermediate node. So there\n\u003e\u003e isn't necessarily pressure to have a globally synchronized set of realm\n\u003e\u003e bytes.\n\u003e\u003e\n\u003e\u003e \u003e Thus, you can route over nodes that are unaware of AMP, and only provide\n\u003e\u003e \u003e an AMP realm byte to the destination node, who, is able to reconstruct\n\u003e\u003e this\n\u003e\u003e \u003e your AMP data as per your algorithm.\n\u003e\u003e\n\u003e\u003e Yes, the intermediate nodes don't need to be aware of the end-to-end\n\u003e\u003e protocol. For the final hop, there are actually 53 free bytes (before one\n\u003e\u003e needs to signal the existence of EOBs):\n\u003e\u003e\n\u003e\u003e   * 1 byte realm\n\u003e\u003e   * 8 bytes next addr (all zeroes to signal final dest)\n\u003e\u003e   * 32 bytes hmac (also all zeroes for the final dest)\n\u003e\u003e   * 12 bytes padding\n\u003e\u003e\n\u003e\u003e So any combo of these bytes can be used to signal more advanced protocols\n\u003e\u003e to\n\u003e\u003e the final destination.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e A correction from the prior email description:\n\u003e\u003e\n\u003e\u003e \u003e We can further modify our usage of the per-hop payloads to send\n\u003e\u003e \u003e (H(BP), s_i) to consume most of the EOB sent from sender to receiver.\n\u003e\u003e\n\u003e\u003e This should actually be (H(s_0 || s_1 || ...), s_i). So we still allow\n\u003e\u003e them\n\u003e\u003e to check this finger print to see if they have all the final shares, but\n\u003e\u003e don't allow them to preemptively pull all the payments.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e -- Laolu\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Mon, Feb 5, 2018 at 11:12 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Good morning Laolu,\n\u003e\u003e\u003e\n\u003e\u003e\u003e This is excellent work!\n\u003e\u003e\u003e\n\u003e\u003e\u003e Some minor comments...\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e (Atomic Multi-path Payments). It can be experimented with on Lightning\n\u003e\u003e\u003e *today* with the addition of a new feature bit to gate this new\n\u003e\u003e\u003e feature. The beauty of the scheme is that it requires no fundamental\n\u003e\u003e\u003e changes\n\u003e\u003e\u003e to the protocol as is now, as the negotiation is strictly *end-to-end*\n\u003e\u003e\u003e between sender and receiver.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e I think, a `globalfeatures` odd bit could be used for this.  As it is\n\u003e\u003e\u003e end-ot-end, `localfeatures` is not appropriate.\n\u003e\u003e\u003e\n\u003e\u003e\u003e   - Potential fee savings for larger payments, contingent on there being\n\u003e\u003e\u003e a\n\u003e\u003e\u003e     super-linear component to routed fees. It's possible that with\n\u003e\u003e\u003e     modifications to the fee schedule, it's actually *cheaper* to send\n\u003e\u003e\u003e     payments over multiple flows rather than one giant flow.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e I believe, currently, fees have not this super-linear component.\n\u003e\u003e\u003e Indeed, the existence of per-hop fees (`fee_base_msat`) means, splitting\n\u003e\u003e\u003e the payment over multiple flows will be, very likely, more expensive,\n\u003e\u003e\u003e compared to using a single flow.  Tiny roundoffs in computing the\n\u003e\u003e\u003e proportional fees (`fee_proportional_millionths`) may make smaller\n\u003e\u003e\u003e flows give a slight fee advantage, but I think the multiplication of\n\u003e\u003e\u003e per-hop fees will dominate.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e   - Using smaller payments increases the set of possible paths a partial\n\u003e\u003e\u003e     payment could have taken, which reduces the effectiveness of static\n\u003e\u003e\u003e     analysis techniques involving channel capacities and the plaintext\n\u003e\u003e\u003e     values being forwarded.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e Strongly agree!\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e In order to include the three tuple within the per-hop payload for the\n\u003e\u003e\u003e final\n\u003e\u003e\u003e destination, we repurpose the _first_ byte of the un-used padding bytes\n\u003e\u003e\u003e in\n\u003e\u003e\u003e the payload to signal version 0x01 of the AMP protocol (note this is a\n\u003e\u003e\u003e PoC\n\u003e\u003e\u003e outline, we would need to standardize signalling of these 12 bytes to\n\u003e\u003e\u003e support other protocols).\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e I believe the `realm` byte is intended for this.  Intermediate nodes do\n\u003e\u003e\u003e not need to understand realm bytes that are understood by other nodes in\n\u003e\u003e\u003e the route, including the realm bytes understood by the final destination,\n\u003e\u003e\u003e as intermediate nodes cannot, indeed, read the hop data of other nodes.\n\u003e\u003e\u003e Thus, you can route over nodes that are unaware of AMP, and only provide an\n\u003e\u003e\u003e AMP realm byte to the destination node, who, is able to reconstruct this\n\u003e\u003e\u003e your AMP data as per your algorithm.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Indeed, the `realm` byte controls the interpretation of the rest of the\n\u003e\u003e\u003e 65-byte packet.  If you define, instead, a separate `realm` that is\n\u003e\u003e\u003e understood by the destination node, you can redefine the entire 64 bytes of\n\u003e\u003e\u003e the final hop data as you wish.\n\u003e\u003e\u003e\n\u003e\u003e\u003e If we support AMP only at final payees, we can completely redefine the\n\u003e\u003e\u003e 64 bytes in the final hop data for the new AMP `realm`, and not consume the\n\u003e\u003e\u003e next hop (which would reduce route length by 1).\n\u003e\u003e\u003e\n\u003e\u003e\u003e (If we want to support multiple routes converging to an intermediate\n\u003e\u003e\u003e node, then continue routing to a different final node after routes have\n\u003e\u003e\u003e merged (i.e. A-\u003eB-\u003eC-\u003eD, and A-\u003eE-\u003eC-\u003eD, with the payment being merged by\n\u003e\u003e\u003e C, who forwards the combination to D), then we need to follow the current\n\u003e\u003e\u003e hop data format, but I think supporting AMP at final payees is actually\n\u003e\u003e\u003e enough... AMP at intermediate nodes might not be used often enough by\n\u003e\u003e\u003e senders for it to matter, as taking advantage of that seems more complex\n\u003e\u003e\u003e than just asking your routing algo to provide you multiple routes to a\n\u003e\u003e\u003e destination, which you are probably already doing)\n\u003e\u003e\u003e\n\u003e\u003e\u003e ----\n\u003e\u003e\u003e\n\u003e\u003e\u003e Overall, good work I think.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Regards,\n\u003e\u003e\u003e ZmnSCPxj\n\u003e\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\n\u003e\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\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180207/48a507f8/attachment-0001.html\u003e"}