WBD092 Audio Transcription 

Christian Decker - An Introduction to The Lightning Network

Interview date: Sunday 10th March, 2019

Note: the following is a transcription of my interview with Christian Decker, a core tech engineer at Blockstream. I have reviewed the transcription but if you find any mistakes, please feel free to email me. You can listen to the original recording here.

In this episode for Lightning Month, I talk with Christian Decker from Blockstream. We discuss the competing whitepapers, how the various teams collaborate on Lightning, how payment channels work and upcoming dev projects.

“Lightning is a mechanism for us to make Bitcoin more useful, make it available to more people and extend Bitcoin’s reach into more use cases.”

— Christian Decker

Interview Transcription

Peter McCormack: Morning Chris, how you doing?

Christian Decker: Hey, I’m doing good. Thanks for having me.

Peter McCormack: Thank you for coming on. So I’ve told you that I’ve got a whole month of Lightning shows coming up and this one’s going to be the first one, because when I spoke to Adam about it, he said, “you have to speak to Christian”. You’ve heard some of my interviews and I always start my interviews with, what is Bitcoin, because of the variety of answers I get. But for this, I’m going to be asking obviously something slightly different. So what is Lightning?

Christian Decker: Lightning is a mechanism for us to make Bitcoin more useful, make it available to more people, extend Bitcoin’s reach into more use cases and basically enabling all of the promises that we thought we had solved back in 2009.

Peter McCormack: Okay and just so everyone knows, what is your role at Blockstream?

Christian Decker: So I’m a software engineer and researcher at Blockstream. I’m mainly working on Lightning, the specification and our implementation called C-Lightning.

Peter McCormack: Okay. So Adam said to me, the reason I have to talk to you is that Tadge released his white paper first, but actually you had prepared yours first. But because it wasn’t an academic paper, it was actually hidden away from everybody.

Christian Decker: Yes.

Peter McCormack: Can you talk me through this?

Christian Decker: So this is probably the worst thing that can happen to you as a researcher, is basically that, you’re spending months and months on writing up a paper and coming up with a basic idea of how this should fit together and how it should work. Then you write all of this up in a process that takes several weeks to get it right and then you basically send it to a conference. Sometimes you even have to wait for a conference to be open for submissions before you can actually submit it. Then it takes again, months on end for the conference to actually review what you’ve done and then basically give you the thumbs up or thumbs down.

If you get the thumbs up, you are good to go, you go to the conference, your paper can be published and then basically makes its rounds around the world. That’s the stage where other people might jump in. Before this, basically, only yourself and the reviewers had access to the paper. Once it’s accepted and it’s going to a conference, you can actually share it with the wider world, because at that point you sort of had dibs on the invention

It so happens that I wrote my duplex micropayment channels paper, which is what was under review at that time. I had submitted it and then a few days later somebody pointed me towards this lightning.network address with a pdf on it. I was shocked that there is something that looks very similar to what I did. It turns out, yes, there is a lot of overlap. We have different approaches, but they basically just had scooped me!

I spent a very frantic weekend trying to grok the paper and wrap my head around this competing proposal. I could make out some differences, but the core idea of having a payment network made up of payment channels was the same. Yeah, we then had to sort of emphasize our differences a bit more and try to point out that we are better than Lightning. But at that point, the race was basically lost and the paper got published, had some success. But obviously, everybody now talks about Lightning!

Peter McCormack: Okay. So the community has to what, make a decision about which one it wants to implement?

Christian Decker: Well, it basically is the Lightning paper coming slightly before and honestly having some major advantages over duplex micropayment channels, had more momentum behind it. For me it was basically the decision, do I want to create a competing implementation of a payment channel network?

Or do I want to join this effort surrounding Lightning and basically just help making Lightning a vigorous system that has more utility, than having two different systems that split the community? Because this being a payment network, the basic utility comes from everybody being on the same network. Everybody is able to pay to everybody else.

So I decided to drop my duplex micropayment effort in favour of joining the Lightning effort and sort of trying to get that out the door more quickly and making it better. But we are grabbing some of the nice parts of duplex, micropayment channels back, some of the good features that we had, some of the trade-offs that I liked a bit more about duplex micropayment channels and try to bring them into Lightning. So what we end up with is sort of a synthesis of both protocols that have better tradeoffs overall.

Peter McCormack: So the people working on Lightning took a look at your paper, you debated it together and shared ideas?

