Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Christian Decker: Scaling Bitcoin with Duplex Micropayment Channels

Episode Date: November 23, 2015

Christian Decker is a PhD student at ETH Zurich, where he is currently finishing up the world’s first PhD thesis entirely about Bitcoin. The computer scientist has been part of the Bitcoin community since 2009 and just recently turned off his last miner after 6.5 years! We talked about the current scalability debate and what his research indicated what blocksize could reasonably be handled today. We also discussed his proposal for Duplex Micropayment Channels. Like the Lightning Network, Duplex Channels use a network of payment channels to enable cheap, instant and trustless offchain transactions. The proposal, which he is currently implementing, is one of the most promising approaches to scaling Bitcoin. Topics covered in this episode: How losing 9000 btc got him on the front page of the New York Times The scaling Bitcoin debate and what blocksize could be handled today How payment channels work and could be used for off-chain transactions The advantages Duplex Micropayment Channels have with regards to privacy The differences between Duplex and the Lightning Network Whether off-chain transactions could work on Ethereum as well Episode links: Christian Decker's ETH homepage A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels [PDF] Bitcoin Meets Strong Consistency [PDF] Information Propagation in the Bitcoin Network [PDF] Epicenter Bitcoin Lightning Network Episode This episode is hosted by Brian Fabian Crain and Meher Roy. Show notes and listening options: epicenter.tv/106

This is Epicenter Bitcoin episode 106 with guest Christian Decker. This episode of Epicenter Bitcoin is brought to you by ShapeShift. With no account or signup required, it's the easiest way to buy and sell gems, counterparty, dogecoin, dash, and other leading cryptocurrencies. Go to Shepshift.I.O. to instantly convert your altcoins and to discover the future of cryptocurrency exchanges. Welcome to Epicenter Bitcoin, the show which talks about the technologies, projects, and startups driving decentralization in the global cryptocurrency revolution.

My name is Brian Fabian Crane. And I'm Meheroy. Today we are joined by Christian Decker, who is a researcher at ETH Zurich. He has a very interesting idea about scaling Bitcoin using off-chain networks. First, we would like to have an introduction from you, Christian. Yeah, hi, thanks for having me. I'm, as you said, I'm researchers at ETH Zurich. I am also one of the early adopters of Bitcoin, you can say.

I started in 2009, a few weeks after the original paper and I thought, heck, that's a night thing. I would like to try that. And later when it came time to choose a topic from my PG, I didn't have to look too hard to basically say, hey, Bitcoin might be a good topic. Took some time to convince my professor, but in the end it turned out to be the greatest topic he had for a long time. Wow, I didn't realize it was 2009 because I don't know actually who's the person we've had on the show who was earliest involved in Bitcoin.

So I guess Mike Hearn was he 2009 or 2010? Gavin and Dresden was 2010, I guess, no. I'm not sure. We actually had a, the first Zurich Bitcoin meetup was in 2011 with Mike Hearn and Stefan Thomas from today's ripple. Right, right. Yeah. That was, that was, that's quite amazing how how far we got with Bitcoin and similar technologies.

That was, that was an interesting meeting back then, yeah. So you've been interested in the topic sort of continuously since then? Yeah, yeah. I would say I have been, I have been following Bitcoin for a long time. I think my first involvement was trying to reverse engineer the protocol. Part of the protocol specification or documentation, as it's called today, was made by me and one other guy, I guess. And yeah, I was involved quite a long time.

And I just stopped mining a few days ago. after six and a half years yeah that kind of hurt so you were you had what like butterfly labs or or k-n-c equipment and you were running that at home one of the first edition calapeno's and yeah that that stuck with me for a long time and now it was time to shut it off because it's not worth it anymore. Cool. That's fascinating. Actually, I didn't realize you had been such an early adopter and so deeply involved for such a long time. I guess it was just lucky. And yeah, it also brought me some headlines when in 2012, 9,000 bitcoins were stolen from my wallet. From your wallet? Yeah, I actually managed to lose 9,000 bitcoins to a hacker. And

But it got me on the front page of the New York Times. Wow, you would have been a millionaire with that stash. Yeah, so people keep telling me. Yeah, personally, I don't know if I would have paid $9,000 Bitcoin to be on the front page of the New York Times. I mean, that's one of the perks of being an early adopter, right? you somehow mined all these coins and you didn't invest anything and then you lost them. And so, yeah. It's like you lost a lottery ticket.

But one that actually won. So actually that makes it particularly interesting, no, because we have talked about this topic again and again and we keep coming back to it, which is this sort of topic of scaling Bitcoin and one of your ideas that we'll talk about in a little bit does relate to that. But I'm sure you as someone who's sort of been through that whole history, you have a lot of opinions on that in general. So how have you been participating and thinking about this debate and controversy and arguments that are going on about the block size increase

and how Bitcoin can be scaled? Yeah, I mean, the whole topic of the blockchain block size increase is less of a technical problem, I have to say. It's more about economics and incentives. And it also strongly depends on what we want to achieve with this network. I mean, in my first publication, I basically showed that there are some natural limits to how many transactions can the network can support, and that was three years ago. And I basically used that as a starting-off point for the remainder of my research. But the limits were a lot higher than what we are talking about today,

