Blockstream's Christian Decker On Latest Lightning Network Developments And What Bitcoin Could Be Like In Future | ForkLog

Blockstream’s Christian Decker On Latest Lightning Network Developments And What Bitcoin Could Be Like In Future

Interview
03.09.2019

Christian Decker is one of the true Bitcoin veterans and the first person in the world to get a Bitcoin related PhD. Today the Switzerland-born engineer is one of the leading developers at Blockstream working on Lightning Network specifications and C-Lightning implementation.

In an exclusive interview with ForkLog, Christian Decker tells how he came to the industry, reveals some of important features that might be included in Lightning Network, and gives a somewhat unexpected forecast for the future of the largest cryptocurrency.

ForkLog: Hello Christian, will you please introduce yourself to our readers and tell more about your background and how you came into Bitcoin space?

Christian Decker: I am a software engineer at Blockstream, and I am working on the Lightning specification and its C-Lightning implementation. I was doing my studies at ETH Zurich for Master in Computer Science, specifically I was working on distributed systems and distributed computing when I first heard about this strange little white paper on Bitcoin. Immediately I got very much interested, but after I dug in it took me quite a few weeks to actually understand it. Anyway, from there on I had my hobby, later that hobby became the topic of my PhD, and in a few years I became the first ever Bitcoin PhD.

ForkLog: What were the theses of your Master degree and the PhD?

Christian Decker: My Master thesis was Bittorrent, not so much related to Bitcoin, while my PhD’s final title was on the scalability and security of Bitcoin. It was basically the result of what I what I have pitched for a few years before, a 16 page document outlining all the things that were wrong with Bitcoin and how we could address them. And believe me, it was not easy pitching Bitcoin for PhD, it was a lot of work, but in the end my professor was really happy.

ForkLog: How did you find your way into Bitcoin development, eventually getting a job at such a big blockchain company as Blockstream?

Christian Decker: I started following Bitcoin development and discussing things with people back in 2009, it became my full time job with the PhD in 2012, and in 2016 I became a full time software engineer at Blockstream.

ForkLog: What would you say to the claims that Blockstream is usurping the Bitcoin development, establishing a sort of monopoly in that space?

Christian Decker: People often get the order of things wrong. Blockstream is a company that was founded by people who for a long time were very much involved in the development of open source projects. They had normal day jobs and did it in their spare time, but at some point maintaining this project started to take so much time, so you either had to stop working on it or you had to find a way to get paid for your contribution to building this infrastructure.

That’s how Blockstream was started. People often think that Blockstream came from the outside and hired a bunch of people who then started to grab the power. In fact it was a group of Bitcoin enthusiasts who wanted to keep working on this project, it was really important for them, but they also needed a way to fund their efforts. So the idea was to create a company as a way to support the Bitcoin ecosystem by supporting the developers and to expose the knowledge that was collected by those developers to other companies.

Blockstream may have been one of the first, but now there are a lot of other companies that have seen the value of supporting this new open source project, and developers of the Bitcoin client are employed by a number of companies. We have the MIT Digital Currency Initiative which is funding a couple of engineers including Wladimir van der Laan, we have Chaincode which is funding a lot of engineers, and we have Blockstream that is funding a lot of Bitcoin efforts.

It is always hard to explain how developers are not being controlled by someone, but if you look at from the point of view that these people are really interested in doing that work, it will make thing a lot easier. And I can assure you that there are no secret developments in the space, at least not the ones that I am aware of.

ForkLog: As a person who has spent quite a while researching Bitcoin problems, what are the biggest and most important issues the cryptocurrency is facing today?

Christian Decker: The most obvious problem we have is scalability of blockchain systems in general, they just don’t scale. For the entirety of my PhD work I tried to find a solution to the scalability issues, and what I settled on in the end was these layer two off-chain protocols. They scale much better than having things on-chain.

Other problems involved are energy consumption. It would be nice to have a system where the work performed to secure the network would also have other use cases. I did not make any progress there; that was probably more than I could have achieved. It’s been a while though, so maybe a will need to revisit that.

ForkLog: That’s pretty much close to what some critics say about Proof-of-Work algorithm in general, accusing it of wasting too much energy.

Christian Decker: I think calling it a waste is a bit of a strong word because Proof-of-Work is useful in that it secures the network. But it would be nice to have additional use cases as well. The properties of Proof-of-Work are pretty restricted and you can’t really use it much for anything else. I think the only example of useful Proof-of-Work besides securing the network that I found is a private coin. Private coin is basically about finding private numbers, but then the question is how useful are private numbers.

It is really hard to inject that usefulness into Proof-of-Work, because for that you need a few properties for such a system: you need to have some way of committing to the transaction data that you want to validate, it has to be scalable and we are also targeting one block every ten minutes. These are the really hard issues to merge with the existing Proof-of-Work systems.

