Pierre-Marie Padiou is CEO and co-founder of ACINQ, building on Bitcoin’s Lightning Network. We talk about how ACINQ got founded and their very impressive new Lightning wallet, Phoenix. Phoenix represents a step forward in non-custodial Lightning wallet user experience and we talk about the tradeoffs that go into making this a reality. This episode is a must listen so you know how to best demonstrate Lightning for Bitcoin Lightning newbies or family/friends.

ACINQ links:

• Twitter: @acinq_co
• ACINQ Website: https://acinq.co/ 
• Phoenix Website: https://phoenix.acinq.co/ 
• Github: https://github.com/ACINQ/ 
• Telegram: https://t.me/phoenix_wallet 

Sponsor links:

• Kraken
• Unchained Capital
• CypherWheel by CypherSafe
• GiveBitcoin

Stephan Livera links:

• Show notes and website
• Follow me on twitter @stephanlivera
• Subscribe to the podcast
• Patreon @stephanlivera

Podcast transcript:

Stephan Livera: Pierre, welcome to the show.

Pierre-Marie: Hi, Stephan, nice to see you again after Berlin, I think, the last time we met.

Stephan Livera: That’s right, I ran into you at the Lightning Conference, and we were talking about your new app Phoenix, which you had just put out at that point, as well. And I was very impressed by it. And we’re going to get into all of that.

Pierre-Marie: Okay.

Stephan Livera: So look, let’s just start with a bit of your story. I know you’ve been around Bitcoin for a little while, and you’re leading ACINQ. Can you tell us a little bit about yourself and how the company got started?

Pierre-Marie: Yeah, well, I’m an engineer, a software engineer, so I’m a technical person. But I always wanted to create a company, because, basically, I like freedom, and I don’t like to have bosses. So when I first heard about Bitcoin, I think it was maybe 2012, or 2013, something like that, I was convinced that this created an environment where a lot of opportunity would arise, and at the same time it was extremely interesting to me. So I didn’t hesitate long before starting a company. And so, ACINQ was founded in 2014.

Pierre-Marie: And we started working on the Lightning in 2015. I think we were the second implementation to be developed, shortly after c-lightning, and shortly before LND. And we have been developing eclair and doing variants of eclair with Phoenix with eclair mobile since then. And we’re not going to stop, obviously.

Pierre-Marie: It’s a long run. It’s quite fascinating and very interesting, because the fact that you can start from scratch, with a blank page and the target being to have a global payment network. So if you like building distributed systems, if you like a technology, and if you like also working in an environment that’s very complex and with a lot of impacts on nontechnical things like finance, politics, or that, that’s very interesting. So I’m very happy to have the chance of building ACINQ and working on the Lightning network.

Stephan Livera: Right. And tell us a little bit about what your experience was like when you first read the Lightning network white paper, and what was it that spurred you on to go and build a Lightning company?

Pierre-Marie: Well, actually initially, so I told you that ACINQ was founded in 2014, initially we are building a hardware wallet. That’s not a well known fact, but we started building our hardware wallet around the same time then Ledger.

Stephan Livera: Oh, okay.

Pierre-Marie: And a bit about smart cards, you know that French have a history with smart cards, and so independently, Ledger and us, just came up with the conclusion that smart cards were the appropriate tech to install your Bitcoins on. And the best part is that we are actually working in the same building as Ledger. They were renting a coworking space that we were working in too. And so we were developing the two things, most at the same time, without knowing that. We weren’t talking to each other much, but pretty quickly we realized that we were working on the same topic, and so we had to move.

Pierre-Marie: And later on we didn’t have a background in the hardware, we didn’t have the connections required. The thing is that when you work with hardware on smart cards you have to have some connections with a manufacturer on because they usually work with large companies, banks, governments, things like that. They make orders of the size of a 100K, more than that. So if you’re a Bitcoin startup in 2014 there is no way you can ask for a few thousand chips. They’re not going to say yes. Ledger was able to pull that off, because they had the relevant experience and all the relevant contacts. That wasn’t our case. And the thing is when Lightning arrived, when the paper was released, this was much closer to our specialty.

Pierre-Marie: When I say we, it’s my co-founder, Fabrice, and myself, so it just made sense. We knew that it would be very difficult to develop, but to put it to paper at the time, and not a very precise paper. The paper was just the idea. Some smart contracts, but a lot of things were left to the implementer. And at that time, in early 2015, Rusty Russell, who works at Blockstream, he did a fantastic job of… I think, he published a series of blog posts, and I think it was getting to the ground with Lightning, something like that, where he started working on how can we really implement this thing? How can we get past the stereotypical white paper on a business thing? And this is how the specification project started.

Pierre-Marie: It was not a collective effort until 2016, Scaling Bitcoin Milan, where the different teams who were collaborating on the mailing list mostly, but in a very unorganized manner until then. Instead in Bitcoin Milan then we went together on and decided to try to formalize the Lightning space.

Pierre-Marie: That’s how the [RFC], it first started, and that’s what allows now any of companies like for example, it takes the Nayuta people, the Japanese company, they were able to implement the Lightning implementation, full Lightning implementation without any help whatsoever, just by reading the specifications that we all published on GitHub, which means that’s the effort was successful because that’s the goal, was to make the process of working on Lightning as permissionless as possible. I think, the Nayuta story proves that that’s one goal that we achieved.

Stephan Livera: Yeah, that’s awesome to hear the story of how it came together. I’d also love to hear a little bit about that journey, as I understand, ACINQ had two rounds of funding, one in late, I think, it was October 2018 for, I think, it was 1.7 million, and then another round, more recently, for 8 million. Can you tell us a little bit about that process and what was that like for you?

Pierre-Marie: Well, it’s my first startup, so I wasn’t at all… I have no prior knowledge of dealing with funds, and all of that. So the first fundraise that we did actually occurred in May, I think, 2018. We announced it a bit later, and it was at the time, so it was after 2017 and the big rush, and the big, everybody knows about that, the big bubble on Bitcoin and altcoins. And so this obviously sparked interest, via investors, and at the same time, as a consequence of the influx of users, the scalability limitations of Bitcoin were made more visible. That’s where some people paid a lot of fees to make on chain transactions when they wanted to trade very quickly on some exchange. They probably paid too much. But the idea was that it would cost a lot of money too, if too many people were using the same blockchain space at the same time, which made our Lightning project very understandable for investors. So that’s how we were able to raise money.