which is one or two or eight megabytes. I don't have the current numbers, but I would believe that we can support 16 megabyte blocks without too many problems. That's a natural limit, I'd say. At that point, the network just isn't fast enough to propagate the block through the network so that the majority knows about this block before a new block being found in the remainder of the network. That being said, we have some lower limits which are of an economical nature, meaning that at some

point, it just becomes unfeasible for people to participate in this network. I'm definitely not an expert on those kind of issues, but I would say we can definitely support slightly larger blocks today. So this one is, so this higher limit of you're saying 16 MBE is, does it come through your paper information propagation in the Bitcoin? network? Yes, that's exactly the publication I was talking about. That's basically us trying to point out the natural limits of what the network can support, and we thought we could analyze how blockchain forks came to be and then take the blockchain forks as an sort of a symptom of

of not being able to reconcile the global state of the network anymore. And we have found that larger blocks also lead to a slower propagation in the network. Not much of a surprise there, but we have a few numbers in there as well, namely that at the time about one kilobyte of extra data would result in the median time of noticing a block was delayed by 80 milliseconds. So that is probably faster today. And we do have a new publication coming out hopefully sometime soon, which actually shows that there has been an improvement over time.

But it still remains the problem that we cannot, we cannot scale too quickly to larger block sizes. So let's get like an on the ground field for this number. So what you're saying is if you add one kilobyte to the block, the median propagation time increases by 80 milliseconds. So that means if you add 1 mb to the block, it would affect the median propagation time by 80 seconds, right? So basically what you're saying?

That was back then, I have to say. That was back then. So let's say, let's just to see, just as a thought experiment, let's say that that number held true today. So when you go from, say, 1 mb to 10 mb, so you are adding 9 more mbs, then the median propagation time would be, say, impacted 9 times. into 80, so that's like 7.2nd seconds, right? So that is over 10 minutes. Yeah. And 10 minutes is the block time for Bitcoin.

What would happen if one block needs more than 10 minutes to propagate to the network? What would happen to the network in that scenario? So our expectation is that the first block would basically split the network in half, because by the time we have reached a majority of the network, we already have a second block propagating through the network, or we have an expectation one block propagating in the network already. So that way we would definitely create a hard blockchain fork. Now the resulting network is smaller, so the two partitions of the network are smaller, but they will work on competing block

chain forks, right? Now, it is possible that we then lose, that we didn't find another block in one of these partitions and find again another block in this partition. At this point, we have a three-headed blockchain fork. And this will not be resolved in a single. next round of blocks being found, right? So what we actually lose is one confirmation on the, on the, on the, on the number of confirmations, we have to wait for for us to be certain that the transaction goes through.

And the extreme case is that we actually fork off indefinitely. Yeah, so, so basically you start having, but let's say if you take the, if you take this skill us back a little bit, we say, okay, it's not 720 seconds, so, you know, 12 minutes, but let's say it's four minutes that it takes to propagate. Then we are still left with a scenario that there are a lot of forks all the time and they go deeper than just, you know, one block. They can have, you know, two blocks deep or maybe even three in a worst case, in a bad case so you start having a very probably behaviors that you don't want. So I mean the one thing we will have for sure is that we lose certainty into what this

being confirmed in a transaction actually means. Today we can be reasonably sure that if my transaction ends up in a block then that means that yes it is it is being confirmed right today's blockchain fork rate is about 1.5% meaning that we have about two and a half forks every day if we if we go if we have this this sort of higher fork rate then we suddenly lose this the certainty and we need more confirmations for us to regain the certainty on the other dimension we have now a lot of of computational resources being spent in a network to work on forks which are eventually going to be orphaned.

And that might be even the scenario which is worse, because now we are having this huge number of fights between mining pools and lots of resources being wasted. And we actually facilitate a large miner who might not have 50% or more, suddenly he needs much less. He has to fight only against other pools that are that suffer this delay in propagation while he doesn't have to. So this all plays into sort of selfish mining again, which which gets easier if you have a high blockchain for a grade.

So in a sense, what you're saying is let's assume that 60% of the mining power is in China and then 40% is in the United States, just quite simply. So what you're saying is because a block made in China needs a lot of time to propagate to a block made in the United States, the 60% of the miners in China, because they hear about the blocks earlier, as a cartel, they can come to a situation where they keep dominating the American miners every time.

And effectively, in order, to get like 51% of the network, you just have to be in China, a Chinese minor, and have more than half of their 60%, which is like 30%. And like your effective power in the network is like a 51% minor, because you can always outcompete the American ones due to the block propagation problems. Yes, you are, by adding delay into the propagation, then you are basically weakening the remainder of the network compared to the block finder. So we don't need to go as far as saying, hey, this is China and this is the rest of the world.