ForkLog: You were the person to make the first ever Lightning transaction in Litecoin. How did that story start in the first place?

Christian Decker: For Lightning to actually work we needed to have SegWit activated because the way we handle transactions in Lightning is that we have a chain of transactions that is unconfirmed at any point of time. And if we have transaction malleability in the system, then we might break the connection from one transaction to another and suddenly you don’t have a solution on how to handle funds.

So when Litecoin activated SegWit after years of work on it, and this happened even before Bitcoin activated it, I started to think about how hard it would be to port Lightning on Litecoin. It turned out this was quite easy. A few hours before Litecoin was to activate SegWit I contacted some other developers, some other clients, and asked if they wanted to make a first ever main net Lightning transaction with me because it would be a nice gesture to have it across multiple implementations.

Sadly, I was a bit late and they didn’t have time to adapt in time to make it for the SegWit activation, so I set up two nodes, one in Zurich and the other one in San Francisco, and just did the whole thing.

ForkLog: It’s funny, back in 2016 you actually argued that “strictly speaking” Lightning does not need SegWit and that changes to the Bitcoin protocol can be implemented in different ways. 

Christian Decker: The way we have constructed Lightning at the time was very much relying on SegWit. We have certain parts in the protocol that are really relying on having the malleability fix and without SegWit it would be much harder to build this in a secure way.

ForkLog: What are you working on at this particular time?

Christian Decker: Right now I’m still working on the Lightning specification and C-Lightning. In the end of last year we had our second specification meeting in Australia and we have this huge list of things that we would like to implement or to improve. There is also a selection of things that I find the most interesting

ForkLog: In your recent talks you’ve been mentioning Spontaneous Payments as one of the most anticipated Lightning features. What is it about?

Christian Decker: Spontaneous payments is a method to send a payment without having to exchange an invoice before. Currently the way we use Lightning is that I go to a vendor or a point of sale, they create an invoice for me which I scan and pay. That’s very important for the Lightning protocol because the way we assure that the payment actually goes through is by having this setup, using this invoice first.

With spontaneous payments we can do things without a seller. What you can basically do is say that you want to pay Bob, that you don’t want to talk to Bob and you don’t want to get an invoice from him first, but you still want to send him some money. So you know Bob’s name, or node identity, you create a Lightning payment, and once Bob receives the incoming payment you give him the necessary information how to claim the funds. With the invoice workflow Bob is the one telling you how to send the money to him.

This is one of the most important and most requested features. The reason why it wasn’t in the 1.0 specification is that this flow of having an invoice and then paying that invoice matched more with what we expected people would do. There is also some difference in the assurances that you get with invoice versus spontaneous payments. Namely, if I get an invoice from you and then pay it I have a proof that I have made the payment – I have an invoice and a matching secret that you generated when creating that invoice. If I have the invoice and the matching secret I can go to a court and say that I have paid you for my coffee but I never had it.

With spontaneous payments I don’t have an invoice, that’s the difference in this workflow, but people are really asking for this solution.

ForkLog: What are other most requested features for Lightning Network today?

Christian Decker: For me one of the most important features which is on our roadmap, is splicing. It basically allows us to have all of our money in a Lightning channel and still to be able to perform on-chain payments from it, or to take a share in an existing channel and add some funds from the outside. What it does is it allows us not to care about which funds are on-chain and which funds are off-chain and to show a single balance, to show how much money you have at your disposal and that if you want to pay for something you can use up to this amount.

Then we have the multipart payments, which is also very important since it allows you to bundle multiple channels together. If I currently have a single 10-dollar channel then I can transfer up to 10 dollars in one payment, but if I have ten 1-dollar channels I can only transfer up to one dollar in one payment. With multipart payments, we can have ten bundled channels and pay up to ten dollars, so the point is that you don’t care who you open channels with and how much you put into those channels.

I think those two features are fundamental for us to make user experience that is much easier than what we have today. Currently you have to care a lot about things like opening a channel with some guy and then thinking that he might not be online, so I don’t want too much money. With those features you get a lot of flexibility, you can automate a lot of stuff in the background.

ForkLog: So why is it actually important to be able to open multiple channels?

Christian Decker: Being able to open multiple channels and still have the total capacity available allows you to not to have to connect to a big hub in order to be well connected. You can start connecting to random people and still be able to transfer the total amount. Currently we have that issue that if you open one big channel with one peer, than you can pay up to that amount. If you were to open multiple channels with different peers, then the amount you can transfer is reduced, but having just one peer is rather bad because you are relying on this peer to be online when you want to send a payment. Whereas if you open five smaller channels, then even one of those goes away, four fifth of your balance is still available, so you are less reliant on that one peer.