Pierre-Marie: By the way, we are lucky to never have to actually go do a road show and look for money. It has always been people interested in our project and contacting us too. So we are able to choose who we want to work with, which is very important, because as I told you at the beginning, what I like is freedom. And when you start talking investors, obviously, you lose it, that freedom. So the fact that you can choose who you want to work with, it makes a lot of difference from my perspective. And so that’s the first round.

Pierre-Marie: And the second round happened in 2018, in July 2018, this one is interesting, because I think it shows that the situation is very different between 2018 and 2019 with regard to Lightning. Lightning maintenance has been deployed in very early 2018, so in 2019 you already have somethings do to look at and it’s not something in the future that’s going to be raised in the future. It’s something that exists today, even if it’s very early. So what this fundraising means is that it made sense. And after a year of bear markets, a year and a half, again smart investors can recognize the value of Bitcoin and not get lost with all the other blockchain that claim to serve everything by just tweaking some parameters. And I think, it’s very telling for the knowledge that external investors have about the space we’re working on, that they’re able to make that kind of investments at that time.

Pierre-Marie: What’s funny too is that as part of this fund, as part of this race, the French BPI, which is not a bank actually despite its name is, is BPI stands for public investment bank. It’s not a bank; it’s a public organism that support innovation. So their job is to fund innovative startups, but obviously, since they are state-funded, they are not going to take some choices that are not politically correct. And they, they have not invested in Bitcoin. They hadn’t invested in Bitcoin before. They hadn’t invested in Ledger, for example. The fact that they decided to join the round, it’s a minor share, but still. It says a lot about the perception of the going from, again, not from the external people, not from investors, but from a more public standpoint. In 2018 right at the time when we made the first fundraise, our bank account got closed by our bank just because we were in Bitcoin. We don’t do any trading whatsoever.

Stephan Livera: Oh no.

Pierre-Marie: But just because Bitcoin, our bank account got closed. And a year later this BPI institution joined our capital. So I think it’s a really interesting evolution. So that’s pretty much it, regarding the investment that we had.

Pierre-Marie: Obviously, the good news is that now we have enough funding to be able to continue with the development on lightning network, which again it’s going to take time. It’s a very slow process. Not because there’s not enough people working on it. Obviously we welcome, obviously, a lot more people to join, but even if there were, I don’t know, 100000 developers, like Ethereum, it would still not arrive like that, because it’s a whole infrastructure to develop. It’s a protocol. It’s tools for companies, for exchanges, for any company that works in the Bitcoin environment. It’s tools also for users, wallets. And if you look at what we do, I think, what products we have released so far, it’s exactly that. We have worked on the protocol, and we have built tools in order for all the potential actors to have what is needed to join and to use the network.

Stephan Livera: Yeah, that’s really interesting, the stuff you were mentioning there about how BPI France, it’s basically like the French government is investing in a Bitcoin Lightning company, in some ways.

Pierre-Marie: Yes, I think this may have been a bit overblown by the media, the Bitcoin media, because it’s nice to say that France government is invested in Bitcoin. It’s actually, they support innovation. Yes, they do have ties. They are owned by the state, but they make their own decisions. But I think the one thing to remember is that two years ago this investment wouldn’t have been possible. That’s true for political reasons. Now it’s possible. I don’t think it’s interesting to look deeper than that. It’s just that, yeah. So it’s not like France is buying into Bitcoin. It’s just that Bitcoin sounds interesting, and Bitcoin is more and more well understood. And of course, the first natural reaction for a lot of government types is just to be scared and to just reject it right away.

Stephan Livera: Yeah, certainly. And it’s positive from that perspective. So how big is the team at ACINQ?

Pierre-Marie: There are six of us, so it’s very a small team. Not that small compared to other Lighting teams. It’s a small development community, really. But obviously with the recent funding we’re looking to hire more people.

Stephan Livera: Awesome. And you’ve got a range of products. So you’ve got strike, and eclair, and I think Phoenix will be really interesting to talk about. I think Phoenix is a really… I’ve had a chance to try it out. I was really impressed, to be honest. I thought it was just, wow, how quick it is to set up and spend and, all of that too.

Pierre-Marie: It feels almost like if it’s custodial.

Stephan Livera: Sorry?

Pierre-Marie: It feels almost like if it’s custodial.

Stephan Livera: Yeah, it really does. It does. So can you just give us an overview, for the listeners who aren’t familiar, what is Phoenix wallet? And what was the aim of Phoenix wallet?

Pierre-Marie: Okay. The aim is very simple. So as I said before, ACINQ existed in 2014, when Lightning network, the word wasn’t even invented yet. At that time when we wanted to demonstrate what Bitcoin does we did one thing, we told whoever was sitting in front of us, “Okay, can you download this Bitcoin wallet, whatever Bitcoin you want? I’m going to send you five dollars, five euros. Okay. You get five euros, and you can send it back to me or send it back to you or your friend. And that’s where the magic happen and people understood that, “Okay, the money’s on my phone now. It’s not in my bank account. It’s there. If I lose it there’s no one to save me. I’m responsible for it.” The whole thing about no trusted third party, financial independence is very easy to explain it from that starting point than just theoretically. And as Bitcoin was more and more used by more and more people, this kind of demo was harder to make, because it would cost more and it wasn’t just… As the network evolved, this particular use case of just sending a small amount of money, a small amount of Bitcoins to other people was just not working with an on chain wallet anymore.

Pierre-Marie: And what we wanted to do with Phoenix is exactly that. We wanted to be able to do exactly that same use case. Very simple use case, you start from nothing, I send you Bitcoins, you send me back these Bitcoins. That’s it. We wanted to be able to do that, and we didn’t start from scratch because we had eclair mobile, which was released in 2017. Eclair mobile was our first shot at trying to have a decent UX with Lightning. Remember that not so long ago a lot of people didn’t believe that it was possible to have a decent UX, that it would be reserved to engineers or experts of Bitcoin, people knowing what the channel is, and how to manage it, and so on. So we had that experience with eclair mobile, but our aim was to have a very easily usable wallet. And so the goal, there is a lot of work and a lot of engineering happening under the hood with Phoenix.

Pierre-Marie: But the goal for the end user, it’s very simple. It’s just you download the wallet, you show a QR code. The QR code is a bit bigger than what the QR code looked like a few years ago, but it’s still the same thing. It’s the same thing. And some people scan this code, send you five dollars, and you have it. And then you can send it back immediately too. There was no channels, no inbound liquidity issues, no nothing. Everything is taken care of. So it has been a lot of work in 2019, and what I really appreciate is that it seems so easy that some people don’t believe that how it works. Some people really think that, “Okay, but you do have some… It’s hosted, right? Or it has to be custodial. Or there has to be a…” No, it’s just a that we made some trade offs, true.