We just need to say, we have a group here which is strongly connected with really, really fast connections. And the next block is being found in this cluster. And then we have a weekly connected other cluster. And the cluster which has not found the block will be at a disadvantage over the cluster that has found the block. Because they will hear it later. Right.

I mean, I think that's why, you know, the episode we Mayer and Sebastian did on Pekkon NG, I thought it's such a nice proposal, no, because it just gets rid of so many of these problems. Yeah, you resolve quite a lot of the races there. It's a really interesting proposal and I mean Gunzira, one of the authors, will be present in my defense later in January. So I hope I get to talk to him about that proposal as well and see what we can do with it. So defense, of course, being for your PhD thesis because you're doing a PhD thesis about Bitcoin at the moment. Yeah. So talking about PhD thesis, I think perhaps this is a...

is a good, a good segue to, to talk about your research. And the one project that I think you are known for that has some attention and is your duplex network and duplex being essentially like the lightning network, which I think a lot of people know and, you know, we've done a show about it as well. So can you talk a bit about how you came to work on that? So we had some research before that concentrating on how to extract application data from blockchain, from the Bitcoin blockchain. And once we finished that, we noticed that there is a possibility to actually scale up the number of transactions that the current blockchain can support, but simply having a moving all of these transfers off the blockchain.

And we then started, we basically took the simple micropayment channel, which was implemented by Mike Hearn into BitcoinJ, and which we had used before, and thought, okay, there's a, there's a limitation there. We can, we lock in funds into this channel and we can transfer it at most once from one end to the other. simply because, well, there is no way to move these coins back. So what we thought we would like to do is to simply have a construction where we can send money both ways, hence the duplex in the title. And we use the construction which starts creating two simple micropayment channel network, two simple micropayment channels between two peers, one going in one direction and the other one going in the other direction. Now, the problem is that, I mean, if you charge these channels on both ends with one Bitcoin,

and you send one Bitcoin in one direction and the other Bitcoin in the other direction, then this guy still has some credit on these construction of two channels, but it's on a wrong channel. He cannot send it back to this. So what we try to do is basically just take these sets or these pairs of simple micropayment channels, flip them over, and now having credit back on the channel that you can actually spend from. That took a bit more of a detour than we were planning to, but in the end we had a, I would say, really nice and really clean construction that actually achieved. this, having two simple micropayment channels which can be reset if the capacity on one of them

is consumed and you'd like to transfer capacity from one to the other. So maybe just to give a little bit of background because I'm sure some people will not be familiar with payment channels. And basically the idea is as far as I understand it and of course feel free to correct me, is that right, you say on Bitcoin, the number of transactions is sort of limited, but But what you can do is you can sort of lock up Bitcoins or you can sort of put them in a multi-sig address that only several people can spend together. And then you sort of go offline and you send each other signed transactions.

So you can basically move money around and you still can do it securely because the person can sort of go back to the Bitcoin network to sort of claim their money. But while you're moving these transactions around, well, you don't actually have to, you know, you don't have to wait for confirmations. You don't have to put them in a block, right? So you can sort of have your cake and eat it too in terms that you have the security of the blockchain, but you don't have all the downsides of it, such as, you know, limits and the costs and the speed. But you can you can do it immediately and much cheaper, much faster. So yeah, basically the micropayment channels, both the simple one as well as the duplex micropayment channel, as well as the Lightning Network, are a form of smart contracts.

Smart contracts basically allow you to encode part of your business logic into the scripting language used by Bitcoin. And at any point in time, the parties participating in this contract have the assurance that what has been agreed on will eventually take effect. And we use the blockchain only to set up these contracts and in the end to either settle them or to mediate some conflict we have between us. And the important part in all of this is that at any point in time, all parties have the assurance that what has been agreed upon will actually take place. And this assurance comes in the form of a transaction which if we want to settle or if you want to have conflict mediation, then we just take these transactions, broadcast them into the Bitcoin network, and the Bitcoin network will take care of resolving our conflict.

So in your like around five minutes ago, you went through kind of three iterations of micropayment channels. You started with the simple one. and then you moved into one where so you started with a simple one which is Meher paying Christian and only Meher can pay Christian and that's it so this is the kind of micropayment channel

that our listeners would be aware we discussed on the episode with Streamium where somebody is streaming a video and the other paying is other person wants to look at the video and pay him money so in that case the money only needs to flow from the person who is seeing a stream to the person

to the person who is creating a stream. So it's only in one direction. That was the simplest one that was invented by Mike Hahn and Spielman. Then you went into these two other kinds of channels in which initially money can flow in both directions, like from Meher to Christian and Christian to Meher. And then you went into the third most complex one in which not only can the money flow in both directions,

but the liquidity is also saved. You don't need to lock up as much money as in the second design, right? Yes. So the difference is in the second scenario you mentioned, we just have two channels in both directions, right? And we cannot transfer more than what has been allocated to either of the channels. In the second case, we are actually using, we are still using simple micropayment.