Christian Decker: Yeah, we had some really interesting discussions and we saw that there are merits on both sides, but Lightning basically had more momentum and honestly the trade-offs were more in favour off of their side. So I decided to jump ship. In gamer terms, I’m probably WinTeamJoiner! But it turns out that this has helped the effort quite substantially. There is no point in creating two competing networks. If we can create one where everybody can participate in and everybody can interact.

Peter McCormack: So when I spoke with you yesterday, you told me about something which I’d heard of that there is actually a long history of payment channels. So can you explain what a payment channel is, what that actually means?

Christian Decker: So I mentioned this usually when I give lectures on these payment channels or layer two solutions or off chain protocols, but I’ll use them interchangeably because they sort of mean the same. What you basically do in a payment channel is two parties meet somewhere. They put some money on the table and then start discussing about who gets what share of this money.

The reason we put this money on the table in the first place is so that no single party can basically grab the money and run away because it needs the acknowledgement of both parties to split this money up again. Now in Bitcoin terms, this is basically just a multisig address where both parties need to sign off on the payment that originates from this address. That basically means that both of us have to come to an agreement of how we want to split the funds that are on this multisig address

So that’s the basic concept and we can discuss back and forth on how to split this money. So if I put a $10 bill on the table, all $10 belonged to me, and we have one transaction that basically refunds me my $10. Now if I want to transfer $1 to you, then I create a new transaction that would be a settlement on this payment channel and you get $1 out of this and I get the remaining $9 out of it. We can transfer this back and forth multiple times and we always have a transaction in our back pocket that basically reflects the latest state that we agreed upon.

Now, this might seem like a silly trick, but if you look at what the Blockchain sees from all of this is basically, okay, there is a payment that creates this multisig address where we pay in some money. That’s usually called a setup transaction. Then eventually there will be a settlement transaction that sort of subsumes all of the interactions that we had in between where we basically say, “okay, this is the final state on how we want to split it”. So with these two transactions, we’ve just settled however many transactions we have or transfers we had between us two.

This allows us to make far better use of the Blockchain space that we have because two transactions now basically aggregate whatever happened in millions of transfers between us two. The true power of all of this comes from the network part of Lightning network basically. Meaning that if we have a channel open between us, it’s nice to be able to move funds back and forth, but chances are that we will not have millions or billions of interactions between us.

So the networking part is basically that I can extend a payment to you and you can forward it to a third party who might be the intended recipient of my initial payment. By chaining these multiple hops of payments along payment channels, we can actually reach anybody in the network. That’s the true power of the Lightning network, is that by just having this two-party relationship called a channel, we can then extend payments to any participant in the network by just chaining these two-party interactions.

Peter McCormack: You were telling me that Satoshi discussed this quite early on?

Christian Decker: Yes. So, when I give my lecture, I usually start with the question, “what’s the earliest payment channel or off chain protocol that people can think of”. Usually, people will start talking about Lightning. Some people might mention the simple payment channels that were discussed on Bitcointalk quite early on, where you can create incremental payments from one direction to the other, but not the reverse.

But very few people actually, I’ve only heard a core team member discuss this so far, is basically that in the original Satoshi client there was this concept of a sequence number for transactions. That was basically that we can create an initial transaction like our initial settlement transaction giving me back my $10, and we can then amend this transaction by replacing it with a new transaction. The rule would basically be that the new transaction would need to higher a sequence number than the replaced transaction.

We should probably mention that the core difficulty in all of this, is that we have the settlement transactions, but we have no really easy way to invalidate an old settlement transaction. So when we started off with the $10 on a table and we have a refund transaction that gives me back my $10 and you get $0. Then we do an update and now you get $1 and I get $9. Now you might want to use that transaction that has $1 in it for you and I would definitely prefer the one that gives me back my full $10.

So we have a race between these two states. So you have a valid state that gives you $1 and I have a valid state that gives me $10. So we need a mechanism to invalidate the old state where the transaction would give me back my $10. With the end sequence proposal that was basically saying, “hey, if there is a transaction that has a higher sequence number, that is to be preferred to whatever came before.”

Now, this didn’t really work, it was actually broken. First of all, because you can only replace transactions as long as they aren’t confirmed and there is no real way for it to incentivize miners to actually pick only the most recent one. So depending on me as a miner receiving or not the updated transaction, it could happen that the old transaction would confirm and well, we agreed to something newer, but the miner didn’t see whatever we agreed upon in time.