Pierre-Marie: I think maybe we’ll go over them. But at the core it’s very similar. 95%, 99% of Phoenix, of the code, is exactly the same as eclair mobile’s. You run the Lightning node on your device, you have the private keys, you’re watching the blockchain. We are using Electrum servers for that. You can point it to your own Electrum server, which is one of the way to do that you’re still responsible for your funds. And yeah, we are really proud of what we have achieved with Phoenix, and we hope we have other plans to improve it even more.

Stephan Livera: So let’s just talk through a little bit of the setup and the typical experience that it is for a new person when they set up a Bitcoin wallet, because many Bitcoin wallets, they’ll force that user to go through the, “Write down the 12 words” or “Write down the 24 words.”

Pierre-Marie: Yes.

Stephan Livera: So I noticed when I open Phoenix, it’s different already, because it’s not forcing that straight away.

Pierre-Marie: Yes.

Stephan Livera: It’s just got a warning there saying, “Hey, you need to back up your 12 words,” but you can actually just open the app, download it, install it. And you can just get started straight away without having to click around and do all that.

Pierre-Marie: Exactly. And if you keep in mind the use case that I described you before, obviously the newbie that just wants to discover Bitcoin, you don’t want him to take five minutes to write down his seed. He’s not going to do it. He’s just a [inaudible 00:22:26], what we did instead. We had a user telling us that too, “You should not block the onboarding process with this. We know that we have to backup. So just put a warning, a persistent warning, and people are going to do it quickly after they have funds on it.” And it’s even better that they do it seriously, properly, when they take time to do it and they don’t like screenshot it on their phone because they just want to get rid of the pesky window.

Pierre-Marie: So when you download Phoenix and you run for this first time it will immediately arrive on the main screen displaying zero Bitcoins. And now you’re going to hit on the receipt button, and the moment you hit the receipt button it will display the QR code. It’s a Lightning payment request.

Pierre-Marie: So at that point you don’t have any channels. You don’t have readily available inbound liquidity. What we could have done was that for each new wallet that starts somewhere our node, the ACINQ node could create, up front, a channel to this a mobile. That works too. The problem is that, first, we don’t know for sure if the user is really about receive Bitcoins or is just installing the app and not doing anything with that. If we have a million users doing that it’s going to cost us a lot of money, and it’s a potential attack vector.

Pierre-Marie: So the idea we had with Phoenix is to reverse that, which is find a way for the user to generate a Lightning invoice, even if he doesn’t have a Lightning channel, or any lightning channels yet. And only when we see an incoming payments and we can say, “Okay, we have incoming payment for you. You don’t have any channels. But if you want we can, now that we know that there is an incoming payment for you, then we can open a channel and take a fee, take it out of the incoming payments,” which solves the issue that I described before, because then we’re not going to spend money upfront. Users are going to pay for this inbound liquidity when they need it, and that can scale. If we have a million people doing that, that kind of scale, because we’re not going to pay upfront for all these users.

Stephan Livera: Okay, yeah. That’s great. And could you maybe go a little bit deeper into what’s happening behind the scenes there? So as I understand that QR code, really, it’s actually got like a Lightning invoice, and correct me if I’m wrong, but my understanding is it’s got like a routing hint to a private channel that doesn’t exist yet.

Pierre-Marie: Yes.

Stephan Livera: And then as soon as the, let’s say you’re setting up the newbie, as soon as you make that payment then all of a sudden it knows, “Okay now there’s an incoming payment.” Then it asks you, “Do you want to set up the channel?” Can you explain a little bit about what’s going on there?

Pierre-Marie: Yeah, so on the Lightning network, there are two types of channels. You have public channels, who are publicly announced on the network, and you have private channels. Private channels, the idea is that you don’t necessarily have to publish all the channels you have typically for a mobile phone. If you take eclair mobile, eclair mobile only opens private channels. When you create an invoice you have to tell somehow the payee, the person who is going to pay this invoice, you have to have a way to tell him how to find this private channel. So maybe the route is going to go through public channels and the last hop is going to use your private channels. So you have to tell about those channels, and that’s done with routing hints.

Pierre-Marie: So when you create an invoice on Lightning you have the possibility, it’s optional, to say, “Okay, you can use whatever route you want, but if you need it, those channels that are not necessarily public, they do exist. You can go to through this route. So we use it and a lot of mobile Lightning wallets use that. That’s, also why if we don’t have those private channels we would have a lot of problems already with the Lightning network routing table, because there will be a lot more channels. And syncing the routing table is already. It’s not an easy task for mobile devices, because there are constraints in terms of performance and resources.

Pierre-Marie: So building on that, what Phoenix does is it adds a routing hint to its invoice, but contrary to eclair mobile, this routing doesn’t point to an actual channel. It points to a fake private channel, and that goes from our node to your Phoenix wallet. And what happens is that the payee will find a route, and the only route which can go to Phoenix, will have to use this routing hint. So it will go to our node, and then we can say, “Okay, I see that the next channel in the route is this random identifier, and I know that this random identifier isn’t really an actual channel. It’s actually just a pointer to this particular Phoenix.” And that’s how we do the route. So we kind of have to beat the way the routing occurs at the last hub, but it’s exactly the same from the point of view of the rest of the network, from the point of view of the sender. From the point of view of the receiver too. It’s strictly compliant Lightning.

Pierre-Marie: The only thing is that when we do the last hop, it’s not really a channel identifier. It’s some other kind of identifier that we can reserve to a node.

Stephan Livera: Yeah.

Pierre-Marie: And that point maybe there is no actual channel to the Phoenix user. And that’s when we can ask the user if he needs us to create a channel, at that time. And that’s how we solved the onboarding process. Basically you start with zero, someone scans the QR code, and then you’re going to see a popup that says, “Okay, we have an inbound payment for you. We will start to do a setup.” We won’t even talk about channels to do a setup. “It’s going to cost you that much, do you accept on that?”

Stephan Livera: Got it. And actually, I’m curious. What happens if you press no there?