channels for both directions. But what we can do now is we take the money that or the coins that are bound to one channel and are therefore bound to move only in one direction and we flip them from one channel to the other in an atomic way. So that way suddenly if I transfer 0.5 bitcoins to you and you transfer your whole Bitcoin on your channel to me back, then you still have. credit for 0.5 Bitcoins, but they are bound to the wrong channel. So what we do now is we destroy the two channels, we build up to new channels, and now I have

a channel from which I can send 1.5 bitcoins to you, and you have a channel where you can send 0.5 bitcoins from you to me, which was the amount I previously sent to you, right? Let me just interject here because I think there's one thing we need to briefly explain so people can make sense of that unless they remember the streaming episode well, right? Which is that you can only go sort of in one direction in a channel, right? Because if I give Meijer, you know, 0.2 of that Bitcoin in the channel, then Mayer has the option to like cash in that 0.2 in the Bitcoin blockchain. Now I can say I give you 0.3 and that works. right, because Mayor can cash in either one, but of course he's only going to take the bigger one, but he can't give me money back on that channel, right?

Because let's say he signs a new transaction, that gives me only 0.25. I can't rely on that because at any time, Mayer could cash the 0.3, right? So you have to have a problem that if you've gone in one direction in a channel, well, you can't go the other way, right? And so now what you're saying is there's basically a way to sort of flip that so you can start going the other way. Yes. So the problem in a simple micropayment channel is exactly what I was talking about before, that if you receive some money, you will always have the assurance in the form of a transaction

giving you that money that you can get that money. If you transfer it back, I cannot destroy your your assurance. But so so what we are, so what we? we do is basically we destroy the whole setup until you get to this assurance, replacing the whole construction. What Lightning does is basically finding a way to replace your assurance with something that basically hurts you if you try to cash in that one. So I think this is the crucial point which it's just kind of hard to appreciate.

So let's just walk through this one. So what's happening in a normal macro payment channel? In a normal micro payment channel when, let's say, it's between Meher and Christian in the beginning. So when I want to send you one Bitcoin, like, for example, let's say, let's say you are creating content and I want to pay you for the content. and then I foresee that the maximum amount we will spend

I will spend on this content is one Bitcoin so in the normal case the way it would work is we would create a multi-signature address and lock that one Bitcoin in that joint account which is owned by both you Christian and me Meher so both of us are joint owners of that one Bitcoin and we can imagine this as a cake and then we are just

so this this cake is is on the Bitcoin blockchain and this cake has a time lock so if nothing happens the cake will be divided like I will get the one Bitcoin back let's say one day later and Christian will get nothing so that's the cake and one day later I get to eat the cake completely if nothing else happens now off chain of the blockchain Christian and I can can figure out a way of dividing this cake amongst each other So I can send a statement to Christian that says, okay, now Christian gets 2% of the cake and I get only 98% of the cake. And we don't broadcast this to the blockchain, but once our transaction is over, Christian could take that 2% broadcast it to the blockchain and get the actual Bitcoins return, right?

So that's the simple micropayment channel case. now what you're saying is the problem with this case is the money can only flow from meher to christian but you could always imagine that we could make two different cakes so if if if if christian so let's say now we are in a different scenario where both both the people are providing services to each other so like meher is streaming content and christian is also streaming content and both of them like want to pay each other. So you can create two cakes. So one cake for payment flow from Meher to Christian

and then another cake for payment flow from Christian to Mehe and then you start to decide how much, what percentage of each cake does Meher own and what percentage of each cake does Christian own? And then once this division is complete, both of us broadcast the transactions to the network and we split our funds. Yeah.

Right. So these are the first two basic scenarios. And now what you're saying is the duplex micro payment channel adds something, a third capability to this scenario. Yeah. So what we do is once we have, so I gave you all of my cake, but I do own about, let's say, half of the other cake, then what we do is we just say okay let's let's forget about all of that now I create I create a new

cake which is half of the previous cake which I can send from me to you and on the other side we create a cake which is worth one and a half cakes which you can send to me and we have reset basically the whole scenario and we can restart trading again so what happens is that I can actually send you more than one cake in total and you can send me more than one cake in total. Due to this reset, we can actually have millions and millions of... We can transfer these coins or cakes or whatever you want to call them. We can transfer them multiple times. So that's the whole idea of the construction, yeah.

So basically in an optimal scenario, we are left with millions of cakes. In an optimal scenario, I owe you 1,000 cakes and you owe me 1,000 cakes, and so we don't have to transfer anything. No, I'm certainly glad that we've extensively talked about cakes because this is a topic we've completely neglected so far in the history of this podcast. But it's obviously very important. Our show today is brought to you by our friends at shapeshift.io. Shapeshift is the fast and easy way to trade all coins,

and they now support over 50 cryptocurrencies, which includes all the ones you have ever heard of unless you have no life and spend way too much time on Bitcoin talk. So if you want to trade all coins, there's the old way of doing it, which means create an account somewhere, giving them all your data, depositing your money, and then growing old while hoping for the best. Or there's a shape shift way, which is fast, easy, and means getting it all done in less in a minute while not even needing an account. So here's something to consider.