But we can also do it more maliciously, where I can basically go to the miner and say, “hey, these two transactions that are competing, please use mine and I’ll give you some small part of whatever I cheated Peter out of”. So this bribing works. So the end sequence mechanism never really worked and we ended up repurposing these this field for different proposals, the check sequence verified proposal, the BIP68 relative timelock proposal and all of that stuff.

So we grabbed back the wasted space, so to speak, but we had to come up with a new update mechanism. That’s basically what all of the follow up papers did, was basically create a system where we can enforce whatever we agreed upon and basically ensure that only the latest state actually makes it onto the chain and I can’t really use my $10 refund transaction, despite having agreed with you to actually give you $1.

Peter McCormack: So that was Satoshi mentioning it early on. At what point did payment channels start to become a serious discussion, where you guys were really thinking, “this is something we now really need for Bitcoin”.

Christian Decker: So there have been quite a few experiments with payment channels over time. Mostly we’ve been using these simple micropayment channels where you can only send in one direction. That was interesting because you could suddenly create a streaming mechanism or streaming service that you could pay by the second. What one of my students did was basically implement an access point that you could set up a captive portal with. Then you basically log in and pay per byte that you use your Internet for and the second you stop paying, you would lose Internet access again.

But these were inherently limited because if you can only transfer in one direction, then as soon as I have used up my balance, there is no way for it to be re-used again. So while we get a bit of flexibility, when we pay, how much we pay and we can do these really rapidly adjusting increasing payments, there is no way for us to do bi-directional payments. While there may be a way of doing multi-hop payments, they’re very limited, as all the money flows always in one direction.

So in late 2014 after I wrote a paper on Mt. Gox, malleability and all of that fun stuff, it was time for us to go back to look at scalability, which was basically my main PhD topic. I looked at these payment channels and was like, “okay, maybe we can build something out of this”. We came up with a mechanism called duplex micropayment channels that did actually allow us to do by bi-directional payments so that we could actually use the money that is in a channel multiple times and send it back and forth.

As mentioned before, the Lightning efforts started in parallel and then they were able to build a different mechanism. But, it ended up basically being what became the Lightning network in the end.

Peter McCormack: Was there ever a time where you personally wrestled with the block size?

Christian Decker: Very early on. When I pitched my PhD, I wrote up a document that was like 16 pages and it had all the problems I’d like to address on Bitcoin and how to make it work better. Basically, the number one thing coming from a distributed computing background was that, yes we have solved somehow consensus or Byzantine agreement. But it’s really inefficient and we really can’t go to VISA levels of transactions.

The first publication I did was basically just going and measuring this, what happens when broadcasting transactions in a network and seeing what happens if you broadcast blocks and how the size of a block impacts the propagation time of the block ends in the network. Propagation time being the principle problem that miners face because if you can’t get your blocks to be known to the rest of the world in time, there might be competing block.

What we showed was basically that the naturally occurring Bitcoin forks were because of inefficient communication in the network. Later this was actually used by Emin Gun Sirer to then show that selfish mining exists where you keeping the information for yourself might end up helping you compete against other miners. So really the first and foundational piece of research we did was basically show that, yes there is a limit to scalability of how much a block size can grow.

Always with the caveat that if we want to have the network as decentralized as possible, we probably need to put some limit on the block size and not let them grow indefinitely, because then we end up with a system that never converges again to a consistent state. These numbers have been picked up a few times and basically what we showed is that with the network at the time, a 13mb block would basically result in us not creating a chain any more. But would basically just be a sprawling tree where everybody was on a different branch and was sort of not agreeing with anybody else on a different branch anymore.

Peter McCormack: Okay. So let’s get back to the Lightning. So the papers out and discussed, debated back and forth, a final version is agreed upon. How many implementations do people start to work on? Is it two to begin with?

Christian Decker: So it actually is quite interesting because Tadge and Joseph published the paper and suddenly there was a lot of buzz, but nobody really thought about implementing it. So at some point, Rusty, a colleague of mine, he took up the challenge of trying to write a small explainer, a blog post about Lightning. When he was hired at Blockstream, he started working on C-Lightning. In the meantime, Tadge and Joseph had started looking into this more closely and soon afterwards they founded Lightning labs.

At the same time, a small development company in Paris called ACINQ also thought, “hey, this is cool, let’s start this.” So all of a sudden there were these three companies after months of radio silence. Suddenly there were these three companies coming up with an idea or starting to implement these things. At some point we decided, “hey, it doesn’t really make sense that we implement three different incompatible versions.

