 Hello everybody. Welcome to today's Protocol Labs Research Seminar series. Today we are joined by Supra Mazumdar, who will be presenting her work titled CryptoMaze, Privacy Preserving Splitting of Off Chain Payments. Supra is currently pursuing her PhD at the Indian Statistical Institute, where her research interests include scalability and privacy in blockchains, data privacy, and combinatorial optimization. Thank you so much for joining us today and I'm going to let you take it over from here. Hello everyone and thank you for joining the talk. So I will be presenting. So this is one of my work which I've done as a part of my PhD thesis. So my thesis deals with designing secure off-chain protocols for payment channel networks. So specifically I'm interested in studying the scalability issue in blockchain. So this is a joint work with my supervisor Dr. Shushmita Rooj, who is presently a faculty at UNSW Sydney. So let me, so the title, I would say CryptoMaze. So I mean, you can consider that we have a given this network. I mean, since I have my work deals with payment channel networks, so that's what's in sync, being in sync with the work which I'm done. So this is the title. So we have done some good construction. So as to ensure that the privacy is preserved at the same time, it's quite efficient, not hindering the scalability. And at the same time, we have ensured that whatever state of the art protocols we had studied, it's trying to counter the shortcomings of those. So like if I need to sum up within one minute what exactly the work is trying to address. So in payment channel networks, we can have quite high value payments. So it's quite unlikely that a single path for routing the such high value payment. So you have to split it across multiple paths. So our basic idea is to ensure that it's atomic. That means either whatever partial payments are getting routed either everyone is all the payments are reaching the recipient or none of it is reaching. At the same time, it should be privacy preserving the sense that none of the intermediaries must figure out who is actually involved in routing this payment. And at the same time, since only the standard and receiver has the motive of doing a transaction, intermediate parties are just interested in earning some processing fee and just not going into the fact that they can be altruistic and they might be interested in just running the protocol. But at the same time, I'm just assuming that they they will route a payment given they get a good processing fee. So in the process, none of the intermediate parties must lose coins. And at the same time, since the payment is being split across multiple parts, they should be unlinkable. Like even if some of the notes collude, they shouldn't figure out whether they are part of the same they are routing the same payment or they are actually routing different instances. And at the same time, we figured out that when you're splitting payment, there might be some set of channels which might be shared across partial payments. So our objective is that since you are routing us in single instance, or even if an channel is shared, you are instantiating just one single option contract for that. So this is the key idea which I will try to address in the top. So let us just see like why we are interested in starting this scalability of blockchain. So as you can see, like on this, some of the popular cryptocurrency is still yet to match the level of throughput which this conventional payment system offers. Like as you can see visa, it has got around 24,000 transaction per second processing speed and PayPal also is quite hard. Recently Ripple, I'm not sure, but I have seen somewhere that it has crossed visa and it's now around 50,000 and there's a news which stated that Ripple processed around 50,000 transaction per second. So but yet Ethereum and with Konami, Ethereum definitely if it is upgraded to the Ethereum 2.0, it will move into the proof of stake mechanism. So it's enhancing scalability and finally this Bitcoin still it's yet to catch up with such conventional payment systems. This is what is the problem which is actually faced in such decentralized payment cryptocurrencies. So this is a term which actually this concept comes from the cap theorem which is used for decentralized data storage. So this scalability trilemma, the flavor is the same, the term coined by Vitalik. So what does it state? Like, I mean, you can either have like security decentralized, you can have a combination of either two, but not the three of the properties in a particular decentralized network. So like if I say this currently Bitcoin and Ethereum, they are decentralized and secure, but since they use a civil resistant mechanism like Bitcoin is using proof of work and that involves a lot of computation overhead. So scalability is a major bottleneck for such cryptocurrencies. Next, what can be the thing? So I mean decentralized and it's scalable. So like IOTA, VCHANES, but they are lacking on the security side and there is certainly laughs like there can be a prominent leakage of sensitive information and attacks on these systems. Next is like we can have scalable and secure system like Ripple, Hyperledger and Stellar, but to some extent they are like permissioned or like some consortium of organization are controlling this particular network. So again, it's not fully decentralized. So we can say that if we are using a public blockchain, then the more decentralized it is, the more secure it will be like more resilient to civil attacks. But then again, if you want a certain amount of centralization, then definitely there is some person who is controlling the security aspect as well. Like what are the solutions which can address this scalability trilemma? So I will just speak of our layer 2 protocols, but I mean they're even in the base protocol, I mean the layer 1 as well, there have been several words like sharding, alternate consensus protocols, which currently a lot of work is going on, which will ensure that definitely this Bitcoin and Ethereum, this scale up and match to the level of provide a high throughput. But why I am particularly interested in layer 2 protocols is that it's quite modular. Also, one doesn't need to do a hard fork in the underlying blockchain. And at the same time, we can just get the scalability without worrying too much about the security because you can always fall back on the underlying blockchain network. So here are some of the instances like Lightning Network, Plasma, Raiden. There are other examples as well like sidechains and rollups, plethora of examples, which are currently existing. So I will discuss about just payment channels. So here, what is the basic concept? I mean, given we have the underlying blockchain, like how one can construct a payment channel and basically how a network can evolve, given we have certain set of payment channels. So basically, you can think of it as like a concept of two parties having a joint bank account. So consider here, it's like Alice and Bob. They deposit of around, I mean, it's imbalanced, but Alice's depositings is 0.01 BTC and Bob's amount is quite less than that. And they mutually agree exchange signatures and that transaction is getting recorded on the blockchain and this instantiates the creation of payment channel. So I'm not going into the details of like how this can be done because that you can refer to the paper by Poon and Raya. And next once this transaction, a funding transaction is getting recorded on chain. So these two parties can happily do several off-chain transactions. Like suppose there are 10 such transactions in which Alice needs to transfer around 10 to bar minus 6 BTCs to Bob, maybe in lieu of certain services like maybe he wants to buy, maybe for internet service or maybe he's printing out documents and Alice is providing the service. So in that case, I mean like if each of these transactions hit the blockchain, then it would be quite time consuming because what Bob demands is like instant payment and instant service. So in that case, it's better they just mutually keep track of whatever state update it's going on. In case of there is a dispute then obviously what happens is that whenever you update your state to the next state, then you have to revoke it like they will share the keys for the prior transaction and update the state. So in case one of the parties is acting malicious, then the other party can slash the funds deposited in the funding transaction and penalize the counterparty. As of now, I'm not going into like what can happen if either party is acting malicious. So consider like after 10 transactions, they decide to close the channel. So they mutually might agree on a commitment transaction which states out the balance like what Alice is entitled to and what Bob is entitled to. And finally, this transaction hits the blockchain. So over here, you can see like instead of 12 transactions hitting the blockchain, we are just happy with two. So as to 10 transactions, there is no record as such. Like whatever happens is happening with mutual concern. So next, like let us see. So this is the paper where you will get an idea like how this Bitcoin Lightning network and how what is the underlying concept. So let us see how things work in the channel payment channel. So consider this Alice, it has opened a channel with Bob. Bob has opened a channel with Charlie. So now, if Alice wants to do a transaction with Charlie, so what did what she can do, she can open a fresh channel with Charlie and sorry, so she can open a fresh channel with Charlie, but already she has a channel with Bob and Bob is having a channel with Charlie. So opening another channel might be a costly offer because you have to hit the blockchain and provide the mining cost for the particular transaction. So instead of that, what they will do, they can leverage on this existing channels like Alice transfers payment to Bob or transfers the payment to Charlie. So in this similar fashion, there can be other participants who which can form channels with these members in the network and together, this can be like a graph network with bi-directional channels and they can happily transact and in case of any dispute, they just go and settle it in the blockchain. So let us see like as I was speaking like what will be the problem with high-valued payment routing. So suppose there is a request where this node A wants to transfer seven units to node H, but as you can see, there is not a single path which can accommodate this transaction of seven units. So instead of like rigorously adhering to finding a single path, it's better the payment is split and send as partial payments across the channels. So like we can do a split of four and three. So once you send an amount of four units to channel AB, so we push assets to E and again D will push three units to C. So in this way, we can complete the flow and get the and transfer this payment to the node H. So I'm not going into like how you can do this routing. So any standard maximum flow algorithm or push three level or whether or many routing protocols stated in literature. So for multi-path payments, so any of them might fit here. So let us now assume that we have this set of loads. So now we see like how payment occurs in Lightning Network particularly. So suppose X wants to transfer some amount to W. So she figures out that there is a path from X to W via this intermediaries, Y and Z. So what W does is that he samples a random value X and sends the hash of the value to H to X. So this H is the hash which is shared with X. So what he does is that he forms a hash time lock contract. So the name comes from the fact that hash is the puzzle that the counterparty needs to provide the preimage in order to claim this amount. And so over here, like I have assumed that it wants to transfer four units to W. So like an each intermediary, it's charging point one unit. So that's why X is transferring four point two units to Y. Y claims point one units and transferring point one Z is claiming a fee of point one and finally four units is reaching W. And the time out, since we are terming this time lock, so each option contract has a time lock. So it's in a decreasing order like P1 is strictly greater than T2 and T2 is strictly greater than T3. So based on the southern system parameters, so we choose this time out period within which these parties need to react and solve the payment. As the other party, like suppose Y is not responding within time T1, X will go unchain and the state will revert to the initial state when four point two units will be credited to X's account. So this is how hash time lock contract, but it holds good for single path routing. Now, let us see like whether we can extend this for a multi-path routing. So consider like we assume here like suppose this party B and C, they have colluded and they are talking to each other. So they know what is happening. So suppose now A is forming an HDLC with B and A has formed an HDLC with D. Now D has formed an HDLC with C, and but C realizes the terms of the contract letter that is the hash used the same as what B has received from A. So that means, but there's a time lock. So like before C has received this B has received. So at that time C wasn't aware like whether they are receiving the same time lock hash value. So B has forwarded to E, but then C realizes that this is the same hash value which she is receiving. So what happens that she will not forwarded to the party F. So why this is a problem? Because I mean, it's a tendency of the nodes in the network that they would prefer to route full-valued payment rather than partial payments because partial payment is subjected to the success of all the partial payments in other routes, right? Like we will see like B and C if there is a partial payment. So they know like if B's path succeeds, but C somehow somewhere in C routes the payment fails at path at node F. Then the entire transaction, I mean, the state of the channel will be reverted. So this is a big problem like they will be locking their collateral for a certain amount of time. So instead of that B or say this party C, they would prefer to lock their collateral if it's a single-valued payment instead of partial payments. So that's why like C has dropped this payment, but since E, this payment has reached E. So E has forwarded to H. Now H as you can see, instead of receiving seven units, it receives just four units. So the problem is that payments become linkable. And at the same time, you see that payment is not atomic. So just partial payment is being successfully routed. So now what can be done? So there's already a work done to address this. So this is turned as atomic multipath payment whereby for what it can be done is that you the sender A figures out that there are three parts which will be routing the payment to participant H. So one is the path marked in yellow, the second in green and the third part is marked in blue. What is the underlying idea in atomic multipath payment? It's that once the off-chain contracts reaches and all the partial payment is received by H, it will receive these partial secrets like SH from the first path, SX from the second path, and SD from the third path. So once it does that, it will receive the master secret. And using this master secret, it can figure out what is the actual preimage for this hash H, hash X, hash value X and hash value Z. So once it gets the master secret, it can reconstruct the preimage for each of this path and claim the payment. But there are certain problems like you can see these three channels, there are two such contracts. I mean redundant contracts being established for each of the parts because these channels are shared across this path which are routing the partial payment. So definitely that's an overhead. And next is a big problem like this is a problem faced in HTLC. So this attack was identified in one of the paper anonymous multi-hop block. So what happens in this attack is that suppose Alice wants to do a payment to Bob and in between you can see these two tiny devils are existing. I mean they are participants which is routing the payment. So what Bob does is sharing the hash value and in the meantime Alice just proceeds with her HTLC. So what Bob will do is that Bob will share the preimage with the devil X, but the devil instead of sharing the preimage with Charlie and Charlie sharing it with Katesh. So the devil will just suppress the secret and directly do an option communication with another devil with whom he has colluded. So this devil directly shares the preimage with Alice. So now you can see like instead of a path length of five, it is becoming a net path length of two because this intermediary channels with Charlie and Katesh is being circumvented. So what is the problem now? So what devil will do? Devil will cancel the off-chain contract with Charlie. Charlie will in turn cancel it with Kitty. Kitty cancels the off-chain contract with devil. So this intermediate parties like Charlie and Kitty will think that the payment has failed, but in reality the payment has succeeded because Bob has successfully managed to transfer the secret to Alice. So what devil is managing to do? Steals fee of Kitty and Charlie. Who is the loser? Is that actually Alice? Because Alice think this path is of length five and she is paying actually four intermediaries. Two intermediaries, two actually means one. You can consider this as a civil. So this one party who is capturing all the fee for rest of the intermediate parties, so basically she ends up paying extra. So there is another construction by Sanchez, Cartier and Maffey on this construction actually wasn't mentioned in the paper, but actually it prevents health and preventing one whole attack. So as you can see like in each of the off-chain contrasts between Alice, Bob, Charlie and Eve. So they're using some different condition like Y1, Y2, Y3 and Y4. And so Y4 can be solved using X4, Y3 can be solved. So internally these parties receive certain partial secrets. So once Eve receives the secret X4, she can reconstruct the secret value for Y3, condition Y3. So she will just do a Zor of X3 with X4 and share it with Charlie. Charlie does the same with Bob. So now you can see like even if Bob and Eve colludes, they cannot figure out where they are part of the same payment. And like even though they can figure out, but they cannot figure out what is the preimage because the condition Y4 and Y2 it's different. So if they can solve it, that means they are able to figure out a collision for this particular hash. But still the problem of redundancy process like as I had shown previously, sorry. So like even if you and this protocol is for single path, so we do not know like this extension would not be straightforward. So it would involve again certain amount of computation. Next we, this is the paper which is quite interesting like deals with split dynamic splitting of payments like instead of figuring out the routing and then going for protocol, it will just put on the condition as and when the payments are being split. So good point about this protocol is that this, the sender can just be happy with having the local knowledge that she A can just split it to B and D, but she need not be aware like what B is doing. So A is putting the condition A and B in this contracts with AB and AD channels. Now using the condition A, B will form its own condition with channel VE. And similarly DC forms a new condition, but A needn't be bothered about what condition B and D is designing. So they locally construct the condition and forward the payment. At the same time, they are forwarding the payment and this finally reaches the party age. But as you can see like again, we have this problem of multiple contrasts for a single payment. So in the paper, it was stated that this problem of redundancy needs to be there because if you need the property of unlinkability to hold and we figured out the scheme is still weakly linkable because the public key of the recipient was shared for and the secret partial secrets were homomorphically encrypted. So it had a bit of high computation overhead and at the same time, since the public key of the recipient was being shared. So somehow like it could be possible that two payment instances they are using the different public key and even if two parties are colluding and they see they are using the same public key they can figure out with high probability they might be part of the same payment. Given all these problems of state of that, these are the objectives which we wanted to realize for our protocol. So first is that it should be efficient like as I stated, there shouldn't be too tank consuming because the basic idea is to make the network scalable. So it shouldn't be making the things slow. And at the same time should be privacy, preserving an atomic like the payment either fully succeeds or it doesn't succeed even if one of the partial payment fails. And as I previously mentioned that if nodes colluding with each other they can figure out they are part of the same payment they might try to censor such partial payments. So we need to ensure that they are unlinkable. And there was this problem of constructing multiple off-chain contracts in the previous state of the art which I mentioned. So what we need is that even if the channel is shared across multiple instances there should be one particular off-chain contract on the channel. And at the same time on this intermediaries must not be losing coins like when we are designing the protocol. How do we realize this thing of avoiding construction of off-chain contracts on a shared channel is the basic idealized in mapping the set of parts to the set of edges. Once this is done given the set of edges we start with the steps of the protocol. So let me talk about how we do this. So these are the notations which I've used in my paper and some of them like what are the for the mathematical maths which we have done like we have taken this elliptic curve of order Q and selected a base point. So basically this security of a protocol comes from the hardness assumption of discrete lock problem. So like and also we have this we have used a standard cryptographic hash function for where we have considered that given the hash it's very difficult to figure out the pre-image. And also the timeout periods so depending on what sort of payment channel network you're using so maybe for each framework like for LND for regular for C lightning these terms may be different so I'm not going to like for practical purpose what you can set so in just in same gender. So let us figure out like how we can map the set of parts to set of edges. So we can do a BFS like given the set of suppose we assume that A already knows like how this payment has been split and it is reaching H. So given the set of part it will just do a BFS starting from H. So once it knows that from H you see G and F were involved in routing the payment and again from G E was involved in routing the partial payment and similarly C and E were routing the payments to F and in similar fashion ultimately you go back to A. So why I'm doing a reverse BFS starting from H I will state it in my next slide. So once you are done so what is the what advantage we are getting here is that instead of considering each part individually we are just mapping it to a set of edges. So even if the partial parts are sharing the particular channel that is getting considered once in the set instead of having multiple entries. So like what we did a BFS from H just it allowed us to like design the time out period for each of the off-chain contracts for like what we need for our protocol because else it would be difficult to do that. So like since H is the recipient and G and F are the immediate neighbors which is transferring so this gets the least time out period T and next G is getting its flow from E and F is getting its flow from C and E. So it is getting a time out period of T plus delta. So delta is the time taken for confirming the transaction option and next in the next level we have the channels DC and BE. So we add an extra delta term so it is T plus 2 delta and finally the channels AD and AB. So it is having a time out period of T plus 3 delta. So this is allowing us to figure out like in a BFS level fashion we can assign the time out period for each of the off-chain contracts. Next let us see how given this set of edges or how like what sort of pre-processing can be done. So what A does is that A will sample certain secrets for each of these edges involved in routing the payment like for BE it will share the secret XBE for the channel BE for DC for channel D is having the single channel so XDC. The main thing is that E is splitting the payment to G and F. So it can sample like these secrets for the only the nodes which is routing payment to a single channel but whenever there is a split we in A cannot directly sample that A need to do some back calculation I will come to that like how it will be done and for finally for the recipient H like if it is seeing that it is receiving this partial payments from two such channels so in order to like in order to see that atomicity holds it will sample two such partial secrets Y1 and Y2. Now what H does is that H will sample her own secret XH but she will share the she will share as it's a point on the elliptic curve group instead of sharing the discrete law of this so she will just multiply it with the base point G and share it with A. So that's what I mentioned like except XEG and XCF like wherever the split of payment is occurring except for that rest of the values are sampled. So this particular construction of option contract is inspired from this particular anonymous multi hop lock so what it is being done is that the idea comes from that like whatever condition is being shared over here so this the hardness of this construction comes from the discrete assumption of discrete lock hardness so once suppose as you can see P0 is sharing the condition Y0 and next P1 has this partial secret Y1 so to some extent so the multi hop HTLC was being functioning was acting but instead of using hash time lock contract we are they have made use of this scriptless script construction like basically you can complete the signature only of a particular contract only if you know these individual secrets. So P1 shares this condition Y1 with its participant and similarly ends at Pn-1 shares the condition Yn-1 with Pn so like this particular contract Yn-1 can be solved by Pn because it has this particular secret key Kn which is summation of all the partial secrets and once this key is released Pn-1 will just subtract Yn-1 from Kn and reconstruct Kn-1 so Kn-1 satisfies the condition Yn-2 and similar way they just go and keep on subtracting their partial secrets and ultimately the secret Y0 reaches P0 and the counterparty P1 can claim the payment. So ours is a bit different like we don't actually go for decrementing of this partial secrets but rather it's based on incrementing of partial secrets as and when the intermediate parties are claiming their payment so I will just come back to like how the construction is going. So what is the advantage of this particular construction was like it reduced the space for cryptographic operation because it was doing away with hash locks and it was also improved upon the fungibility because now you cannot distinguish between regular Bitcoin transaction from this particular transaction for off-chain payments which had hash locks. So this is like our condition for off-chain contract so as I stated the H is receiving two partial secrets Y1 and Y2 so whatever I have I'm stating over here so all these computations are being done by E so this is the pre-processing phase. So what A will do A knows this partial secrets Y1 and Y2 so she will just recombine it and do an addition and blind this particular Y with a blinding factor Egh for this particular channel she will construct the off-chain contract where Egh you just constructed using hash of this secret Y concatenated with the channel identifier so this ID of gh along with that she will since A has the knowledge of this value which is shared by your node h right so h is not sharing the discrete loop but just the point on the seductive curve so she can you can just add it up and construct the condition for off-chain contract on gh and similarly for fh she can do this similar operation but this time the channel identifier will be different so this makes this two off-chain contracts on channel gh and fh unlinkable next similarly for egef and cf so like yes after gh and fh you have egef and cf so what it will do she will just add this conditions for this all the outgoing contracts and add it with the partial secret which this particular party g had with itself so she had xgh and a will use xfh for ref and for cf she will again use the partial secret xfh because as you know fh is the outgoing channel for f but the incoming channels are the channels ef and cf so combine these two flows it's the outgoing flow for to the node h is being constructed so that's why the dependence on these two incoming flows once this is done so as i had stated previously like you can sample all the partial secrets for each of the node but instead but not for the particular node which is actually splitting the value so what is the main idea like what what happens if like if a is if e is now splitting the flow to g and f so you can think like we can just add up the conditions used for those outgoing channels like ege and ef and add these secrets and form the condition for this our incoming channel be but what can be the problem over here so now suppose assume that g has provided the secret to this condition rege and she claims the money coins from e and service for some unfortunate event lightning strikes and f is now dead so f doesn't respond and what happens is that now e cannot solve the c is a condition of put for forth by this channel be be right because b is b requires the secret from both g and f so this dependency if there is a dependency what happens is now e is paying to g but e can e doesn't get the secret from f and if this is not possible b b she cannot claim coins from b because she can only construct this secret or if both the parties are responding now she is at a loss because now b will cancel the contract and b is the one ending up losing coins so this is what we previously mentioned that none of the honest party must lose coins in the process so what we need to do that we in order to ensure that we go for some one out of n sharing of secrets and how this is done is that so e now must be allowed to claim coins from b even if one of the neighbor doesn't respond so now sorry if one of the neighbor responds so like if e can e can be e will be able to construct the secret which is needed by b even if g is responding or f responds like even if if one of them doesn't respond she is not at a loss so what happens is that to avoid unlinkability we cannot have used the same condition for these two channels right we cannot equate reg with re f so we have to ensure that these two conditions are different but we we have needs a structure something like this like rbe must be dependent on reg as well as the secret supplied by this party g that is xcg and re f like the channel e f and the conditions supplied by the nodar but the problem is that if you want to do a back calculation so a should know all the discrete log because only then she can construct the condition like create a point on this elliptic curve so what what she knows actually she if you take a if you do a sub if you subtract xhg from this rbe because as you can see like rbe sorry is a combination of reg and re f so over here reg and ref is again dependent on rgh and rfh and rgh and rfh is again dependent of eghy so all these values are known but what she doesn't know is this value xh but if she takes if she just subtracts xhg so given all these points she knows she knows the discrete log value so now she's all good with the proceeding with the construction so yeah so what she will do is so she can fix her discrete log for rbe minus this point xhg to some random value of her choice and i'm not going into the details of math but if you do the back calculation you can figure out this value xhg and xcf given that a now has the knowledge of all the partial secrets so like previously i stated like that but then it the structure is a bit different from what i stated here so it's not exactly reg plus ebe of xhg so we just recombine these two partial secrets and construct the point xc and use it to construct like either of these two equations get satisfied then rbe can be you can reconstruct the secret for rb so like even if g or f replies then this like e can claim the coins from b and next the construction for dc ab and ad it's a simple straightforward like whatever we had stated for the rest of the channels because there is no splitting involved but this is the trick for ensuring balance security security of the party which is splitting the payment so we needed to do this back calculation for reconstruction of secrets and next let us see like we a simple onion routing scheme like the one used for htlc is used for forwarding of contracts so not onion routing swings routing protocol which is used in lightning network so as you can see like the condition rav plus and the timeout period for each of these off-chain contracts are forwarded so once this off-chain contract reaches the designated parties they get the partial secrets as well so like d receives xdc and v receives xbe similarly d forwards the off-chain contract to c and c receives the partial secret next b forwards the off-chain contract to e and e gets the partial secret so in similar fashion everyone forwards the off-chain contract and finally h gets these two partial payments and it will compute that whether she has got all the partial payments and once all the partial payment reaches her she will get the partial secrets which she needs in order to reconstruct the secret for claiming the payments from parties g and f because she has her own secret xh but she cannot recompute the secret needed for solving the contract and that's all the partial payment reaches her so once this is done so the release phase is like you just provide the discrete log of each of the condition so i'm not going into the details like just whatever condition i had constructed i mean instead you just provide the secret so in this similar fashion the discrete log of secrets are provided and finally a ends up paying the coins to the party h but now consider that again what happens like if f is destroyed so now g is the sole person providing the condition to e but as i stated that e is now self-sufficient she can just claim the coins from b so b provides the secret and also the same property holds here like even a can reconstruct back the a can provide the money to b so only the payment succeeds partially but in the process like none of the intermediate parties are losing coins right because now your g g was g had forwarded to e but f failed to forward the secret to e so but still e was able to claim coins from b so it's fine like a it's a is losing points because a is the ultimate sender but the rest of the participants or the correctness holds is like a maximum amount of loss a can make is the total amount she is forwarding right so maximum amount of loss is seven units rest of the participants they cannot make a loss they can either make a profit of zero that is none of the contracts are succeeding or the or they make a positive profit like the some excess over the processing fee they receive and finally the participant age it makes a profit of seven units so this is how the correctness of the algorithm holds next for the these are the privacy and security goals realized by protocols so as i stated what is the correctness i mean what is the gain each party should have consistency is realized like there is no one whole attack like if the outgoing contracts are resolved only then the incoming party can claim money from the incoming contracts and as i stated previously like how you can realize balance security and also there is value privacy because the payments are split and across multiple parts and there is unlinkability of partial payments because now none of the parties can figure out that whether they are part of the same payment or different instances and also relationship ardent with anonymity holds because the sender and recipient cannot be identified because this is a problem in htlc like you can consider like if all the parties are going on chain then with high probability you can figure out who is transferring the payment to whom but even if all the parties go on chain in this particular protocol they cannot figure out because the conditions are unlinkable and of course atomicity holds like either the payment succeeds fully or it like either the recipient is receiving the total payment value or it is not receiving like the release phase starts only if the recipient is receiving all the partial payments so that's a bit difference because as i had shown previously the s can end up losing the partial of partial amount but the atomicity over here is like the age must be able to get all the points which for which the transaction was decided it shouldn't be that she he receives the partial amount and starts the release phase so that's not allowed so the for security analysis we have used the universal compatibility framework so we have designed an ideal world we have taken the ideal world we are considering this ideal functionality f we have assumed the parties are interacting with it and on top of that we have constructed an ideal attack us in the simulator which is basically helps in simulating the protocol seen in the real world but actually we are not studying the protocol in the real world we use this ideal functionality for the blockchain and the secure message transmission like for each of the channel we use these two ideal functionalities and we construct this hybrid world for this particular protocol and then we show that the hybrid is indistinguishable from the ideal and also like if you just remove these blocks of ideal functionalities used and then the hybrid becomes indistinguishable from the real world as well so we show indistinguishability and for all these previous properties which we have mentioned we show that these properties hold in the ideal world and with negligible probability we can for the bad cases this gets like the this gets violated and there is a distinguishability attack so for performance analysis we have chosen three metrics so first one is the time taken for executing this protocol and second is the communication overhead like how much message is being exchanged for particular for all this particular protocol and third is the parameter which which is like we stressed in the very beginning is like how much optimization we are achieving in terms of chain contracts for such partial payments so some status stats which we provide from the experiments like when we increase this transaction value to 0.04 BTC so we saw that payment instance like that had multiple routes sharing this payment channels like there were not edge disjoint so we saw that such cases shoot up to 30th person and payment channel shared in a single instance that increased from 33 to around 60% and for each of this particular payment instances we saw that a particular edge got shared from and the number count increased from 2 to 5 so that was quite high right if we use the state of the art protocol that means if an edge is shared five times by each of the partial payment that means you need to construct five such option contracts for a single payment on a single channel so what is the like like saving or we can say the saving we achieve in terms of construction of chain contract is that when you increase the payment value so number of option contracts constructed per payment increased from 24 to 68% so this is the particular saving which we had so of around 69% of saving which we observed compared to the state of the art and we also tested it for real instances so we took a snapshot of lightning network and these are the state of the art like we did an extension of multi-hop HDLC which I stated previously with a multi-path routing protocol and we compared it with atomic multi-path payment and the splitting payment dynamically so when we observed we found that crypto means is quite efficient I'm almost matching the time taken by atomic multi-path payment and but we saw the overhead is a bit high because we did this since the sender was involved in this pre-processing step and doing this back calculation and there was some communication overhead because there's this mapping of paths to edges so we saw that crypto means is on a bit higher side but still within feasible bound but this is fine as long as we are addressing the issues of like the shortcomings of the state of the art so similar pattern is observed for simulated instance so we tested up to network of having 25,000 nodes and over here here also we saw that crypto means is very fast compared to what other multi-path payment protocol where the time taken for the other protocols was a bit higher and for multi-hop HDLC it was very high and of course the communication overhead was higher than AMP or the splitting payment dynamically so this is fine like we are addressing as I stated the shortcomings so like the best one as we stated was the splitting payment protocol by EK et al but the problem with this particular protocol is that it was weakly linkable and it was using homomorphic encryption so that's what we tried to do away with we didn't want some heavy crypto primitives being used for this particular channel payment channel network because that would be against the very idea of enhancing scalability so these are some of the open problems so like as I stated like we were assuming that the route was given to us and then we are designing the payment protocol so we want to do something like what this paper of dynamic splitting of payment is doing so we want to reduce the computation overhead on the sender and make it more efficient but the challenge is that like it is very difficult to figure out what is the fee for each because you do not know which which parties will be the intermediate parties routing the payment right whenever you are splitting dynamically so it might be the case that in some intermediate parties in order to on fees might be routing the payment via longer paths where certain nodes in this path might be and another like a pre-image of this particular party so there might be several civil nodes so deciding the fees the channel and then as I mentioned that linkability is an issue and also then there was a problem of redundant option contract so given all these can we design a protocol avoiding all these problems next is that since we are still using a standard standard lock time for this particular protocol can we move to a constant collateral locking protocol where you can use constant time update for each of the channels and as I mentioned that we are leveraging on this scriptless script construction which relies on snor or ecdse but this is not supported by all cryptocurrency so can we make it generic so there is a single path construction provided by the agrarjan and malvolta so based on BLS signature scheme so can we do something based based on such a construction so that's all from my side so this work is available in this archive and it's accepted in IEEE and if you have any questions feel free to ask and I'm really happy to take questions now and even if it's not possible now you can reach out to either me or my co-author Shashmita so with this I end my presentation all right thank you so much for joining us today I know I really enjoyed your presentation it's fun seeing a lot of other folks who have taken part in the research seminar series being cited in your work here and it looks like our lab leads and a few other folks who joined think this topic and what you were discussing is extremely timely for some of the research that we're conducting here at PL and also the space of general so I want to thank you again for joining us today. For anyone who's watching on YouTube if you would like to join these talks live feel free to go to our github account that's linked down in the description and you can also follow us on Twitter at Proto Research to be able to get any new updates about new speakers coming out in the future and then one final update if you're interested in applying to one of our grants for example the PhD postdoc or faculty grants those applications will be due on April 14th 2022 so in a few weeks so go and take a look at those at grants.protocol.ai so super thank you again for joining us today I really appreciated your talk and I hope you had a good time and we look forward to hearing from you again soon all right. Yeah thank you friend and it was a pleasure and I really enjoyed during the talk.