Shapeshift is a company that really stands by its values and goes out of its way to protect users' private data. One way they do this obviously is by not requiring you to give them any personal information to user service since you can't even create an account to use it. And secondly, when Bit License was enacted in US, Shapeshift was the first company to say, screw this, we're not standing for this nonsense. And what they immediately did was move the company out of the US and interest Switzerland. So ShapeShift is a company that really believes in the core values and core ideals of Bitcoin.

And we think that's very honorable and very cool. And plus, by sponsoring shows like ours, they really help entertain people like you and help promote growth in the industry. So good job, Shapeshift for doing us right. And we'd like to thank Shapeshift for their support of Epicenter Bitcoin. So one of the ways or one of the things we should talk about here and we've talked about, that's in the Lightning Network context as well. So in Lightning Network, there's this concept of, I don't remember what their name is, but basically you have these like hubs that connect different people, right?

Because if it's between me and you, then we can set this up and it's pretty simple. But of course, you don't want to have to set up these connections between every single party that's doing business, because that's gonna be even less efficient than Bitcoin today. But you wanna set up a few, and then somehow you can like,

hop, like between different sort of route. So you can have a, each person can have a bunch of connections. And if everyone has a bunch of connections, you can sort of route through everyone and pay between each other. So how does that work? And you call it payment service provider. What do those entities look like? What is their function? So the idea of payment service providers actually comes from,

internet service providers because well if I if I want to contact Google for example I'm not drawing a new cable from my PC to Google every time I want to to do a transfer but I am connecting to my ISP and my ISP will forward that payment on my behalf right if we were to draw a cable every time we want to do we want to do a connection we would actually pretty soon deplete the copper resources we have in the world and we would make use of this shared medium, which is, well, copper. In the Bitcoin case, we also have a shared medium.

It's called the blockchain. Its size is limited. We cannot do too much about it. So we try to keep as much as possible in a local fashion. We don't just shout out into the world, hey, I'd like to talk to Google, but we are actually sending our packets to our local ISP, which will then forward them. So that's why we call them payment service provider. And yeah, that's the basic idea of it.

In the end, it turns out that unlike ISPs, we do not really have to trust these payment service providers because we have a number of options which we can use, use to ensure that if we send them some money, they will actually forward it to the endpoint. The most trivial one, of course, being since we now do local transactions only, we can, I mean, if I'm okay with losing a send, I can just send one cent to the next top, see if it arrives, and if it arrives, if I get an okay from the merchant I'm trying to buy my coffee to from, I can just send the next cent. A much more complex construction would be the H.TLC, the or the hash time lock contracts, which actually allow us to build end-to-end security

and ensure that the one transfer actually ends up at the destination. So let's walk through a scenario in which Brian is our payment service provider so I want to transfer you money and and now like in my head I'm imagining this as two cakes there's a cake between me and Brian that we can let's say that let's have I want to be very rich so in my imagining scenario I want to have 100 BTC in the cake between me and Brian and let's also make Brian very rich by having 100 BTC in the in the cake between Brian and Christian

and now Meher wants to pay Christian. So how would that work? Like, I want to pay you one Bitcoin and I have 100 BTC locked in a channel with Brian and Brian has 100 BTC locked in a duplex channel with you. So basically what... Well, we already have the network set up, right? All you need to do is basically you send the money to Brian

and then Brian sends it to me. And then I tell you, hey, by the way, I received your money. is good. Now, how we achieve that is a bit dependent on how we want to do it. There is this small incremental type of transactions where you send a millionth of a Bitcoin to Brian. Brian sends a millionth of Bitcoin to me. And then I say, hey, go ahead for the next millionth until we eventually have transferred the whole amount. And all Brian can do is basically, basically, say yeah sorry I I'm not forwarding this and he may have gained one millionth of

a Bitcoin in the H TLC scenario what we do is we basically secure the transfer using a secret so I invent a secret I transfer you a derivative of that secret from which you cannot derive the secret is the You cannot reconstruct the secret anymore, specifically it's a hash. And what you then do is you tell Brian, hey, I will transfer you 100 millibit coin if you can tell me the secret matching this hash. And then Brian does not know the secret to matching that hash. So he is forced in order to get his money to contact me and ask me and tell me, hey, if

you can tell me the secret matching this hash, I will get your own. I will give you 100 millibitcoin. So me being the one who invented a secret can now say, okay, here's the secret and give me my 100 millibitcoin, please. Now, Brian goes to you and tells you, hey, here's the secret. Please give me my 100 millibit coin. And by doing that, we have completed the whole transaction. And at the same time, I have given you a...

a receipt that I have actually received the money, otherwise I couldn't have claimed it. So, so let's let's let's let's look at the leg between you and Brian. So in a sense, um, you are giving Brian the secret and Brian is supposed to give you 100 milly Bitcoin. Yeah. But how does that work? Can't you just take that 100 milipitcoin and not give Brian the secret? On the other side, can't, uh, can't Brian, can't Brian, just take the secret and not give you the 100-milly Bitcoin? No, because that is part of the smart contract we have constructed, right? In this smart contract, both parties are always assured that one party misbehaving cannot work

