NODE ONLINE
EP 142
slp@node:/transmissions$ open --transmission SLP142
TRANSMISSION_DETAIL

TRANSMISSION SLP142

Marie Padiou - ACINQ & Phoenix Wallet: easiest non-custodial lightning wallet yet?

with Pierre

DATE 18 January 2020
DURATION 01:25:46
GUEST Pierre

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.

listener@future:/timestamps$ list --chapters
CHAPTER_INDEX
    listener@future:/transcript$ decode --transmission SLP142
    TRANSCRIPT_BUFFER DECODED

    Hi and welcome to the Stephan Livera podcast, a show about Bitcoin and Austrian economics. Today, for episode 142, we've got the co-founder and CEO of ACINQ, Pierre Marie Padiou, and he's on to tell us about his company and also his new wallet, Phoenix, which I think is quite possibly one of the easiest non-custodial Lightning wallet experiences out there today. So this podcast is brought to you by Kraken, one of the world's leading Bitcoin exchanges. They're one of the longest standing, they're consistently rated the best, they've got a high quality platform, they offer some great liquidity, they've got high trading volume and low fees with no minimum or hidden fees. They've also got Kraken Pro mobile app delivering all the security and features you love about Kraken Exchange in a beautiful mobile-first design for Bitcoin trading on the go. There's Kraken OTC desk for those seeking a more private, personalized service for large block trades. There's Kraken My Margin up to five times and futures up to fifty times leverage. There's also CryptoWatch platform, which is a popular charting and trading terminal for cryptocurrency markets, and their mission is to provide one powerful interface to scan prices, analyze market movements, and make trades. So go and find out more at kraken dot com. This episode also presented to you by Unchained Capital, a Bitcoin financial services company empowering customers with financial freedom and control. All their products and services are built on the foundation of multi-sig. So Unchained offer a multi-sig two of three vault, which is a great option if you're thinking through how best to secure your Bitcoin. So you hold two keys and Unchained would hold the third key in that scenario. And then if you need to access liquidity without selling your Bitcoin, that's where you can use Unchained's collateralized loans. So you can put up some Bitcoin, you pay interest, all that Bitcoin is stored on chain in dedicated multi-sig addresses and it's never rehypothecated. They've also got some updates with notifications for pending transactions, key check and loan actions. They've also got a default external spend workflow with Caravan where you can copy paste the redeem script, so you've got verifiable information about your Bitcoin. They've got incredible content on their website as well, so make sure you go and look them up. The website is unchained-dashcapital dot com. Check out givebitcoin dot io, the easiest and safest way to get your friends and family into Bitcoin. GiveBitcoin is now actually part of the parent brand Swan, and there's another product coming called Se- Give Bitcoin. So Give Bitcoin is an awesome product because it helps advance people up that learning curve and turning them into a hodler. Sometimes when you just give it to them straight, they'll just lose that Bitcoin. So that's why there's value in Give Bitcoin, because you can buy it for your friends and family with just their email address, and that gift is time delayed with a regulated US custodian for one year. Give Bitcoin delivers twelve monthly lessons to that recipient, and there is input from many well-known Bitcoiners such as Saftein, Matt Adell Citizen Bitcoin and Jan Pritzker is recently now the CTO. I'm an advisor with a small equity stake as well. So keep an eye out for more exciting announcements coming from Give Bitcoin and Swan. The aim is to have a positive impact on Bitcoin adoption, so I'm excited to have them as a sponsor. Have you backed up your Bitcoin seed? Look into CipherSafe, CipherSafe dot io. CipherSafe are producing the CipherWheel product. So if you've invested in a Bitcoin hardware wallet and you've got a bip thirty nine twelve word or twenty four word seed Seed. Make sure it's backed up in a way that's fireproof, waterproof, rustproof, petproof, and tamper evident. Cipher wheel comes in a wheel shape and it masks the words of your seed unless you unlock the padlock tamper evident seal so you know it's been opened. CipherSafe are also switching the stainless steel alloy used to improve the corrosion resistance and otherwise the product scored an A versus heat and crushing on Jameson Lop's recent round of physical seed testing. So make sure that you or your loved ones have access to your bitcoins if an accident occurs. It's in pre order now, and orders will be going out in early February, so go and order yours at ciphersafe dot io. So on to the interview. Pierre, welcome to the show.

    Hi, Stephan. Nice to see you again after, Berlin, I think, last time we met.

    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 gonna get into all of that. 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 know, you're, you're leading ACINQ. can you tell us a little bit about yourself and how, how the company got started?

    Yeah, well company, because basically I, I like freedom and I don't like to have bosses. So, when I first heard about Bitcoin, I think it was maybe in two thousand 12 or 2013, something like that. I, 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. And, we started, working on Lightning in 2015. I think we are the second implementations, implementation to, to, To be developed, shortly after, Sea Lightning and shortly before LND, and, we have been, developing, Eclair and doing variants of Eclair with Phoenix With Sekramoji, since then, and we're not going to stop. Obviously, it's a, it's a long run, it, it's, 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, I mean, that's, it can, it's a one-time opportunity. So if you like building distributed systems, if you like, technology, and if you like, also- working in an environment that's very, complex and, with a lot of, impacts on, on, non-technical things like finance, politics, all that. That's, that's very interesting. So

    so I'm very happy to have the, the chance on the, of, of, of, building ACINQ and the working on the Lightning Network.

    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?

    Well, initially, actually initially, so I, I told you that, I think was founded in, 2014. Initially, we are building a hardware wallet. That's, not a well-known fact, but we, we started building a hardware wallet around at the same time than, Ledger. And, if you know a bit about smart cards, you know that French have a history with smart cards. And, so independently, ledgers

    just came up with the, the conclusion that smart cards were the appropriate tech to store your bitcoins on. and, the best, the best part is that we are actually working in the same building as, as Ledger. They, they, they had, they were running, a co-working space that we were, that we, we are working into, and, so we were developing the two things most at the same time without, knowing that I mean, we weren't talking to each other much, and, but pretty quickly, we realized that Ramor is working on the same, topic, and so we had to move. And later on, we didn't have, a lo- we, we didn't have a background in, hardware, we didn't have the connections required. The, the thing is that when you, when you work with, hardware and smart cards, you have to have some connections with, manufacturers because they usually work with large companies, banks, governments, thing like that. They make orders of the size of a hundred K, more than that. So if you're a Bitcoin startup in, 2014 There is no way you can, you can, ask for a few thousand, chips, they're not gonna say yes. Ledger was able, were able to pull that out because, they had the, the relevant experience and they were in touch, and the relevant contacts. That wasn't our case. And, the thing is, when Lightning, arrived, I mean, the, when the paper was released, this was much closer to, our our, specialty, when, when I say we, it's mainly, my co-founder, Pharis, and myself. so it, it just made sense, we knew that it would be, very difficult to, to, To develop, but for just a paper at that time and not a very precise paper, the paper was just the idea, some, 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's, he, he published a series of blog posts and, I think it was, getting to the ground with lightning, something like that, where he, he started working on how can we really implement this thing, how can we past, can we get past the, the, theoretical white paper and build the thing, and, this is how the, The, specification project starting. I mean, it was not, a, a collective effort until 2016, scaling Bitcoin Milan, where the different teams who were Collaborating on the mailing list mostly, but in a very, like, unorganized manner until then. in, in scaling Bitcoin in Milan, then we, we went together and, and, and decided to, to try to formalize the, the lightning, specs. That's how the R-RFC effort started, and that will allows now any, anyone, any other companies like, for example, the Naya people, The Japanese company, they were able to implement a Lightning implementation, a full Lightning, implementation, without any, any help whatsoever, just by reading the specification, that we are, published, on, on GitHub, which means that, the, this, the effort was successful because that's the goal was to make,

    The, the process of, working on Lightning as permissionless as possible. That's, I think the Naya Data story proves that, it, that's, that's one goal that we achieved.

    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, as I understand, I think had, two rounds of funding, one in, late, I think it was October 2018 for, I think it was one point seven million, and then another round more recently for eight million. can you tell us a little bit about that process and, what was that like for you?

    Well, it's my first startup, so I wasn't at all, Knowledge of dealing with, funds and all of that. So the first, fundraiser that we did actually occ- 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, if I'm, everybody knows about that, the, the The, the big bubble on, on the, on Bitcoin and, and, altcoins. And so this, obviously, this obviously sparked interest, by, i-investors. and, At the same time, as a consequence of, the, the inflow of users, the scalability, limitations of, Bitcoin were made more visible. that's where the, some people, paid a lot of, fees, to make, unchange transactions when they wanted to, you know, trade very quickly on some exchange. they probably paid too much, but, I mean, the idea was that it would cost a lot of money to, if, too many people were using the- The same, blockchain space at the same time. Which make, which made our, Lightning project, very un-understandable for investors. So that's, that's how we, We're able to raise money. But, by the way, we, we are lucky to never have to, like, go, actually go, do a roadshow and look for, for money. That's, it has always been people, wanted to, I mean, interested in our project and contacting us to, to, so we're, we are, we are able to, to choose who, who we want to work with. Which is very important because I, as I, as I told you at the beginning, what I like is freedom, and, when you start to have investors, you obviously you, you lose a little freedom. So the fact that you can, that you can, choose who you want to work with. it's, it's a very big, it makes a lot of difference from my perspective. And, so that's the first round, and the second round, happened in 2018, in July 2018. It's, this, this one is, is interesting because I think it shows that, It's very dif- the situ- the situation is very different between two thousand eight, eighteen and two thousand nineteen with regard to Lightning. Lightning mainnet has been deployed in, very early two thousand eighteen. So in two thousand nineteen, you already have some Some, I mean, things to, to, to look at and, there, there is, it's not something in the future that's gonna, that's gonna be released in the future, it's something that exists today. Even if it's very early. So, what, what this, fundraiser means is that, it makes sense and after a year of bear market, a year and a half even, Again, it's w- the investor, smart investors, can recognize the value of Bitcoin and not get lost with all the, other, blockchains that claim to solve everything by, just tweaking some parameters. And, it's very, it's, it's very-- I think it's very telling, for the,

    for, for, for the,

    about the knowledge that, external investors have about the space we're working on, that they're able to make that kind of investments at, at that time. what's funny too is that, as part of this, fund, as, as, as part of this, raise, the French BPI, which is not a bank actually, despite its name, this BPI stands for, Public Investment Bank. It's not a bank, it's just, it's a public organism that supports innovation. so they, they are, their job is to fund innovative startups, but obviously since they are, state funded They aren't going to take some, choices that aren't politically correct, you see what I mean? And, and they, they have not, invested in Bitcoin, they, 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, it's, it's a minor, share, but still, it's, it's, it tells a lot about the perception of Bitcoin from, again, not from the external, from external,

    people, not from investors, but from, maybe from more people. From a more public,

    standpoint. in 2018, right at the time when we made the first, fundraiser, our bank account got, got closed by our bank. Just because we were in Bitcoin, we don't do any trading whatsoever.

    I know.

    But just, just because Bitcoin, our bank account got closed and a year later, this, this, BPI, institution, joined our, our, capital. So I think it's already, it's already, interesting, evolution. So that's pretty much, it regarding the, the invest-in-the, investment that we have. Obviously, the good news is that now we have enough, funding to, be able to continue development of Lightning Network, which again is, it kind of takes time. It's a very slow process, not because, there's not enough people working on it. I mean, you could obviously, we welcome obviously There'll be a lot more people to join, but even if there were, I, I don't know, a hundred thousand developers like Ethereum, like Ethereum, it wouldn't, it, it- It would still not, like arrive like, like that, because it's a whole infrastructure to, to, to, develop. It's a protocol, it's tools, for companies, for exchanges, for, I mean, any company that works in this, in the Bitcoin environment, it's tools also for users. wallets, and if you look at what we do, what I think what products we have, released, so far, it's exactly that. We have worked on the protocol, and we have, we have built tools. In order to, for, for any, all the potential actors, to have the, the what it, what is needed to join and to use, the, the network.

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

    I mean, yes.

    I think this may have been a, a bit overblown by, the, the, the, the media, the Bitcoin media, because it made, like it's nice to see that, to say a French government needs to invest in Bitcoin It's actually, I mean, they support innovation, yes, they do have ties, and they are owned by the state, but they make their own decisions, but w- I, I think the, the one thing to remember is that two years ago, it wouldn't have been-- this investment wouldn't have been possible. That's, 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, France is buying into, into Bitcoin. It's just that, Bitcoin sounds interesting and, Bitcoin is more and more well understood and, because the first natural reaction for a lot of, government types is just to scare them to just reject it right away.

    Yeah, certainly, and it's positive from that perspective. so how big There

    are six of us, so it's very small team, not that small compared to other Lightning teams, it's, it's a small, development community really, but obviously with the, the recent funding, we are looking to, to, hire more people.

    Awesome. and I mean, you've got a range of products, right? So you've got, Strike and Eclair, and I think Phoenix would be really interesting to talk about. I think Phoenix is really-- I've had a chance to try it out, I've, I, I was really impressed, to be honest. I thought it was, it was just, "Wow, how quick it is to set up and spend and all of that." It feels,

    it feels almost like if it's custodial, right? Sorry. It feels almost like if it's custodial.

    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?

    Okay, the aim is very simple. So as I told before, as I said before, ACINQ existed in 2014 when Lightning Network The, the world wasn't even invented yet. At that time, when, we wanted to, 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 wallet you want? I'm gonna send you, five dollars, five euros. Oh, okay, you get, you get five euros, and you can send it back to me or send it back to your, your friend. And that's what, that's where, the magic, happen and people understood that, okay, the money is on my phone, it's not my bank account, it's- It's there. If you lose, if I lose it, I'm gonna-- there's no, no, no one to save me. It's, I'm responsible for it. I mean, the, the whole, the, the, the whole, thing about, no trusted third party, financial independence is very easy to explain from that, from that, starting point than just theoretically. And, as a, a Bitcoin was more and more, used by more and more people, this kind of, demo was, harder to make because it would, it would cost more and,

    And it, it wasn't just, I, I mean, as, as the network evolved, this particular use case of just sending a small amount of money, a small, a small amount of bitcoins to, to other people was just not working with a non-chain wallet anymore. 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, we wanted to, to be able to do that, and we didn't start from scratch because we had, ACINQ, which, which was released in 2017. ACINQ 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, a decent UX with Lightning, that it would be reserved to, engineers or, experts of, of Bitcoin, people knowing what a channel is and how to manage it and, and so on. So we had that experience with Acinq, but our aim was to have a very, easily usable, wallet. And, so the goal of-- There's a lot of work and a lot of engineering happening under the hood with Phoenix, but the goal for the end user, it's, it's very simple. It's just you download the wallet, you show a QR code, it's a bit The QR code is a bit bigger than what the QR code looked like, a few years ago, but it's still, same, kind of the same thing. And, some people scan this code, send you, send you, five dollars, and you have it, there, there you have it. And then you can send it back immediately too. There is no channels, no inbound liquidity issues, nothing, everything is taken care of. And, it's, what I, really-- 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 how it works. Some people really think that, okay, but you, you do have some, it's hosted, right? Or, or,

    It has to be custodial or there has to be, no, it's just, that we made some trade-offs. It's true that I think maybe we're gonna go over them, but, at the, at the core, it's very similar. I mean, ninety-five percent, ninety-nine percent of Phoenix, of the code is exactly the same as ACINQ. You run a Lightning node on your, 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, which is the recommended way to do, but, you're still responsible for your, for, for your funds. And, yeah, we are, we are really, proud of what we have achieved with Phoenix, and we, we hope we have other plans and, to improve it even more.

    So let, 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 Write down the twelve words or write down the twenty-four words, right? So I noticed when I open Phoenix, it's different already because it's not forcing that straight away. It's, it's just got a warning there saying, "Hey, you need to back up your twelve words, but you can actually just open the app, download it, install it, right? And you can just get started straight away without having to, you know, click around and do all that. "

    Exactly. And if you keep in mind the use case that I, described you before, obviously the, the newbie Five minutes to write down his, it's just, it's not, he's not gonna do it, it's just a block here. So what we did instead, and that's, we had a, a user, telling us that too, you shouldn't block, the, onboarding process by, with this. We know that we have to back up, so just put a warning and, people will, a, 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, of the, pesky window. So, Yeah, the first, so when you download, Phoenix and you run it for the first time, it, it will, it will immediately arrive on the main screen displaying zero bitcoins. And now You're gonna hit on the receive button, and when you hit the receive button, it displays a QR code, it's a lightning payment request. 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's starts somewhere, our node, the ACINQ node, could create upfront a channel to this, mobile that works too. The problem is that first, we don't know for sure if the user is really about to receive bitcoins or if it's just installing the app and not doing anything with that. And if we have a million users doing that, then we're gonna, it's gonna cost us a lot of money. And, I mean, i-i-it's a potential attack, attack vector, right? So the idea we had with Phoenix is to reverse that, which is find a way to, for the users, for the, for the, for the, user to, to generate a Lightning invoice, even if it doesn't have a Lightning channel, or any traditional yet. And only when we see an incoming payment, and we can tell, okay, we have an incoming payment for you, you don't have any channels. But if you want, we can, now that we know that there is incoming payments for you, incoming, yeah, 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- The issue that I, I, described before, because then we aren't going to, to, to, to spend money up front, we're gonna, user are gonna pay for this inbound liquidity when they need it, and that can scale If we have a million, people doing that, that can scale, because we, we aren't, we aren't going to pay upfront, for all the users.

    Okay, yeah, that's great. And could you maybe go a little bit deeper into what's happening under the, behind the scenes there? So as I understand, that QR code really, it's actually got like a Lightning invoice, and I, yeah, 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 Yes. And then, as soon as, you know, the, let's say you're setting up the newbie, as soon as you make that payment, then, then all of a sudden it kind of, it knows, okay, now there's an incoming payment, then it asks you, do you want to set up the pa- the channel? Can you explain a little bit about what's going on there?

    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. Like if you take Eclair Mobile, Eclair Mobile only opens private channels when you create a invoice. You have to tell somehow the, the payee, the, the person who is going to, to, to pay this invoice, you have, you have to, 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 the, your private channels, and so you have to, to tell about those channels. And that's done with routing hints. 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 aren't necessarily public, they do exist, and you can, you can go through this, this route. So we use it, and a lot of, mobile, Lightning wallets use that, That's also why, if, if we didn't have those private channels, we would have a lot of problems already with the Lightning Network, routing table, because there would be a lot more channels. And, r-uh, syncing the r- the routing table is already,

    it's not an easy task for mobile devices because there are, constraints in terms of, performance and resources. So building on that, what Phoenix does is it adds a routing hint to its invoice. But Contrary to a clairvoyant, this routing hint doesn't point to an actual channel, it points to a fake private channel, channel, and the that goes from our node to Your, Phoenix, wallet. And what happens is that these, the, the, the PE, will, find a route. And the only route which can go to this, to, to Phoenix, we have to use this, this private, 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, an actual channel, it's actually just a pointer to this particular, Phoenix, and that's how we do the routing. So we kind of, have to- A bit the way, the, the routing, occurs at the last hub, but it's exactly the same from the, from the point of view of the, of the, the, 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. The only thing is that when we do the last hop It's not really a channel that we are, it's not really a channel identifier, it's some other kind of identifier that we can reserve to a, to a node. And at that point, maybe there is no actual channel, to, to the Phoenix, user, and that's where, that's when we can We can ask the user if he needs us to create a channel at that time. And that's, that's how we solve the unblocking process. basically, you start with zero, someone scans the QR code, and then you're gonna see a pop-up that says, "Okay, we have an inbound payment for you. we offer to create,

    to, to, to do a setup, we don't even talk about channels, to do a setup, it's gonna cost you that much, do you accept or not?

    Got it. And, actually, I'm curious, what happens if you press no there?

    Well, if you press no, so again, this payment- Is a real Lightning payment, so there is a preimage, right? even if the, the last hop in the route, which is our node, he knows that there is an incoming payment. What we already, what we, what we have is an incoming, HTLC, you know, a hashed time lock contract. Just a contract. We know that if, if we have the preimage to this hash, then we'll, we'll, we'll gonna be able to pull the money, but we need this preimage. So then we ask, Phoenix, do you want us to create a channel? If you want to, then you have to give me the preimage. If he says no, I don't want to, I, I, I don't want to give you the preimage, I don't want this new channel to be created, then we know that it's gonna, it's not gonna give us the preimage, so we, we can fail there. So it's really, We have tweaked some parts of Lightning, but it's very, very, marginal. It's, it's, it's, it's a very small modification. The whole, the, the whole process that guarantees that It's, trustless, that guarantees that I can't pull money, I can't, I can't, take money from a sender if I, if I haven't forwarded the, the The, the payment correctly, still exists. and if it didn't, then, that wouldn't, I mean, it wouldn't be interesting at all. It, we would have lost, everything that makes Lightning interesting.

    Right, right, yeah. So in other words, basically that payment through to the new, you know, the newbie Phoenix user, it would just fail, and, you know, they would just do something, they would try another, they would try again with the new one, right? 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 wanna have either a direct channel with the ACINQ node or at least a route to the ACINQ node so that your payment Go to that newbie, right? To that person who's just set up their Phoenix wallet, right?

    Yes. I mean, the good thing with, our wallet is really, is, is reasonably well connected, so even if you don't have a direct channel to us, there is a good chance that your, your payment, succeed. Yeah. Which is, something that's, you, you have probably, heard the, presentation made by, Christian, Christian Decker, in, Berlin about the success That's something that's, I mean, it's kind of off-topic, I'm, I'm kind of, off-topic, now, but this, the, the reliability of payments and the, the, the overall success rate of making payments on Lightning is, is a very, very important thing, even if we, we, We just discussed about end user and, a pretty UX, a pretty UIs, at the core. this is all useless, completely useless if the network, the, the core of the network isn't, reliable enough. So yeah, let's put aside,

    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. 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 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?

    Yes, that's true. The second to last hop, that's, I, I, I, I, I used the last hop as, in my previous explanation, but it's actually as the second to last hop, in the route. He, he can change the amount basically, so he can reduce the amount and take the difference of foreign. So what the payment secret does is that, is that he can't change anymore the, the, the amount. And, yes, invoiceless, about, sorry, amountless invoices, amountless invoices, yes, there are a security risk. and, We do display a warning also on Phoenix when you pay an invoice less, an amount less invoice, because that's a risk. We decided not to prevent it altogether because, We wanted to, to the user to have the choice, and, also since we knew that, a payment secrets wa-was, right around the corner, it would be, it would have created confusion because we would have prevented it, then allowed it again, and the, the risk didn't seem, that, that, big, so we just added a warning, very, explicit, and, the user can choose what he, what he wants. But yes, that's, that's,

    Yeah. So anyway Yes, if you're trying to help someone set up on Phoenix, you, 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 your, you know, the person you're trying to onboard into Lightning. so that's, that, so that's really cool. now,

    yeah, there's a, if you, if you, if you already have Phoenix and you onboard someone on Phoenix, then you can use,

    Correct thing. So, if you do, Phoenix to Phoenix payment, that's not gonna be a problem.

    Yeah. Yeah, yeah, yeah. That's, 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 like a trusted Fund it with a Bitcoin payment. Yeah. On chain. 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 want it to be, to, to make it very easy to send funds to your s-- Lightning wallet from a legacy Bitcoin wallet. So it's a swap. we went with a trusted swap, which means that when you use the swap feature, either from Lightning to Unchain or from Unchain to Lightning, then, you trust, you trust us to, to- In this operation, basically you pay us the amount and then we make the, the swap. That's trusted. The reason we, we went with that scheme is that, trustless swap Well, for, for starters, they don't exist. it's not entirely trustless. you have, you still have in one case to pay the fee upfront, so you're still trusting, you're trusting for, not for the amount of the swap, you're trusting only for the, for the, the fee that the swap, service is going to, 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, and the other reasons is that the, the, the construct is, more complicated, is gonna have more transactions, and so it's gonna 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 swap out, but in one, in, in one of the cases, then 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 e-everything is broken basically. From our, from the good UX point of view, everything is broken, because then you have to understand a lot of things and then, and it's not good. So we decided to go, very, with a very simple, alternative, which is, again, trusted. and I believe that such choice that makes sense for, for, for the Phoenix use case.

    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 there's, that's an aspect as well, just so 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. Paying a hundred dollars, that means you're paying, what is it, ten, ten cents on a hundred dollars, right? If you're sending a lightning payment. And then if you're doing, oh, sorry, go on.

    Yeah. So regarding the, the fees So there is the difference between the, the swap fees and the, on the flight creation fees and the payment fees. The reason is that, so when you send, when you, when you pay a lightning invoice for, 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, our, the goal is to have a multitude of Trampoline nodes and You would build a, a, a route not from a hub to hub, but from trampoline node to trampoline node, and each trampoline node would have to figure out the ro-the route to the next trampoline node. And the consequence of that is Is that from the point of view of Phoenix, when you, when you pay the invoice, you don't know what the route will be. So you don't know what the fee is gonna be. So it makes it very, easy to, to, make payments because you don't have to, bother about the, the route. I mean, I'm, I'm talking, from a computationally, computational perspective. But you have to be pessimistic because you, you make the, the HTLC, you send the payment to the Torporino node, and then you hope that whatever fee you have added to your, to your payment will be enough to cover the, the route to the destination. And So with trampoline, the fee has to be pessimistic. That's the first thing. And second is that currently in, in our implementation, in the, in the Phoenix as 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 isn't enough. So what I mean is that in a near coming version, it's like it's not far in the future, we are, we are testing it right currently, so it's gonna be, ETA in a few weeks. The goal is for Phoenix to have a rough estimate of how much it's gonna 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, to answer, no, it's not enough, sorry. best I can do is that, and then, and then, you can try again, which means that those payment, fees are going to be reduced significantly. That's what I wanted to, to say on the, on the, so it's, it's different from the other fees which are for the swap, and for the channel creation. Those fees, they are used So there are basically zero point five percent from, for the when you, when you receive an incoming payment, which covers the cost for us to cre- to open a channel, so which means opening a, a Bitcoin transac- creating a Bitcoin transaction on the, on the blockchain. And the swapping is the same because swapping it implies creating a new channel in the way we have implemented it, so it's the same thing. And, so that's zero point five percent.

    Yep, got it. So then basically, if somebody is funding it for a hundred dollars with an on-chain transaction, that will cost about fifty 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?

    Yes, I mean, obviously yes, the network minus fee is going to, I mean, what you pay is the minus fee. What I, what, I was, About to say is that it depends on the actual fee rate of 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 UT-UTXOs, which can be the case because we manage a, a, a decent number of channels, then, it might cost, significant, significantly, not because the fee rate is, currently high, but because that's what our wallet, is looking, is, is, That's the state of our UTXOs at the time of the swap.

    Yeah, got it. So, so to summarize then, it's basically the minor fee and also the, you know, ACINQ's wallet, because depending on the number of UTXOs available, that, you know, it might be more or less easy to do that, on-chain transaction.

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

    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 PP by making a payment to my, 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, 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.

    Yes. I mean, we don't Because what is working for us, it's, it's one part of, ear- earlier in the discussion, I said that there was a lot of engineering in the background to make Phoenix really seamless. AMP is, is, part of that engineering. it's one of the building blocks. When you, when you have it, it seems sim-

    And it disappears completely from your mind, it just works, but when you, when you don't have it, it's, it's really, it's basically impossible to, to know how you can spend your, your funds.

    So, there isn't much to say about it. It's just that even if in the background you may have, depending on how you have used your wallet, depending on how you are spending it, you may have one or ten channels, it doesn't matter at all. you can spend it, like if it was one big channel. And the important part, the, the, the catch twenty two 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's not, it sounds a technical thing, but it has a 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, then you don't have, it's not linear anymore. It doesn't, 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 gonna have two times a reserve and you can't, you, you- It, it's not, it, it, you won't be able to spend from zero to the sum of both of your channels seamlessly. 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. Phoenix users than the opposite, because our node still has to maintain a, a standard reserve. So we always have something at stake, whereas Phoenix users don't always have something at stake, and we, we did that because we, we know that if people try to cheat We are gonna be able to, to notice that on the blockchain and we're still gonna be able to get our funds back.

    Gotcha. Yeah, so I guess, the way to understand that for listeners is basically, in this case, Async 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 Async has to now watch the blockchain to make sure there are no cheating attempts, right?

    It, it, no, it's, it's not that we're taking the risk on behalf of the customer. It So, so in the, in the, a, a 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 gonna 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, 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 the, the, the punishment, mechanism works in Lightning is that The, 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 even if it tries to cheat. So what, what we did is that since Phoenix users don't have a, a, a reserve, there may be, cases where they could try to publish a revoked transaction. That's, that's so it's not that we are taking the risk on their behalf. It's just we are taking a risk deliberately to, ensure that the, the UX is good for Phoenix users.

    Gotcha. Yeah, sorry, I, 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 A sync 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, you know, how you're thinking about that from a privacy point of view and then potentially, lead into what trampoline routing is?

    Okay. So, so, so there is a, a difference between, so we have done a, a, several, trials. There is difference between The trade-offs that I mentioned, we got, we got two swaps, which to us just makes sense, and it's unless, there is some new ideas, those trade-offs are going to stay, in the foreseeable future. Like, yes, if you do a swap, you're gonna have to trust us because we don't have a better way to do it. There's, there's, there's a difference between that and our current Torpor implementation, which is just Which limitations are just because it's not a final version. Just wanna start with that because to us it makes a big difference between the persistent traders and those which we believe, are temporary. So what happens is that When you make a payment on Lightning, on a Phoenix, on Lightning from a Phoenix, you delegate the calculation of the route to a Trampoline node. In the current implementation of Phoenix, this Torporino is our node, it's the ASIC node. So basically what, what you do is you send an HLC, and in the next hop, I mean, I, I'm, 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, it's some remote node, it's actually the destination. So this implies that we know what payments, what amount you're paying, and we know the destination of the node. We also know, your ID obviously because you're talking, to, to, to us. So from, from that perspective, Phoenix in its current version, it offers no-- it's exactly the same, and we have exactly the same information as if we were a hosted, Lightning wallet provider. So that's the state of Phoenix right now. It's, if we released it that way, it's because we know that it's not gonna be, the case, in the future. So how does, Torporin works in the, in the, in a fully deployed setup? You have, instead of having only one Torporin node, you have a multitude of Torporin nodes in the network, and Phoenix knows a number, a decent number of Torporin nodes. You don't have to know all of them, but you need to know, I don't know, maybe a hundred 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, a hundred Torporin nodes, he can Randomly pick,

    Torpori nodes within that set and do a route that goes through all those Torpori nodes and that the last, hop in the route will be the destination, which means that From the point of view of a Torporin 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, and you don't know where you are in the route. The goal is to have exactly, the s-exact, exactly that. If you will, it's like instead of doing source routing, Between 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 hub. So, in- In theory, the privacy that you can have with this scheme, I mean, our, what we believe is that it's at least equal to what we have currently Because if 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 public channels. And Mobile devices they have to sync this routing table. At some point, they're not gonna be able to sync the whole routing table, right? So they have, they will have to prune it, but they will have to prune it in a way that That's r- makes, that reasonably makes sure that they can reach, anyone in the network. And there is a good chance that this, these heuristics will, will, result in a lot of, mobile devices having the same pruned view of the graph. You know, i-is, does, does that make sense what I'm saying?

    Yeah, yeah, yeah. So, and there could be potentially a privacy implication of that, right? That they don't, you know, if there's only, say, basically limits the potential ways that you could have routed it through. And part of Lightning, you know, one of the ideas that even from a recent interview with Rusty was saying, is this 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, w-roughly where that person, was routing the payment from.

    Exactly. So my, my, my point is that with the current routing scheme, we could argue that, from the, from the point of view of, the random walk, target, we are gonna hit a wall with the current way of doing it. routing. With Trampoline, suppose there are a lot of Trampoline nodes on the network, then you can select a subset, a random subset of, of these, Of, of, of those, trampoline nodes. You don't have to have a complicated arithmetics to be able to make sure that you, you will still be able to reach whatever, pay, whoever, pay you want to, to reach. You just take a random subset of, trampoline nodes, which allows you then, which allows your, your payment routes to look much more like a random walk, so because you don't have to have a, a very, Complex heuristics that guarantees that, yes, you are pruning a view of the network, but it's still, you'll still be able to, to find, the destination that you want to find.

    Yeah.

    So, bottom line is that it's, it's, it's absolutely true that the current implementation of, Torpor in the way we have done it in Phoenix, it does leak payment information to, I wanna, that's true. But, it's not a property of Torpor, it's just a property of the way we have implemented it currently.

    Yeah. And, I guess, I was looking through some of the Lightning spec discussion and I noticed, T-Bast from your team, was discussing There was this idea, and there was a little bit of feedback from, some others like Matt Corallo and Z-Man, right? And I think Matt Corallo's, sorry, Matt Corallo's concern was something like, you know, 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 wanna help the clients reduce their route map size because that might be taking a step backwards in Lightning from a privacy perspective. So I guess that's kind of a, a bit of a debate that

    It is a debate, and the, the argument that I just made are, are basically the same that, Bastien did on the, on the, on the, on the request. And, I mean 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, for everyone. We, we still have to convince others. We are pretty sure that, it's a good, way to, to, 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.

    Yeah. Yeah, yeah. So, hopefully, you know, yeah, we can see what happens with that and, I, I think, they're, they're probably the key points that I was keen to-- Oh, one other point around, Phoenix and the seed. So, with the seed, i-is it basically just a bip thirty-nine seed on the bip eighty-four, like the B- you know, the B32, yes,

    yes,

    that's, yeah.

    If, so in terms

    of recovery?

    so what happens is that when you have a lightning channel, what, what, what it means to have a lightning channel is basically to, to hold

    that's, represent-represents the current state of the, of the, the channel. This commitment transaction is, is to be published on chain if something wrong happens. And what you, what your seed protects, protects is the, the, the, the address that this Commitment transaction pays too. So just having the seed, if the commitment transaction is published, just having the seed is enough to recover your funds. And what, what we have been careful to, to do is to follow the same, path as a standard Bitcoin wallets, so you can use-- we, we actually recommend using Electrum when you want to, to recover your funds if something, if something happens And the, the common topic, the, the channel gets forced closed. It shouldn't happen, with, Phoenix or very, very rarely, much re- much, more rarely than, for, Eclair Mobile, for example. but it, it, it can happen, can definitely happen. We had one user, we had a bug that we, that's, fixed in the last version of Phoenix that caused, in, in a very rare case, but that caused, channel to be forced closed, and the From, enter the seed and boom, the funds were there. He was able to just swap them in to his new Phoenix wallet. So, yeah, just, w-we're following the, the bit, thirty-nine, bit eighty-four, and it's paid to a regular ASIC with us.

    Excellent. and let's talk a little bit about Eclair. So as I understand, Eclair, sorry, Eclair Mobile, I should say, which was the first, your first, Lightning wallet, and my understanding is you're still maintaining Eclair Mobile? File as well, and, that, that is seen more like a power user or developer or enthusiast wallet, correct?

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

    Excellent. look, 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, right? Because, you see all sorts of different numbers, right? Like if you look at the Lightning Network paper, it says like millions of transactions per second, and I think once you consider actual hardware limitations and things, it might be like per node, it might be something closer to like a hundred 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,

    Yeah, on the performance side, to me there is no limitation, because it's a completely horizontal scaling issue. There is, even if you have hardware performance limitation, you can still, 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, it can be, it, it can be useful. To me, there is-- on the, on the throughput, from the throughput point of view, there is no limitation. I don't see why there would be a limitation. On the total number of nodes, I think the- This is related to, the tr- the discussion that we had about, trampolining. The limitation is going to be for end, like leaves, therefore, And points to, finer routes in this network. And, the first, nice things, were private channels, and we may need to go, To go, further than that, we believe that Taproot is the appropriate way to, to, to work on that, but there may be, other ways. That's, I, I believe that's gonna be the main, limitations, limit-limitations for, for, technical limitations, I mean, for, for the number of nodes.

    Yeah. and, I had one other question as well, which was just around centralization on the Lightning Network and permissioning, right? So, I, I was curious to get your view on if you think Lightning- Because if you listen to a skeptic, right now, again, I'm, I'm, I'm bullish on Lightning, right? But if you listen to a skeptic, they might say something like, "Oh, look, it's gonna end up being really permissioned, and there's just gonna be a bunch of big nodes that become hubs, and you have to go through them, and that will impinge on the permissionless, you know, censorship-resistant nature of Lightning." What's your take on that?

    Well, two, two things. first thing, there are going to be large nodes.

    it's, it's obvious, that if you have like exchanges, we, we have seen, recently we have seen, Bitstamp and, Bitfinex, Run a node, if Lightning is to succeed, obviously, large companies, will have large hubs, large nodes. It's, it's obvious. I think what's, important is we'll still be, possible, feasible, to run, a node if you're not, if you're- If, if you're not, if you're on a small node, that's-- I think that's the proper way to, to, 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 you have the guarantees that you want to have, if you want to bypass those nodes completely. It's, it's really important to be able to bypass those nodes. so that's, that's why, I don't, I don't see an immediate issue with that. like if you compare to mining If you compare to mining, you can't make, I don't know, ten thousand or a hundred thousand dollars investment and, become a miner. You can't do it. The, the price, the price to entry are too high. But It's not the same with Lightning. You can start, you can run a Lightning node, even if you have, not,

    billions of dollars, and you still be able, like, if you want to pay,

    someone that some large hub doesn't want, don't want you to pay, you can still bypass that, that, large hub. So I think that's essential, w-with regard to, to the basic properties of Bitcoin that we absolutely want to preserve with, Lightning. But that's actually on only a part of a more general point of- If Lightning is to succeed, will it be centralized? Will it be permissioned? I think it can't succeed if it's permissioned, because it's, it's really all or nothing. I mean, from my point of view, when you design a, a protocol like, like Lightning, which is- Complicated, it's complex, it's costly to develop and to, I mean, it's basically what we are doing is working around the, the, the hard limitation that's, the, that we have, when we work on, on Bitcoin Well, it's a very limited space. What, what can we do to take, to make the best of it? So it has a cost, and we have to have properties that Justifies that, that, this, that we pay that, that, that cost. So if we don't have those properties and if it's more expensive than a centralized payment system like, I don't know, PayPal, then it doesn't, it just doesn't make sense and so it's not gonna succeed. So, to me, is either Lightning, keeps, the The, the properties that Bitcoin offers, and then maybe it can succeed. If there are other, potential way it can fail, maybe it, maybe someone find, find a flaw or maybe I don't know, but I- it- It's a, it's a requirement, or it can, it can't, protect those, properties. In, in that case, it's not gonna be competitive anyway compared to centralized services, so it has no way of, of 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, you know, replenish a channel, then are they now more dependent on there being enough submarine swap or just trusted swap providers to allow them to, you know, basically manage their channel balance? Or do you see it like maybe- Some of the technical innovations coming and, you know, MPP and some of these other things might, you know, lessen the need for that kind of thing.

    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 NPP will have an impact on the more, like the, the bigger picture of what's going on with liquidity. Yeah. I'm not really, convinced that things like channel rebalancing are going to, help a lot, because, I mean, it depends how you, how you, what the scope of it is. If by rebalancing you mean going to the chain Then of course it can, it, it, it will help because it means you're getting out of the Lightning Network and going back to the Lightning Network, so you can, basically that's what, that's what it does when you, when you go, on-chain. So then if there are some, Some, pay-payments that always go, in one direction, then you can, cut that off, and then, pull back, put back, real liquid liquidity. What I think is that we don't know yet, there are a lot of unknowns. I mean, there are a lot of unknowns in Bitcoin in general and in ACINQ in particular. we don't know what the The overall flow of payments will look like, and this will have a big impact on the liquidity needs. For example, if, you have like- A, a huge, but, Amazon, Amazon is, accepting, Lightning. Is it, is it, is it gonna be a big problem regarding liquidity? I don't think so. Because if, Amazon runs a node, they are gonna, 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, that, that see that there will be an opportunity to, to route payment to, Amazon, which will provide that liquidity. So, what Amazon will do is just wait for their channels to, to be full and then close them and get back that, the funds on chain and do whatever they want to. Maybe they're gonna refund some clients sometimes, so maybe they're gonna, 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 w- you may want to, receive funds and, that's what of the, of the, of the task, of the harder task we had, on, on Phoenix, but I think over, the, the overall, you're gonna get paid, you're gonna have your salary or something, every now and then, and every day you make payments. And this doesn't-- 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's more or less equally, then yes, they have, they will have to, to have enough liquidity. they will have to have enough liquidity on both sides, and they can decide who they allocate their funds to, but they can't decide who, they can't tell people to open channels to them, or they have to have some- There, there has to be some good reason for that. So, routing nodes will be limited. They, 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, and the exchanges are offline, routing nodes are online. So, That by the way will be also, probably a limiting factor to, the, the size of, routing nodes. So I don't To me, it's not this liquidity, thing. It's not the most, pressing issue, p-provided that the, the- For me, the, the, the most, 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. I mean, at least it's, it's way, after the, the routing, part, in my opinion.

    Got it. Yeah, no, that's a really good, a really good, reflections there. I suppose, just to finish it off then, what are you more, what are you most excited about for twenty twenty with Bitcoin and Lightning just generally? Is there anything you're particularly looking forward to or that you're hoping we get in twenty twenty?

    Well, as a, as someone who, who's most interested in, in building software as opposed to trading, I'm not following the, the price of Bitcoin a lot, but obviously, I'm looking forward to

    it's, I, I think it's, I mean, everybody says that, and I, I think it's really true. It's, it was really nice to be able to have a, a period of time when, when things were more quiet so that we could, build what we have to, to, to build, more peacefully. so the, this halving thing kind of contradicts that. I, I hope we still be, I, I mean, I don't really want to see the craziness of- For 2017. And, but it's exciting too because we have Lightning now, we don't, we didn't have it in 2017. And, what's pretty interesting is that if this halving, creates a new, you-- a euphoria, I mean, a new influx of users Will we be ready, will the Lightning Network be ready? I mean, Phoenix can be one answer to that, is the network as a whole, reliable enough to, to handle more users? I think that's an open question. I think it's, we are very early, so it's gonna be, if that happens, it's gonna be a big test. So that's from the Bitcoin, I mean, Bitcoin and Lightning point of view, and also, on, on the purely Lightning part. We had this, this, meeting in, Australia actually, in Adelaide, end of 2018, in which we discussed the, the next, Features, main features of Lightning. We are AMP was one of those features, but we are only, we have, we are not done yet, so we are still in the process of implementing all of those and, There is, dual funding, and also splicing, splicing out, there are a lot of things which are very exciting. They take a long time to develop. It's, it, I, I, I feel it's like it, it must

    feel, even longer for users because they don't even know when, when that's gonna happen. We mostly don't, not,

    we're not sure, either, but, yeah, there are a lot of things that are in the pipe. I think the, the, the, the transition from Lightning UX in 2018 and the Lightning UX in 2019 nineteen and twenty shows that there are a lot of things that we can do, on the protocol side to, to, to, to actually improve, user experience, on the, on the, for, for end users, and it's not gonna stop. So for people who, who were, afraid that it would, it would never be possible to have the same, I mean, a decent UX on Lightning, a decent, an easy way to, to, to, To receive our cents on Lightning, I think the recent developments show that, there are a lot of, improvement that we can do, and they show also that there are, there are a lot of future, even, further improvement that we can, we can make. So it's a lot of, A lot of work, but a lot of, interesting perspectives for, for ACINQ.

    Yeah, and look, I've gotta 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, I've found it really, really impressive to, just play around with the app. And, I mean, I, I've played around with Lightning apps, and this one was really impressive, so I could definitely see myself being able to help, if, if I wanted to

    look, I guess as we close it out, just make sure you let the listeners know where can they, find, you know, you online, where can they find ACINQ, and, where can they download Phoenix? Oh, and also, Phoenix for the iPhone as well.

    Yeah, well, in 2020, one of the-- We are working on it. for now, we have only, released, Android, apps. ACINQ Mobile was Android, Phoenix currently is Android, but

    A big next step, for Phoenix in two-thousand twenty. So, yeah, our website is acinq dot co, there is a dedicated, landing page for Phoenix, which is phoenix dot acinq dot co. all our software, our server node, Eclair Mobile, Phoenix, Strike, all of those, they run on our Eclair stack, which is an implementation of, a full implementation of Lightning, written in Scala, our GitHub is It's, it's, it's on GitHub.

    all our, mobile applications are, are open source. They, it's, Eclair Mobile and Phoenix on GitHub, and you're welcome to, to contribute. For developers, we, we prefer using GitLab, so it's on our Eclair GitHub, there is a link to our GitLab page, and, for support, in 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.

    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.

    Great to, to talk with you, Stefan.

    So I hope you found that useful. And obviously, if you're a Lightning hardcore purist, you'll run your own stack with your own LND and Zap or Zeus, etcetera. However, I think for a newbie or a newcomer to Bitcoin and Lightning, this is a great wallet to set them up with. And if you need to do a demonstration at a Bitcoin meetup or with your family and friends, this is a great one to try because it's non-custodial and it's extremely quick to set up. There's a real wow factor when you demonstrate this for people and then get them to As well. So give that a try. I hope you enjoyed it. Check out my website at stephanlivera dot com. Also, just a quick note for Patreon supporters, I'm gonna start now putting up the ad-free version of the show and early for those people as well. So thanks, and I'll see you in the citadels.