Pierre-Marie: Well, if you press no, so again, this payment is a real Lightning payment. So there is a pre-image. Even if the last hop in the route, which is our node, he knows that there is an incoming payment, what we have is an incoming HTLC, Hashed Time locked contract, just a contract. We know that if we have the pre-image to this hash then we’re going to be able to pull the money. But we need this pre-image. So then we ask, Phoenix, “Do you want us to create a channel? If you want to then you have to give me the pre-image.” If he says, “No, I don’t want to give you the pre-image. I don’t want this new channel to be created,” then we know that it’s not going to give us the pre-image, so we can fail it. So it’s really, we have tweaked some parts of Lightning, but it’s very, very marginal. It’s very small modifications. The whole process that guarantees that it’s trustless, that guarantees that I can pull money, I can’t take money from a sender if I haven’t forwarded the payment correctly. It still exists. And if it didn’t then it wouldn’t be interesting at all. We would have lost everything that makes Lightning interesting.

Stephan Livera: Right, right. Yeah. So in other words, basically that payment through to the newbie Phoenix user, it would just fail. And they would just do something. They would try again with a new one. And I guess, it’s also really just interesting, as well, because it just means that if you are trying to help a new person set up, then maybe you might want to have either a direct channel with the ACINQ node or at least a route to the ACINQ node so that your payment can more easily go to that newbie, to that person who’s just set up their Phoenix wallet.

Pierre-Marie: Yes. The good thing with our node is it’s reasonably well connected, so even if you don’t have a direct channel to us, there is a good chance that your payment succeeds.

Stephan Livera: Yeah.

Pierre-Marie: Which is something that you’ll have probably heard the presentation made by a Christian Decker in Berlin about the success rate of payments. It’s kind of off topic of the feature now, but the readability of payments and the whole overall of success rate of making payments with Lightning is a very, very important thing. Even if we just discussed about end user and a pretty UX, pretty UIs at the core. This is all useless, completely useless, if the network, the core of the network, isn’t reliable enough. So yeah that was a side…

Stephan Livera: Yeah, yeah. No, that’s totally fair. And we might, we might get to the more broader points around Lightning later, but let’s just keep it to Phoenix for now.

Stephan Livera: One point that I noticed is, right now that amount that, sorry, that invoice rather is amountless, and some wallets treat that, and maybe rightfully so, that that’s a security risk. Because for example, I tried to fund my Phoenix wallet with a Zap payment, and I think Zap wallet actually doesn’t regard that as a valid invoice. So what I actually had to do was put in a manual amount and, as I understand, the reason for that is that if you do an amountless invoice without using the payment secret flag, or whatever it is, then I think one of the intermediate hops or maybe the next, the second last hop can steal the fee or steal that as a fee. Is that essentially the correct understanding there?

Pierre-Marie: Yes, that’s true. The second to last hop, I used the last hub in my previous explanation, but it’s actually, yes, it’s second to last hop in the route. He can change the amount basically, so we can reduce the amount and take the difference. So what the payment secret does is that it can’t change anymore, the amount. And yes, invoiceless about… Sorry.

Stephan Livera: Amountless invoices, yeah.

Pierre-Marie: Amountless invoices, yes, they are a security risk. And we do display a warning also on Phoenix when you pay an amountless invoice, because that’s a risk. We decided not to prevent it altogether because wanted the user to have the choice. And also since we know that a payment secret was right around the corner it would have created confusion because we would have prevented it, then allowed it again and the risk didn’t seem that big. So we just added a warning, very explicit, and the user can choose what he wants. But yes, that’s a…

Stephan Livera: Yeah. So anyway, for listeners, I guess, if you are trying to help someone set up on Phoenix, what you might want to do is just make sure you put in a manual amount. So then that way, for now, if you’ve got Zap wallet or some other wallet, you can still pay that and then fund the person you’re trying to onboard into Lightning. So that’s really cool.

Pierre-Marie: Yeah, if you already have Phoenix and you onboard someone on Phoenix, then you can use an amountless invoice. Because our interpretation of trampoline already has the payment secret, so if it needs to finish payment that is not going to be a problem.

Stephan Livera: Yep, yep. Yeah, yeah. That’s a good point to note and we’ll get to trampoline routing, as well. I think one other point I wanted to touch on as well is that you have two options to fund. You can fund that wallet with Lightning payment or just with a Bitcoin payment. And as I understand, it’s not actually a submarine swap like the trustless style, but it’s more just a trusted swap in. Could you outline a little bit of that process if somebody wants to fund it with a Bitcoin payment on chain, that is?

Pierre-Marie: Yeah, so the idea is just you can send to your… So Phoenix is pure Lightning. All the funds you have in Phoenix are on Lightning. But we wanted to make it very easy to send funds to your Lightning wallet from a Legacy Bitcoin wallet. So it’s a swap.

Pierre-Marie: We went with a trusted swap, which means that when you use the swap feature either from Lighting to on chain or from on chain to Lightning, then you trust us in this operation. Basically, you pay us the amount, and then we make the swap. That’s trusted. The reason we went with that scheme is that trustless swap, for starters, they don’t exist. It’s not entirely trustless. You still have to in one case to pay the fee upfront, so you’re still trusting, not for the amount of the swap you’re trusting only for the fee that the swap service is going to charge you. So it’s definitely better from that standpoint, but it’s not perfect. So that’s one of the reasons.

Pierre-Marie: And the other reasons is that the construct is more complicated. It’s going to have more transactions, so it’s going to cost more. And the third reason is that in one direction, I don’t remember on the top of my head I don’t know if it’s a swap in or a swap out, but in one of the cases the sending wallet needs to understand what it is doing, meaning that it needs to speak the swap protocol. And so you wouldn’t be able to just send funds to your Phoenix wallet from any Legacy Bitcoin wallet, which is kind of a big problem, because then everything is broken, basically. From the good UX point of view, everything is broken because then you have to understand a lot of things, and it’s not good. So we decided to go with a very simple alternative, which is again trusted. And it’s a choice that makes sense for the Phoenix use case.

Stephan Livera: Yeah, right. Okay. And so yeah, so we’ve covered that. I think another thing maybe we just point out the fees, as well. So that’s an aspect, as well. Just so all the listeners are aware exactly what are the fees. So I’ve just read from the website and pulled that together. So as I see it, the fee for sending is 10 sats plus 0.1% of the amount sent. So as I understand then, if you’re paying 100 dollars that means you’re paying, what is it, 10 cents on 100 dollars, right?

Pierre-Marie: Yes.

Stephan Livera: If you’re sending a Lightning payment. And then if you’re doing… I’m sorry, go on.