against the contract. And so the contract is set up in such a way that in order to claim the money, I actually have to reveal on the blockchain the secret. And that is being done with, well, the scripting language in Bitcoin. And hence, I call it encoding part of the business logic in the Bitcoin scripting language. So either you give the secret or the transaction is not valid. So how does that compare with the Lightning Network? What are the main differences here? So the construction of the H TLCs is identical to Lightning,

which also means that Duplex Micropayment Channels and Lightning Network are interoperable. We can imagine, we can easily imagine a network which is composed of a number of Lightning Network, of Lightning nodes and a number of Duplex Micropayment Payment Service providers. because we can by having the same H TLC construction, we can ensure that independently of how the transfer is implemented, we have this back tracing phase in which a secret is sent back through the same route to the origin of the transfer. Okay, that's great to hear because I recently talked with touch from, from, um, Lightning Network who wrote the paper, right? And at the time when we had them in the show, they weren't working on implementing it,

but now they are. And so is Joseph. And then also at Blockstream, right, they hired Rusty Russell, who's also working on implementing a Lightning Network. And I think they are sort of coordinating to make sure that that's also going to be compatible. So does that mean, are you also working on actually implementing that and actually bringing that to Bitcoin? Yeah, I'm currently working a bit on the preliminaries, but I do plan on implementing the whole

network stack of the duplex micropayment channel. We also had one student here at DTH doing the next layer of things, which is basically a BGP-inspired routing protocol. even if we had a Lightning Network or Duplex Micro Payment Channel today, we would still need a way to somehow find a way, find a route from the sender of a payment to the endpoint of a payment, through this network of interconnected payment service providers or Lightning Hubs. So I am planning on implementing it.

It's going a bit slow because this whole business of pushing a bit of pushing a bib which we need to actually secure all of this through the review process is slow and yeah there have been a few setbacks on that side. So is that the transaction malleability fix? Yes, in order for all of this to be secure we actually need to ensure that there is no way of disconnecting a transaction from its predecessor. With this off-block of blockchain protocols we build chains of of interdependent transactions which are not confirmed on a blockchain. And we need to ensure that if this transaction is building on this one,

then we cannot change the hash of this one. Otherwise, the reference from this transaction back to the first transaction would not be valid anymore. That's what generally is called transaction millability. Okay. And so all lightning and duplex, they depend on this in the same way. Yes. So transaction availability has, it would be really nice to have a fix for that. Also because Mount Gox then couldn't claim anymore that it is to blame for their half a billion loss there.

Well, they can still say that was the cause, no. So. Well, we have a paper actually proving that it wasn't. the case. Right, right. Yeah, I mean, it was never very plausible. Today's magic word is Duplex, D-U-P-L-E-X. Head over to let's-stock bitcoin.com to sign in, enter the magic word, and claim your part of the listener award. So that's great. And so let's say that fix happens with a transaction. action availability. I mean, is there a significant resistance or some people saying we don't

want that or are there people who think it should be done in different ways and can't come to agreement? Or what's the sort of roadblock there? So it's always the devil is in the detail. It's I published about what was it? I think August I published a Bitcoin improvement proposal for normalized transaction IDs, which changed a little bit the way the hash used to reference the transaction is computed. Basically, it was stripping out all the information that could have been modified on the flight without invalidating the hash, the signature. And initially, it was a hard-for proposal.

That did not sit too well with a few developers, so I made it a software proposal. which I published in September. And now, well, everybody wants their nice feature in there as well. So I have been rewriting it a few times now. And while discussing with Peter, we actually came up with a much better solution. So Peter and Greg basically came up with a way to implement the segregated witnesses, which are implemented in elements alpha, to basically backport that to Bitcoin

and hopefully fix smellability forever. Okay, and there are people can align around that idea or that sounds plausible that that's going to happen? So I think the segregated witnesses proposal is so far the easiest, even if not the easiest to implement. So the segregated witnesses is, of course, in production in elements alpha, and it is a good solution for the problem at hand. My proposals were a bit easier to implement.

Actually, I have implemented them. But segregated witnesses seems to be the proposal everyone is rallying behind. And so I guess that has a good chance of being merged sometime in the future. So assuming that transaction malleability is solved, can you go into how somebody could become a payment service provider and make money, building a business around it? So the requirement for you to become a payment service provider is have some big. Bitcoins.

Because you, initially when you set up these channels, you need some coins to fund the channel so that you can actually start transferring Bitcoins. That being said, we have not figured out how yet to do addressing in this network and how to assign addresses in this network, simply because for this kind of routing to be efficient, need to have some sort of structure in this network. For example, ISPs use prefix-based routing. And that would be cool if we could do that in PSPs as well. So the second requirement would be to actually be integrated into that network and start

opening channels with other people. Now on the earning money part, you can attach fees to to these transfers as well. So just as you would attach a fee to a transaction you sent into the blockchain, you can attach a fee to the transfer you're doing in the duplex micropayment channel network. And every hop in the network would then draw some of a part of that fee from your transfer until at the end, the last hop eats up all the fees. and what air comes out at the end is just the amount you wanted to transfer in the first place.

