Blockstream Talk #3 —Christian Decker: Lightning Network: Bringing The Digital Cash Narrative Back To The Forefront

Link to the podcast video: https://youtu.be/KbrZavVgkkk

Welcome to Blockstream talk number three. Our conversation today is with one of the world’s leading experts on the Lightning Network, Dr. Christian Decker. Christian is also known as dr Bitcoin because his dissertation was the first distributed computing phd that focused explicitly on Bitcoin. His work on duplex micropayment channels actually predates the Lightning Network paper. but in a bizarre twist of fate, it ended up being caught in academic review and publication ended up falling after the publication of the Lightning Network paper. in developer circles, christian is seen as the inventor — or at least one of the inventors — of Lightning-like scaling solutions. so really there’s no better person to talk to about the current state and the future of the Lightning Network. most investors have been looking at Bitcoin as a high-growth inflation hedge. but what’s going on in El Salvador, and how Bitcoin is actually being used in emerging economies is really bringing the digital cash narrative back to the forefront. so in this conversation i was keen to get christian’s views not only on the state of the Lightning Network now, but what could go wrong. is the Lightning Network ready for prime-time? and integration not into just a platform or a wallet, but into an entire economy, as well as the role of the Lightning network in driving Bitcoin adoption going forward. don’t forget to like, subscribe, and share. and if you’ve got any ideas for future episodes let us know in the comments section below. Thanks again and i hope you find this conversation useful.

Jesse Knutson: All right christian, how you doing?

Christian Decker: I’m good thanks!

Jesse Knutsn: good. long time no see

Christian Decker: yeah it’s been a while, but i’ve been looking forward to this.

Jesse Knutson: So Christian maybe we can start off with a quick introduction: who you are, what you’re working on and what’s your role at Blockstream?

Christian Decker: yeah so i’m Chris. i am what some people might call a Bitcoin OG. Idiscovered this paper in 2009 back when I was doing my studies at ETH Zurich, which then later became my phd topic. I had been doing my doctorate on scalability and the security of Bitcoin. and when it came time to go into the industry, Blockstream offered me to basically continue working on these topics and i’ve been working on that ever since.

Jesse Knutson: good stuff. so high-level: what is the Lightning Network? what is the problem it’s trying to solve? and how is that important to Bitcoin?

Christian Decker: so fundamentally the problem that we have is that a blockchain does not scale indefinitely. Basically we are limited by the parameters not just of the Bitcoin blockchain but also of the network that we run on to a limited capacity that we can use. and going beyond that, which might be required for a global system such as Bitcoin for everyday purchases, might not be possible directly on the Bitcoin blockchain. so what we do is we try to make more efficient use of the limited capacity that we have by aggregating more and more transactions into very few on-chain transactions. and the way we do this is by creating off-chain contracts that can handle hundreds or thousands of transfers and whose on-chain footprint then end up being just single transactions on the Bitcoin blockchain. so what we do is we open a persistent relationship between two endpoints called a channel. we do that by sending a certain amount of Bitcoin to a multi-sig address where both endpoints have to agree on what happens with these funds, otherwise these funds cannot be moved. and then we decide on how to divvy up these funds. what we can do is, if you and i want to open a channel, i can put in 10 Bitcoin and you can put in zero — so initially all of the 10 Bitcoins belong to me, but then i can decide to basically pay you a Bitcoin by agreeing on a new settlement of this off-chain contract where you get 1Bitcoin and I get 9. so we change how the Bitcoins are tallied up. and once we are happy with how we did that or I want to use my funds elsewhere, we take one of these agreements — the latest one — and settle it on the blockchain, freeing these coins again from this off-chain contract, and at the same time settling every single agreement that we have in the meantime with just a single transaction chain. so for us it’s a way to aggregate many many thousands of transactions in a very small space. and besides that we have different trade-offs that we that we can also address later maybe.

Jesse Knutson: so are there any limitations on the Lightning Network at the moment? I remember before there used to be like a funding limit — the amount of Bitcoin that you could send between parties. and can you go both ways in transactions now?