Pierre-Marie: Yeah. So regarding the fees, so there is the difference between the swap fees, and the on the fly channel creation fees, and the payment fees. The reason is that, so when you pay your Lightning invoice from Phoenix, you’re using trampoline, which means that you are delegating the route computation to a third party node, which currently is our node. In the future the goal is to have a multitude of trampoline nodes, and you would build a route node from hop to hop, but from trampoline node to trampoline node. And each trampoline node will have to figure out the route to the next trampoline node. And the consequence of that is that from the point of view of Phoenix, when you pay the invoice, you don’t know what the route will be, so you don’t know what the fee is going to be. So it makes it very easy to make payments, because you’ll have to bother about the route. I’m talking from a computational perspective.

Pierre-Marie: But you have to be pessimistic, because you’ve made the HTLC, you send the payment to the trampoline node and then you hope that whatever fee you have added to your payment will be enough to cover the route to the destination. And so with trampoline, the fee has to be pessimistic, that’s the first thing.

Pierre-Marie: And second is that currently in our implementation, in the Phoenix, as it is today, we don’t have any retry mechanism. It’s very, very basic. So we have to be extremely pessimistic, because there is no retry mechanism if the fee we choose is not enough. So what I mean is that in the upcoming version, it’s not far in the future, we are testing it currently, so the ETA is a few weeks, the goal is for Phoenix to have a rough estimate of how much it’s going to cost, how much the actual route is going to cost, and then try to send a payment with that much fee. And maybe the trampoline node is going to answer, “No it’s not enough, sorry. Best I can do is that.” And then you can try again, which means that those payment fees are going to be reduced significantly. That’s what I wanted to it to say on the…

Pierre-Marie: So it’s different from the other fees which are for the swap and for the channel creation. Those fees they are used… So they are basically 0.5% when you receive an incoming payment, which covers the cost for us to open the channels. So which means opening a Bitcoin transaction, creating a Bitcoin transaction on the blockchain. And the swapping is the same, because swapping implies creating a new channel the way we have implemented it. So it’s the same. And so that’s 0.5%.

Stephan Livera: Yeah, got it. So then basically if somebody is funding it for 100 dollars with an on chain transaction that will cost about 50 cents, roughly. Okay. And then, I guess, for the swap out case, so as Phoenix is a fully Lightning wallet and if you want to pay an on chain Bitcoin address, there is also a fee associated with that and, as I understand, that is basically associated for the miner fee for that swap out, correct?

Pierre-Marie: Yes. Obviously yes, the network miner fee is going to… Well, what you pay is the miner fee whether it was… I was about to say that it depends on the actual fee rate at the time when you make the swap, but also it depends on the state of our Bitcoin wallet. If we have a lot of small UTXOs, which can be the case because we manage a decent number of channels, then it might cost significantly, not because the fee rate is currently high, but because that’s what our wallet is… That’s the state of our UTXOs at the time of the swap.

Stephan Livera: Yeah, got it. So to summarize then, it’s basically the miner fee and also the ACINQ’s wallet because depending on the number of UTXOs available it might be more or less easy to do that on-chain transaction.

Pierre-Marie: We have no interest at all in taking a fee at that time, for us. It’s a good thing for us to do that, because it allows us to consolidate our UTXOs. But we’re not taking a direct fee, and one thing that we’re going to do for the swap out, so Lightning to Bitcoin, it’s to allow the user to choose the priority, which he can’t currently, which will allow finer grained control on the fees.

Stephan Livera: Yeah. Cool, cool. Another point I was really interested to talk about is MPP. Now I had a chance to, again, I was testing and playing around with the wallet, obviously, in preparation, and I went into my Phoenix wallet, and then I went to the settings, and I looked at my channel list. And then I saw I had two channels, and then what I wanted to do was test out MPP by making a payment to one of my own nodes, but just deliberately over the size of that channel just to see how it would work. And I found it works just like that. It was really cool. And when I made the payment it actually showed, “Oh, this was an Atomic Multipath Payment.” So tell us a little bit about that. And I think as far as I can understand, this is one of the first Lightning wallets that really supports that all the way through.

Pierre-Marie: Yes. We don’t particularly market that, because what is missing for us, it’s one part of… Earlier in the discussion I say that there was a lot of engineering in the background to make Phoenix very seamless. AMP is a part of that engineering. It’s one of the building blocks. When you have it, it seems seamless, and it disappears completely from your mind. It’s just works. But when you have it, it’s basically impossible to know how you can spend your funds. So there is not much to say about it. It’s just that even if in the background you may have, depending on how you used your wallet, depending on how you are funding it, you may have one or 10 channels. It doesn’t matter at all. You can spend it like if it was one big channel.

Pierre-Marie: And the important part, the catch-22 is that it’s not enough to have AMP. You also have to have what we call the zero reserve feature. So the zero reserve, it sounds a technical thing, but it has big impact on the usability of the wallet. So the goal of the reserve in Lightning channels is to make sure that both parties, at all time, have something at stake. Otherwise, if you don’t have something at stake, then you can try to cheat, because you have nothing to lose. That’s why there is a reserve. The problem is that if you combine a reserve with AMP it’s not linear anymore. It’s not the same thing if you have two channels that both need to maintain a reserve, even if you have AMP. It’s not the same thing compared to having one channel, because if you have two channels then you’re going to have two times the reserve and you won’t be able to spend from zero to the sum of both of your channels seamlessly.

Pierre-Marie: So what we have done is, we have created a special type of channel, where Phoenix users have the right to have a zero reserve. So their balance in the channel can go all the way to zero, which means that in that particular case our node trusts a bit more Phoenix users than the opposites, because our node still has to maintain a standard reserve. So we always have something at stake, whereas Phoenix users don’t always have something at stake. And we did that because we know that if people try to cheat we are going to be able to notice that on the blockchain and we’re still going to be able to get our funds back.

Stephan Livera: Gotcha. Yeah, so I guess the other way to understand that for listeners is, basically, in this case ACINQ is kind of taking on that risk on behalf of the customer in some ways to make it easy for the user. But it means ACINQ has to now watch the blockchain to make sure there are no cheating attempts.

Pierre-Marie: No, it’s not that we’re taking the risk on the behalf of the customer. So in the lightning channel, it’s like a Mexican standoff. It’s everybody is looking at everybody else and, and if you don’t behave correctly then you’re going to get punished. So when you have two parties in a channel both are watching the blockchain to make sure that the other party isn’t cheating. What we do by allowing one party’s balance to go all the way to zero, is that now they can try to cheat without any consequence, because the way that the punishment mechanism works in Lightning is that the honest node will be able to sweep the funds of the dishonest node. But if the dishonest node doesn’t have any money, it doesn’t change anything, so it never tries to cheat. So what we did is that since Phoenix users don’t have the reserve, there may be cases where they could try to publish a revoked transaction. So it’s not that we are taking the risk on their behalf it’s just, we’re taking a risk deliberately to ensure that the UX is good for Phoenix users.