Basically, with every hop, may he get some cake. Yes. So basically, like, if I become a payment service provider, what I really need is to be Bitcoin rich. So I need a stash of Bitcoins that I can put in creating channels with a lot of different people, right? That's what I need. And what would make a good payment service provider, somebody who has a lot of channels open with a lot of different people?

So, I mean, it is important to make the entry barrier as low as possible. So that's also why we created these duplex micropayment channels in the first place. If you had a hub and spoke model, then you have the problem that you have to be really rich to cover all the transfers that go through you. In the duplex micropayment channel network, you would have a small amount, let's say, one Bitcoin associated with each channel. And since you can now transfer it multiple times back and forth, this Bitcoin now becomes much more, you get much more out of this single Bitcoin than if you could transfer

it once. The barrier to entry is low in that you're not forced to have a certain number of connections you have to open. All you need to do to get started is to open two connections and then route payments through you between the two endpoints you are connecting to. And once you have more cash, you can open new connections and position yourself better in the network so that you are more central to the network. and somehow more payments get routed through you.

Okay, so perhaps this is a nice opportunity to explain the difference between Lightning and your proposal. So if I understood it correctly, what you are saying is, in scenario one, let's assume like Brian and Meher are both payment service providers on Lightning. And in scenario two, Brian and Meher are payment service providers, service providers on the duplex network.

Now in scenario one, so when both of us are payment service providers, it's a scenario where you need money to flow frequently from Meher to Brian and from Brian to Meher because Christian might be a customer of Meher or Sebastian might be a customer of Brian and then sometimes Christian wants to pay Sebastian, sometimes Sebastian wants to pay Christian. So the payments are flowing in a lot of different directions. So in scenario one, Lightning, so the difference between scenario one lightning and scenario two duplex is that in scenario one, Meher and Brian would need to create a channel, destroy it again, create a new one, destroy it again, while in duplex micropayment, Meher and

Brian create a channel once and they can operate with that single channel like route many more payments to that single channel as compared to Lightning. Is that the advantage of the duplex network? So I think the, so in both cases, in the Lightning Network case and in the Duplex Micropayment channel case, the channels have a lifetime, which is limited. Some say that a channel will be active for a month or for a year, but in both cases they are not endless. And they are in fact pretty similar because the overall effect achieved by lightning and by a duplex micropayment channel is pretty much identical. Where we differ is

the construction of the channels. And if you, so I read an early version of the lightning paper And it took me a really, really long time to figure out what they are actually doing. And what we did is we basically started from the two simple micropayment channels, combined them into a two-directional channel, and then figured out how to reset them. We have, I think our construction is a bit easier to understand because it's built, on well-known blocks that we basically analyze individually and we can show that they are working, whereas lightning is a bit more complex in that all of these parts are very much dependent on each other, and you cannot strip them apart and analyze them independently.

So I wouldn't say that duplex micropayment channels and lightning are completely different because they achieve the same goals with sort of the same guarantees, but the construction and the ease of implementation varies a lot. And hopefully me being the author of Duplex Micropayment Channels, I, of course, would argue that mine is easier to implement and hopefully get it correct.

Okay, so the advantage of your approach is the ease of implementation. Yes. Okay. And so one final question on this topic. So now we have kind of moved from, so when we move from Bitcoin the blockchain to the lightning network or to the duplex network, we are moving away from something that is decentralized and censorship resistant to a structure that has payment service providers,

like for example me, that can be, that have to comply with government regulations, etc. Now the advantage of this kind of seems to be that because I can't steal any funds as a payment service provider for the end customer it means that they can use any payment service provider in the world and they don't need to trust any of the payment service providers which in turn means that for the payment service providers I can go and set up in in any country which has easy rules to become a Bitcoin payment service provider, set up my business there, even if the customer does not trust the country I'm operating out of, it doesn't matter because it's trustless, right?

Yeah, so we certainly maintain the security in the sense of the coins cannot be stolen by an intermediary. And I'm pretty sure that these intermediaries will eventually also be regulated. That being said, it should be really easy to set up an intermediary or, well, a payment service provider. There is no license. All you need to do is to insert yourself into the network, fund a few channels, and start transferring coins for other people, and basically start earning. As for moving to a country where the regulation is lenient, that's not strictly necessary. I mean, you can operate all of this over a tour. And it's relatively low traffic, so I'm pretty sure we wouldn't annoy tour so much that they would ban us. And by basically

obfuscating your location, you have achieved the same goal as moving to a country that has lenient policies. And so, yeah, there is very little trust in all of this, and you are free to choose whatever payment service provider you want to. We have an additional advantage. So one, some people have asked me whether there is a privacy concern, because now all my payments go through a payment service provider. All that payment service provider sees is what.