Christian Decker: yes. The fundamental innovation that we had as compared to prior constructions like the simple micropayment channels was that we can move funds in both directions. With simple micropayment channels we were limited to forwarding only in one direction, because the way we were sort of disambiguating which state was to be settled was by the recipient choosing always the one where he had the maximum. With Lightning and later developments like Eltoo, we came up with mechanisms where we can actually enforce a later state without having to rely on these weak incentives to do so. As for limitations, yes we initially had a limitation about the number of Bitcoins you could put into a single channel, but that was much more to prevent people from pulling their life savings into a channel, and much less of a technical limitation. It is something that we added as a gentleman’s agreement between parties to protect people that might be over-enthusiastic from getting really badly hurt. but you could always override that and we have since removed those limitations from the defaults.

Jesse Knutson: okay so there’s no limitations on it at all now?

Christian Decker: no

Jesse Knutson: okay wow that’s exciting

Christian Decker: You can put your life savings into it but I suggest not to!

Jesse Knutson: Exactly. so I guess fundamentally this is a scaling solution, and the focus I think on scaling in Bitcoin is certainly on Lightning at the moment. are there any other solutions to this problem? are there any other competing solutions, or is this the one at the moment?

Christian Decker: I think there are a couple of complementary solutions being tackled at the moment. it depends on how widely you define the Lightning Network suite of protocols.

Jesse Knutson: well even broader — to just scaling Bitcoin.

Christian Decker: yeah so there’s definitely the class of off-chain protocols — L2, L3 or whatever you want to call them — where we are actually doing things off the blockchain, hence the name. And Lightning and other proposals certainly go into that direction where we anchor some predefined agreement on the blockchain itself and then we go into a separate room and do our trading back and forth and only when we want to settle, we go back to the blockchain and enforce what the agreement was that we settled. There is the Lightning Network as we have it today, there is a proposal such as Eltoo for different kinds of constructions for similar channels, there are discreet log contracts that try to do some more fancy stuff, there’s multi-party channels, but all of these are based around the idea of setting aside some funds on-chain, immobilizing them such that the parties of the off-chain contract have to agree, and then mobilizing them again once this agreement has to be resolved. and that goes hand-in-hand with other attempts to increase the efficiency of the on-chain mechanisms: things like Taproot, things like cross-signature aggregation, where we make more efficient use of the capacities in the Bitcoin blockchain that we have to squeeze in ever more transactions into the existing space — this, without breaking backwards compatibility with existing client implementations.

Jesse Knutson: yeah or even as I think you mentioned last time I mean eventually you know the 2017 scaling wars were about bigger blocks, or I guess Lightning Network fundamentally. so at some point bigger blocks do play a role in it as well i guess. is that correct?

Christian Decker: I think it’s probably not correct to say that the 2017 scaling wars were about the block size. it was more about when should we actually consider a block size increase. i don’t think that fundamentally everybody is against eventually increasing the block size. we might have to do that eventually. the problem is more when we want to do that and when we consider it safe to do so? and 2017 there were a lot of proposals that were showing up that there is capacity that we could use before making a breaking change, before potentially forcing a large chunk of the network off of the blockchain, before forcing participants that might currently be able to participate off of the network by imposing a higher computational burden and a higher storage burden. and it basically is about timing — it is not about a fundamental opposition to considering a block size increase. the problem is it being a breaking change, it should definitely be the last option we consider — not the first one — just because it looks simple. it definitely isn’t simple.

Jesse Knutson: and what about Liquid? how does Lightning interact with Liquid?

Christian Decker: so depending on who you talk to, Liquid is also a L2 solution, and there the sort of counting gets a bit weird because you can actually have Lightning generally considered to be a L2 solution on top of Liquid. and then you have a L2 solution on top of a L2 solution — hence I usually go for off-chain contracts, because those don’t infer an ordering. but Liquid can be used as a basis for off-chain contracts as well, and therefore most of the technology — if not all of the technology we build on Bitcoin — can be ported over to Liquid. and in fact, Liquid builds on the Elements project which is the experimental platform that Blockstream has been built on. and being this experimental platform, it is a way for us to verify that ideas work out, where we can test new features, and where we can do very interesting things before trying to back-port them into a more stable Bitcoin environment where we can then show the utility which we experimented on in Elements. and so SegWit for example is something that was first tested on Elements and where we could then take the results back to Bitcoin Core and have a very educated guess about how it should look like in the end. and so our implementation c-lightning works both on Bitcoin as well as Liquid — with LBTC — and yeah it just works.

