Ugam Kamat [ARCHIVE] on Nostr: š Original date posted:2019-06-25 š Original message: Hey guys, I'm kind of new ...
š
Original date posted:2019-06-25
š Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190625/0934469a/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 7836 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190625/0934469a/attachment-0001.png>;
š Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190625/0934469a/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 7836 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190625/0934469a/attachment-0001.png>;
