Thanks Christian for the references! As ZmnSCPxj pointed out, there was a loophole in my proposal that could potentially lead to DoS and failure attacks in the channels. These references should help me in working my proposal to circumvent such attacks. Have a great weekend.
Ugam From: Christian Decker <decker.christ...@gmail.com> Sent: Friday, June 28, 2019 11:09 PM To: Ugam Kamat <ugamkam...@gmail.com> Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org> Subject: Re: [Lightning-dev] [PROPOSAL]: FAST - Forked Away Simultaneous Transactions 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 <mailto: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 <mailto: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