Jesse Knutson: so outside of c-lightning, there’s other competing implementations of Lightning, right? is that the right way to characterize it? is it competing? is it eventually like a winner-takes-all of this market? or does the whole pie grow together and they each have their own kind of niches?

Christian Decker: i’m not seeing it as pure competition. it is more of a collaboration on interoperability, adding more perspectives to the specification effort. we come from very different places and different use cases that we’d like to address, and sort of having this clash of visions ultimately ends up with a more complete and better system than if one of us would go it all alone. so on the specification and on the compatibility side we are very much collaborating. we are competing a bit on the feature side where everybody is coming up with their innovative use cases, with their more extended features and user interfaces and so on and so forth. but on the specification and compatibility side it’s a very friendly process, and I think it’s not going to be a winner-takes-all situation. we try to address very different markets — we do have very different trade-offs. with c-lightning for example we aim for being very lightweight on resources, allowing you to run on servers in a high-density environment, or on embedded devices with limited resources. whereas other implementations might target more of the mobile market or the desktop market. so I think everybody has their niche and we collaborate wherever possible and we compete a bit on the user experience.

Jesse Knutson: so where do you think we are in the development of Lightning? in terms of: adoption, ease of use, maturity — how early are we in into this and how much farther do you think we need to go before it gets really mainstream adoption?

Christian Decker: I think at the moment it is very much still a techies tool. you need to have quite a bit of experience, you have to have quite a bit of knowledge about the underlying workings, and the abstraction layers are definitely not quite there just yet. but the basics are working solidly. the adoption is already there, but I think before we can really talk about mass-adoption, we need to provide better abstractions, better user interfaces, and either make things more understandable or hide them below the covers such that I don’t want to have to explain to everybody how a channel works or how to re-balance your liquidity — and that’s even on top of all the knowledge you already have to have about Bitcoin’s inner workings — now you also have to learn about channels and liquidity and re-balancing and how to find a path and onion-routing. it’s a huge thing to learn, and so we’d like to abstract away all of these details or automate them as much as possible, such that new users aren’t confronted with this overwhelming piece of information that usually scares them away.

Jesse Knutson: but there are implementations — or the people who are adopting it quickest right now — I think of El Salvador, right? and the 70% of their population that’s unbanked. these aren’t tech-savvy people, presumably so how are they interacting with Lightning?

Jesse Knutson: so there’s this dichotomy of users we have at the moment where the one side is very tech-savvy, they they know about all of the intricacies, and they have spent and invested the time to actually read up on this stuff. and it’s a major investment — don’t underestimate this. and the other side of users is where these users are using a provider that tells them, Hey, don’t worry — we’re taking care of everything! sadly, that also means that they’re taking care of their security. and the classic Not your keys, Not your coins dictum of Bitcoin — it means that you are fully trusting this custodian to actually have your best interests in mind. so probably not the thing that we want to encourage, but for ease of adoption and reach that we can have to other users, it is probably the way that many people will go.

Jesse Knutson: yeah I think that’s probably likely. it seems that you kind of need a big exchange blow-up every cycle just to remind everyone of that Not your keys, Not your coins principle, and we haven’t had one in a while so we might be overdue, knock on wood. one of the main criticisms you get of Bitcoin is that it’s old tech, it’s clunky, it’s difficult for people like my parents or someone to use, and it’s slow, right? so you do a transaction, it comes up as pending really quickly, but if you go back to december of 2017, you could have transactions sitting in the mempool for hours or god-forbid, days, waiting for them to clear. so how important a piece of the puzzle is Lightning to making Bitcoin that much easier for everyone to use, and to achieving its end-goal of — the white paper’s behind me, the peer-to-peer digital cash — and hyperbitcoinization, and taking over the world?

