Hi Ugam, I just wanted to quickly note that the current proposal [1] (implemented here [2]) is to give up on the fixed 65 byte frames altogether and allow variable payloads (reclaiming what previously was padding in the hop payloads). Given the low diameter of the network, this gives us a lot of freedom to put additional payloads in the onion :-)
Cheers, Christian [1] https://github.com/lightningnetwork/lightning-rfc/pull/619 [2] https://github.com/ElementsProject/lightning/pull/2689 On Tue, Jun 25, 2019 at 1:07 PM Ugam Kamat <ugamkam...@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