Maybe we should join efforts and create a more compatible version of this and basically creating a bigger network that will help us all to get more use out of it”. So to begin with the whole effort was started with these three companies and we met in Milan in 2016 at the Scaling Bitcoin conference. We sort of jotted down the scope, what we’d like to do in the first version and that’s what later became the spec version 1.0 and that’s what started all of this basically.

Peter McCormack: So is there a set of standards that you all comply with?

Christian Decker: So we collaboratively write these documents called “BOLTS”, which is the silliest acronym we could think of. It stands for Bases Of Lightning Technology. Obviously, the acronym came after the name, like this should be.

Peter McCormack: Well it’s perfect for Lightning!

Christian Decker: Yeah! I think at this point we’ve used all of the naming jokes related to Lightning and electricity! So we collaboratively write these and sort of discuss back and forth on how we should implement certain things and what the trade-offs are. What I always like to point out is that we come from really different outlooks into this protocol.

There’s Eclair who’s primarily focused on mobile nodes that have spotty network connections and not that powerful of resources. We mostly concentrate on power users running on servers and really good connectivity. And LND basically is running mostly on desktops, which also have rather good connectivity and sort of a more hobbyist user base, so to speak.

Peter McCormack: Are there any risks of incompatibility between them?

Christian Decker: Oh, yes! We’ve found many of them. But we will always come back to the table and then discuss tradeoffs, and who is right and who is wrong. Mostly we agree you right away who should change their implementation and what the right way of it is. It’s mostly that we have under spec something, that we have an implementation detail that turns out to make us incompatible. So we need to add that to the spec and basically clarify where this has gone wrong and how it should be addressed in future.

Peter McCormack: Was there any discussion about just collaboratively working on one implementation?

Christian Decker: I think, no. We always had this idea of having multiple competing implementations, especially because as I mentioned before, coming from different viewpoints, we’re not as blind as if we were just all agreeing right away. But we can actually have this trial by fire of ideas and test them in different scenarios and test them in different implementations before settling on one solution that should be used.

So I usually compare this with a dialectic principle, where you have a thesis that is proposed, it is then discussed, an antithesis is proposed and then by combining the two, you end up with the end result that is stronger than either of the theses that started off with.

Peter McCormack: I guess me as a user will hopefully be at a point where I won’t ever know which implementation I’m using?

Christian Decker: Yes. So that is something that we’ve currently been starting working really strongly on, is basically simplifying the user experience and hiding all of the nasty details of the technology behind some really nice abstractions and requiring less knowledge from the user, because this should be as easy to use as possible.

You shouldn’t have to learn about channels. You shouldn’t have to know about channel capacities and channel exhaustions and on chain closures and HTLCs, what they are, how they can get stuck. There’s just so much to know in the Lightning network and you shouldn’t have to know it to use this at all.

Peter McCormack: Okay. So it’s out in the wild now. People are using it. What would you say is the current state?

Christian Decker: The current state? Whenever I look at these plots of the current network, I’m almost overwhelmed by how quickly this thing grew! It’s something that is very frightening for us. All of the people basically putting their trust in code that we wrote and all of this excitement around Lightning. It’s a really humbling exercise to see how this network grew from a few hackers that were basically just playing around with the tech, to something that is being actively used and that people are actually building stuff on top.

Peter McCormack: I guess what I was asking is, where do you see the current state in? We’re still advised not to put too much money on it, not to risk too much money. How far away do you think we are from having something that you could competently say, “okay, we’re good now”.

Christian Decker: That’s always hard. I mean, it’s like having your baby! It will never grow up. It will always be this small, cuddly thing that you cherish and you don’t want to expose it to the bad world that is out there. But at some point, you have to realize that this has its own life and that it has created its own world. I tend to be a bit overprotective when it comes to Lightning. I think there will not be a point that is where we can say, “okay, this is now open for everybody and everybody should use it and put their life savings in it”.

It will be a gradual process of people, users and developers getting more comfortable with the idea of using it in their day to day life. We can steer this in a way, by making it easier to for new users to be onboarded. But right now we’re mostly focusing on people that actually can give us the technical feedback that we need to fix stuff, that can help us test the implementations and that can later also help us, onboard new people.

Because if we were to open the flood gates right now, we as a developer team would be completely overwhelmed by all the support requests. So it’s more about creating this environment where other people can help users to onboard and to use this in the first place.

Peter McCormack: Do you still code?