Christian Decker: I think it’s a very important piece of the puzzle. I mean I too want to have Bitcoin be a currency that we can use in a day-to-day scenario, and that has always been my view of this system that and why it’s interesting to me ever since 2009. and so Lightning actually gives us the opportunity of having better trade-offs — or different trade-offs, let’s say — to Bitcoin-on-chain transactions. besides the scalability multiplier that we already mentioned before, it also has different behavior. unlike on-chain transactions in Bitcoin, a payment on Lightning is final as soon as it is acknowledged by the recipient. so there is no waiting for confirmations — you can literally transfer Bitcoin over Lightning at the speed of light, and there is immediate finality. there is also a difference in privacy: when you use Lightning to transfer your Bitcoin back and forth, there is no permanent trace being left on the blockchain. what is left on the blockchain is an aggregate of millions of individual transfers, but not the individual transfer anymore. so, while buying coffee on the Bitcoin blockchain will leave a permanent indelible trace of my interaction with that coffee shop, in Lightning it is far far more difficult to disentangle the traces that are left on the blockchain by individual payments because they’re all bunched up into the final settlement, and it might even be impossible. so only people that are directly involved in the payment itself have any idea that there is a payment that happened. and so we have scalability, we have real-time payments, and we have privacy. and for us developers, maybe it’s interesting to see that doing off-chain contracts is also a way to add experimental features in a far quicker way than if we had to convince the entirety of the Bitcoin network to do an update because, Hey we have this cool idea, it might be worth trying it out, but now I have to go on a huge campaign to basically change the protocol. whereas if we go for off-chain protocols, we can have much quicker interactions, and only the parties that are involved have to even know about this experiment. and so over the last couple of years, there’s a lot of experiments that sprung up from Lightning, to multi-party channels, to discrete log contracts, that would have been very difficult if we had to do that directly on the blockchain itself. because again, pushing changes down to the blockchain — a global consensus system — is really hard.

Jesse Knutson: yeah, painful. so I think the use case of Bitcoin — we kind of touched on this — is different in different parts of the world, right? so interestingly, in the developed world it’s store of value, it’s an inflation hedge, it’s speculation. and then in emerging economies it’s more people actually using it to make payments and to do things like you would use money normally. so where do you see the growth for the Lightning Network coming from? I think in 2017 a lot of us assumed it was going to be through micropayments and social media, but the whole El Salvador experiment is really interesting to see it come up organically through people that actually are unbanked that really need this kind of technology. so where do you think the bulk of the growth is coming from maybe in the next five years?

Christian Decker: I certainly hope that this trend of rapid expansion from the people that need it most continues throughout the future. and I think El Salvador was definitely a big moment for the Lightning Network, because all of the sudden you had this confirmation that, Yes, this is actually working for the intended use case that we set out as Lightning developers all these years ago to basically build a system that brings back the cash nature, the payment nature, of Bitcoin. and so my hope is that we can actually help these communities to build an alternative payment system to what is clearly not working if there’s like 70 percent unbanked — there is something wrong and we should address that.

Jesse Knutson: exactly, yeah. and it’s exciting. I mean Bank the Unbanked is such a cliche but it’s cool to see it developing in this way, and people who actually need it being able to put it to work — that’s pretty cool. so do you see any issues though with the Lightning Network? I mean this is a very public prime-time test of the lighting network. do you see any issues? like technically is there anything that could go wrong when we’re trying this experiment at scale?

Christian Decker: there’s a lot of unknowns in here that we don’t know how to steer at the moment, and how the network will react, so certainly the structure of the network and the evolution of the network being a network where we perform payments by following connections among the peers — unlike Bitcoin which is a broadcast medium — we actually have to use existing communication paths in this network. the structure is very much what gives both stability but might also create bottlenecks, and so we need to be very cognizant about these trade-offs and we have to make sure that we are not developing single points of failure, and so a steady incremental growth of the network is certainly desirable because it gives us time to evaluate the existence of bottlenecks and steer against them. whereas a sudden influx of millions of users might not give us time to react to these developments. and if we recreate single points of failure, what’s the point, really?