Stephan Livera: Gotcha. Yeah, sorry, I could have worded that a bit more precisely. Okay, I’m also keen to talk about the other big, big trade off, which we obviously have to talk about, which is around privacy and trampoline routing. So let’s talk a little bit about this. So I guess, let’s start with the first observation, which is that currently ACINQ node knows the public key of the person you are trying to pay and then the amount, and can you tell us a little bit around how you’re thinking about that from a privacy point of view and then potentially lead into what trampoline routing is.

Pierre-Marie: Okay, so there is a difference between… So we have done several trade offs. There’s difference between the trade offs that I mentioned where you’ve got two swaps, which to us just make sense unless there is some you ideas, these tradeoffs are going to stay in the foreseeable future. “Yes, you should do a swap. You’re going to have to trust us, because we don’t have a better way to do it.” There’s a difference between that and our current trampoline implementation, which limitations are just because it’s not the final version. Just want to start with that because to us it makes a big difference between the persistent trade offs and those which we believe are temporary. So what happens is that when you make a payment on Lightning, on Phoenix, on Lightning from a Phoenix, you delegate the computation of the route to a trampoline node. In the current implementation of Phoenix this trampoline node is our node, the ACINQ node.

Pierre-Marie: So basically what you do is you send an HTLC,and in the next hop… I’m summarizing, but basically it’s how that works. In the next hop it’s not a direct neighbor of our node. It’s some remote node. It’s actually the destination. So this implies that we know what payments, what amounts you’re paying and we know the destination of the node. And we also know your ID of usage because you’re talking to us. So from that perspective, Phoenix’s current version, it’s exactly the same. We have exactly the same information as if we were a hosted Lightning wallet provider. So that’s the state of Phoenix right now.

Pierre-Marie: If we routed it that way it’s because we know that it’s not going to be the case in the future. So how does trampoline works in the fully deployed setup? Instead of having only one trampoline node, you have routed to the trampoline node in the network, and Phoenix knows a decent number of trampoline nodes. It doesn’t have to know all of them, but it needs to know, I don’t know, maybe 100 of them, something like that. As opposed to knowing the full routing table if Phoenix wanted to compute the route itself. So then Phoenix has, let’s say, 100 trampoline nodes. He can randomly pick trampoline nodes within that set and do a route that goes through all those trampoline nodes. And that last hop in the route will be the destination, which means that from the point of view of a trampoline node, you have the same information as from the point of view of a regular Lightning node today when you only know what’s before and what’s after. You don’t know where you are in the route. The goal is to have exactly that. If you will, it’s like instead of doing source routing between the adjacent nodes, which is the case with regular routing on Lightning, currently, we are doing source routing between trampoline nodes. And each trampoline node figures out, by itself, the route to the next trampoline hop.

Pierre-Marie: In theory the privacy that you can have with this scheme… What we believe is that it’s at least equal to what we have currently, because without trampoline the routing table will keep increasing. It keeps increasing every time there is a new public channel and every time there is a new node with private channels. And mobile devices, they have to sync this routing table at some point. They’re not going to be able to sync the whole routing table. So they will have to prune it, but they will have to prune it in a way that reasonably makes sure that they can reach anyone in the network. And there is a good chance that is this heuristic will result in a lot of mobile devices having the same pruned view of the graph. Does that make sense, what I’m saying?

Stephan Livera: Yeah, yeah, yeah. So and there could be potentially a privacy implication of that.

Pierre-Marie: Exactly.

Stephan Livera: That they don’t… If there’s only, say… Basically it limits the potential ways that you could have routed it through.

Pierre-Marie: Yes.

Stephan Livera: And part of Lightning, one of the ideas that even from a recent interview with Rusty was saying is this idea of potentially trying to make the routing a little bit more like a random walk such that it is more private and you can’t infer from the length roughly where that person was routing the payment from.

Pierre-Marie: Exactly. So my point is that with the current routing scheme, we could argue that from the point of view of the random walk target, we are going to hit a wall with the current way of doing routing. With trampoline, suppose there are lots of trampoline nodes on the network, then you can select a subset, a random subset of those trampoline nodes. You don’t have to have a complicated heuristics to be able to make sure that you will still be able to reach whatever payee, whoever payee you want to reach. You just take a random subset of trampoline nodes, which allows your payments routes to look much more like a random walk. So because you don’t have to have a very complex heuristics that guarantees that, “Yes, you are pruning a view of the network, but you’ll still be able to find the destination that you want to find.”

Stephan Livera: Yeah.

Pierre-Marie: So bottom line is that it’s absolutely true that the current implementation of trampoline, the way we have done it in the Phoenix, it does leak payment information to our node, that’s true. But it’s not a property of trampolines. Just to property of the way that we have implemented it currently.

Stephan Livera: Yep. And I guess, I was looking through some of the Lightning spec discussion, and I noticed t-bast, from your team, was discussing and trying to propose this idea. And there was a little bit of feedback from some others like Matt Corallo and Zeeman. And I think Matt Corallo’s concern was something like, “It might…” And I think it was what you were basically saying, is that it might impact the privacy, and I think his concern was like, “We don’t want to help the clients reduce their route map size, because that might be taking a step backwards, in Lightning, from a privacy perspective.”

Pierre-Marie: Yes.

Stephan Livera: So I guess that’s kind of a bit of a debate that has to get resolved before trampoline routing comes to Lightning network, right?

Pierre-Marie: Yes, definitely. It is a debate, and the argument I just made are basically the same that Bastien did on the pull request. And it’s definitely a sensitive topic, and I think it’s great that you are able to see that. It’s not like if any change that happens on Lightning is just a walk in the park for everyone. We still have to convince others. We are pretty sure it’s a good way to improve routing on Lightning, but definitely other people may think differently and we will have to convince them. So if from the point of view of a user, a simple Lightning user, I find that very reassuring.

Stephan Livera: Yup. Yeah, yeah, yeah. So hopefully, yeah, we can see what happens with that. And I think they’re probably the key points that I was keen to… Oh, one other point around Phoenix and the seed. So with the seed, is it basically just a BIP39 seed on the BIP84, like the BC, the Bech32?

