Ugam Kamat [ARCHIVE] on Nostr: 📅 Original date posted:2019-06-25 📝 Original message: Hey Rene, thanks for your ...
📅 Original date posted:2019-06-25
📝 Original message:
Hey Rene, thanks for your comments! Regarding, pathfinding I agree, that smaller payments will have higher success rates, but this kind of bundling of payments will make some routes accessible which might not have been previously either due to `htlc_minimum_msat` limit of those nodes. Also, this reduces the number of HTLCs that are added making 483 limit more harder to reach. I think the decision might be a balance that we need to strike and can be an optional feature that can be enabled.
Yes, this proposal can only work for spontaneous payments as I think it would be impossible to bundle the hashes generated by the invoices and extract the pre-image. Regarding, proof of payment, as far as I know, spontaneous payments in itself does not carry that as Alice already knows the pre-images. So, this situation would be similar to that or even AMP for that matter where the user generates the preimages by themselves.
Could one resolve this in the world of scriptless scripts or when changing to secret / curve point based preimages based on the discrete log? To be frank, I have not done any work on this and will have to read this up before I can comment. Really appreciate your feedback.
Ugam
From: René Pickhardt <r.pickhardt at googlemail.com>
Sent: Tuesday, June 25, 2019 5:03 PM
To: Ugam Kamat <ugamkamat1 at gmail.com>
Cc: lightning-dev <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] [PROPOSAL]: FAST - Forked Away Simultaneous Transactions
Hey Ugam,
I like the very clearly communicated idea and the fact that we can do crazy stuff with the filler of the onions. I have two concerns / questions:
1.) In pathfinding we actually try to make payments smaller (like moving to AMP) instead of combining payments. I think it was shown several times that the probability of finding a path (successful route) decreases with larger amounts. So saving fees might actually not be the metric that we are trying to optimize.
2.) Am I correct that this proposal would only work with the spontaneous payment scenario as the payment hashes of Eric and Grace could not just be added up as easy as the preimages can to get the overall payment hash for Alice? So in that sense on the invoice based system your proposal is not working and we don't have a proof of payment as Alice already knows the preimages? Could one resolve this in the world of scriptless scripts or when changing to secret / curve point based preimages based on the discrete log?
best Rene
On Tue, Jun 25, 2019 at 7:07 AM Ugam Kamat <ugamkamat1 at gmail.com <mailto:ugamkamat1 at gmail.com> > wrote:
Hey guys,
I’m kind of new to this mailing list, so let me know if this has been proposed previously. While reading Olaoluwa Osuntokun’s Spontaneous Payment proposal, I came up with the idea of simultaneous payments to multiple parties using the same partial route. In other words, say Alice, Bob, Charlie, Dave and Eric have channel opened with one another, and say Dave also has channel with Frank who has channel with Grace. Now, Alice is at a restaurant and wants to pay the bill amount to Eric (the restaurant owner) and a tip to Grace (who was her waiter). In the current scenario, Alice would have to send two payments A->B->C->D->E and A->B->C->D->F->G. However, if we repurpose the onion blob <https://github.com/ElementsProject/lightning/pull/2363>; in the same way as is needed for Spontaneous Payments, we can create a scenario where there is no path duplication. Dave would split the payments, one to Eric and other going to Grace through Frank. The preimage PM used in commitments A->B, B->C and C->D will be a function of pre-images P1 of D->E and P2 of D->F and F->G such that PM = f(P1, P2).
Proposal can be implemented by repurposing the onion in similar fashion as Spontaneous Payments with slight modification
This proposal works in similar fashion to Spontaneous Payment proposal, by packing in additional data in the unused hops. For B and C the onion blob will be identical to other lightning payments. When D parses the onion, the 4 MSB of the realm will tell D how much data can be extracted. This data will encode the hashes of the pre-images that would be used for commitment transaction towards Eric and other towards Frank. For simplicity and privacy, I propose using 2 onion blobs for the data. So the payload can be 64 + 33 bytes = 97 bytes. The first byte would indicate how many hashes are packed, so we have 96 bytes for the payload, meaning we can pack a maximum of 3 hashes for 3 route payments from D. Now D will split the onion (18 hops as it has used the first two for bifurcation data) into number of routes. In the above case it will be 9 hops each. Now these two onions are similar to other lightning payments. The first hop tells D the short-channel id, amount to forward, CLTV and the padding. Since, the preimage is 32 bytes, we can pack that in one single hop that is received by the final party. This leaves the remaining 7 hops can be used for routing. Below figure depicts the onion split in terms of how A will create it. D will add the filler to make each onion have 20 hops. Onion data is encoded in the same order in which the payment hashes are packed in the bifurcation data for D.
Calculating the preimages
Eric and Grace will parse the onion and use the pre-images for settlement. Let P1 represent the pre-images of D->E and P2 of D->F and F->G. When the pre-images arrive at node D, it will combine them such that PM = f(P1, P2). The easiest way for both A and D to calculate that will be PM = SHA256(P1 || P2 || ss_d). Where || represents concatenation and ss_d is the shared secret created using the ephemeral public key of sender (the one generated by Alice) and private key of Dave. The need for using shared secret is to prevent the vulnerability where one channel operator who has nodes across both branches can use them to calculate the PM. Using shared secret also ensures that it is in fact D that has parsed them together.
Advantages of this proposal:
* Commitment transactions between A & B, B & C, and C & D now carry only one HTLC instead of two
* This means lower fees in case of on-chain settlement
* Lower routing fees for Alice as Bob and Charlie would not get to charge for two routings
* Since 483 is the max limit of the htlcs nodes can accepts, preventing duplication will allow more number of htlcs in flight.
* If each payment of Eric and Grace is below the htlc min B or C accepts, but together if it is higher, this route is now usable
Some thoughts on if this proposal can be misused?
* The probability of transaction failures increases as now the transaction is dependent on 2/3 branches
Deployment
Not all nodes need to support this feature. For example, B, C, E, F, and G does not even know that the payment arrived through branching. The nodes that can handle branching of payments can signal that using global features.
Ugam
_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org <mailto:Lightning-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
https://www.rene-pickhardt.de
Skype: rene.pickhardt
mobile: +49 (0)176 5762 3618
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190625/edb91a2b/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7836 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190625/edb91a2b/attachment-0001.png>;
📝 Original message:
Hey Rene, thanks for your comments! Regarding, pathfinding I agree, that smaller payments will have higher success rates, but this kind of bundling of payments will make some routes accessible which might not have been previously either due to `htlc_minimum_msat` limit of those nodes. Also, this reduces the number of HTLCs that are added making 483 limit more harder to reach. I think the decision might be a balance that we need to strike and can be an optional feature that can be enabled.
Yes, this proposal can only work for spontaneous payments as I think it would be impossible to bundle the hashes generated by the invoices and extract the pre-image. Regarding, proof of payment, as far as I know, spontaneous payments in itself does not carry that as Alice already knows the pre-images. So, this situation would be similar to that or even AMP for that matter where the user generates the preimages by themselves.
Could one resolve this in the world of scriptless scripts or when changing to secret / curve point based preimages based on the discrete log? To be frank, I have not done any work on this and will have to read this up before I can comment. Really appreciate your feedback.
Ugam
From: René Pickhardt <r.pickhardt at googlemail.com>
Sent: Tuesday, June 25, 2019 5:03 PM
To: Ugam Kamat <ugamkamat1 at gmail.com>
Cc: lightning-dev <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] [PROPOSAL]: FAST - Forked Away Simultaneous Transactions
Hey Ugam,
I like the very clearly communicated idea and the fact that we can do crazy stuff with the filler of the onions. I have two concerns / questions:
1.) In pathfinding we actually try to make payments smaller (like moving to AMP) instead of combining payments. I think it was shown several times that the probability of finding a path (successful route) decreases with larger amounts. So saving fees might actually not be the metric that we are trying to optimize.
2.) Am I correct that this proposal would only work with the spontaneous payment scenario as the payment hashes of Eric and Grace could not just be added up as easy as the preimages can to get the overall payment hash for Alice? So in that sense on the invoice based system your proposal is not working and we don't have a proof of payment as Alice already knows the preimages? Could one resolve this in the world of scriptless scripts or when changing to secret / curve point based preimages based on the discrete log?
best Rene
On Tue, Jun 25, 2019 at 7:07 AM Ugam Kamat <ugamkamat1 at gmail.com <mailto:ugamkamat1 at gmail.com> > wrote:
Hey guys,
I’m kind of new to this mailing list, so let me know if this has been proposed previously. While reading Olaoluwa Osuntokun’s Spontaneous Payment proposal, I came up with the idea of simultaneous payments to multiple parties using the same partial route. In other words, say Alice, Bob, Charlie, Dave and Eric have channel opened with one another, and say Dave also has channel with Frank who has channel with Grace. Now, Alice is at a restaurant and wants to pay the bill amount to Eric (the restaurant owner) and a tip to Grace (who was her waiter). In the current scenario, Alice would have to send two payments A->B->C->D->E and A->B->C->D->F->G. However, if we repurpose the onion blob <https://github.com/ElementsProject/lightning/pull/2363>; in the same way as is needed for Spontaneous Payments, we can create a scenario where there is no path duplication. Dave would split the payments, one to Eric and other going to Grace through Frank. The preimage PM used in commitments A->B, B->C and C->D will be a function of pre-images P1 of D->E and P2 of D->F and F->G such that PM = f(P1, P2).
Proposal can be implemented by repurposing the onion in similar fashion as Spontaneous Payments with slight modification
This proposal works in similar fashion to Spontaneous Payment proposal, by packing in additional data in the unused hops. For B and C the onion blob will be identical to other lightning payments. When D parses the onion, the 4 MSB of the realm will tell D how much data can be extracted. This data will encode the hashes of the pre-images that would be used for commitment transaction towards Eric and other towards Frank. For simplicity and privacy, I propose using 2 onion blobs for the data. So the payload can be 64 + 33 bytes = 97 bytes. The first byte would indicate how many hashes are packed, so we have 96 bytes for the payload, meaning we can pack a maximum of 3 hashes for 3 route payments from D. Now D will split the onion (18 hops as it has used the first two for bifurcation data) into number of routes. In the above case it will be 9 hops each. Now these two onions are similar to other lightning payments. The first hop tells D the short-channel id, amount to forward, CLTV and the padding. Since, the preimage is 32 bytes, we can pack that in one single hop that is received by the final party. This leaves the remaining 7 hops can be used for routing. Below figure depicts the onion split in terms of how A will create it. D will add the filler to make each onion have 20 hops. Onion data is encoded in the same order in which the payment hashes are packed in the bifurcation data for D.
Calculating the preimages
Eric and Grace will parse the onion and use the pre-images for settlement. Let P1 represent the pre-images of D->E and P2 of D->F and F->G. When the pre-images arrive at node D, it will combine them such that PM = f(P1, P2). The easiest way for both A and D to calculate that will be PM = SHA256(P1 || P2 || ss_d). Where || represents concatenation and ss_d is the shared secret created using the ephemeral public key of sender (the one generated by Alice) and private key of Dave. The need for using shared secret is to prevent the vulnerability where one channel operator who has nodes across both branches can use them to calculate the PM. Using shared secret also ensures that it is in fact D that has parsed them together.
Advantages of this proposal:
* Commitment transactions between A & B, B & C, and C & D now carry only one HTLC instead of two
* This means lower fees in case of on-chain settlement
* Lower routing fees for Alice as Bob and Charlie would not get to charge for two routings
* Since 483 is the max limit of the htlcs nodes can accepts, preventing duplication will allow more number of htlcs in flight.
* If each payment of Eric and Grace is below the htlc min B or C accepts, but together if it is higher, this route is now usable
Some thoughts on if this proposal can be misused?
* The probability of transaction failures increases as now the transaction is dependent on 2/3 branches
Deployment
Not all nodes need to support this feature. For example, B, C, E, F, and G does not even know that the payment arrived through branching. The nodes that can handle branching of payments can signal that using global features.
Ugam
_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org <mailto:Lightning-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
https://www.rene-pickhardt.de
Skype: rene.pickhardt
mobile: +49 (0)176 5762 3618
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190625/edb91a2b/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7836 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190625/edb91a2b/attachment-0001.png>;