Jesse Knutson: yeah, okay. and do you see any indications of that now? is there any way to track this in real-time?

Christian Decker: so there are certain measurements that we can perform. I myself have supervised a couple of student theses looking into how the structure of the network is evolving, how the structure of the network is looking like. we’re talking about centrality measures that give us a clue about what paths might be taken in the payments — again we don’t really have any visibility into what payments are performed on the network overall, but by looking at the structure of the network we can see whether there are single points of failure. and there are certainly some that have a very dominant role, but as long as we have alternatives — so if these if these participants go down in the network, we still have enough resilience in the network itself to take over the load. and so i have been quite happy with this redundancy — in a positive sense — here, of the network. but we will definitely continue to monitor that.

Jesse Knutson: and what about exchanges? i mean this is another big application that people used to talk a lot about. and I think to date only Bitfinex is the only exchange that’s integrated Lightning so far. and even ones that have talked about it seem to be really slow in bringing it to fruition. why do you think that is? do you have any thoughts on that?

Christian Decker: the main issue is that usually either you are a trader that is swapping back and forth between a currency pair trying to time the market, or you are interested mostly in unidirectional flows. so either you are putting your fiat on an exchange and then getting your Bitcoin out, or you are putting your Bitcoin in and getting your fiat out. and the place where Lightning shines the most is where payments in both directions are almost balanced.

Jesse Knutson: so kind of net each other out

Christian Decker: exactly, because then we actually can make use of the liquidity that is in a channel multiple times, amortizing the cost to actually set up the channel. and so for day-traders it’s definitely something interesting where they can open a channel with an exchange once and then at the beginning of the trading day, or whenever they set up an order, they can push over just the amount that is required for their strategy over to the exchange, and at the end of the trading day, or when the order gets executed, they can pull back the funds to their side of the channel. and this minimizes the exposure to the custodial risk that an exchange might pose, right? if the exchange doesn’t have control over your funds because the funds are actually in a channel and belong to you, then even the exchange getting hacked doesn’t cost you any funds. but when you are the retail user that is making use of an exchange to swap in fiat for coins or coins for fiat then these channels don’t get used as much. the utility that you get from going over Lightning is much reduced, and so there is less incentive to actually do that. and so i would definitely like to see a less trusted exchange, because you can actually pull the control of the funds from the exchange, and thus also reducing the liabilities an exchange might have — which I think is a positive for exchanges — but still retain the ability to exchange your funds at any point in time by simply swapping them in for funds on the exchange.

Jesse Knutson: now what about Taproot? that’s another big one. what does the Taproot implementation mean for the Lightning Network?

Christian Decker: there’s a couple of things that impact Lightning. first and foremost of course there is much less information that leak onto the blockchain. since Taproot allows us to hide even complex scripts inside of what looks ultimately like a singlesig address, you can hide a lot of the details about a Lightning channel inside of Taproot. ultimately Taproot will also enable us to have multisig that look just like a singlesig, and since all of these off-chain contracts basically started off with a multisig where the participants add the funds into a shared account, namely multisig, we will no longer be able to look at the blockchain and say, Oh that this is a two-of-two — it might be a Lightning channel — no, that trace is gone. and even for closes where we have a bit more complex scripts because we have to deal with, Oh this guy now behaved and this guy now is correct and there’s a time lock and stuff like that — that will also be all hidden inside of taproot ultimately. so if you have a collaborative open and a collaborative close between agreeing parties, there will be absolutely no trace of the channel even existing other than somebody sent some funds over from one address to another. in addition, there is a lot of cool things we can do with the newly-introduced Schnorr signatures, which allow us to be much more efficient in how we use some of the primitives that we have in Bitcoin. for example, we have a couple of messages that require multiple signatures and multiple public keys and all of these can now be combined into a single public key and a single signature. and beyond that, the way we currently implement end-to-end security in Lightning payments is called hash-time log contracts (HTLCs). they have a bit of a downside in that they are recognizable by parties that participate in the network. so if i receive a forwarded payment for a hash H, and then i receive a second forward payment for hash H, i can see that they are the same payment. and with Schnorr, what we can do is we can use PTLCs (point-time log contracts) where this constant — these values — are changed over the course of a single payment. and so this collating of information is no longer possible, increasing not only the privacy but also but also making funds more fungible in the network.