Christian Decker: I code loads, yes! I’ve started coding in C when I started to with this project and coming from a more academic background where we mostly use more abstract languages, this was really intimidating. But call it Stockholm Syndrome, I’m starting to really like C and yeah, I spend 70–80% of my time still coding. The rest of the time I basically just try to try to help people on stack exchange or our issue board or whatever.

Peter McCormack: So if you had to be honest about Lightning. What are the bits that worry you and what are its potential limitations right now?

Christian Decker: What worries me is that there might be a bit off a flashover when it comes to hype. If we get too excited and we can’t deliver features quickly enough, then people might get frustrated by the lack of progress being made, despite there being progress. I always try to put things into perspective and show that this is basically being built by small teams that can’t move as quickly as most people would like.

So this also plays into this slow and deliberate rollout, to more people than that might actually help us with this in the first place before it becomes this big thing where everybody is expecting it to work right away and just has these small issues that are around. From a technical point of view, I think we need to improve the network structure, the resilience against failures in a network, the success rate of individual payments and we probably need to sort of be able to bolster the capacities in the network. Before we can actually go to a place where we process billions of transfers a day.

Peter McCormack: It is still kind of cool though now using it because it pretty much works most of the time I’ve used it. I’ve had payments not get through because there hasn’t been enough capacity. But a lot of the time it’s been fine. It’s been an absolutely pleasure. I guess you must be quite proud of that as well?

Christian Decker: Oh, absolutely. Yeah. It’s an amazing feeling to see basically two screens next to each other and they connect over this global network and you press send on one side and the green check mark on the other side appears. It’s what I wanted Bitcoin to always be and we hit against the limits there and now we can finally get where we wanted to be in the first place. The community feeling is huge.

I mean, this feels a lot like back in 2009 when I first joined Bitcoin. It was this buzz, it was this excitement in the air about what we can do and everybody is looking for use cases where we can apply this and everybody’s just pitching in and helping out! Even if you’re not a technical person, try to talk to people and what are cool ideas and what could we do? It’s all of this excitement that got me working on Bitcoin in the first place. Now we’re back at that stage.

Peter McCormack: Are there any external criticisms which are fair?

Christian Decker: I think many criticisms are fair. We should always be honest about the tradeoffs that we’re making with Bitcoin. One of the most prominent ones is probably that Lightning is not well suited for huge payments. But then again, the idea of Lightning is to be a complementary system to Bitcoin. Not a replacement of it.

I mean, we rely on Bitcoin really heavily for our system to work. We will never replace it. I think criticisms are fair as long as they are not exaggerated and we should take them seriously and we can address them as they come up. We always have to remember that Lightning is still a very young project. There’s stuff we haven’t figured out just yet. We will cross those bridges when we come to them.

Peter McCormack: Do you have any fear about the impact of Lightning on the fee network and the worry for miners? I mean, it’s a debate that’s starting to happen a little bit. Any suggestion of maybe alternative ideas? There’s been talks of recycling old coins, there’s been talks of having slight inflation and everybody is shot down immediately. But in the back of my mind, I keep thinking, well, there could be a situation where the fee market in the future does not cover enough for the miners and that’s going to impact the security.

Christian Decker: Yeah, absolutely. I mean that’s definitely a fair point and something that comes up fairly often. I do think that… Look the block space is limited and we need to keep it limited for Bitcoin to stay as decentralized as possible. So what Lightning is doing is basically making better use of the resources we have by aggregating multiple transactions into multiple transfers on the Lightning network, into one or two transactions on the Bitcoin Blockchain.

Peter McCormack: It’s also enabling transactions that wouldn’t have happened normally as well?

Christian Decker: Absolutely. I mean, it basically extends the reach of Bitcoin as a currency to places where we couldn’t have done before. I almost like to call the Lightning network, a fee aggregation network, because what we do is basically we create this second layer of payment channels, where we now perform millions of transfers.

The work that the miners have to do is just confirm those two transactions, the setup and the settlement transaction, instead of having to verify each of these small transactions. But because we have some quite different requirements on the confirmation speed of these transactions, we are actually willing to pay higher fees for these on chain transactions that are left on the on-chain. We are willing to do so because the utility we got from these two on chain transactions is way higher than if we had just these two on chain transactions without the aggregation that we did on the Lightning network.

So I think our willingness to pay higher fees, the fact that we’re a complementary network and not replacing all of the use cases for Bitcoin, will maintain the fee market such that the miners will still be able to make a living by securing the network and have less work to do to get those fees basically.

