{
  "episodeId": "SLP9",
  "speakers": {
    "stephan": {
      "name": "Stephan Livera",
      "role": "host",
      "tag": "STEPHAN"
    },
    "bryan_vu": {
      "name": "Bryan Vu",
      "role": "guest",
      "tag": "BRYAN"
    }
  },
  "segments": [
    {
      "speaker": "stephan",
      "time": "00:02",
      "start": 1.56,
      "text": "Hey guys, welcome to Stephan Livera podcast episode nine, and my guest today is Bryan. Thanks, thanks for coming on, Bryan."
    },
    {
      "speaker": "bryan_vu",
      "time": "00:11",
      "start": 10.62,
      "text": "Thanks, Stefan. You've had a lot of great guests so far, and I'm definitely happy to, join and talk a little bit about Lightning."
    },
    {
      "speaker": "stephan",
      "time": "00:18",
      "start": 17.77,
      "text": "Excellent, excellent. So I'll just quickly intro you for the listeners. Guys, Bryan Vu, he is the VP of Product at Lightning Labs. he previously worked at Google. He got into Bitcoin, in the earlier days, around 2011. He joined Lightning Labs about two years ago. and just for a bit of background for anyone who's a bit newer, Lightning Labs is one of the three Lightning- Implementations, and Brian, you've also got a, a very, cool Twitter account, b v u, a three letter, so definitely, Twitter OG."
    },
    {
      "speaker": "bryan_vu",
      "time": "00:50",
      "start": 50.26,
      "text": "Yeah, I was, I was early on at Twitter, even though I actually don't use it very much."
    },
    {
      "speaker": "stephan",
      "time": "00:56",
      "start": 55.78,
      "text": "Very nice, perfect for when you launch your own ICO. B V U coin."
    },
    {
      "speaker": "bryan_vu",
      "time": "01:00",
      "start": 59.69,
      "text": "Yes, perfect."
    },
    {
      "speaker": "stephan",
      "time": "01:01",
      "start": 60.99,
      "text": "Yeah. Okay, excellent. So anyway, guys, I wanted to invite Bryan on and discuss some of the articles that he wrote on the Lightning Labs blog and just sketch out a vision of what Lightning Network could look like in future years. So we're gonna try and pitch this discussion at people who know what Bitcoin is but aren't super in the detail on Lightning Network and try and help make that a little bit more real for everyone. So Bryan's articles, he-- one of them that we'll start with is \"Lightning User Experience: A Day in the Life of Carol.\" so Bryan, maybe, you wanna discuss a little bit on that article in terms of onboarding?"
    },
    {
      "speaker": "bryan_vu",
      "time": "01:42",
      "start": 101.69,
      "text": "Yeah, so, in the article itself, we talk about the Autopilot process, and that's essentially the very first thing a user will do when they open their Lightning wallet for the first time. They will use that process to move funds from their on-chain Bitcoin addresses into Lightning channels, from where they can, conduct tra-transactions much more quickly, and cheaply. the other thing to note about Autopilot is it's in a pretty early stage, so Autopilot can have a variety of- Variety of different heuristics that talk about, or that, that look at a node's uptime, a lo-a node's, success rate at routing payments, capital, availability, et cetera. And, currently, Autopilot doesn't do, as much as we expect it to in the, in the relatively near term, but it's, it's a very, you know, sort of nascent state of onboarding right now, but that's going to be improved pretty dramatically over the next, you know,"
    },
    {
      "speaker": "stephan",
      "time": "02:39",
      "start": 159.21,
      "text": "Yeah, cool, cool. yeah, so I guess this is sort of like as you're just starting with Lightning and you might, you might get this app, and the idea is obviously that we want the app to- Kind of do things in the background for the user so they don't have to manually manage them. but if that, if that does happen, are there any risks around autopilot doing sort of quote-unquote bad channel management? Like, is there a risk that maybe it puts, you know, too much into a channel with the wrong or a dead node?"
    },
    {
      "speaker": "bryan_vu",
      "time": "03:11",
      "start": 190.57,
      "text": "Yeah, there's, there is definitely that risk, especially with the current, version of Autopilot. However, as we develop the routing network itself, I mean, one of the reasons why, there is this, you know, significant potential for that to happen with the current implementation of Autopilot is that we don't actually have routing nodes on the network at all yet. So, or at least we haven't written the routing node software. And so, or we haven't released it, let's say. because of that, a lot of the heuristics that we plan to use for autopilot aren't readily available to the apps. but as we build out the routing network, we've got a few engineers working, you know, hard on that, currently, that autopilot experience will get a lot more reliable, a lot more, you know, it should actually get quite a bit faster. We've, even since I wrote the post, we think we can get the initial"
    },
    {
      "speaker": "bryan_vu",
      "time": "04:02",
      "start": 242.43,
      "text": "20 minutes max, for initial, first channel and first transactions. so I think that, there is that potential, and then there is the case where Autopilot would have to manage that as well. So in case, for example, one of your gateway routing nodes-- and I think we'll get into, you know, the discussion of all those distinctions later-- but if one of your gateway routing nodes goes down for whatever reason or they don't have enough capital to route your payment, and that happens consistently, Autopilot will Close that channel and open channels with, other gateway nodes. But as, as the, as the routing network evolves over time and we have more information about which gateway nodes are reliable, the system itself should become very, very, transparent and seamless to the user. Of course, like the whole concept is we don't want the user to even know that there is such a thing as autopilot. They should just know that they have some funds and their wallet is taking care of onboarding them to the Lightning Network and, you know, they can just go buy whatever they want."
    },
    {
      "speaker": "stephan",
      "time": "05:02",
      "start": 301.66,
      "text": "Oh, that's quite interesting actually. So it won't necessarily say, \"Oh, hey Brian, you have five channels open and you have, you know, X, Y, Z amount of Bitcoin in each one.\" Would it just show some-- Is the idea that it would just show you a total?"
    },
    {
      "speaker": "bryan_vu",
      "time": "05:16",
      "start": 316.01,
      "text": "Yes, yeah. So currently, our app, which, is being written by a couple engineers, Tancred Hayes and, Valentin Wallace, we're about to, to launch-- we're in the process of launching a early version of that. it basically, shows just the, the total balance, and our goal is really that that's all the user needs to know. They just need to know how much Bitcoin they have and that they can send it immediately wherever they want to."
    },
    {
      "speaker": "stephan",
      "time": "05:42",
      "start": 342.24,
      "text": "Yeah, that's really clever. Okay, I like that. and then what are the key differences with the light client Neutrino protocol to call out?"
    },
    {
      "speaker": "bryan_vu",
      "time": "05:52",
      "start": 352.21,
      "text": "Yeah. so Neutrino is essentially, the way that we'll be able to run Lightning nodes and Bitcoin nodes in general on mobile phones. it's a pretty significant improvement in terms of privacy and resource usage over the existing, simplified payment verification that, that Satoshi came out with, and that, Mike Kearon and Matt Carallo specified in, in BIP thirty-seven. it's-- the differences are a little bit technical, but essentially, With, BIP thirty-seven, you're giving a full node a list of addresses, and that full node is, is, responding with information about transactions related to those addresses. With Neutrino, there's essentially a compressed list of transactions within each block, and that is, that, that entire compressed list is sent to the, to the mobile app, and the mobile app can decide which blocks it's interested in. So, I don't know if it's totally clear from that explanation, but, in, in the Neutrino case, the full node has much, much less information about which transactions the mobile node, is interested in."
    },
    {
      "speaker": "stephan",
      "time": "07:02",
      "start": 421.9,
      "text": "Okay, yeah, cool, cool. Now, I think, I think it's a fascinating, you know, it's a fascinating technology, and it's really just really cool to see the way this is all building out over time. And obviously, this, we're, you know, we're in early days, it's very sort of speculative, but, I think there's some real potential to improve The way we use Bitcoin. okay, so then the next section that you go into is kind of hypothetically, if Carol were to then go to the mall and try and buy something using her Lightning smartphone app. And so, do you have any comments on how maybe the, the regular buying experience while you're out in a brick and mortar store might change or improve?"
    },
    {
      "speaker": "bryan_vu",
      "time": "07:45",
      "start": 465.32,
      "text": "Yeah, I think, I think there's, it's definitely going to be some pretty major improvements over, existing, you know, on-chain transactions where you've gotta wait for confirmations and, and that sort of thing. In, in the, Lightning case, essentially you'll go to your store, the store will generate an invoice for you, that will have the amount that you're, you're, being requested to pay and some details about the products you're buying. You'll scan that with your phone, you'll You'll click confirm, and that's it. so I think that, you know, the new term vision is, is, that the experience will be something similar to using, like, my Starbucks app when I go buy coffee, there's basically a QR code scanning and a confirmation process. eventually, we hope that we'll be able to, make that into an NFC, type thing, so it'll be like an Apple Pay, you'll just kind of tap and confirm. but, you know, it should be easier than, you"
    },
    {
      "speaker": "stephan",
      "time": "08:47",
      "start": 526.74,
      "text": "Yeah, no, that sounds great. Okay. and then do you want to comment a little bit on the potential for routing failures? Now, I guess, I'll say there was some recent discussion about this, and I know that there were some kind of safety precautions put in at the start of Lightning Network, like the amount that you can place in a channel and so on. but still the conversation is worth having. Do you have any, comments on that?"
    },
    {
      "speaker": "bryan_vu",
      "time": "09:12",
      "start": 551.9,
      "text": "Yeah, absolutely. I think that one of the things that, maybe folks in the community in general don't, don't quite know, and it's, it's very early in, in terms of where we are with Lightning, but as I mentioned, a few minutes ago, there's no-- we actually have not, released the routing node software, So, the way that the routing nodes, the few routing nodes that there are, is connected, are connected, isn't necessarily, in the most, structured way at this point. And what we, what we expect is that routing nodes will, will be running a set of rules that tell them, which other nodes are, are reliable to connect to, and they themselves will also, understand which nodes they should be accepting connections from. They will also d-need to do things like managing, fee rates. They'll need to- To do things like managing their capital, ratio. So, we're writing software that basically, handles all that, all those rules for them. There's a bunch of other things around like metrics and a few other things like that that routing node operators will need, but that doesn't exist currently. So when people are routing payments, in the network today, it's, it's, you know, kind of haphazard, and it will be a lot, lot better once we actually have routing node software out there. So I would say that, you know, we've, we've kind of, you know, made a lot of progress on the, you know, the underlying protocol implementations, you know, obviously Lightning Labs, see Lightning from Blockstream and, Eclair from Aysync. But, we have not yet built the software that, that runs on top of those, protocol implementations, and that's the routing node software and, you know, there's some client software out there, you know, we're, we're kind of early on in our own You know, the routing network is, is, not going to be nearly as reliable and, as robust as it will eventually be. so that's one thing I was trying to get, get at with, with the following post, about routing, but, currently, you know, there's, you know, all kinds of potential for routing, for routing failures, especially for larger payments. there's another concept called atomic multi-path payments, which we can talk about a little more detail, as well. It's, Massively improve the routing experience, but, you know, we basically haven't even really started trying to, to complete the routing, solution at this point."
    },
    {
      "speaker": "stephan",
      "time": "11:33",
      "start": 692.53,
      "text": "Cool, cool. Okay. I suppose just while we're on that topic of routing and the, the-- and the, there are the three different implementations, would it be that each of the three teams would have their own routing node software or, a-and it's kind, kind of all interoperable or what, how, what's the sort of plan with that?"
    },
    {
      "speaker": "bryan_vu",
      "time": "11:53",
      "start": 712.62,
      "text": "Yeah, that's a good question. I would say that, we actually haven't talked that much about routing with, with the other teams just because there is so much work and there has been so much work to be done on the, the base protocol implementation. I think that, I'm not actually sure if the other teams are planning to build their own routing software or, you know, obviously the routing software will be interoperable and it doesn't know Whether the end user or the merchant is using C-Lightning or Eclair or, LND, so, you know, our routing node software, of course, will work with, with any of the implementations. I think that, you know, as we move further along, I would like to have, more in-depth conversations with the other implementations about our ideas for, you know, how we'll set up our routing rules, but, that's, you know, it's still very early days on that."
    },
    {
      "speaker": "stephan",
      "time": "12:42",
      "start": 762.39,
      "text": "Yeah, cool, cool. No, I like that. very interesting, a-aspect of how this is all going to develop out. Okay, so I think the next area to, to discuss is a-around merchant benefits. So We're, we're starting to see some more, more and more discussion around what the benefits of Lightning will be, even on the merchant side. So obviously the, the first step would just be it's even cheaper fees, right? So with Lightning, sometimes the fee, well, often the fee is even less than one cent. So that's, you know, really, a really good result for the merchants. And also from his talk at Building on Bitcoin, July two thousand and eighteen, Sergey Kotlyar, who is the CEO of Bitrue He made a few comments around how Lightning Network can help restart or, or give a fresh start to many of the pain points and problems that people experience trying to use Bitcoin Layer 1 payments. Do you wanna comment a little bit on that, on the benefits for merchants?"
    },
    {
      "speaker": "bryan_vu",
      "time": "13:42",
      "start": 822.3,
      "text": "Yeah, yeah, and, I watched Sergei's talk and it was, it was a great talk. I think there's a lot of good insights in that talk. I think, one of the things that he touched on, is, is that idea of how Lightning is invoice, invoice based, rather than, I guess, Bitcoin's address based, where you just, kind of send to a, a payment anon- an address anonymously. Or I guess without any kind of tracking. I think that's a big benefit for the merchants, in that, they, they know which payment is attached to, you know, which specific transaction, and so that they can handle things like refunds, they can handle things like, making sure that, you know, there's not, two payments from the same person, et cetera. So I think the invoice, invoice based model is, is a big plus of Lightning, and a lot of, Bitcoiners don't kind of realize that. They think, \"Oh, you know, Lightning should be, should work like Bitcoin addressing.\" but I actually think that that is a, is definitely a, a, a worse experience, especially for the merchants, than, what we have with, with Lightning. I think that another thing, you know, like you mentioned, the fees are, are gonna be lower. So again And by the way, I, I'm really thankful to Sergey and, Justin Kimarena, who, who work at Bitrefill for being very, forward-thinking and way ahead of the ball. I talked with, you know, Sergey before our, our release and, and they were just, ready to go, they had everything integrated, way ahead of time. But, the other thing, that I think, you know, obviously, you know, Bitcoiners probably know the fraud argument with, you know, of course, Lightning And I think another thing that will hopefully, improve about the merchant experience is that, currently I, I think I probably have, you know, eight to ten different credit cards, all the different, credit cards I have to use for groceries versus gas, you know, versus different department stores. and I have to manage all these different point systems. and then the merchants themselves, they have to game the system, the credit card system, by offering their own store credit cards, and every time I go to the store, they'd wanna try to get me to"
    },
    {
      "speaker": "bryan_vu",
      "time": "15:53",
      "start": 953.46,
      "text": "Wasted effort, that's the result of the structure of the credit card, fee system. So I think that, you know, in an ideal world, if, if payments are very straightforward, very cheap, you know, merchants can, can lower their prices a little bit and, we don't have to do all this kind of, gaming stuff, in order to, maximize our, our payment, returns, I guess."
    },
    {
      "speaker": "stephan",
      "time": "16:18",
      "start": 977.86,
      "text": "Fantastic point, Brian. I really like that. I think, that's something people have Yet that will come in with the impact of having really, really low fees and really reliable fees that don't require the sort of old world, payment rails, if you will, or and all the, the associated gaming that happens with that. Great points. Yeah, and I think it also even provides additional privacy as well, so that's another, great benefit for the merchants."
    },
    {
      "speaker": "bryan_vu",
      "time": "16:47",
      "start": 1007.41,
      "text": "Yeah, yeah, absolutely."
    },
    {
      "speaker": "stephan",
      "time": "16:49",
      "start": 1009.37,
      "text": "Okay. okay, so how about ex- the, interaction between Lightning Network and the main chain? So in this example, you walked through how Carol might refill her Lightning wallet using an exchange. So could you sort of outline that process a little bit and then just talk about if there's any examples of it?"
    },
    {
      "speaker": "bryan_vu",
      "time": "17:14",
      "start": 1033.51,
      "text": "Yeah, so, we've worked with a few exchanges and there's definitely a lot of interest, from exchanges in integrating with Lightning. there's definitely engineering work going on, internally at a few, exchanges. And, the essential concept is that You, if the exchange has Lightning channels and Carol or the end user has Lightning channels, there's really no on-chain transaction that needs to happen in order for me to move money from, let's say, my USD or, you know, Australian dollar balance into my Lightning wallet. that can happen essentially instantly. That, you know, if I have a BTC, balance in my exchange also, I can move, transition that BTC, balance directly to- To my Lightning wallet instantly as well. So once I've, you know, spent the money in my Lightning wallet, I will need to go refill it, and I can refill that using my, you know, my paycheck for my US dollars if I send that to an exchange, or if I have some BTC there, I can just, refill that wallet immediately. So, yeah, I think, that, that process should be, you know, when we get those exchange integrations, done, that should be a very seamless, Process. We have a few different ideas around some stopgap ideas, for how people can refill their channels without using an exchange, because of all the, you know, the kind of, administrative overhead asso-associated with exchanges. So you will be able to send money directly in and out from, Bitcoin addresses to Lightning channels, but, those are, those are,"
    },
    {
      "speaker": "bryan_vu",
      "time": "18:50",
      "start": 1129.58,
      "text": "you know, we basically want lightning channels to be set up in such a way that you spend and then you refill, you spend and then you refill. You're not opening and closing, opening and closing, because that, that creates a lot more on-chain transaction, traffic."
    },
    {
      "speaker": "stephan",
      "time": "19:01",
      "start": 1141.22,
      "text": "Right, yeah, that's very clever. It's a more efficient use of Bitcoin's block, blockchain, block space rather on layer one. Okay, clever. and another concept I was interested to ask about is, do you anticipate that employers would set up a Lightning channel to pay their employees, or would it kind of go through some other mechanism?"
    },
    {
      "speaker": "bryan_vu",
      "time": "19:24",
      "start": 1163.78,
      "text": "I guess there's, there's really two ways to think about that, and I think it's a really good question 'cause I, I'm not sure how it's gonna evolve. I would say that, it probably makes a difference how much the employee makes. So if the employee's maybe like an hourly paid employee or they're, they're getting paid per day or they make a relatively small amount of money, I can imagine, an employer using Lightning. if they, you know, if they're making very large amounts of money Then they probably don't wanna put all of their earnings into their Lightning wallet, so there might have to be a way for, for employers to split that money, or the employers might just pay in regular Bitcoin and leave it up to the employee to refill their Lightning channels. the, there, there could be, you know, exchanges and those kinds of things that can make all that happen without having to do a single on-chain transaction. so I think those-- there are a few different possible models, and I think, that, that is a really interesting question. I actually am"
    },
    {
      "speaker": "stephan",
      "time": "20:16",
      "start": 1216.08,
      "text": "Yeah, no, that's, yeah, just, I just thought I'd try and help make it more real for people, you know? so I guess, it's almost like if you're a baller, you can, you can take an on-chain payment, and if you're not a baller, well, it's all, you can do it all in lightning channels, and I suppose the other thing you can do is maybe tell your employer to split your payments, to say, okay, pay me, you know, twenty percent or thirty percent of my wage on, Yeah,"
    },
    {
      "speaker": "bryan_vu",
      "time": "20:48",
      "start": 1247.54,
      "text": "a lot of that has to do with, you know, how the security for phones evolves, and there's a bunch of stuff with, you know, trusted execution environments, hardware wallets, et cetera. So, it also depends on how much money people are willing to, to hold on their phones. So depending on, you know, how some of that key management technology evolves, people might be willing to hold very large amounts on their phone."
    },
    {
      "speaker": "stephan",
      "time": "21:07",
      "start": 1266.55,
      "text": "Yeah, good points, good points. Okay. And then sort of related, I guess just more broadly about this post, do you have any thoughts on the future balance of on-chain layer one payments versus off-chain? sort of payments, is there any kind of equilibrium that will met, that will be met there?"
    },
    {
      "speaker": "bryan_vu",
      "time": "21:28",
      "start": 1288.16,
      "text": "I think there will be an equilibrium at there. our CEO, Elizabeth Stark, talks about it being kind of like checking account versus savings account. So your savings, you would keep on chain, and your, day-to-day expenses, the amount that you need for your day-to-day expenses would be off-chain. and so, I think the where that equil-equilibrium, ends up going is Is, yet to be determined, like it's, actually partially, related to those security parameters we just talked about. but, you know, my ideal goal would be you could handle basically all of your day-to-day, transaction stuff with Lightning, and then you would only need to use on-chain payments for funds that you weren't gonna touch for, let's say, three months or six months or a year even, or longer. but anything less than like a three-month holding period, you would just, hold it"
    },
    {
      "speaker": "stephan",
      "time": "22:24",
      "start": 1344.06,
      "text": "makes sense. Yeah. Okay, cool. and then later on in this post, you also touch on AMP. Did you wanna, tell the guys about what AMP is and how it might work?"
    },
    {
      "speaker": "bryan_vu",
      "time": "22:35",
      "start": 1355.41,
      "text": "Yeah, yeah. this is also related to our routing, failure discussion a minute ago. I think that AMP, which stands for Atomic Multi-Path Payments, was proposed to the mailing list by one of our engineers, Connor Fromnek, a few months back. And essentially what it allows you to do is it allows you to s- split a very large payment into, lots of small payments. So it's a little bit like, on the internet, you, you wanna send a large file to somebody, you split it up into lots of sp"
    },
    {
      "speaker": "bryan_vu",
      "time": "23:05",
      "start": 1385.07,
      "text": "Receiver puts, puts it all together at the end. with AMP, routing becomes, more efficient and, you have fewer, you know, bottlenecks, et cetera. So, AMP is definitely a big part of the routing story, and I think, you know, will also improve the reliability, and speed of the network"
    },
    {
      "speaker": "stephan",
      "time": "23:24",
      "start": 1404.46,
      "text": "Yeah, fascinating stuff, hey. Okay, cool. Let's now go over to the, the second post, which is l-exploring Lightning Network routing. And so, essentially in this post, you cover a lot of different, kind of more technical topics, so let's set the context. what are the key important goals with routing?"
    },
    {
      "speaker": "bryan_vu",
      "time": "23:49",
      "start": 1429.4,
      "text": "Yeah, I think, for routing, what I was trying to get across in the post is what we really want is for the user to not have to worry about routing at all. All they know is that they see a balance in their wallet, they see a product they wanna buy, they press buy, it happens. in the background, there's a lot of different things that happen, and there's a lot of different goals that we have. one of which is we wanna make it easy for anybody to join the routing network. So if you have a little bit But of, you know, you've got good bandwidth, and can manage the uptime for that node, you should be able to start routing payments for other users. So we wanna keep it, easy to enter and exit the network. the other thing is that, over time, you know, all these routing nodes are essentially adhering to the rules that, that we talked about earlier, which are around the success, ratio and, you know, node uptime, et cetera, capital Availability. So, over time, the nodes that, are more successful at routing, they will become better and better connected and will be able to route more and more payments. They'll gain higher volumes, they'll earn more fees, and so they'll move up kind of within the network. and so I guess the, the key things are that, we want the network to be decentralized, we want the network to be, highly reliable, and we want it to be basically, very simple for, for the end user. I should also mention that, you know, people, you know, in the post I tried to address this as well, but, you know, over-- there's been this whole concept of like, \"Oh, there's gonna be this one giant lightning routing hub,\" and what I tried to explain in the post was that"
    },
    {
      "speaker": "bryan_vu",
      "time": "25:33",
      "start": 1533.47,
      "text": "If there were only just, you know, one or a few very, very large hubs, and adding the multiple hops allows, payments to be balanced out at, at multiple levels, improving, improving the capital efficiency, lowering fees, and making the network more robust, more private in the process. So, yeah, I think, you know, primarily, you know, speed, oh, of course, low fees is another goal for routing, but, you know, the fees we expect to be very, very low because there Of, machines that will need to be, involved with each transaction, and each of those machines can route, you know, millions of payments with very modest hardware and power and, and bandwidth requirements. So, as you mentioned, the fees should be, should be very low, so we're not even really, too worried about optimizing fees yet. over time, I think the routing node operators will, will naturally do that."
    },
    {
      "speaker": "stephan",
      "time": "26:28",
      "start": 1588.05,
      "text": "Yeah, great points. Okay, so, another point that you make is how, okay, so you've got channel balances in Lightning, and I like how you've outlined that there are sort of natural, inbound flows and outbound flows for the different types of users. So the end user, the consumer, say, the merchant and exchanges. Could you maybe outline some of the typical cases for each scenario?"
    },
    {
      "speaker": "bryan_vu",
      "time": "26:58",
      "start": 1618.12,
      "text": "Yeah, I think, so at, at the very, you know, the most basic level, I have my own physical wallet full of, you know, US dollars, and I can go to the store and spend a bunch of those dollars, and eventually I will have to, go to the ATM and refill my wallet. the same thing kind of happens with Lightning. So you'll create your channels, you'll spend your money, you know, you won't be, you know, handing over physical cash, but you'll be, scanning QR"
    },
    {
      "speaker": "bryan_vu",
      "time": "27:27",
      "start": 1647.46,
      "text": "Refill your, your balance, whether that's from an exchange for, you know, US dollars or, or whatever fiat you use, and, or, you know, you've got some BTC in cold storage that you wanna refill your wallet with. So at the end user level, you're kind of having to, to balance, there. Merchants also have to balance their books. So, merchants, you know, obviously it's the reverse process where they actually need to create channels, send the money out of those channels so that they can and then, their customers will, you know, so slowly fill up the channels, fill up the channels, fill up the channels, and then the merchant will have to send a transaction out to an exchange or to a supplier or to pay off employees, to give themselves additional capacity. So essentially, merchants and users, at the end of the day, they sort of have to balance their books just like they do in the, in the, you know, existing financial system. Everybody's gotta sort of balance their books, unless you can print money, But, every-- and, you know, exchanges are the same way. So exchanges, they have to, you know, they take, you know, they'll send money out to the lightning channels of users, and they'll be receiving, funds from merchants, and all those processes, should, you know, overall balance themselves out, and, they're, you know- There's a bunch of, a bunch more detail about, different ways that that balancing process happens, but, you know, generally, you know, the financial system is, is, has to be balanced overall."
    },
    {
      "speaker": "stephan",
      "time": "29:00",
      "start": 1739.5,
      "text": "Okay, cool, cool. and then, so next down in the article, you talk about this concept of gateway routing nodes, and it, it, the idea is that these are those that serve the end users. Could you outline, what the, what these are? And then we'll, we'll go into further discussion on that."
    },
    {
      "speaker": "bryan_vu",
      "time": "29:18",
      "start": 1757.52,
      "text": "Yeah, yeah, that's a good, that's a good point. and yeah, that's, that's part of one of those things that isn't that widely known in the community, partly 'cause, we have a bunch more blog posts that I've, I've been meaning to write, but, Gateway routing nodes are essentially kind of the front line of routing nodes that, end user applications will connect to. So, a gateway routing node is maybe, a relatively new routing node, they don't have that much connectivity yet, and so they're accepting inbound channel requests from, you know, mobile phone users or PC users, and they're routing payments, through the network for those, those end- And users. As a routing node, sort of over time, they gain a history of having high uptime, having high routing success, having enough capital on hand, they may, decide to add more capital and potentially become, a bridge node, which is kind of like a routing node for routing nodes. but the gateway routing node is kind of that, that first, step that autopilot is connecting to, to get the user's funds into the network, initially."
    },
    {
      "speaker": "stephan",
      "time": "30:29",
      "start": 1828.67,
      "text": "Okay, got it. Okay, and then is the idea that these gateway routing nodes would be run as a business, or maybe they would just rather be run by a business with some kind of incentive to run a gateway routing node?"
    },
    {
      "speaker": "bryan_vu",
      "time": "30:47",
      "start": 1846.65,
      "text": "Yeah, I think that's a good question. I think there will likely be both. I think that a gateway routing node is really designed to be something that, you know, just enthusiasts will run. So for example, I have my, Bitcoin full node, and the, you know, kind of the overhead in terms of network costs and storage and, et cetera, should be very similar between running like a Bitcoin full node and, Gateway routing node, of course, you have to have a little bit of Bitcoin to, to put it in the network, but it shouldn't be, you know, heavily capital intensive. and so at the base level, those will be kind of, most likely just individuals. as the, as those individuals gain, as I said, that sort of that history of, of, you know, performing well as a routing node, they can potentially, start to increase their volumes, increase their connectivity, increase their capital. and I imagine, you know, some of those folks might end up running sort of like small businesses, and earning fees with those. but the network itself will be, you know, very highly competitive just because it is relatively easy to-- the barrier to entry gonna be very low. So, even, you know, a very well connected node has other nodes that are gonna be, you know, well connected around it, and, if they're charging too much in fees, they, they won't make much. So, I don't not enough to, you know, build some sort of giant company, but, I think, you know, potentially somebody who's very good at running routing nodes might be able to, make a little bit of money on it. and so I do think that, as you mentioned, the, you know, people like merchants or, exchanges, et cetera, will most likely run their own, well, not most likely, they may, they may decide to run their own nodes as well, but, yeah, so I think, I think there will be a combination of, you know, people who just, they wanna make sure they have reliable nodes to connect to, but, the majority of, at least the gateway level will probably be just individuals, just because I don't expect them to be very profitable."
    },
    {
      "speaker": "stephan",
      "time": "32:54",
      "start": 1974.34,
      "text": "Okay, got it, got it. Okay, cool. yeah, I think as you said, it might be, let's say, I'm a merchant and I wanna make it easy for customers to pay me, so I'll run a routing node kind of system. scenario. Okay. and then, so the next section, you talk about buffer capital, and you talk about channel exhaustion. So could you maybe outline what channel exhaustion is and then outline how- How routing nodes that don't have enough capital would get routed around?"
    },
    {
      "speaker": "bryan_vu",
      "time": "33:24",
      "start": 2003.72,
      "text": "Yeah, so channel exhaustion is what happens when, you have, if you're, let's say, a gateway routing node and you've got, let's say, five hundred, mobile phone users connected to your routing node, and they have all sent more money out than you have, dedicated to the rest, to connect to the rest of the network. Basically, it means that you have not put in enough money into your node to handle all of the users that you've accepted. and what,"
    },
    {
      "speaker": "bryan_vu",
      "time": "34:01",
      "start": 2040.58,
      "text": "What should h-happen in that case is, in the short term, if, if my app realizes that one of my routing nodes, is giving me failures for whatever reason, but let's say they run out, they've, they've exhausted their capital, it will attempt to route through another gateway routing node. So by default, Autopilot connects to five gateway routing nodes, so if one of the five is down, it'll try another one of the five. if that routing node, doesn't, increase its capital or it stays offline for other reasons, my app will disconnect it, so my autopilot will know this, routing node has been unreliable for, you know, the past few hours, it will then go through the process of reallocating, the funds to other gateway routing nodes, so it'll get routed around that way. And then further, the other routing nodes that are connected to, to that routing node will- Detect that that routing node is, you know, generating a lot of failures, and so the other routing nodes will disconnect from that routing node as well. So eventually, that routing node, if they're not-- if they don't have enough capital in the system and/or they don't have connectivity, their power is down for whatever reason, they will eventually get, taken out of the network. So, so there's a few of the things that will happen, in terms of that those, you know, poorly behaving routing nodes getting routed around."
    },
    {
      "speaker": "stephan",
      "time": "35:24",
      "start": 2123.61,
      "text": "Got it. Got it. And, I guess- to, if I understand correctly, then it's if they run out of capital, then that node operator would just simply have to find a way to get replenished?"
    },
    {
      "speaker": "bryan_vu",
      "time": "35:37",
      "start": 2137.16,
      "text": "Yes. So there's two things that node operator can-- That's a good question. Yeah. So the node operator can either, add capital so they can open new channels or, add capacity through this process of splicing, so they can, you know, they can take their on-chain BTC and move it into the Lightning Network, and, contribute that to, to their capital. Or, they can, they can refill those channels. So they can, send money in from an exchange to refill those channels, or they can send that money in from, you know, they might have another pool of capital somewhere else, or they can ask somebody for, for capital. basically, somebody has to send capital into that channel."
    },
    {
      "speaker": "stephan",
      "time": "36:15",
      "start": 2174.84,
      "text": "Okay, cool, cool. okay. And then, so then further on down, you mentioned this concept of bridge nodes, and I think i-there's a relation there between the bridge nodes and the routing nodes, but can you outline what a bridge node is and maybe what is the key distinction between that and other routing nodes?"
    },
    {
      "speaker": "bryan_vu",
      "time": "36:35",
      "start": 2194.94,
      "text": "Yeah, so really in, in the posts, there's really only two kinds of routing nodes. there might be more eventually, but, currently, I foresee there just being gateway routing nodes, which are those routing nodes that accept, connections from anonymous, users. So basically mobile phone users, PC users, basically end users. Those gateway routing nodes are also accepting What we call non-advertised channels, which means that those channels that are connected to the mobile phones aren't available for routing. So this, this is one of the other things that is very different, I think, in the current network than, than, than how the network, will work in the future, which is that, most of the channels won't be visible, in the routing, routing graph. But to get back to your question, the bridge nodes are those nodes that don't, or that are, connected, that are connecting different routing nodes to each other, and then aren't connecting, mobile phones directly or, you know, basically end users directly. So, they're more like the interior routing nodes that help facilitate the hops between routing nodes. and so over time, if you're a gateway routing node, if you perform well as a gateway routing node, other nodes will attempt to connect, connect And more of your, more of your routing will consist of payments between routing nodes, or hops between routing nodes rather than those, sort of first hops from end users or, or merchants, if that makes sense."
    },
    {
      "speaker": "stephan",
      "time": "38:06",
      "start": 2285.57,
      "text": "Yeah, got it, got it. No, I like that. It's a good explanation. Okay. Cool. and then I think the other question I had was out of What we've explained so far today in terms of the routing and the end user cons- you know, consumer experience, are there any key differences in the vision of Lightning Labs versus the others, so Blockstreams, SeeLightning, and Async?"
    },
    {
      "speaker": "bryan_vu",
      "time": "38:32",
      "start": 2312.25,
      "text": "that's a good question, and actually, I think that there, there are slight differences, I would say, a lot of differences are very technical in terms of, you know, the programming languages used. Async, I think they've moved a little bit further ahead with regard to, you know, the mobile phone apps and, the merchant, side of things. Blockstream, I think they've focused a lot on, you know, tight integration with Bitcoin Core, and those,"
    },
    {
      "speaker": "bryan_vu",
      "time": "38:59",
      "start": 2339.45,
      "text": "you know, it's, it Because at least, at least in my, the things that I'm exposed to are, are very sort of low level protocol, details with those guys. you know, major, I guess business differences other than that in terms of like long term vision haven't really emerged. So I guess I couldn't really explain, their long term vision, and they probably couldn't explain ours either. So, you know, we've been very, we've been very focused on the protocol implementations itself, which I think is the hard part, and I think we On it, but, you know, we've worked really closely with them, it's been a great collaboration, and, you know, I definitely am very interested to see what their, their visions are, are, you know, we're kind of interested to see what our own vision is, we have, we have, some pretty good ideas, but, I, I actually don't know how ours compares to theirs."
    },
    {
      "speaker": "stephan",
      "time": "39:47",
      "start": 2386.62,
      "text": "Yeah, okay, cool. Actually, out of interest, what's, what's the sort of process for collaboration? Do you guys sort of meet up once a year or just do kind of regular calls or how does that work?"
    },
    {
      "speaker": "bryan_vu",
      "time": "39:57",
      "start": 2397.45,
      "text": "Yeah, so we have a regular call, every two weeks, it's hosted by Rusty Russell of Blockstream, but, you know, Lalu OsenTokun, our, our CTO is, is a major player in there, and Fabrice, from Async, as, as, you know, represents, Async and Eclair. and so we have the, the bi-weekly call, we have, of course, the mailing list, you know, anybody's welcome to, you know You know, informally, every now and then, and, we do try to have, in-person meetings as well. So, yeah, I think, you know, it's a very collaborative process and, and, we, you know, we definitely try to, to get together when we can."
    },
    {
      "speaker": "stephan",
      "time": "40:43",
      "start": 2443.19,
      "text": "Okay, cool. Alright, and a few more, I guess, general questions. maybe you just wanna tell the guys a little bit about what watchtowers are and what the plan for development with those is."
    },
    {
      "speaker": "bryan_vu",
      "time": "40:56",
      "start": 2456.05,
      "text": "Yeah, yeah. This is, this is a good question. It's a, it's a bit of a, technical question, but definitely for those folks who have been paying attention to Lightning and, and our development, it's an important one. in Lightning, there is, there is a potential for, Nodes to behave badly, and to attempt to steal money from, the end users or merchants who are connected to them. the way that Lightning works is there's, what we call, a breach remedy transaction or, a revocation transaction that can be broadcast in the case that your, counterparty, is trying to cheat you, essentially. The watch-- the, the problem with that, of course, is, you know, you may not be online all the time. so the default is, seven days, I believe, at least in LND. so if you're, if you happen to be offline for seven days in a row, you might not notice that your counterparty is trying to cheat you. so in that case, what we call a watchtower will broadcast the, revocation or remedy transaction for you, and, and your money will be recovered and the channel will be closed. so that's, that's essentially what the watchtowers are for. you know, if we have a world, I think that, you know, in my ideal world, that should happen relatively infrequently. You know, people are online Pretty consistently these days. And, you know, I think that, you know, the game theory around trying to, steal money, the game theory around at least like a routing node trying to steal a bunch of money for, from those who are connected to it, I think are, is pretty, pretty strongly against an attempt of this, of this nature, but, we'll definitely see how it goes and, and, watchtowers may be more or less important depending on, you know, how often people come online and offline and these sort of breach attempts happen. I think there's-- I mean, I'm only aware of a few that have happened so far since we released our mainnet beta, in March. But, that's essentially Watchtowers are there to protect us from that, from that, circumstance."
    },
    {
      "speaker": "stephan",
      "time": "43:07",
      "start": 2587.46,
      "text": "Yeah. And so is the concept then that-- An individual might run their own watchtower back at home, or maybe, these routing nodes might implement a watchtower service, or how, how would that-- Do you have any ideas on how that would work?"
    },
    {
      "speaker": "bryan_vu",
      "time": "43:25",
      "start": 2605.14,
      "text": "Yeah, that's a great question. I think you, I feel like you've been following our, our GitHub repo. so Conner from Net, is currently implementing that private re- that private watchtower functionality. So that's gonna be kind of the initial iteration of watchtowers, where let's say merchant or a routing node can run their own, watchtower on a different machine. or an end user can, can run their own watchtower. over time, we wanna, you know, we're potentially going to have, a system where there will be a discovery of watchtowers, so you can pick another person to run a watchtower for you, or there could be services that run watchtowers. but the first iteration is exactly what you talked about, which is kind of, businesses or individuals running their own watchtowers."
    },
    {
      "speaker": "stephan",
      "time": "44:07",
      "start": 2647.09,
      "text": "Okay, cool, cool. Yeah, no, I was just basically speculating, thought I, thought I'd, it'd be good to understand how that works. Okay, cool. Yeah. Okay. and then, yeah. Okay. and then the next question I had was around, now maybe this is a bit more technical, but could you explain to the guys what splicing is?"
    },
    {
      "speaker": "bryan_vu",
      "time": "44:28",
      "start": 2667.63,
      "text": "yeah. So splicing, I actually, mentioned it, so that's a good, good conversation, point, 'cause I, I think I mentioned it without really explaining what it is. But it's the process of essentially resizing, a lightning channel. So let's say I join the network with five hundred dollars and autopilot opens five one hundred dollar channels for me. I later decide that I want to add another five hundred dollars, so I'll have a total of thousand dollars of capacity in the network. I can splice into those existing channels? So I can make five two hundred dollar channels, or I can, add, you know, five more one hundred dollar channels. So then I would have ten one hundred dollar channels. the one thing to know is that this is splicing is something that should really be handled behind the scenes and mostly, I think, will be cared about by routing node operators. I don't think that, end users should really have to worry about splicing. Auto pilot should take care of this whenever it's necessary for them. So if they have a particularly small channel, then splicing would be probably, would make more sense. If they already have very large channels, like, let's say, hundred dollar channels, then, it's probably better to, increase the channel diversity and, connect to, other, other gateway routing nodes. So there, there's going to be kind of a, a decision that gets made wh- about, you know, whether to splice or whether to open new channels. and, but I think that should all be automated."
    },
    {
      "speaker": "stephan",
      "time": "45:56",
      "start": 2756.46,
      "text": "Got it, got it. Okay. And I guess just technically, what's happening under the hood when you splice? Is it an on-chain transaction to do that, or how does that work?"
    },
    {
      "speaker": "bryan_vu",
      "time": "46:07",
      "start": 2767.33,
      "text": "Yeah, so, that's a, that's a good question, and I'm actually not the most, knowledgeable about that, but it is an on-chain transaction. So, it is an on-chain transa-transaction to convert,"
    },
    {
      "speaker": "bryan_vu",
      "time": "46:21",
      "start": 2781.31,
      "text": "One funding transaction to a different funding transaction. one thing to, to note about that is you can splice many channels at a time. So in the example I just gave, let's say you wanted to splice up, five different channels and add, add to them, that's only a single transaction to splice them all at once. So you can, you can splice many channels at the same time. or let's say I wanna reduce my capacity, let's say, you know, I need, I need some funds. I've got my, I've got a and I need to be on chain for, for, I need to pay somebody on chain. That could be a single splice transaction as well. So, so those are the, yeah, but it, those are on trans- on chain transactions."
    },
    {
      "speaker": "stephan",
      "time": "47:03",
      "start": 2823.32,
      "text": "Okay, cool, cool. No, that, thank you, that, that makes sense. what about backups? So let's say, Carol, you know, she set up her Lightning wallet, you know, on her smartphone app, but then she loses the, you know, she-- her phone breaks or she loses the phone. Do we have any ideas on how backups could work for them?"
    },
    {
      "speaker": "bryan_vu",
      "time": "47:29",
      "start": 2848.83,
      "text": "Yeah, yeah, great questions. so, one of the things that, we've been working on our CTO, Lalu, that I mentioned earlier, is a, a new seed format. It's called Aezed, but it allows us to, essentially have a similar backup concept to how, you know, regular Bitcoin wallets are, are backed up. So, if there's, you know, I think there's twenty-four words by default, and there's different derivations, for the different types of transactions within Lightning. so at the first level, you will want to, have that seed that allows you to basically,"
    },
    {
      "speaker": "bryan_vu",
      "time": "48:16",
      "start": 2896.43,
      "text": "recover in the case of, you know, you lose your phone or something. there's also a concept of, backups for each channel. So each time you open a new channel, you'll have to, sort of refresh your backup, and that, that is something that potentially watchtowers, could also do. so there are a couple different levels of, of backup that allow you to, and if you have that, that per-channel backup, if you, if you, if you lose your phone, you can close all of your channels. If you only have the original seed, you then have to ask your counterparties to close the channels for you. so there's, there's a few different layers of backup, and Connor is definitely, much more expert on that than I am, but, you know, the, the general concept It should be, it should, should be very similar to, backing up your regular Bitcoin wallet."
    },
    {
      "speaker": "stephan",
      "time": "49:10",
      "start": 2950.43,
      "text": "Okay, no, great, great. the next question I had was just around, you know, Lightning Network reference rate. So this concept of, you know, time value of BTC, interest rates in Lightning Network. Do you have any comments on that, Brian?"
    },
    {
      "speaker": "bryan_vu",
      "time": "49:27",
      "start": 2967.03,
      "text": "Yeah, that's a great question. I did listen to your, your conversation with Nick, and, you know, obviously he knows a lot more about finance and, and interest rates than I do, but, for me, you know, the concept that I've always had in mind in terms of the fee rates for Lightning is that those fees for routing, payments should get pushed down to, To, you know, operate their hardware, operate their software, as well as the risk to their capital, in case of, like sort of a security breach. So, the-- So I expect that those, those fee rates should, get pushed down, quite a lot. And I don't imagine that-- At least in my mind, I've never imagined that there would be a premium above those two, you know, those two costs for the routing node operators. I think that, you know, ideally over time also, you know, the security of the nodes will get better and, you know, there will be less of a, less of a need to, worry about, sort of, like, I guess, Calculating for that, that risk of, of, theft. But, I'm not, you know, the, the reference rate concept didn't entirely, you know, resonate with me just because I just don't imagine that there would be a kind of a persistent interest rate type premium. but I also have to admit that, I don't, I may not completely understand the concept. So, the, oh, the other thing that I, I thought of when I was listening to the episode was that, different routing nodes based on their varying Level of time that they've been routing and their different, history, et cetera, will have, different fee rates and different volumes, and so, you know, they're, they're also wouldn't necessarily be sort of like a globally, known, rate, which I think you guys talked about a little bit as well. so I think, I feel like there are some, some reasons why I don't think, something like the reference rate will, will necessarily emerge, but, you know, it's, it's certainly To do a little more thinking about it."
    },
    {
      "speaker": "stephan",
      "time": "51:29",
      "start": 3089.46,
      "text": "Excellent. Yeah, no, thank you. I think that makes a lot of sense. Yeah, and I think I did ask that, I did actually ask that question of, what if we aren't able to come up with a standardized rate or everyone just has different rates and we can't really, you know, standardize on something? but, you know, it's, it's, it's a nascent space, we, we might, see further developments come. I think the other question I wanted to ask you was, a-and I guess obviously a lot of us Bitcoiners, who, who, who believe in this, think it's gonna go really, really big, and if you think Bitcoin, the pr- you know, the price is gonna go huge, you kind of naturally don't want to spend a lot of it Yet, and in, in a sense, you're using it more like a store of value, at least in these earlier stages. did you have any, comments around Lightning Network contributing on that?"
    },
    {
      "speaker": "bryan_vu",
      "time": "52:21",
      "start": 3141.12,
      "text": "Yeah, I think, yeah, I think the store of value use cases, I agree with most of your previous guests, you know, very illustrious, economically, literate folks. I think that, It is, you know, Bitcoin has to become a store of value first before it does become a medium of exchange, but I think that, something like Lightning can also accelerate that process of the store value, becoming, sort of, stable. So I think that, a couple things that I think Lightning, can improve upon in terms of Bitcoin is, from a decentralization standpoint, I think if we lived in a world where there wasn't something like Lightning And you had to use, centralized services or you had to transition your funds from fiat for your day-to-day business, and then you were only able to use, and you only use Bitcoin basically for holding. I think that, The, there would be, I guess points of failure in terms of whichever, you know, five or six exchanges are available in your country. I also think that, there's a loss of privacy with that, and with that loss of privacy, there would also be potentially loss of fungibility. So I think that, and also, also there's just, you know, a lot of inconvenience in terms of having to, you know, do kinds, all kinds of KYC/AML. Like I've had to take pictures of myself, you know, For, for various, exchanges. So I think that just, you know, from a pure store of value standpoint, the, the fungibility and security,"
    },
    {
      "speaker": "bryan_vu",
      "time": "54:01",
      "start": 3240.72,
      "text": "aspects of Lightning can be, very, very helpful. It's also just making Bitcoin much more liquid and, making it so that you can, You know, spend your Bitcoin everywhere. Lalu always talks about the, the, the matrix meme, which is when, you know, Bitcoin's a million dollars, you won't have to sell it, I think, you know, that's very much, you know, my hope as well. So, you know, I think Lightning is a big part of that."
    },
    {
      "speaker": "stephan",
      "time": "54:27",
      "start": 3267.19,
      "text": "Yeah, excellent. Yeah. So I think I, I tried to summarize is basically that Lightning will still help reduce the single points of failure kind of concept. It will also improve the fungibility, and it, it does add some level of privacy to the end user as well. So, all, all great points. And I think, yeah, it's, a really, to follow. So, thanks a lot for coming on today, Brian. it's been a fantastic and really, interesting conversation with you. did you have any final comments you wanted to make, Brian?"
    },
    {
      "speaker": "bryan_vu",
      "time": "55:05",
      "start": 3304.58,
      "text": "let's see. yeah, thanks, Stefan. It's been a great conversation, and, you know, definitely very impressed with, your level of research and, and knowledge of Lightning. I think, we, we have not done as good of a job as I would like, in terms of, you know, blog posting and, and putting some of this documentation out there. So, it's, it's nice to be able to, get some of this information out in a, in a relatively low impact way, Let's see. I think, I guess, I mean, I would just say that, you know, if people are looking at the Lightning Network now and expecting that that's how it's going to be, you know, let's say three to six months from now, I would say that, Lightning is gonna change a huge amount when we introduce this concept of, you know, routing nodes and, when we have, you know, non-advertised channels. so I think Lightning is gonna get a lot better, a lot more reliable, Those three things all, all in there. We've done, we've done the hardest part, which is the protocol implementation. But when we get the, the routing rules stuff out there and the client apps out there, I think, Lightning will be, you know, you know, kind of fully operational at that point. So I just, I feel like some people think that Lightning is fully operational now, and, I think that, we have a ways to go, but, we're making really, really good progress and,"
    },
    {
      "speaker": "bryan_vu",
      "time": "56:24",
      "start": 3383.51,
      "text": "you know, last year"
    },
    {
      "speaker": "bryan_vu",
      "time": "56:29",
      "start": 3388.75,
      "text": "Even be technically possible until, you know, this year. So, we're really happy with, where things are at, and, you know, I think the community wishes it was faster. You know, we, we, we get a lot of, you know, complaints about how long Lightning's taking, but, this kind of stuff takes a while, and, security and, and privacy, decentralization are super, super, super important to us, and, you know, we're all long-time Bitcoiners, like yourself,"
    },
    {
      "speaker": "bryan_vu",
      "time": "56:59",
      "start": 3418.73,
      "text": "We want to, you know, do things right."
    },
    {
      "speaker": "stephan",
      "time": "57:01",
      "start": 3421.23,
      "text": "Excellent. No, thanks very much, guys. so, guys, you can find Bryan on Twitter, his handle is at b v u, and also obviously, guys, go and check out the Lightning Labs website, you can see the GitHub, and obviously, I'll put the, links in the description, in the show page for, the routing blog post and the Lightning UX post. Is there anywhere else that you would like to direct people to, Bryan?"
    },
    {
      "speaker": "bryan_vu",
      "time": "57:30",
      "start": 3450.07,
      "text": "no, I guess, those are probably the best places to reach me though. as I said, I don't use Twitter that often, but, I think my email address is on the, on the website as well."
    },
    {
      "speaker": "stephan",
      "time": "57:39",
      "start": 3458.64,
      "text": "Excellent. Okay. Well, thanks very much, Bryan, and, chat soon. Great, thanks, Stefan. Okay, thanks guys. Thanks for that, Brian. and so guys, I will put the notes for this episode on my blog, stephanelivera dot com, look up S L P nine. just a quick reminder, please subscribe to the podcast so you get all the new episodes as they come out. Share it with your friends, share it on social media. any feedback, come back, come back and find me on Twitter at Stephan Livera. thanks, and that's all from us."
    }
  ]
}