Jesse Knutson: okay interesting. so it sounds like the main application is probably privacy, right?

Christian Decker: yeah. and size savings! don’t underestimate size savings.

Jesse Knutson: and moving on: so Greenlight. blockstream recently announced greenlight. can you run us through what the thinking is on greenlight and what the benefits are and who the target audience is?

Christian Decker: yeah so like we said before, there’s this dichotomy of users: when we have Lightning users we have the ones that really have invested time to read up and learn about all of the intricacies of running a Lightning node and they get their hands dirty to actually run their own Lightning node. then we have the vast majority of people that either don’t have the time to invest or aren’t just interested in the tech details that underlie this — and we shouldn’t be forcing them to actually have to learn this to use them. and so we took this custodian model and said, Okay what if we strip them of the keys? what if they no longer have to have access to the keys? can we find a middle-ground where we can help users with the management of the infrastructure, the management of the nodes, without having access to the keys? and so adhering to the Not your keys, Not your coins principle, what we do is we can run c-lightning nodes on behalf of our users without ever having access to the funds that are underlying it. and so what we do is we provide a service that allows users and developers to spin up c-lightning nodes incredibly quickly — in less than a second you can have your c-lightning node up and running — but all the time retaining full control over the funds that you put onto that node. and we do that by having the node request signatures from an app on your phone, on your desktop, or on your hardware wallet, whenever it wants to move the funds. and the app can then independently verify that, Yes, this is actually sensible and the command that initiated this actually came from a from an authenticated user and not a hacked node. and so what we end up with is a system where we can help you manage your infrastructure, where we can manage your your channels for you. and you basically can reap the benefits of being a Lightning user much quicker than if you had to first learn all of the technical details to get to that point. and so our hope is that by showing users the benefits of Lightning before they have to invest all of that time, they will actually end up first of all seeing that this is something that they might be interested in, and later on invest the time to take on more control over their own infrastructure. and it is certainly our goal to have an easy on-boarding experience, provide the learning materials for you to upgrade your own knowledge, and eventually we want you to off-board into your own infrastructure. and for that we have built a variety of tools that we will make available for you to actually run greenlight on your device, or provide the same service for your friends and family. so it is basically our strategy of moving the education behind this first Aha moment and making it more palpable for users to to get started with Lightning.

Jesse Knutson: okay we’ve got a couple of questions here from twitter as well. so three questions here. the first question is what will the Lightning network wallet Bitcoin payment user experience be like in 2030 relative to what it’s like now?

Christian Decker: my hope is that it will be absolutely seamless. there should not be really a difference between Bitcoin on-chain and Lightning funds, simply because that is already confusing, right? i want to perform a Lightning payment but i have five Bitcoins on-chain and three off-chain but the amount is four. what can i do, right? and so we want to abstract away these differences by both introducing technology on the specification side with proposals such as splicing, and with swap services that allow you to do on-chain payments despite only having off-chain funds. and the idea here is that ultimately we end up with a single balance being shown to the user and the full balance can always be used for on-chained payments or off-chain payments, and you can basically decide on a whim. so that’s certainly a hurdle that we’d like to remove over time, and ultimately it should become as easy as approaching the point of sale and tapping your phone or tapping a device on it and be able to perform payments in just a matter of seconds — the entire payment flow that we’ve gotten used to from centralized organizations but enhanced by more privacy and decentralization.

Jesse Knutson: that’s great. so the next question is this user says that with c-lightning they currently only see the fee detail on a payment. is it possible to show all the routing details as well?