Pierre-Marie: Yes, yes.

Stephan Livera: Yeah. So in terms of recovery?

Pierre-Marie: So what happens is that when you have a Lighting channel… What it needs to have, a Lightning channel, is basically to hold a commitment transaction that represents the current state of the channel. This commitment transaction is to be published on chain if something wrong happens. And what your seed protects is the address that this commitment transaction pays to. So just having the seed, if the commitment transaction is published just having the seed is enough to recover your funds. And what we have been careful to do is to follow the same path as a standard Bitcoin wallet, so you can use… We actually recommend using Electrum when you want to recover your funds. If something happens and the channel gets force closed, it shouldn’t happen with Phoenix or very, very rarely, much more rarely than the, for example, eclair mobile for example. But it can happen. Anything can happen.

Pierre-Marie: We had one user, we had a bug that’s fixed in the last version of Phoenix, that caused, it’s a very corner case, but that caused channel to be force closed, and the user just had to install Electrum, enter the seed and boom the funds were there. He was able to just, swept them into his new Phoenix wallet. So yeah, just we are following the BIP39, BIP84 segwit address.

Stephan Livera: Excellent. And let’s talk a little bit about eclair. So as I understand, eclair, sorry, eclair mobile I should say, which was your first Lightning wallet. And my understanding is, you’re still maintaining eclair mobile, as well, and that is a more like a power user, or developer, or enthusiast wallet, correct?

Pierre-Marie: Yes, eclair mobile gives you the raw experience of Lightning. It’s not hiding anything. It’s not trying to hide complexity. It just shows things how they are on a more lower level. So you have to manage an on chain and off chain balance. You have to create channels yourself. You can open channel to anyone you want. Currently doesn’t support AMP, but it’s going to support AMP soon. So it’s a great way to use Lightning if you absolutely want to know what’s happening under the hood. If you don’t like the fact that you’re connected to our node… So with eclair mobile you’re completely off the hook. You can connect to whoever you want. You can create your own node, and I think Rusty likes to connect to eclair mobile to his c-lightning node just to test interoperability between our implementations, but you can do whatever you want. It’s a different set of trade offs, so it makes sense for us to keep maintaining it.

Stephan Livera: Excellent. I’d love to talk a little bit more about Lightning network, just more broadly. Do you have any views around how big this thing can get? How fast can transactions be? Because you see all sorts of different numbers. If you look at the Lightning network paper, it says millions of transactions per second and I think once you consider actual hardware limitations and things, it might be per node, it might be something closer to like 100 transactions per second. And then let’s say you’ve got however many routing nodes that you see being out there, what’s your sort of view on how that evolves? Do you see it being like, “Okay, there’ll be a solid 5000 routing nodes out there.”

Pierre-Marie: Yeah, on the performance side, to me, there is no limitation, because it’s a completely horizontal scaling issue that is even if you have, how do we performance limitation, you can distribute one Lightning node. There’s no reason why you wouldn’t do it. So just because our node is identified by a single node ID doesn’t mean that it has to be one single computer. It can be… So to me, on throughputs, from the throughput point of view, there is no limitation. I don’t see why there would be a limitation.

Pierre-Marie: On the total number of nodes, I think this is related to the discussion that we had about trampoline. The limitation is going to be for our end, leaves, endpoints to find routes in this network. And the first nice things were private channels, and we may need to go further than that. We believe that trampoline is the appropriate way to work on that, but there may be other ways. I believe that’s going to be the main technical limitation for the number of nodes.

Stephan Livera: Yeah, and I had one other question, as well, which was just around centralization on the Lightning network and permissioning.

Pierre-Marie: Yes.

Stephan Livera: So I was curious to get your view on if you think Lightning, because if you listen to a skeptic… Now, again, I’m bullish on Lightning. But if you listen to a skeptic, they might say something like, “Oh look, it’s going to end up being really permissioned, and there’s just going to be a bunch of big nodes that become hubs. And you have to through them, and that will impinge on the permissionless censorship resistant nature of Lightning.” What’s your take on that?

Pierre-Marie: Well, two things. First thing, there are going to be large nodes. It’s obvious that if you have exchanges. Recently we have seen Bitstamp and the Bitfinex run a node. If Lightning is to succeed obviously large companies will have large hubs, large nodes. It’s obvious. I think what’s important is will still be possible, feasible to run a node to run a small node. I think that’s the proper way to look at the issue, not to try to limit the size of the larger nodes, but to still make sure that it makes sense and that you have the guarantees that you want to have if you want to bypass those nodes completely. It’s really important to be able to bypass those nodes.

Pierre-Marie: So that’s why I don’t see an imminent issue with that. If you compare to mining, to compare to mining you can’t make, I don’t know, a 10,000 dollar, 100,000 dollar investment and become a miner. You can’t do it. The barriers to entry are too high. But it’s not the same with Lightning. You can run a Lightning node even if you have not millions of dollars, and you’ll still be able… If you want to pay somewhat, that some large hubs don’t want you to pay. You can still bypass that large hub. So I think that’s essential with regard to the basic properties of Bitcoin that we absolutely want to preserve with Lightning. But that’s actually only a part of a marginal point of if lightning is to succeed, we’d be centralized, we’d be permissioned.

Pierre-Marie: I think it can’t succeed if it’s permissioned, because it’s really all or nothing. From my point of view, when you design a protocol like Lightning, which is complicated, it’s complex, it’s costly to develop and to… Basically what we are doing is working around the hard limitation that we have when we work on Bitcoin. It’s a very limited space. What can we do to make the best of it? So it has a cost, and we have to have properties that justifies that we pay that that cost. So if we don’t have those properties and if it’s more expensive than a centralized payment system, like PayPal, then it just doesn’t make sense. And so it’s not going to succeed. So to me, it’s either Lightning keeps the properties that Bitcoin offers and then maybe can succeed.

Pierre-Marie: The other potential way it can fail, maybe someone finds a flaw. Maybe, I don’t know. But it’s a requirement. Or it can’t protect those properties. In that case it’s not going to be competitive anyway, compared to centralized services. So it has no way of having success.

Stephan Livera: Yeah. And also do you have a view… Yeah, very interesting thoughts. And do you have a view on things like another angle of centralization being perhaps the need for liquidity management. So for example, if somebody needs to continually replenish a channel, then are they now more dependent on there being enough submarine swap or just trusted swap providers to allow them to basically manage their channel balance? Or do you see it like maybe some of the technical innovations coming and MPP and some of these other things might lessen the need for that kind of thing?