ForkLog: Do you consider yourself a scientist, or, perhaps, more of a creator?

Christian Decker: I think of myself more as an enthusiast. I don’t see myself as an economist, I don’t see myself as a scientist, I’m just someone who cares about the technology and finds it fascinating. I like to dig deep when I find something that I don’t know about, I like to learn about new stuff and try to improve it. It’s really all about the challenge of building something new. I don’t have any grand vision in this regard, it’s just about following your interest.

ForkLog: But why exactly do you care about Bitcoin and Lightning?

Christian Decker: All this really got me interested in the first place, and I started when all of this was worth nothing. Still to this day it’s the most interesting and the most challenging project that I’ve seen so far, and it always surprises me when new things come. Bitcoin is a really complex piece of software which tackles some really hard issues. There’s also this combination of technical and social aspects of economics which I find really intriguing.

ForkLog: Historically there has been plenty of discussion about Bitcoin’s killer app. What is it in your opinion?

Christian Decker: Bitcoin’s killer app is Bitcoin. I really don’t know… It doesn’t need a killer app. Bitcoin is what it is, and I’m not sure that I need to have something else that makes it valuable for me.

ForkLog: Basically people have been mostly taking about the ways to accelerate mass adoption of crypto. In this regard, do you think Lightning Network, which is still a bit too far from being user friendly, can really help things?

Christian Decker: Lightning is definitely a good development for Bitcoin adoption because it adds more use cases to what we can do with it. We have the ability to do micropayments, down to a very small amount, we can have real time payments, we have the ability to use the scarce resources that we have in Bitcoin, namely in the block space, much more efficiently. These features are incremental, but still they make Lightning very important the Bitcoin adoption. It’s definitely not going to replace Bitcoin but it adds use cases making it more useful.

ForkLog: If you were to talk to someone who just learnt about Bitcoin, which properties would you highlight in the first place to describe its value?

Christian Decker: I’m not sure that I am the right person to sell Bitcoin is that sense, because I have a very different to most people approach to Bitcoin. I’m in it for the tech and challenges. I don’t care that much about mass adoption or its value.

ForkLog: Anyway, do you see that in 10 years a good part of the world’s population is using Bitcoin as means of payment?

Christian Decker: I think that in some or another form everyone will eventually use Bitcoin. I’m not sure at level it will be and whether everyone will run around with a Bitcoin wallet, or Bitcoin is somewhere hidden from the user being a part of some mechanism, but I still think that it’s a very important tool for people to use. They will use it, in some form or another.

ForkLog: Do you see a possibility of some other technological innovation getting bigger than Bitcoin and eventually replacing it as a number one crypto?

Christian Decker: I think that if something comes along and fixes all the nitpicking that we have with Bitcoin, there’s slightly some way for us to back it. I found it quite interesting that some of the things that were pitched for Ethereum, for example, we can actually backport them into Bitcoin. It might be more complex, but we can do it.

ForkLog: Any examples of that?

Christian Decker: One of the examples that I usually use is the construction of payment channels for Ethereum, they call them state channels. Because of the way these state channels are managed and how they do the updates, we can actually backport some of their functionality into Bitcoin quite easily.

That was part of a paper that I published last year and called eltoo. It basically takes a different approach to how we build Lightning channels and how we build off-chain contracts. It took me some time to realize that it is very similar to how Ethereum does it. It’s a bit more complex and it took a bit more time to get it working on Bitcoin, but we can do it. And with a lot of innovations that we currently have, such as Taproot, or Adaptor Signatures, we can backport a lot of these features.

So it might not be the Bitcoin that we see and recognize today, but I think Bitcoin itself will be around in one form or another for a very long time.

ForkLog: Such a development could give people like Craig S. Wright more reasons to go around and say that they are the ones following the ‘true Satoshi vision’ and doing Bitcoin as it was designed originally.

Christian Decker: This whole Craig Wright and Satoshi thing, the search for Satoshi, it’s all a bit of a red herring. Satoshi left the space quite a few years ago and let other people to take care about the project. If he is still with us, then he has earned his place even without using the name Satoshi, if he is no longer with us, we have learnt a lot since he has left. I personally don’t think we should take all the things that Satoshi said as an absolute truth, we have to look at them through the lens of what we have learnt in the last few years about things that were wrong and things that were right.

Satoshi might be there with us today under a different name and still be one the important contributors, or he has lost any interest in having a say in the project. Still I believe that if there was something wrong with Bitcoin he would make his word.

Christian Decker was interviewed by Andrew Asmakov
Photo credit: Anastasya Stolyarov / Unchain Convention

Found a typo? Highlight text and press CTRL+ENTER

Subscribe to our Newsletter

<

Related posts

Tags: , ,
  • Jose

    2056691