Christian Decker: the thing is that the way we currently store that information is such that we only have details about the difference between the amount that was paid and the amount that was initially sent. and so that is the fee that we pay to the network. we can of course add that information, but we have to gauge whether it is generally usable for users or whether this is just a very specific use case that maybe impacts just one or two users. this is because we don’t want to require more resources from the systems that we run on, and storing more information increases the database size. and so it is always a trade-off between what we store, what we display, and how many user users actually have an advantage from it. that being said, I mean c-lightning does have very extensive plug-in infrastructure where we expose a lot of that information. and so it should be quite easy for medium to advanced users to build a plug-in that takes all of this information and stores it in a separate file so that they can then go and analyze that information after the fact.

Jesse Knutson: and why is that desirable? why would somebody want to see the routing details?

Christian Decker: it might actually be useful to determine whether certain channels in the network are something that are useful for users. and if a channel for example leverages higher fees than a parallel channel, we might still want to bias towards it, because in the past we’ve seen that that is very reliable. and so this information can be used to optimize — over the course of multiple payments — the reliability, but also the speed of a payment. and so it is more of an advanced use case. not many people do hundreds or thousands of payments where this would become statistically significant, but for advanced users it’s definitely an option to store and bias with that information as well.

Jesse Knutson: okay the next one: what steps need to happen before we can implement splicing in more wallets? and maybe you can explain what splicing is as well?

Christian Decker: so splicing is actually the thing that i mentioned before where we want to have a single balance that can be spent both on-chain and off-chain. so splicing basically boils down to having all of your funds in a Lightning channel — no funds on-chain at all. and when you want to perform an on-chain payment what you do is you coordinate with your counterparty to say, Hey i want to close this channel — part of the funds go one way, and then we reopen the same channel in the same transaction. basically what we do is we close — move funds out — and reopen the channel. since the funds that remain in the channel never touched a singlesig and were always under the control of both parties, we can be absolutely sure that this will eventually confirm on the blockchain. and so therefore we never have to wait for it to confirm in the first place — this way you can perform on-chain payments from off-chain funds. there is also the opposite direction where you can say, Okay i close this channel, i splice in funds from outside, and then i reopen this channel immediately. and there are a couple of reasons why you might want to do this. so for example, if you’re a merchant and you have this channel that is very active but you don’t have any funds on that channel anymore, you might want to add some funds from an on-chain address that you have somewhere else to bump up your spending capacity in that channel. or if it’s a very active channel you can increase the capacity just to say, Okay we now can have a bit more in balance, we can now process larger payments, even though we didn’t know that at the beginning and we didn’t allocate these funds initially. so we currently have a proposal that is out there for other implementations to verify. it builds on Lisa Neigut’s proposal for dual-funding which is also a proposal that we have on the Lightning specification. and it is just a matter of time until other implementations will pick this up and dissect it and propose changes, maybe. after all, this is the principle of the Lightning specification: that we want to have as many eyes on the specification as possible so we have to get the best trade-off in the end. and so once we get a feedback from other implementations, they might implement it themselves. and once we have at least two independently-implemented implementations, then we can go and actually take this proposal and incorporate it into the Lighting specification. so we always have — for any change that we want to have to the Lightning specification — we need to have two independent implementations that verify that first of all, all of the details are in there, and that the implementation is actually solid and doesn’t break.

Jesse Knutson: great all right to wrap it up. looking forward, what excites you the most about the world of Bitcoin?

Christian Decker: the world of Bitcoin — well i’ve had quite quite a bit of excitement already!

Jesse Knutson: never a dull day.

Christian Decker: yeah i’m hoping that we will continue seeing this incremental adoption. i don’t see that we will have a sudden jump. i see a lot of technical challenges that are yet to be addressed, and that’s always interesting for me. and it’s what’s kept me interested in the space for the last — wow it’s been 12 years already.

Jesse Knutson: time flies!

Christian Decker: there’s still so much to be experimented. so much to be discovered. and i’m looking forward to it.

Jesse Knutson: that’s great, christian. really appreciate you doing this and taking the time to speak with us today.

Christian Decker: awesome yeah thank you so much for having me

Jesse Knutson: all right thanks a lot

Christian Decker: awesome. see ya.