Bastien Teinturier - 00:00:00:
It was really the very early days of sending payments through Lightning, and our goal was just to ensure that it got better. Whenever I explain to people what I work on and how I work on it, no one understands it. Everyone says, but why are you sharing your code publicly with those guys who are your competitors? But you're also working with them, but you're doing the same thing, aren't you? Cannibalizing yourself. We're all collaborating, really on the same project, so it feels much more like collaboration than competition. It's really a matter of what priorities you have for your specific product. In our case, we really want to prioritize your funding and spacing because we feel it really helps the mobile UX experience. Lightning Lab is mostly prioritizing open Taproot instead of opening and splicing. But eventually, at some point, we will also implement Taproot. They will also implement the offending, and we will end up with feature priorities. I think that Bitcoin developers should try to stay layer to agnostic, but acknowledge when there are things that Bitcoin overall would benefit from. It's just magical to be able to send money to the other parts of the world just via the Internet.
Kevin Rooke - 00:01:16:
Bastien Teinturier is the VP of Engineering at ACINQ, the team behind the Lightning implementation Eclair, as well as the mobile wallet called Phoenix. In our discussion, we spoke about collaboration and competition between Lightning implementations. Today we discussed the task of building Eclair and Phoenix, and we also discussed Lightning adoption and Lightning business models. Bastien has asked to have his share of today's show splits sent to the Human Rights Foundation. So if you enjoyed this episode and if you learned something new, the best way you can support the show and the Human Rights Foundation is by sending in sats over the Lightning Network. You can use any Podcasting 2.0 app, but my favorite to use is Fountain. Just a quick message from today's sponsors. This show is sponsored by Voltage. Voltage is the industry standard and next generation provider of Lightning Network infrastructure. Today's show is also sponsored by Stakwork. Stakwork is a Lightning powered transcription tool that takes the best of AIS and humans to create better, faster, and less expensive transcripts. We'll have more from Voltage and Stakwork later in the show.
Kevin Rooke - 00:02:28:
That's Jan. Thank you for joining me today. I'm excited to talk all about the work you're doing at ACINQ and Eclair and Lightning implementations more broadly. But before we get into the show, why don't you tell listeners a little bit about how you first discovered Bitcoin and why you decided to build on the Lightning network.
Bastien Teinturier - 00:02:50:
Okay, so first of all, thanks for having me. I discovered Bitcoin a while ago, but not that long ago. I think it was in 2015 probably when a colleague at Microsoft did a brown bag explaining what Bitcoin was and why it was interesting. And at the time, it piqued my interest, but not enough to actually dive into the code and look into it more deeply. But then at some point, I got bored from what I was doing at Microsoft and wanted to do something that was more researchy, closer to math. And I really like cryptography, so I was looking for a job in the crypto industry and I was lucky to find one. And eventually, at some point, I was listening to a podcast talking about the Lightning Network. And I didn't know about the Lightning network at the time. I didn't know anything about it. I think it was in 2018, something like that. And I'm not entirely sure, but I think it was Christian Decker who was interviewed on that podcast and mentioned that it was an interesting project because there were multiple implementations and he started naming them. And then I found that Eclair was a French name. So I said, oh, if this is in French, I really have to see the hiring and apply. And luckily for me, they were hiring at the time and Asan had just done it, Series A, so there was room for new people to join. So I applied, and I think that two weeks later I was in. And then it's been a great adventure since then.
Kevin Rooke - 00:04:22:
Nice. What was it that got you so excited about the idea of Lightning? Was there anything in particular that stuck out to you and made you go, oh my God, I have to work on this?
Bastien Teinturier - 00:04:33:
I really liked the fact that it was using onion encryption because I thought it was really cool technology that was underused. Basically only the top project was actually using onion encryption, whereas I thought it was really interesting and I was surprised to see that it was not used at all by other peer to peer networks. There weren't that many peer to peer networks, actually. That's really useful. So I thought that this aspect was really interesting. Building a peer to peer network with encrypted messages and somewhat good privacy guarantees is something that I found fascinating. So this is really what drew me to this. And also it's just magical to be able to send money to the other parts of the world just via the Internet, through just a mobile phone. And this is incredible. We don't even realize we forgot how incredible that is today, to be able to just pay anyone in the world without having to ask anyone for permission.
Kevin Rooke - 00:05:35:
Yeah, that's a really good point. Now, how long have you been at ACINQ? Have you been there? A few years.
Bastien Teinturier - 00:05:42:
I've been there for less than four years.
Kevin Rooke - 00:05:45:
Okay, so in that time, let's say four year time span, you discovered the Lightning Network in 2018 on that podcast with Christian Decker. What did you think the Lightning Network would accomplish then? And in the last four years? Has it lived up to your expectations or exceeded them or fallen short?
Bastien Teinturier - 00:06:08:
Yeah, when I joined, I was just curious to see how far the project was and if it was actually working. And at the beginning it was kind of working, but payments were mostly failing. They were getting stuck very often. A lot of details of the internal details of Lightning had to be exposed to the UX and users. It was just impossible to understand for real users. So it was really painful. It was really the very early days of sending payments through Lightning and our goal was just to ensure that it got better and that people could actually use this thing reliably and could actually make payments without having to think a bit too much about it and without having to be very technical users. So I think that has been the main focus for the last years and we've accomplished a lot and it's improved a lot nowadays. I think that anyone who tried Lightning four years ago and was trying it from scratch today would be very surprised by the state of Lightning today. And I'm really proud that we were able to achieve that. And there are a lot of aspects that are different aspects that we are working on, ranging from security to privacy to UX, and I think that we have improved on all of those. Also, another very important thing that has happened in the recent years, I would say only in the last two years or so is better collaboration between Lightning folks and bitcoin folks, because we realized that Lightning couldn't just be built without touching bitcoin at all. If we wanted to make Lightning fully secure or better, we have to make some changes at the bitcoin layer. And those changes are not only for Lightning. Therefore, any protocol that is building on top of bitcoin, like any other layer to protocol, like bolts, for example, or payment pools, all of those things would benefit from some changes in bitcoin. And that was only started because there were good connections between the Lightning developers and the bitcoin developers. And we started really working together and making sure that people working on, some people working on bitcoin had this in mind and knew that there was some work necessary to a little bit earlier to protocols. So this is something that's fairly recent and I'm very happy because we've had already great results on that topic and I think it's going to get even better with pending work on transaction version three and potentially L2 at some point. So this is really interesting work.
Kevin Rooke - 00:08:47:
Yeah, that is interesting. Why do you think the communication between bitcoin developers and Lightning developers has gotten so much better in the last couple of years? Is it that Lightning had to reach this, like, critical mass of adoption and desire in the community for bitcoin developers to consider it seriously? Or what was the catalyst there that kicked off this improved communication?
Bastien Teinturier - 00:09:14:
Maybe because I don't think Lightning is the only layer 2 solution, not at all. Lightning is a specific set of tradeoffs that is good for some scenarios, but there are other scenarios that are better addressed by other kind of layer two protocols on top of bitcoin side chains or anything else. And I think that in the early days of Lightning, people were cautious valuing Lightning too much. Everyone technical knew that it would take a lot of time to build that. There were a lot of technical issues that needed to be figured out and most of them were non trivial. So people didn't want to say, Lightning is definitely the only thing that's going to make bitcoin scale. They were cautious and we don't want to make it look like there's only bitcoin and Lightning. There are lots of other layers of protocols that are interesting and I think that's why it's important for bitcoin core developers to be interested in other things as well and not necessarily be really invested into Lightning at all. But we need some of them to be invested in adding things to bitcoin that help over layer two protocols reliably build on top. And I think that since Lightning has made a lot of progress and was able to basically find the limits of what we could do with bitcoin today, that's when we realized that there were improvements to bitcoin that were really necessary and that there were more general than only lightning. So bitcoin core people just acknowledge that because they knew that there were things that could be improved there. So that's when the discussion started happening and things started to people started to work on those things.
Kevin Rooke - 00:10:58:
Right, now how do you think you mentioned that there are multiple layer 2s out there and there will probably be more in the future. How do you think bitcoin developers should be prioritizing or thinking about how to prioritize features for the various layer two scaling solutions?
Bastien Teinturier - 00:11:17:
I think that ideally they would not have to know about any specific one, but all the different layer two solutions should help give Bitcoin core developers feature requests of things that would make every layer two protocol better. And then there should be some aggregation for finding out the right abstractions that are actually working for all of those protocols. For example, fee bumping is something issues with feedbumping are something that we run into with Lightning because I think it's very mature, but any layer two protocol that uses present transactions has these kind of issues but just wasn't mature enough to start really investing into them. But this is a really fundamental issue in bitcoin. So the feature request comes from layer 2 developers, but actually it makes sense to fix it for bitcoin as a whole. So I think that bitcoin or developers should try to stay layer two agnostic, but acknowledge when there are things that bitcoin overall would benefit from and that would incidentally, also fix the life of layers to developers.
Kevin Rooke - 00:12:27:
Right, one thing you mentioned early on was when you started on Lightning payments failed frequently. And this is something I heard from a lot of people on the show and a lot of people have mentioned how much payment sale rates have gone down in the last year or two. What do you think? Is that attributable to? Why are we now seeing river put out a great report a while ago, maybe a couple of months ago, that their node is seeing 98% 99% payment success rates. Now, early on when I was talking to people at the beginning of the show, people would say hey, back in 2020, every time I did a payment I kind of half expected to fail and I wasn't sure if it would actually go through. And then obviously back in 2018 I'm sure the problem was much worse. What are some of the developments that have led to the point where we can now reliably send a payment through most nodes on the network?
Bastien Teinturier - 00:13:35:
I think it's mostly that we've done a lot of cross implementation compatibility work because one of the issues, it was not only payment failing, but one issue was payment just being stuck. And that was something that used to happen a lot. And when that happened, you had to wait for a week to get your funds back because some channel somewhere was withholding the HLC and had to eventually foreclose. And the reason for that was almost all the time bugs in one of the implementation or incompatibility in one of the implementation we realized that we are working with a common specification that we hope is general enough and precise enough that people implementing it, many different teams implementing it would implement the same thing. But we actually realized that there is room for interpretation. And most of the things that are in the spec sometimes can be interpreted differently by different teams depending on what they already have in their implementation. They are sometimes piazza into one interpretation of the spec or another and that could lead to incompatibility between implementation. And that was the main reason that the payments were getting stuck or failing. And we spent a lot of time doing cross compatibility work, looking at other implementation, finding those bugs and making sure that they were fixed. And I think that's why we are in a good state now because implementations are very compatible today. There are not so many remaining issues where implementations differ in behavior.
Kevin Rooke - 00:15:11:
Can you highlight some of the specific interpretations that you mentioned that different implementations had interpreted something differently? Are there any specific examples that you can point to from the past?
Bastien Teinturier - 00:15:26:
There's one that was recently raised that is still not fixed, where the specification says that if you want to close a channel that's being used, there may be pending ACINQs in the channel you send a shutdown message to. Your peer and both of the peer's will send shutdown to each other which just sends a signal that now we're going to start closing this channel. It's okay. There are still DLCs. We're just going to wait for them to fail or to succeed, but we're not going to add new HTLC. And once the channel is empty, then we are actually going to close it. And that's what CLN and Eclair do. But actually we realized that LNG does not do that. And if you send shutdown to LND while there are Aclcs inside the channel, they will just send an email out to you and refuse your shutdown. And I thought that this was really obvious from the spec how it should be used, but it shows that it's not the case. So we have more work to do here to clarify the specification and make sure that LND also updates the implementation to avoid these incompatibilities.
Kevin Rooke - 00:16:32:
I'd love to hear your perspective on your relationship with the other implementations. Like, how frequently are you guys communicating back and forth? What are some of the discussions that you're having? What do they look like? And in what ways are you working together? Rather than to some degree, it's a competitive environment, to some degree it's a collaborative environment. I would love to break that down and figure out to what degree are you competitive or collaborative with all the other implementations?
Bastien Teinturier - 00:17:03:
Yeah, and it's interesting because that's the part that people not working in Open Source just don't understand at all. Whenever I explain to people what I work on and how I work on it, no one understands it. Everyone says, but why are you sharing your code publicly with those guys who are your competitors? But you're also working with them, but you're doing the same thing, aren't you? Cannibalizing yourself? And that's really something that's very specific to Bitcoin and Open Source, and it's really hard to grasp for people with normal jobs, basically. And we've known each other with the other implementation for a while, for the OJ. The OJS know each other since 2015, when they met in Milan, 2016 maybe. So we spent a really long time working together. We communicate a lot in many channels, and we regularly look at what everyone else is doing. We see each other in real life regularly at conferences, or we try and at some point organize core Lightning conference every year. But then COVID happened and it kind of broke that vibe, but we need to reboot that. And we also have a spec meeting every two Mondays where we do a call. And most of the implementation, most of the implementers are usually there, so it gives us a good opportunity to talk face to face over video. And we interact a lot over GitHub and many different chat applications. So we really know each other very well. We've worked a lot together, and it feels like we're all not employees, but we're all collaborating really on the same project. So it feels much more like collaboration than competition to me. And luckily, that's mostly because we are lucky enough to have enough money to be able to do that without having to generate enough revenue. Lightning loud Venus we are Vcfunded and that gives us a lot of freedom. Blockchain has enough money to invest into CLN without asking clients to generate revenue. And here we're really lucky to have that because that's what helps us being more collaborators and competitors. So we should be aware that this is the reason why we're allowed to have that very good collaboration and I hope we can preserve that.
Kevin Rooke - 00:19:29:
Yeah, that's very cool. Now, when you talk about some of these collaborations and some of the meetings and things like that, are these mostly private meetings between the implementations or is there value in making these more public and opening them up to the broader Lightning ecosystem?
Bastien Teinturier - 00:19:48:
They are public. Bi weekly meeting on Monday night in a French time zone is open to everyone. I post an issue on the GitHub spec before every meeting to say when the meeting is to give a link to the video. And there's an IRC channel, a Latin dev where we are all usually hanging around so anyone can join and we always see new people joining and just listening in. Anyone can even ask questions if they need. And yeah, it is really public. All. The Lightning conference that we did in Berlin was also open to everyone. And we usually go to a lot of different conferences where we see a lot of people and a lot of people can come talk to us and ask us about our projects, about things they would like to see in our products. They would like to see Lightning. So I hope that it feels like we are approachable enough and easy to reach. But I don't know, maybe if people disagree, don't hesitate to reach out to me and we'll see how we can make it easier for people to give feedback and integrate into a project.
Kevin Rooke - 00:20:56:
Fair enough. So I want to jump into we talked about competing and collaborating a little bit and it's a distinction that Bitcoin has that many other projects and many other places in the tech industry don't have, where there's this fine balance. Do you feel like the balance is correct today? Is the amount of competitiveness and collaborativeness in that kind of sweet spot or is there a room for improvement in one way or another?
Bastien Teinturier - 00:21:31:
I think we're good, yes, because it has created a lot of experimentation. Every implementation has done their own things, has their own pet projects that sometimes different from what the others do. But all of those have eventually, at some point feedback, some useful information to the more general shed project. So I think all of those were useful and it's really nice to see that there is still experimentation happening, that we don't always have the same priorities, but still it doesn't prevent us from moving forward with the important things that matter to most users. So I think we are in that sweet spot today and I think it's great. Awesome.
Kevin Rooke - 00:22:16:
One comment you made on the developer ecosystem. You have a lot of public meetings and anyone can come in and you see new people all the time. You said, what's your feeling for how much developer activity is happening in the Lightning ecosystem? You've been watching it now for a few years. You've got to see this progression. A lot of people have seen the Lightning metrics tick up in the last year and they've seen, oh, there's some almost parabolic growth in public capacity and there's a lot of apps building. Have you seen that same level of growth in the developer ecosystem?
Bastien Teinturier - 00:22:55:
Not really, but I think there are two reasons for that and I'm really going back and forth on that. Earlier I was saying that we should really grow the core team and have much more developers working on the core protocol and implementation. But actually it's really hard. It requires a lot of time to ramp up. There are many things that you need to know to actually be productive working on the core protocol. You need to have a very good understanding of bitcoin, a very good understanding of Lightning. On top of that, there are many ways when you are designing something in Lightning that you can break subtle things like privacy or efficiency. It's really hard to actually start from scratch and provide meaningful spec and implementation contributions. So I was a bit too optimistic when I was younger about that. I think the teams have not grown that much for people working on the core protocol. But now I think that it is okay because we still have a good velocity. We cannot make the corp protocol work scale to that many more developers. We cannot do 10x on the number of developers working on the core protocol while still being efficient. So we need to keep growing the core implementers slowly. But I think that's something that we are doing and we are steadily increasing the number of developers working on the core protocol. And what's nice is that where there is a lot of developer activity for people building on top, and that's a good entry point into future work on the protocol, I guess, because you can start working on top of Lightning. It lets you build a lot. It lets you understand Lightning step by step without having to inject too much at once. And at some point, if you feel after a few years working in there that you really want to do more core development, then you're probably going to be ready to start doing meaningful contributions. So I think it's really nice that there's a lot of activity happening one layer on top of core, core work, and I think that is going to help us grow the team working on the core protocol as well in the future. So I think this is great.
Kevin Rooke - 00:25:12:
I see. So you kind of view the Lightning application developers as almost they're application developers.To begin with, but then they could. Also be like a funnel for creating more core implementation developers.
Bastien Teinturier - 00:25:28:
Exactly. Because I think it's really hard to start being a core developer from scratch, just arriving in that ecosystem and start from scratch and working directly on the core service. A few people can do it. There are people who really like that and who are built to do that kind of thing. But there are a small percentage of developer base. So we're still looking for those people. But I think we're going to get more people that come through the funnel of starting to work on Lightning apps or things that build on top of Lightning and then realize that they are really interested in working at the core protocol layer. So it will take a few more years before we really see that happening, but I'm quite hopeful that this is something that's going to happen.
Kevin Rooke - 00:26:09:
Are there any specific applications where you see a lot of development activity and maybe the rest of the Lightning ecosystem hasn't quite realized that this particular vertical or this particular application is going to be very useful or very important?
Bastien Teinturier - 00:26:26:
That's a good question. I must admit I am mostly focused on the core scenarios of making the payments work reliably efficiently, privately and securely. So I'm mostly looking at what wallet people are building. I'm not looking that much at what people are more experimental things that people are building on top of Lightning. So I don't have anything that comes to mind right now apart from many people working on different trade offs of mobile wallet. And I think having more diversity in the Lightning mobile wallet ecosystem would be very desirable because there are a lot of tradeoffs to how you use Lightning on a mobile wallet. And I think that different users want different trade offs and it's impossible for one wallet to offer all those trade offs and still keep a good UX. So I'm hoping that more people build wallets that are different from the other wallets out there so that users can really find the wallet that suits their needs and the trade off that they're okay with. And that's something that has started to happen and I'm hoping that we see that happening even more in Venexia. Also.
Kevin Rooke - 00:27:43:
Now, you guys have Phoenix wallet, right? Yes. What was the reasoning behind why you built Phoenix and what it could provide that other wallets could not provide?
Bastien Teinturier - 00:27:57:
Okay, so the reason we started working on mobile wallets was that very early on we realized that we were three teams working only on server implementation, XLB and CLN. We were all writing our server software, designing a protocol that we have a lot of assumptions coming from the fact that we knew that the server would be online all the time. We'd have a stable IP address we'd have a lot of bandwidth, we would have a lot of resources. And we realized that Lightning could not be used by many people if we didn't have one of the car team actually working on a mobile wallet because most people would interact with Lightning on mobile. And since Lightning is really complex, you have to really understand the protocol if you want to be able to build, at least especially at the beginning. We wanted to see how much friction that would be with building a mobile wallet, and that's why we started with Eclair Mobile and our goal was to create a wallet that was easy to use for nontechnical users and would hide a lot of technical details of Lightning. And we really failed at that. It was really expandable, was really for expert people. There were a lot of details of Lightning that users had to understand, otherwise they just couldn't get what was happening with their money. And that helped us realize that many things needed to be changed at the protocol layer and we spent a lot of time getting the changes in the protocol to be able to then eventually build a better mobile Lightning wallet. And that's what gave us Phoenix. And I think that if we hadn't done that, the protocol would not be in a state where mobile wallets could be as good as they are today. So our goal was really to make sure that good mobile wallets for Lightning are possible, to show how you can build one with one set of trade offs that we chose so that other people can get inspired by that and build their own mobile Lightning wallet. So I think it's really important because without that we would only have remote control apps of remote nodes and that would have prevented most people from even using Lightning because most people don't want to have to run the node.
Kevin Rooke - 00:30:09:
Right? Yeah, I think you highlighted in a blog post explaining some of the features that Phoenix kind of abstracts away from the experience, I think, like turbo channels and unified balances and things like that. If you look now today at what Phoenix is, is that abstraction something that you think a lot of the mainstream users are going to be able to grapple with and deal with, or do we still need further abstraction to make it appealing? For someone who doesn't know anything about Lightning, doesn't care to run a no, doesn't want to deal with the technical complexity, can get up and running.
Bastien Teinturier - 00:30:53:
I think we've improved, but we're still not there yet. And there are a few things that we need to do to get to an even better state. And we are actually working on those things right now and we are preparing a major update of Phoenix sometime next year where we hope we're really going to jump ahead in terms of UX and make it much better and much better for end users. And yes, This is also something that requires a lot of changes at the protocol layer that are not trivial at all, so that's why it's taking a lot of time. But we are constantly working towards that goal. So we're trying to make sure we push the limits of what can be done for mobile wallets. And by making those changes in the protocol itself, we ensure that every other project, every other team that wants to build a mobile wallet will be able to do the same things, so that we're not centralizing anything around us in particular. And also I want to be very clear that Phoenix chooses a set of trade offs, but we've tried to be as transparent as possible about those trade offs. In the blog post that you mentioned. When we launched Phoenix, we did four big blog posts explaining the main features and what the tradeoffs were in terms of trust or security for every of those features. So I really hope that users have looked at those blog posts and maybe we can put them in a more digestible form to make sure that users are aware of the trade offs that they are opting in when they are using Phoenix. And I'm hoping that other mobile wallet developers do the same thing and very transparently talk about the trade offs because I haven't seen many other teams do that. And I think it's important because there are many ways as a user, you just do not realize what's happening and you do not realize when there is trust or semitrust that you have with the nodes you're connecting to. And I think it's important for at least for technical users to be able to know the tradeoffs, to choose the wallet that they really are comfortable with.
Kevin Rooke - 00:32:59:
I hope you enjoyed the show so far. Just a quick message from our sponsor Voltage. Voltage is the industry leading provider of Bitcoin and Lightning node infrastructure. Many of your favorite Lightning apps and services already use Voltage today to scale their business quickly and easily without maintenance. Voltage also offers an inbound liquidity product called Flow, which allows you to get easy access to inbound liquidity for your node. Overall, Voltage is creating the industry standard suite of noncustodial products, helping brands, engineers and startups scale. To learn more, visit voltage.cloud. Now you mentioned there's an upcoming release for Phoenix, some improvements coming next year. Are you allowed to share any details or any UX improvements that you guys are thinking about?
Bastien Teinturier - 00:33:50:
Yeah, mostly it's going to be built around dual funding that is being added to a specification that lets two peers fund the channel collaboratively. This is interesting to us because it lets us remove a trust assumption when users are doing swaps. This will remove our node from the equation of users trying to do swaps. So this will minimize trust compared to what Phoenix does today. And spacing is also a very interesting feature because it will let mobile wallet users have only one channel per peer they are connected to instead of having many channels. One issue today with Phoenix that if you receive a lot of payments you're going to end up with a lot of channels created. And if you go to the channels page you'll see that you may have 20 or 30 different channels, most of them empty and you just don't know what to do with them. Should you close them? Should you do something manually? Should you let the app handle it at some point and close them? It's really not something that we want to have to show in the UX. So it's going to be much better because users will have only one channel with a node and the size of that channel will fluctuate depending on their usage and what they need, how much incoming and outgoing balance they need. We will just adjust the size of that channel so it will be much easier to understand for the user. And also it will help with receiving reliability because for technical reasons when using multiple payments, when senders plenty of payments into many parts, if you have many channels, since they do not know the balance of those channels, most of the time this will fail because the sender is not able to correct the split among your existing channels. So the maximum amount that you should in theory be able to receive you're actually not going to be able to receive it in practice. But if you have only one channel per peer then we don't have any splitting issues and it's going to make the receiving experience much more reliable. It will make the balance that we show to user more accurate. So I think these are seemingly small things, but actually in day to day use, they matter a lot because people are trying to test the limits and receive the maximum amount that they can receive without having a new channel being open. And they see that most of the time it doesn't work and they end up with a new channel that they don't want. So this is things that people find frustrating in day to day life. So we were going to make it better thanks to all those protocol improvements and since those are protocol improvements that are implemented by most of the teams, this is something that any other wallet will be able to develop and offer to their users once we've shown how it can be done.
Kevin Rooke - 00:36:41:
So things like dual funded channels and Splicing will be not only on Eclair and available on Phoenix but also available on other implementations?
Bastien Teinturier - 00:36:51:
Yes, for the funding and slicing. It's mostly CLN that has led the way and done most of the research and they have the early implementation and we are now working to add to Eclair to get cross compatibility testing so that when we have to implementations having it, we can start shipping it on the network.
Kevin Rooke - 00:37:10:
So once two implementations agree to a specific change, then it becomes a part of the spec.
Bastien Teinturier - 00:37:16:
Okay, so here there's a rule that we decided at the beginning, but we do not religiously apply that in order to avoid preventing progress, since not everything will have the time to implement every feature, we decided that if two implementations, two independent implementations implement a feature and are okay with the specification, they should be able to merge it to the specification. Even if the third or fourth implementation don't even look at it. But actually, in practice, we've always waited for at least a conceptual acknowledgement from everyone and that's what we've done. Also with dual funding and splitting, we all want it, we all want some form of it, maybe the exact details will diverge, but so in theory we could just add it to the specification once CLN and ECB have it. But in practice we don't want to force those things on people. So we're still spending more time to let people have a quick look at it, even though they are not implementing it in the short term, to say that they are okay with it being added to the specs even if they are not going to implement it in the short term. So it's more of a gentleman's agreement that we're not going to follow that rule very hard.
Kevin Rooke - 00:38:35:
What are some of the reasons why other implementations have not decided to implement dual funded channels and Splicing right now?
Bastien Teinturier - 00:38:45:
It's just about priorities because all of the features we are working on today are features that require a lot of work that usually interact very deeply with Bitcoin and with limitations of bitcoin. Then they usually open some painful trade offs with either privacy of your UTXOs or potential briefing attacks for your liquidity. So all of these features are complex features that require a lot of work, so not everyone has the time, it takes a lot of time to implement them. And every team has a limited capacity and different priorities. So that's why we know that we are not going to implement them at the same time. But maybe it's okay. And some team will implement your funding in one year, one year after the others, but they will have implemented, for example, tap channels before the others. It's really a matter of what priorities you have for your specific products. In our case, we really want to prioritize dual funding and spacing because we feel it really helps the Mobile UX experience. And we're not that interested in getting tap changes in the short term because we feel that this can still wait for six more months or something like that, because it doesn't provide very meaningful user facing improvements. But other teams feel otherwise because their products would really benefit in the short term from, for example, taproot channel. So the Lightning lab is mostly prioritizing work on Taproot instead of the old funding and Splicing. But eventually at some point. We will also implement Taproot, they will also implement the role funding and we will end up with feature parity. But it's just going to take a while to get there because we don't have enough developers and enough reviewers to be able to ship all those things at the same time.
Kevin Rooke - 00:40:38:
That makes sense. So I just want to clarify though, in the short run, if only two implementations have dual funded channels, a third implementation cannot benefit from that. Today, if there's only two that have it and a third says we don't have it yet, they're not allowed to participate in that feature until they have it, right? There's no way for them to take advantage of dual funded channels or Splicing.
Bastien Teinturier - 00:41:04:
They have to implement it or to wait for the implementation to support it.
Kevin Rooke - 00:41:09:
So is there ever a, you know, what kind of discussions do you guys have about different forms of Lightning kind of developing over time? If there does get to a point where teams start to head in their own directions and maybe start to fall behind on implementing features that other teams have implemented, does that concern you at all that there may be some kind of split in the nodes, the different functionality of node on the network?
Bastien Teinturier - 00:41:42:
I don't think so, because most of all, the very useful functionalities, everyone will want them. We are all very pragmatic. If someone wants to push for functionality and it's really good, we're all going to implement it. Implement it because it's good. And if it's not really good, it's not going to get a wide adoption anyway, so it's not going to affect the network. And we all basically agree on all the limitations of Lightning today. So we know what areas need to be improved, we know that those areas, we all want to work on it. And I think that already with the things we identified today, we already have a big backlog of at least two years worth of work and that's not even counting what we are going to discover afterwards and add to that backlog. And this is things that we all know that we all want to work on. So I don't think there's a risk that the network will really fork in a user visible way in terms of features that implementation has. Also because things like dual funding and Splicing, these are features, but you could just say that they are just improvements. You can live without them, you don't really need them. They're going to make your life better as an operator because they're going to lower the fees that you pay on chain. They're going to make your own chain footprint more efficient, but you could live without it. So it won't make you fork away from the people that are doing it. If your implementation doesn't have it, you just have to wait a bit more and pay a bit more fees until your implementation added. But it's okay, you can definitely leave with that, right?
Kevin Rooke - 00:43:25:
Maybe not a critical issue. Okay, so you said you guys have this backlog of like up to two years of work already to implement features and upgrades. Are there any things beyond, beyond dual funded chance, beyond Splicing that you guys at Claire are specifically excited about implementing?
Bastien Teinturier - 00:43:47:
Many things, both world of Earth, we are actually working on it very actively because Bolts Twelve is complex, because it's stacked on top of other nontrivial features that we are trying to add to the specification. At the bottom of that stack are Blended Payments, Blended Paths, which is a cryptographic protocol to ensure that recipients can get better privacy than what they have today in Lightning. On top of that, we built on the messages that lets you send lightweight messages between nodes that are unencrypted and that are not payment, that are just data messages. And then on top of that, we build all twelve offers. So all of those things need to happen before it can be shipped. But we've made a lot of progress. And Blended Paths and Onion messages are already implemented in CLN, LDK and Eclair and we have successfully tested Interoperability on most of the things except for Blended Payments, but we should be closed. And then even at the offers layer, all of those three teams are actively working on it. So I think that's something we should hopefully see soon in 2023. Another feature and other things that are really interesting. One of the things that I find really interesting and I would like to make progress on is something that happens at the boundary between Bitcoin and Lightning. There is work being done on Bitcoin for something called Package Relay that lets you bundle multiple transactions to relay them and make sure that you are able to pay the fees to set the fees correctly. And this thing can really improve the way the structure of the transaction we use in Lightning. We can simplify a lot of things in the protocol once we have that. So that's something that I'm really looking forward to and I'm hoping that Beacon chips, Package Relay, hopefully in version 25 or 26 so that we can start simplifying the Lightning protocol by leveraging that. Also on the features, we'd really like to start working on taproot at some point because it opens up a design space, it creates a lot of new things that we can do that we cannot do today. So once we have Taproot and PTLC, it's something that's going to take a long time to actually implement because it requires touching almost all of your code and changing what you store for payments for almost everywhere in your implementation. So it's going to take a while before we ship that, but once we have that, it unblocks building many other fancy protocols on top of payments. For example, retryable payments, where if one of the parts of your payment gets stuck. You can actually retry without waiting for that part to fail, so that payments can always reliably, be retried so that you instantly know whether they fail or succeed, but you don't have this issue where it's just stuck and you don't know if it's going to fail or succeed. There are a lot of cool ideas of things you can do once we have PTLCs and Taproot. So that's something we'd like to implement as well. Another thing we're interested in, maybe in the shorter term is liquidity ads, because I think this is really useful for no entering the network to be able to buy inbound liquidity from other nodes right now. It's been very adapt with a lot of small, somewhat centralized protocols to do that. It will be great when we have a very decentralized exchange for that information. So CLN already has the first version of that, and we're going to be working on it as well. So when both of us have the feature, we should be able to activate it on mainnet. Also, there's been a lot of cool developments in improving Lightning security, basically protecting against an attack called Channel Jamming. There are good ideas that have been explored recently and that we should start to implement, and also many things that we can do at the protocol layer to improve privacy as a whole. And we have a lot of ideas, we just need more time to implement them.
Kevin Rooke - 00:48:13:
Yeah. Wow, that is quite a list. Yes. I'm interested to hear your perspective on you mentioned Taproot. I know the Lightning Labs team is working really hard on implementing Taro. Is that something that is going to what would your relationship be to Taro if that is implemented by LND? Is there any connection between Eclair and Taro? Is there any incentive to work on that as well? Is that primarily their thing, or is it something that you see ACINQ spending a lot of time working on too?
Bastien Teinturier - 00:48:52:
I think it's going to stay their own thing because what's interesting with the way they design Taro is that most of the network doesn't have to know anything about it. The only places that have to know about Taro are the edges of the network, the connection between your wallet and the first node you connect to, and the last node the recipient is connected to. Those are the places where the exchange rates will be set and with the exchange between Taro and Lightning will happen. So we can keep building the rest of the network without having to interact with Taro and still benefit from the additional volume of payments that Taro will create. So we don't have a plan to look deeply into Taro in the short term, and I don't think the LDK or CLN has plans to do that either. And it's totally okay. That's the kind of experimentation that can easily happen at the edges of a network and still leverage all of the routing infrastructure that the network provides. So it's really great that this is happening, and I'm curious to see how it evolves, but I don't think we're going to play an active part in that.
Kevin Rooke - 00:50:01:
Right, so it can plug into the edge of the Lightning Network and then you can benefit as any node operator can benefit from the volumes of assets flowing through the network that are being routed using bitcoin liquidity.
Bastien Teinturier - 00:50:14:
Yeah, exactly.
Kevin Rooke - 00:50:17:
Have you had any discussions about issuing assets at ACINQ and Eclair? Is this idea of being able to issue non bitcoin assets on Lightning something that is interesting even if it doesn't end up being like a Taro specific implementation? Is there any adoption or traction behind this idea of assets on Lightning from your perspective?
Bastien Teinturier - 00:50:46:
To be honest, that's not something we've discussed much, and that's not something we've been very interested in. We're also quite a much smaller team than Lightning Labs. I think we have that size. We're only eight people and we already have our hands quite full with working on Eclair and Phoenix. So we're just focusing for now on the purely bitcoin thing, and we didn't have time yet to look into asset issuance, and that's not something we're particularly interested in right now, but maybe that will change in the future, but for now we're just focusing on Lightning, the core of Lightning.
Kevin Rooke - 00:51:29:
That's fair. One thing you mentioned in the past was that ACINQ is Vcfunded. You guys have raised, I think, a couple of times in the past. What makes this VC model the right approach for ACINQ?
Bastien Teinturier - 00:51:46:
That's a good question because I don't know if it's the right approach, but we've been very lucky to have very good investors that understand bitcoin, understand Lightning. Note that this is a very long term project that's going to be real research and development, that we're not going to get a huge revenue stream in a year or so. And we've been very lucky that our investors really support our mission and give us time to build, basically. And that's something that's really hard to find because most of the time when you are Vcfunded, at some point people expect a lot of financial results to happen very soon. And that's why I'm not sure VC funding is the right solution for everyone. Because depending on who your investors are, it could potentially ruin your project if at some point they just force you to pivot and to do something else and to do something that you are not comfortable with or not something that you wanted to build in the first place. But we've been very lucky with our investors that this is not something that's happening and I'm hoping it stays that way and it's looking good for now, but I don't know if this is the right model for everything, but we didn't really have a choice. We didn't have any other model where we could have built such a project for a long time with a team of eight people without getting enough revenues right?
Kevin Rooke - 00:53:14:
Do you think there's room for other business models to exist, especially for like open source stuff if you're building a Lightning implementation? I imagine there's not tried and tested models for this kind of work because as you mentioned, it's a very unique style of work and it doesn't have much precedent, especially when you have this collaboration and competitive dynamic between implementations. Is there anything on top of mind that you think you'd love to see someone try a different business model or any specifics that you think might have worked well? If you can rewind and not take the VC approach, what other approach would you take? What things would you look for?
Bastien Teinturier - 00:54:00:
I really don't know because we've been very lucky to have those in depth. I really don't know how to do it differently, but I really think that there's room for experimentation here and there's a more general discussion about how to fund open source work generally. And that's something I expect that we'll see more innovation in funding developers working on a various open source projects in the decades to come. And I'm really curious to see how that develops. I have no idea what will work and what won't, but I really hope that people try things and that maybe we find new models that work for all these kind of projects, but I really have no idea what to tell.
Kevin Rooke - 00:54:47:
Fair enough. So on the topic of you have these investors, how do you guys think about eventually delivering a return on that capital for the investors? Because maybe they're fine now to say, hey, go build, do your thing, but eventually they're going to say, we funded you, we want to have some idea of a return in the future. How do you think about generating that return? Is that going to be something that you guys do on Eclair through Phoenix, through some other project in the future?
Bastien Teinturier - 00:55:22:
Okay. By being a big node and running Phoenix, we get some revenue. We get some fees from routing, some fees from underfly liquidity. So that's a source of revenue. I don't know if it's something I don't think that this is something that will ever generate huge revenues because this is a very harsh business where everyone can come in and propose lower fees than you do. And I think that's good, that's healthy. You cannot impose high fees on users because this is an open network. But that also means that this will never give you very high revenue stream. So we were not entirely sure yet how in the long run we will get enough revenue because that really depends on what adoption looks like. If merchants start to really add more support core Lightning, then maybe there's an interesting place in that space. It really depends on how people start using Lightning on the merchant side, I guess, because right now Lightning is more used on the individual to individual side and you don't want to impose high fees and those scenarios because otherwise you're just going to kill the project, basically. And other people can just come in and propose lower fees. I think that it's more when people, when actual real business people buying real things will start to happen, that we will have a better idea of where we can get more revenues. But that's still hard to evaluate today.
Kevin Rooke - 00:56:59:
Right. So the idea there is that maybe when merchants are more widely adopting Lightning, they may be less concerned about fees attached to a payment and they may be more willing to pay a fee as merchants do today.
Bastien Teinturier - 00:57:15:
Is that the idea, honestly? That they will be ready to pay for software? They will be ready to pay for software that makes their life easier and that lets them receive payments easily, and they're going to be able to pay people who write that software. Whereas we don't want to make end users pay for the software, basically.
Kevin Rooke - 00:57:35:
Right, okay. So this could be maybe like a redesign on the point of sale terminal or something. It might be something like that.
Bastien Teinturier - 00:57:44:
Or cloud services or security. It could be many things. But it really depends on how merchant adoption happens. And this is something that hasn't happened that much yet, honestly. Merchants, we've always hoped that merchants will start accepting Lightning payments and there would be a very big wave of merchants starting to do that thing. But we haven't seen that yet and I don't know when or how we are going to see that and what form it will take. So we'll see. We'll see.
Kevin Rooke - 00:58:21:
Yeah. Are there any specific roadblocks that you've heard people bring up, like merchants specifically? Have they said, you know what, we're not going to use Lightning because of XYZ?
Bastien Teinturier - 00:58:35:
I think that it's mostly that people do not want to run things. They want it to work. They want to be that's why things like Strike have worked very well. People want to create an ecommerce platform, but they don't want to actually handle payments. They want someone else to do it for them. Or they want to take something that's easy to integrate and have someone to call when it doesn't work or when something's wrong. They don't want to take open source code, run it themselves and be exposed to the riff that when something goes wrong, they have no idea what's wrong and they have downtime for days or even worse. So I'm curious to see what exactly they are ready to pay for and if they even want to receive payments. Because right now I'm not sure merchants really care about receiving late payments. It's more that people have built things like Bitrefill to hide the fact that users are actually using Lightning to pay for stuff because of discount. But I don't know if merchants will really start accepting ecommerce platforms will really start accepting lighting at scale, I would love it, but I don't know when that will happen or if that will happen.
Kevin Rooke - 00:59:51:
Do any of them bring up the issues around capital gains? If you're accepting a bitcoin transaction and having to custody bitcoin, is that like something that merchants tend to like, bring up whenever they say, we're not going to use lightning?
Bastien Teinturier - 01:00:10:
I haven't talked to merchants about that and the reason why they're not using it, but that's definitely a good point. And talking to at least small shop owners in France, it's really a pain to handle tax gains with other forms of money than Euro. So people just don't want to add more pain around taxes and administrative stuff. So if they don't have a very good need for it, it makes their life more complex and they don't really need it, so they're just not going to do it. We need people to have a strong, compelling reason to start accepting those payments for it to happen. So we'll see what triggers that strong, compelling reason.
Kevin Rooke - 01:00:55:
Yeah. I think to some degree it's important that I think I had Vijay Boyapati on a while ago and he brought up the idea that in order for people to spend bitcoin, everyone has to have bitcoin. Everyone has to be saving it or holding it or, you know, have at least some balance of it. So when we think about like the end user side of the consumer, are there any roadblocks to adoption there that you think we really got to fix in order to get people holding bitcoin and spending it? You know, just PeerToPeer. Because I imagine that could be like that could be the top of the funnel for merchants that adopting it. Right. It's like once you have many people with it, a merchant may be willing to take that risk if they know they're going to get a 50% bump to their business. But today, if they only get a 2% bump or 5% bump, they go, it's not worth the taxes, it's not worth the headache.
Bastien Teinturier - 01:01:56:
Right, yeah. And unfortunately, I think we're not going to see any of those at least in the next ten years because bitcoin doesn't have the capacity to be used by billions of people, billions of people having their UTXO and their Lightning channel just cannot happen. If you just run the numbers to see how much time it would take to onboard, I don't know, 1 billion people to Lightning it would take I don't remember the numbers, but I think Merch has published something, it's ten years or even more than that or maybe 100 years. So that's something that we need to fix here. Because if we cannot get a big enough portion of users into Bitcoin and Lightning, that means that there's never going to be a big enough portion of people who want to pay for things with bitcoin and Lightning at merchants. So merchants will never have. The incentive because there will never be enough volume for them to compensate for the extra efforts of handling those things. So I think that still in the next decade the only people who will add support for being paid will be kind of Lightning are people who are convinced by the mission and who are okay with doing the extra work because they are ethically convinced that this is a good thing. But people who look at it from an economical point of view and rational point of view, I don't think they will have any incentive to add bitcoin and Lightning payments in the next decade. But I hope I'm wrong. And we still have to do a lot of technical work to make it better, to make it easier for more people to on board, to make it easier to share UTXO for, to have a channel with many participants, that kind of thing. But those are somewhat fine in the future. Those are things that are not going to happen in the next two years, so maybe in the next decade, but I have no idea when.
Kevin Rooke - 01:03:50:
Are there any promising developments for improving how quick it is to onboard many people, right? Like if bitcoin has these constraints on how many people can be onboarded at once to Lightning, are there any particular projects or ideas that you're interested in that may expand that capacity over time?
Bastien Teinturier - 01:04:13:
It's still really early on that issue. But what's interesting is that all of those will require some form of covenant built into bitcoin, something that bitcoin doesn't have today and that will require a lot of fork. So it's going to take a while before we get any of that available. But what's interesting is that in the past year or so there's been a lot of activity around the covenant design discussions in bitcoin. That's something that people have talked about on and off for years, but without really actively trying to push the boundaries of research and without actively thinking that this could be supported in the short term. But I think that now people, more people are expecting that we are going to make progress on that and that hopefully in the next few years we will be able to find a good agreement on what a good covenant would be for Bitcoin. And that will really unblock a lot of that situation because all of the research that has been happening around UTXO sharing needs some form of covenant and has currently been starting from the assumption that covenant X or covenant Y is available. But we have no idea whether that kind of covenant will be available or if what's available is going to be compatible. So it's really hard to speculate when or if any specific design is worth looking at because of those assumptions. But now that many people are actively working on that, I'm hoping that we may see steady progress and in a few years we will have steady progress on doing covenants and potentially more efficient offshore constructions for multiple participants. But I don't have any specific project to vouch for here because I think it's just too early. There are only very high level ideas at that point.
Kevin Rooke - 01:06:10:
That's fair. All right, I want to jump into a segment I do at the end of every show. It's called the Lightning round. Are you ready?
Bastien Teinturier - 01:06:18:
Okay, I'm ready.
Kevin Rooke - 01:06:19:
I hope you enjoyed the show so far. Just a quick message from our sponsor Stakwork. Stackwork is a Lightning powered platform for generating high quality transcripts of all your audio or video content. They combine AI engines and hundreds of human workers all over the world who are paid over the Lightning Network to assemble these transcripts. That's what lets Stakwork create less expensive, faster and higher quality transcripts. To see the results for yourself, I use Stakwork to transcribe all of my podcast episodes listed directly on my website. If you want to learn more about Stakwork, visit stakwork.com. That is stakwork.com. Okay, will fees on the Lightning Network go up or down over time?
Bastien Teinturier - 01:07:11:
Routing fees will go up, channel opening fees will go down.
Kevin Rooke - 01:07:16:
How come?
Bastien Teinturier - 01:07:18:
Because routing fees, I think mostly because people are most routing node are quite new and when you're new, you don't know how much volume to expect. So you start with very low fees also to attract payments because you are new. So I think that right now people set very low fees without having made any economic calculations on whether it makes sense to set fees like that. And when you start doing economic calculations of how much a channel costs in the worst case on chain and how many payments you expect to relay through that, so what your fees should be, you see that it should be much higher than what it is today. So not by another of magnitude, but it should still be higher than what it is today. And also because if at some point we implement solutions for channel jamming, all of those require users to pay up front to prevent some spam. So those are actually being added to the fees, so they will make the routing fees. Right. However for the unchained stuff since we are building improvements like dual funding and splicing that will let you more efficiently batch transaction more efficiently do them whenever the Mempool is empty and fees are low. Nodes are going to be able to better utilize the bitcoin blockchain when the fees are low and when it makes sense, when it's economical to make on chain transactions. So that will drive the overall price of channel creation down. Interesting that's the fear relative.
Kevin Rooke - 01:08:58:
Fair enough. How many humans have made, have sent or received a Lightning payment in the last 30 days?
Bastien Teinturier - 01:09:10:
I don't know, and I think that's a good thing.
Kevin Rooke - 01:09:12:
Privacy, take a guess, I want to hear your range. Yeah, of course. It's great that we don't have these numbers for sure, but interested in hearing your best guess.
Bastien Teinturier - 01:09:30:
In the past month, you said how.
Kevin Rooke - 01:09:32:
Many humans have sent or received a Lightning payment in the last month?
Bastien Teinturier - 01:09:36:
Hopefully a few tens of thousands.
Kevin Rooke - 01:09:39:
Okay, nice.
Bastien Teinturier - 01:09:41:
No idea.
Kevin Rooke - 01:09:45:
Will the market share of the largest Lightning implementation go up or down over time?
Bastien Teinturier - 01:09:54:
Down, I think mostly because I don't expect Eclair's market share to rise that much. I expect TLM's market share to rise a bit more because what really prevented their market share from rising was that they had a restriction that you could only have one channel per peer and they lifted that recently. That was the main reason for people not using CRM. They lifted that recently. So I expect more people to start looking at CRM because it's interesting, because it's really portable. And there's also there's also LDK that's coming that has been building support for a while that was still not ready, that is still not ready, I think, for mainnet adoption, but should become ready soon. So that will just diversify the implementation ecosystem. So I expect LDK market share to take some of the market share from everyone else. So that means the biggest one will just go down, right?
Kevin Rooke - 01:10:56:
Are there any books that have meaningfully changed your view of the world?
Bastien Teinturier - 01:11:04:
A lot of them. But recently I'd say thinking fast and slow by Kahneman really interesting book.
Kevin Rooke - 01:11:13:
Yeah, good one. If you could only hold one asset for the next ten years and it could not be bitcoin, what asset would it be?
Bastien Teinturier - 01:11:26:
A beautiful house by the sea.
Kevin Rooke - 01:11:29:
I like it. That's a good choice. If you could give a shout out to just one person in the Lightning ecosystem who is doing some really great work, what do you want to give a shout out to?
Bastien Teinturier - 01:11:42:
I think I always say the same. Gloria Zhao. Because she's doing all the things on Bitcoin that we need for Lightning package, working on RBF, all the very tough problems that people have mostly ignored for years because no one dared working on it because everyone knew it would be hard. And she just arrived and started doing that thing and she's nearing completion. So it's impressive and I hope she keeps doing that. Good work.
Kevin Rooke - 01:12:12:
Awesome. Well, thank you so much for taking the time. I thoroughly enjoyed the conversation and I'm sure listeners well too. Where can everyone go to learn more about you and your work?
Bastien Teinturier - 01:12:23:
Okay, so you can have a look. You should start with a Lightning specification on GitHub at Lightning/bolts. Then from there you could easily find all the implementations. Ours is on GitHub or under ACINQ,A-C, Eclair, and you can find us on Twitter as well @ACINQ_co and me @realtbast
Kevin Rooke - 01:12:52:
Awesome. Thanks to you for the time and I hope we can do it again soon.
Bastien Teinturier - 01:12:55:
Thanks. Thanks for having me.
.png)