Pierre-Marie: Okay. So in my opinion, MPP helps given a snapshot of the network. MPP helps when you want to maximize your chances of making a given payment, but that’s pretty much it. I don’t think MPP really has an impact on the bigger picture of what’s going on with liquidity.

Stephan Livera: Yeah.

Pierre-Marie: I’m not really convinced that things like channel rebalancing are going to help a lot, because it depends what’s the scope of it. If by rebalancing you mean going to the chain then of course it will help, because it means you getting out of the Lightning network and going back to bitcoin. So basically that’s what it does when you on chain. So then if there are some payments that always go in one direction then you can cut that off and then put back, allocate liquidity.

Pierre-Marie: What I think is that we don’t know yet. There are a lot of unknowns, a lot of nodes in Bitcoin, in general, and in in particular. We don’t know what the overall flow of payments will look like. And this will have a big impact on the liquidity needs. For example, if you have a huge… Amazon is accepting Lightning. Is it going to be a big problem for them to get liquidity? I don’t think so. Because if Amazon runs a node they’re going to mostly receive funds, mostly. Which means that they won’t have to allocate funds themselves. It’s other people in the network that see the opportunity to route payment to Amazon, which will provide that liquidity. So what Amazon will do is just wait for their channels to be full, and then close them and get back the funds on chain and do whatever they want to.

Pierre-Marie: Maybe they’re going to refund some clients sometimes. So maybe they’re going to… But mostly they’re going to receive. So it’s not a big problem. And I believe that most of the time end users will end up paying. Yeah, obviously, you may want to receive funds and that’s one of the harder tasks we had on Phoenix. But I think overall, you’re going to get paid. You’re going to have your salary, or something, every now and then, and every day you make payments. And this is okay, because you’re going to provide liquidity, yourself, to the network. And it turns out pretty well. For routing nodes, nodes that don’t mostly send money and don’t mostly receive money that, more or less equally then yes, they would have to have enough liquidity on both sides. And they can’t decide who they allocate their funds to but they can’t decide who… They can’t tell people to open channels to them. Or there has to be some good reason for that, so routing nodes will be limited.

Pierre-Marie: They will have to have a decent amount of capital on their node, and they will have to have the ability to secure it, which we all know is not an easy task if you ask the exchanges. So that by the way will be also probably be a limiting factor to the size of nodes. So to me it’s not this liquidity thing. It’s not the most pressing issue provided that… To me the most difficult part to solve was the inbound liquidity thing for end users, which we worked around that by introducing a little trust. With the on the fly channels that we went over before. But apart from that, I don’t see it as a very limiting factor, currently. At least it’s way after the routing part in my opinion.

Stephan Livera: Got it. Yeah. No, that’s really good reflections there. I suppose just to finish it off then, what are you most excited about for 2020 with Bitcoin and Lightning, just generally? Is there anything you’re particularly looking forward to or that you’re hoping we get in 2020?

Pierre-Marie: Well, as someone who’s most interested in building software as opposed to trading, I’m not following the price of Bitcoin a lot. Obviously I’m looking forward to the halving, just to see what happens. Everybody says that and I think it’s really true. It was really nice to be able to have a period of time when the things got more quiet, so that we could build what we have to build more peacefully. So this halving thing kind of contradicts that. I hope we still be… I don’t really want to see the craziness of 2017, but it’s exciting too because we have Lightning now. We didn’t have it in 2017.

Pierre-Marie: And what’s pretty interesting is that if this halving creates a new euphoria, a new influx of users, will we be ready? Will the network be ready? Phoenix can be one answer to that. Will the network as a whole reliable enough to handle more users? I think that’s an open question. I think we are very early. If that happens it’s going to be a big test. So that’s from the Bitcoin and Lightning point of view.

Pierre-Marie: And also on the purely Lightning, we had this meeting in the Australia, actually, at the end of 2018, in which we discussed the next features, main features of Lightning. AMP was one of those features, but we are not done yet. So we are still in the process of developing all of those. And there is dual funding, also splice in, splice out, there are a lot of things which are very exciting. They take a long time to develop.

Pierre-Marie: It must feel even longer for users, because they don’t even know when that’s going to happen. We mostly don’t. We are not sure either. But yeah, there are a lot of things that are in the pipe. I think the transition from Lightning UX in 2018 and the Lightning UX in 2019 and ’20 shows that there are a lot of things that we can do on the protocol side to actually improve user experience for end users. And it’s not going to stop. So for people who were afraid that it would never be possible to have a decent UX on Lightning, an easy way to receive funds on Lightning, I think the recent developments show that there are a lot of improvements that we can do, and they show also that there are a lot of future, even further, improvements that we can make. So it’s a lot of work, but a lot of interesting perspectives for it.

Stephan Livera: Yeah. And look, I’ve got to say, I think you guys have done a great job with Phoenix in making a non-custodial experience that’s really smooth, really easy. I’ve found it really impressive to just play around with the app. And I’ve played around with Lightning apps, and this one was really impressive. So I could definitely see myself being able to help, if I wanted to onboard a newcomer into Lightning, this is probably what I would go with. So look, I guess, as we close it out, just make sure you let the listeners know where can they find you online? Where can they find ACINQ? And where can they download Phoenix? Oh, and also Phoenix for the iPhone, as well.

Pierre-Marie: Yeah, well in 2020 we are working on it. For now, we have only released Android apps. eclair mobile is Android, Phoenix is currently Android. But we are working on the iOS version, so it’s going to be a big next step for 2020. So yeah, our website is ACINQ.co. There is a dedicated learning page for Phoenix, which is Phoenix.ACINQ.co.

Pierre-Marie: All our software, server node, eclair mobile, Phoenix, Strike, all of those, they run on our eclair stack, which is a full implementation of Lightning written in Scala. Our GitHub, it’s on GitHub. All our mobile application, all are open source, it’s eclair mobile and Phoenix on GitHub. And you’re welcome to contribute. For developers, we prefer using Gitter, so it’s on our eclair GitHub there is a link to our Gitter page. And for support, Telegram seems to work a bit better. So we also have a dedicated Twitter account for Phoenix users that you can use to have support. And yeah, that’s pretty much it. A lot of ways to get in touch with us.

Stephan Livera: Awesome. Well, I’ll include the links in the show notes, and thank you again for joining me, Pierre. It’s been a great fun chatting with you.

Pierre-Marie: Great to talk to you, Stephan.