is the equivalent of the information I would have published on the blockchain anyway. That and he does know which IP address I'm using. So what we do is we actually keep this information off the blockchain. And I would argue that in that sense, we are even more private than we were in the blockchain scenario. Right, because you make it much harder for the services like chain analysis or the company set to clustering of entities and all that. information on the blockchain but also network monitoring right and that's going to be much harder too yeah exactly yeah so so if you if you want to be private just just open a connection to a number of payment service providers and and just randomize who you are going to send the transaction

to or pretend to be a permanent service provider yourself and you're routing payments on on behalf of other people so there it it becomes becomes much easier to obfuscate what you are doing in the network. Yeah, I think that's a big strength. So one of the things, once when we had Mike Hernon, we talked with him about like a network, too, and I think he made a really important point. And he also wrote about this elsewhere. And that the problem starts to be that it becomes much more complicated from sort of a

wallet perspective about how do you implement that. And of course, you do have this sort of thing. let's say if people, you know, I can't pay at a restaurant using Lightning Network or Duplex unless, you know, the party receiving it has also switched to that. So you sort of need the whole network or at least significant portions of the network. You know, it shows that to have the sort of, you know, the real benefit. Do you, is this a problem that, you know, it's just too complex to implement for a lot of the wallets? and maybe not for the big ones, but we have wallets like the Bitcoin Android wallet or Electrum,

where it's small projects are basically one main developer. So yeah, there is definitely added complexity to implementing a wallet. But you can get away with implementing only part of it. You don't need to do all the, it's not, every wallet that needs to do all of the work. And where there is this bootstrapping phase, you mentioned that some people don't use this network, there's an opportunity for intermediaries to actually do this translation. So BitPay, for example, is successful because they allow people to accept payments on a network

where the receivers are not actually on the network itself, but they would like to be able to accept these payments. I do see the difficulty with the added complexity, but I think if we can make it easier for these protocols to be implemented, then we sort of reduce this downside. And that's also what I've been aiming for is a protocol which is easy to implement and hopefully get it right. I would not trust myself to implement Lightning correctly. So one final question, and this is this regards to Ethereum, can you implement duplex micropayment channels in Ethereum?

And would that be easier? The second part of this question is, can Ethereum enable like, the next generation of lightning networks or duplex micropayment channels? And this I do have to be honest, I'm not an expert on Ethereum, but I think we cannot take duplex micropayment channels or lightning and translate them directly to Ethereum, simply because Ethereum makes the assumption that we have this global synchronized state. and on which we are operating. And the other problem is that we have to have fungibility

in what we transfer. In all of the descriptions we had before, we silently accepted that the coins that I want to transfer to you, you don't care whether I send you directly my coins or whether you receive Brian's coins. So the fact that I can transfer 100 to, millibit coins to Brian and he can then send you 100 millibitcoins means that it's not the same 100 millibit coins that are directly going from me to you but it's different coins so we do have to

we do have to keep this fungibility or exchangeability of objects we would transfer but i do think there are venues where we can actually have have sort of the same things or the same sense setting which would allow different applications to also use duplex micropayment channels. For example, one thing would be if we have asset tracking networks and I have an asset which or I have a connection of an asset I want to transfer from me to Brian and from Brian to you, then if we all have the same asset and it is fungible and I can transfer it to you, without any problem. Whether

Ethereum can enable the next generation of off-blockchain smart contracts, pretty sure it can. I mean, the Ethereum scripting language, which is what we use to encode the business logic in all of this,

is basically a super set of the Bitcoin scripting language. So I'm also not an expert on this, but it would seem to me that probably if all you're talking about this, let's say moving ether, then you should probably be able to do something like the Lightning Network on Ethereum, right? But then of course, as soon as you start talking about interacting with contracts and more complex things, then that probably breaks down. Yes, exactly. So Ether is just as fungible as Bitcoins are. So I don't see any problem

in transferring ether. You're right. I was talking about contracts directly and they rely on a global state being synchronized. Cool, excellent. Well, thanks so much for coming on. So we're basically up for time. We had another topic we want to talk about,

which is an interesting proposal you have called a peer census. It's sort of like fight out there and unusual, but very interesting. And I was looking forward to talking about that, but unfortunately, the duplex stuff and Lightning Network stuff is so complex that the one just gets stuck there. But we'll link to the paper in our show notes.

If people are interested in checking out, they can do so. And yeah, we'll see. Maybe we can come back to the topic at some point. Sure, I'd love to. yeah so thanks so much for coming on it was a pleasure talking to you thank you very much for having me that is it from our side and now as as we mentioned like links to christian's website uh and his papers will all be in the show notes and um and you know we put out episodes of this every monday so you can subscribe to it on it on itunes you can get it on android or your favorite

podcast app and of course you can also watch videos on youtube.com slash episode of bitcoin and if you're loyal listener you know what's coming now is that we have been doing this t-shirt bribery contest which basically means if you leave us a review let us know then we'll send you a t-shirt so if you do so please send us an email at show at epsenobitcoin.com now one brief heads up here is that we're sort of out of most t-shirts so we'll have to get and produce and we'll take a little bit longer but uh but yeah that's That's it, so thanks so much and we look forward to being back next week.