Peter McCormack: So what are the most important things now coming up for Lightning? The key kind of development milestones?

Christian Decker: Oooh, loads of stuff coming up! So back in Milan in 2016, we scoped out the specification or for 1.0, such that we can basically implement this and have a minimal set of features in there as quickly as possible. Well, it turns out to have taken two years anyway, but okay!

Peter McCormack: Dev timelines always overrun!

Christian Decker: Oh yeah. It’s always two weeks! But now we met in November in Adelaide for our spec 1.1 meeting and scoped out what we’d like to have in there. There’s so many ideas that we basically put on the back burner to get this initial working version out, that we just put back on the table now and that we definitely like to have and there’s just so much! For me, the most exciting ones are splicing and then splicing out.

Those are basically ways for us to create on chain transactions out of payment channels or stocking up at payment channel by adding some funds to an existing channel. What this basically allows us to do is to eliminate differentiation between on-chain funds and off-chain funds. So if we have a channel among ourselves open and I go to a merchant that accepts only on chain payments, then what we do is basically we do a splice out, where I tell you, “hey, I’d like to do a splice out and by the way, splice out $1 to this guy, by providing you with an address”. Then we collaboratively do a close and reopen.

Basically, the funds are spliced out to this merchant. What this allows us to is basically to stop differentiating between on chain funds and off chain funds and you just get one big balance to see. Because it tends to be confusing for users to have to check, “okay, I have X in off chain funds and Y in on chain funds and I’d want to pay Y plus one. Now I have to close the channel before I can do that”. This basically gives you one big balance that you can look at and be happy about.

Peter McCormack: In your wallet? So you just have one balance in your wallet?

Christian Decker: Yes

Peter McCormack: And when you send a payment, it will just use the appropriate…

Christian Decker: Exactly yes.

Peter McCormack: That’s cool. I didn’t even know about this, because I’ve got that with my blue wallet. I’ve got two balances. Ok, that’s very cool!

Christian Decker: The other feature that also goes into that same vein of user experience is multipart payments, which allows us to bundle the capacity of multiple channels. So currently what you have is each user needs to manage a number of channels and decide to whom they are opening it, because they are allocating funds to this peer.

If this peer disappears, then well, this is money is not available anymore or is not available for a certain time. What the multipart payment allows you to do is basically bundle multiple channels in such a way that you can do a larger payment by splitting a payment over multiple channels at the same time. What this allows you to do is forget about the difference between having one $10 channel or 10 $1 channels because you can always bunch them together again.

So a single peer becomes less important, but you can still perform larger payments even if you split your funds over tens of channels. What this allows us to do is basically hide channels from you because you don’t have to care anymore about having a very stable peer and having a huge capacity because, well, this capacity will dictate what the maximum amount you can transfer at once is, but you can basically spray a number of channels to peers that you think are reliable and the in combination, they will still be there when you need them.

You just bundle channel capacities when you need them. So what you end up with this basically a wallet that shows a single balance, no concept of channels if you don’t want to look at them and it’s just balance and transaction lists that you had before. That looks really close to what Bitcoin is right now. So this is basically what I mean by hiding implementation details from users that don’t want to put in the work to learn about these concepts and we will handle all of this in the background.

Peter McCormack: Oh man, that sounds so cool!

Christian Decker: There is so much more to come!

Peter McCormack: We’ll have to talk again!

Christian Decker: We have onion changes that we’d like to do, rendezvous routing, spontaneous payments and all of that fun stuff.

Peter McCormack: So listen, if somebody is listening and they haven’t had a play with Lightning yet, what would you advise them to do?

Christian Decker: So we have a number of implementations. Each of these implementations has very good guidelines, very good introductory guides on how to get started. All of these can be found on GitHub and just go to one of them, try to figure it out. If you’re more of a mobile person or if you want a mobile app, go to Eclair, they have a really good Android wallet.

If you are on a desktop and just want to get started really quickly, go to LND, download their client. It’s a full feature opinionated client that comes in as a full bundle of functionality. If you’re more of a power user, that likes to tinker with stuff and you’d maybe one to create a service, then come to C-Lightning and we will guide you to where you need to be and help you where you need help.

Peter McCormack: Amazing. How do people stay in touch with you?

Christian Decker: I’m @snyke on Twitter. I’m cdecker on GitHub and that’s mainly it.

Peter McCormack: Great! Thank you. This is really exciting. I can’t wait to see these new things.

Christian Decker: It’s an awesome time to be alive!