{
  "episodeId": "SLP438",
  "speakers": {
    "stephan": {
      "name": "Stephan Livera",
      "role": "host",
      "tag": "STEPHAN"
    },
    "lawrence_nahum": {
      "name": "Lawrence Nahum",
      "role": "guest",
      "tag": "LAWRENCE"
    }
  },
  "segments": [
    {
      "speaker": "stephan",
      "time": "00:09",
      "start": 8.63,
      "text": "Hi and welcome to Stephan Livera podcast, a show about Bitcoin and Austrian economics, brought to you by Swan Bitcoin. Today my guest is Lawrence Nahum, he's from Blockstream, he's the chief architect over there, and we chat about the recent RBF controversy and Lawrence is in the pro mempool full RBF camp, and so we talk a little bit about some of the ins and outs of the arguments there. We also chat about Blockstream Green, Jade, and also built on L2. Now, I've got a new sponsor. Are you ready for something huge? BTC Prague is coming. It's going to be the biggest Bitcoin event in Europe. It's coming June 8th to 10th, 2023 in Prague, in Czech Republic. This is a massive three-day event where there will be ten thousand people, ranging from fresh newbies to Bitcoin whales to business insiders, developers, all being connected together in a unique networking opportunity. There'll be more than sixty world-class speakers and a hundred companies to assure both education and fun in a Bitcoin only feast. I'm gonna be one of the hosts of the main stage for one day, and I'll be on a panel also. You can expect a relaxed summer atmosphere, famous Czech beer, and affordable prices. Go to btcprague dot com, use code Livera to get your discounted ticket. I'm looking forward to meeting you in the BTC Prague Citadel in June twenty twenty-three. This show is also brought to you by Blockstream. They are the creators of Blockstream Green, an industry-leading Bitcoin and Liquid wallet. It's available Available on your smartphone, iOS and/or Android, and also on desktop, gain access to powerful features such as multi-signature security, full node verification, and Tor support. So you can use multi-signature with Blockstream Green, you hold one key on your device, another is held on Blockstream's servers, enabling you to protect your wallet with two-factor. Now, you can also have a time lock or a third-party third backup key to ensure you always retain full ownership of your funds. Blockstream Green also has integration with hardware wallets like Blockstream Jade, Ledger, and... And Trezor. Also, you can use your own full node and connect it to your own Electrum server. So there's lots of convenience and features available here. So if you're interested, go to blockstream.com/green. Now, when it comes to Bitcoin financial services and multi-signature, Unchained Capital are providing a multi-signature service for those of you who need a way to get set up. They have a concierge onboarding program. They can onboard you into a multi-signature vault where you hold two keys in different locations and they hold the third key. Now, don't be worried if you've never done this before, you've never held your own private keys. They can walk you through the process on a call. They can ship you the hardware if you need it, they can do a call with you and walk you through the process of withdrawing out of an exchange or custodian or a single signature wallet into your own multi-signature vault. So this is a great way to give yourself that additional peace of mind, remove single points of failure from your Bitcoin security setup. Go to Unchained dot com, use the code Livera for your concierge onboarding Larry, welcome to the show. Thank you. Hello. So, Larry, I've, I've known you for a little while, and I know obviously you're over at Blo- Blockstream, and you are-- From the earlier days, you were working on Green, which is now Blockstream Green. And so, gonna get into a bunch of stuff today around, the RBF, which I'm sure is gonna be, an interesting one. There's been some recent debate about that also, but I guess just firstly, do, do you wanna just tell Items that are, you know, from a blockchain perspective or from a Bitcoin point of view, what are you mainly working on?"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "03:35",
      "start": 215.02,
      "text": "Right. So I'm, I'm working on a variety of things from Jade, a bit on Green, although you could say less than I used to, and a little bit on other things, you know, like Explorer and/or, bindings for new libraries or working at the architectural level or integration level between, you know, different components that we're working on. So for example, there's some dependencies across like Explorer Doesn't drive just the, you know, explorer at blockstream.info, but also drives the single sig devices like, Green or, or, you know, any Electrum wallet or Electrum compatible wallet that wants to connect to it. So there's always a little bit of coordination and integration, for example, we're updating to, Bitcoin Core v24 and, Are you running, mempool full rbf equals one? We, we will. Yes, yes, we will. For the time being. We'll still, you know, we're going to flag for TNRBF, but at some point, I don't think it's going to be necessary."
    },
    {
      "speaker": "stephan",
      "time": "04:36",
      "start": 275.96,
      "text": "Yeah, yeah. So, look, just to explain for new listeners, let's talk a little bit about this whole RBF thing because I, I have been getting some questions, and I thought, you know what, we might as well talk about it and explain that, at least from your perspective. I know you'll obviously be, more on the pro full RBF side, and it's crucial to point out there is a To, I guess, give us a little bit of a background on where this came from. Okay. I mean, as far"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "05:05",
      "start": 304.98,
      "text": "as I know, a list,"
    },
    {
      "speaker": "stephan",
      "time": "05:06",
      "start": 305.8,
      "text": "yeah, sure."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "05:06",
      "start": 306.26,
      "text": "So as far as I know, Bitcoin had some sort of, replacement built in from, the Satoshi's days, from the get-go, or, you know, from the time he was working on it. However, as far as I know, it was disabled citing-- Well, I'm not even sure if he was citing this, but the, the explanation was that it was, you know Quite freely, both in terms of fees and in terms of, mempool policy, then you could DOS basically nodes with, with transactions, and it, it basically wasn't ready, you know, for, for it to be enabled. Then at some point, there were various discussions about re-enabling RBF in one form or another, whether, you know, the mempool policy level or, well, at, at some point at the transaction level, and, and, and that's really what, what, what happened. Obtaining RBF is what we have today, which Which is a, a flag that you can set on transactions, and this flag, it's a bit of a compromise, this flag allows you to, you know, flag whether you, you're gonna want to replace it later or not, potentially replace it later or not."
    },
    {
      "speaker": "stephan",
      "time": "06:13",
      "start": 372.75,
      "text": "Yeah. So I guess just to explain, so for listeners who are totally unfamiliar, the idea is when you craft your transaction, the Bitcoin wallet, you might, depending on this feature, you might want to have that feature or the ability to later, let's say you start out with a low fee, and then later you see Bump that fee, and that's where this idea of fee bumping or replaced by fee came in, and the idea being that you could add more fee to help it confirm faster, let's say. So as an example, if I had just put out a transaction and then all of a sudden, Binance just drops a bomb in the mempool and drops all these transactions, and all of a sudden now my transaction is really far back, if I could RBF, that could bring it forward. But perhaps there's maybe a little bit more of a, let's say, a controversy or at least a feature as opposed to, you know, because from their perspective, they were saying, \"Oh, I want to be able to manage the risk with a zero confirmation transaction.\" But on the other hand, there are people who are saying, \"No, no, zero confirmation was never safe, it was never a thing.\" So, h-how are you seeing that? Ultimately, miners can, can"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "07:18",
      "start": 438.25,
      "text": "mine any transaction with or without the flag, any replacement thereof, and any node will simply accept it. So this is what we mean when, when we say policy, it's, it's, it miners can ultimately create non-standard transactions and can include transactions that possibly the network hasn't never seen. Potentially they created them, potentially someone else has, given, those transactions to them. And, and that's, that's kind of the baseline. That's what you should like, you know, expect from a security point of view or from a confirmations point of view. That's, that's what you look at. a transaction with one confirmation is, you know, decent. you usually want more for bigger amounts. Six is just a, you know, a number thrown out there. It could be twelve, it could be five. It, it really depends on your risk and the state of the network, the amount, and so on, right? So, you know, if, if you're dealing with big amounts, you really want to deal with transactions that get confirmed because, anything you said at the level can be replaced, and if there's incentives to replace it, like money to be made, especially big money to be made, then, you know, it will be taken advantage of, and, So yeah, like from a mempool perspective, what you really want to have is some coherent view of what's going on. And there's so many things outside of mempool, RBF, that also affects your view of, the mempool. I mean, obviously the nodes you're connected to, because potentially, you're not connected to all transactions in some, to all nodes, and some, well, you're obviously not connected to all, all nodes, but in general, you may not see some transactions until they end up in a block, especially if they're very close Block, but there's, like the mempool size, for example, like it's three hundred megabytes by default, but if you have a bigger one, you may have in your mempool more transactions because you're, well, you have more space, and so you don't need, like, when, when the three hundred one, the default one gets full, what happens is the bottom of, of the mempool, the ones with the lowest fee rate, those get evicted, which actually means you can replace them now, even regardless of the OPTIN R Like they weren't my cash, they're not in my cash anymore, I don't know about them anymore. So now any transaction that replaces them, even if it changes all the outputs, it's fair game, regardless of the fee, as long as the fee is higher than, you know, the minimum of the bottom, which could change, right? Because it's a, a dynamic system. it doesn't have to stay full for a long time, it could, but it doesn't have to be. And then there's also minimum relay fee, it's another flag that you can change, And the other one is blocks only. You can run your full node with validation of blocks and, and everything, but, you know, it, it reduces a lot the bandwidth use, and you don't have to have the full mempool. It also means you don't have a, a good enough fee estimation compared to others, and I argue that not having mempool rbf also gives you bad estimation, because you don't see the others out there out bidding you in terms of the, the market, because you don't see those transactions in your mempool if you don't run it. So now you 'Cause we can bid, or, I mean, people that use, mempool RBF can bid for, you know, the real market value rather than a limited view, and then, you know, they get"
    },
    {
      "speaker": "stephan",
      "time": "10:40",
      "start": 640.07,
      "text": "delayed. Right. If you were, if your view of the network was blocks only, right? Is that, that's basically what you're saying, your information is reduced relative."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "10:49",
      "start": 648.59,
      "text": "That's one of, that's definitely reduced, but I'm saying that also if you don't run with mempool RBF, with full mempool RBF policy, then you don't see some transactions I see. So you don't see the higher fee rate. So you may expect that a block that that gets created, gets created without those transactions when, when actually the miners have interest in mining higher-paying transaction in terms of fee rate. And so you're, you're, you're reading with the wrong information, like missing information."
    },
    {
      "speaker": "stephan",
      "time": "11:19",
      "start": 679.11,
      "text": "Yeah. And so one argument we've seen from some of the zero confirmation merchants and people who are pro this idea of managing the risk of zero- Confirmation, they say, \"Oh, well, actually in practice, people don't really do it.\" So they'll say, \"Look, a lot of people they signal RBF, opt in RBF, and yet only a very small percentage of them actually RBF'd.\" And so I'm curious if you have any view on that idea."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "11:47",
      "start": 707.09,
      "text": "Oh, yeah, I mean, I have quite a bit of, information about this because Green was one of the first ones to implement, opt-in RBF, and at the beginning it was a checkbox on every transaction which you could default to your And well, a-at the time through support and through, you know, users' feedback and social media and so on, we gathered that people were often confused about this, like, why wouldn't I always have, want the ability to replace them? Why would I want to have this or that? And then, you know, you have to explain, maybe put a little help, a-a-and what often happens is that users that don't set it end up being the ones that beg for, \"What do I do? My transaction is stuck for two weeks,\" because the transaction stays"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "12:31",
      "start": 751.04,
      "text": "And, you know, it doesn't get evicted for other reasons, and it can't be replaced because of, you know, first in policy, unless you have, you know, good connections with miners or relationships that allow you to push replacements anyway. And, and that's a terrible user experience because having a transaction stuck two weeks is terrible, but the, the reality is that it's only-- I mean, it's stuck for two weeks, but if someone was to listen to those transactions and rebroadcast them immediately, like a joker, you know, a joker guy All mempool transactions as soon as they expire, rebroadcast them immediately because you can, and now they're locked for another two weeks. And, I mean, that's not user experience either. I'm, I mean, I'm not even sure that will, will, will happen because, at some point I imagined the mempool will be full and that there will be some movement, and, but who knows, right? And the, the reality is that you can't have that sort of UX. It's, it's terrible and having to choose or having to set the, the user interface for"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "13:30",
      "start": 810.44,
      "text": "why do I need to do this? Why do we have extra complex, configuration options that don't work? And why wouldn't-- I, I mean, the other option is, okay, let's have it always on and hide it from the configuration so that you can, right? And, and that works. I mean, that's what we have currently in green. It, it's mostly like an accident, like when we were doing a UX revamp when we did like a B2B3 of the UX, we, we left it out for simplicity and we said we'll add"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "14:00",
      "start": 840.08,
      "text": "It's covered. But, I, I think this is like the, the best option because most users don't care. when they do care, you really want the replaceability, and the only users that get hit by this is basically what Luke Dash Junior calls discrimination of, opt-in RBF, where some merchants, you know, will not treat you the same. you could say rightly so. I mean, I think they should always wait for one confirmations to deliver you the goods, and, and this really only applies to stuff that is delivered online immediately, Requires, you know, physical delivery, that can probably wait the confirmation, right?"
    },
    {
      "speaker": "stephan",
      "time": "14:35",
      "start": 875.04,
      "text": "Yeah. So on that point, I think one of the exceptions may be some of these, zero-conf ATMs, right? So the idea, I guess, the use case in this case is the user wants to sell some Bitcoin and take fiat, and some ATMs will play that probabilistic game and say, \"Oh, okay, we'll still let you have it on a zero confirmation as long as the fee is above a certain level,\" or of course, you know, some of the well-known online Merchants, people like Bitrefill and others, I know Francis has mentioned this even over at Bull Bitcoin as well. I think, I sort of see it like we're going to a full mempool RBF world eventually, but maybe it was a question of should it have been put in at this point? and I think that's probably the point. But I think, I certainly think it's fair to point out that, you know, that maybe some merchants might be underestimating the level of risk there because really any miner who has a new transaction that's valid could put it in And, and you, you know, at that point, you're, you're just, you're out of luck then. Yeah, I mean,"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "15:34",
      "start": 933.88,
      "text": "as far as I know, the majority of ATMs, do KYC or, you know, require a document, or a-as far as I remember, maybe, you know, the situation is a bit different. So those clearly could do zero coin, four one coin, so use Lightning, it's up to them, but, you know, the KYC you do, so in theory, it's harder to fool them. For the How risky this is. I think just because it hasn't been gained so far, it doesn't mean that it won't be gained, especially as incentives go higher and like, I also think that right now there's so many, yeah, like low-hanging fruit in terms of security, yeah, like all the DeFi and all the protocols that, that hundreds of millions are stolen or, or taken rather than stolen, I guess, those are more, you know, more interesting than, than getting a few hundred or thousands, from, some online merchant. Merchants, I think, at the moment at least. So I think that there's, there's, the people that, you know, really support full mempool RBF, and there's the people that say, \"Well, it's inevitable, but for now, couldn't we just do it softly or do it slower or do it like wait a little bit longer, wait for Lightning maybe to pick up a bit more?\" And that is an argument that I'm, you know, I'm prepared to, to have, you know, it, it, it's The other one, the last one, you know, several people that, that actually say, \"Well, no, you should never change, first in policy,\" and that's simply not, you know, incentive compatible, and I don't think it, it makes sense, in, in the future, e-even if, you know, they do"
    },
    {
      "speaker": "stephan",
      "time": "17:17",
      "start": 1036.69,
      "text": "Yeah, and just to clarify here, just for listeners who aren't familiar, what is so-called first seen policy? So first seen policy"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "17:22",
      "start": 1042.38,
      "text": "is the current policy. What we have today is first seen policy with the opt-in RBF. What we had before opting, RBF was, a, a first seen policy where you couldn't replace even-- Well, there wasn't nothing to flag, there wasn't nothing to show. A-and also there was another one where if your coins were, your UTXOs were old enough, you know, you didn't have to pay. This, this"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "17:46",
      "start": 1066.35,
      "text": "The relay and the mempool policy ultimately. And yeah, like, first thing is when your, your node sees the transaction and, it won't accept another one later that shares any of the inputs, unless, you know, I-opt-in RBF, which, which allows it for a fee increase."
    },
    {
      "speaker": "stephan",
      "time": "18:04",
      "start": 1084.44,
      "text": "Okay, so as we were saying, we were talking about first seen policy, and, basically, this is basically a policy that is currently in place until the, you know, let's say, until the world shifts to a full mempool RBF world. But I guess people have argued that this is like a, an unstable gentleman's agreement, because in reality, the miners don't have to respect the so-called first seen policy. They could just neglect that and just say, \"You know what? I'm just gonna treat everything like RBF anyway.\" Or they, as an example, now with the new version of Bitcoin Core, version twenty-four, they could all switch mempool full RBF equals one on in their config, and then from now, you know, the network would just be in a full RBF state from now on, right?"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "18:47",
      "start": 1126.91,
      "text": "Yeah, and, and they could have done this, earlier either through nodes or through, you know, Bitcoin Core but patched. I think it's only like a few lines of code to keep the, you know, opt-in policy check and simply allow any transaction in mempool as long as, you know The fee increase. And, yeah, I mean, it's possible some of them were already doing it. Now it's easier because it's part of core for sure. It's less risky as well, right? Because I don't have to run something else or compile something myself if I don't want to. or, you know, use some patches that haven't been necessarily as reviewed as the rest of core. And now these patches have been, are in and have been reviewed extensively. There's been a lot of discussion around this. And yeah, I mean, it's really It's off by default. Core didn't really do, you know, anything terrible. I mean, the only thing terrible, terrible thing here is that it's not on by default. but yeah, giving user option is fine. Like, they can turn the mempool off, they can increase their mempool size, they can decrease it, they can allow replacement, and allowing replacement is, as you say, the most, incentive-compatible thing with miners. So what else are you gonna do?"
    },
    {
      "speaker": "stephan",
      "time": "20:00",
      "start": 1199.83,
      "text": "And when it comes to letting the users decide, I think this is another point of- Of contention because those in the zero-conf camp, some of the guys over at Bitrefill, they might be seeing it more like users in this, in one sense is Bitcoin node runners, and then in another sense, users are just people who use a Bitcoin wallet, and they don't, they don't necessarily follow the RBF discussion, and they're not really intimately familiar, and they don't really understand this idea of setting the flag on or off. So in that sense, they're not really getting a choice, or they're not getting, reflected into it. And, I guess That was the argument of why their, their use case is being diminished, let's say."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "20:37",
      "start": 1236.66,
      "text": "I mean, the, the argument of the full mempool RBF is not just, you know, it's better UX in the wallet because you don't have to deal with these flags, you know, before you do the transaction, you just deal with it if you need to increase the transaction later. so from a UX perspective, yes, it's much better, but it, it, the important thing is the incentive compatibility. And the other thing that sometimes I worry about is, you They can deal with it in the future very well in different conditions, in, in, you know, with the mempufu and so on. Well, o-obviously they, they need to move to Lightning, most of them already, I mean, the big ones already run Lightning, so that's great. I, I think, you know, more users will move to it."
    },
    {
      "speaker": "stephan",
      "time": "21:18",
      "start": 1278.25,
      "text": "Yeah. One other question that I think is i-interesting is this idea of, will there be people who try to game the feature? And so I think Francis was talking about this in the context of his bill"
    },
    {
      "speaker": "stephan",
      "time": "21:33",
      "start": 1293.34,
      "text": "On chain and then Francis's company is paying out that bill in fiat terms. And so he was concerned that basically people could game him and have a so-called free option on the exchange rate by only selectively rbfing when the exchange rate moves in a favorable way for the customer, but otherwise not doing so. So I'm curious if you have any thoughts on that or do you, do you think the answer really is just that we, we have to drive lightning adoption?"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "22:03",
      "start": 1322.96,
      "text": "I, I think for that use case, I mean, likely as soon as there's, fifteen percent or more, you know, nodes in the network and miners that run this, likely he will have to wait one confirmations to lock in the rate. At the moment he locks it at zero cons for non-RBF transactions, non-opinion RBF transactions, but for opinion RBF transactions, I'm sure he already locks in later, like at one conf. I think it's safe enough, right? If he was trusting zero conf, I'm sure he's trusting one conf. And Yeah, I think long term it's kind of inevitable that he will have to switch to one. That being said, if, he's dealing with the, with the customer with, some level of KYC, maybe that's not even entirely true. It's up to him to extend credit if he has done exten-- you know, enough, you know, risk assessment on, on the customer. If he doesn't have any KYC, then, yeah, the safest thing is waiting confirmations."
    },
    {
      "speaker": "stephan",
      "time": "22:56",
      "start": 1376.49,
      "text": "Yeah, and I think one other thing I was hearing is this idea that if Bitcoin doesn Speaking doesn't support this kind of zero confirmation use case, which I don't really agree with, but, you know, for the sake of argument, this if Bitcoin doesn't support this zero confirmation use case, people are just gonna go and use like some shitcoin, and is that a bad thing? I'm curious what you think about that."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "23:18",
      "start": 1397.63,
      "text": "Yeah, I mean, I, I think I was, gonna say earlier that I'm worried about build-- people building infrastructure on top of fragile fundamentals."
    },
    {
      "speaker": "stephan",
      "time": "23:25",
      "start": 1405.09,
      "text": "Yeah."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "23:25",
      "start": 1405.31,
      "text": "And I think the zero conf is a fragile fundament. So I welcome people that want to build And if, if you-- the, the, the biggest proponent of, of, of this, for Sin, i-it's not just Bitrefill, it's also, you know, Bitcoin analog, John Green, right? And, and I think his m-major use case is, integration with Lightning, like, onboarding, opening channels with Lightning. If, if more people start building on top of zeroconf and, and then it starts, you know, breaking suddenly, you know, we could have a, a big chunk of the industry, and by industry, I"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "24:03",
      "start": 1442.88,
      "text": "Industry, you know, being hit. Yeah. It's a lot of infrastructure, and, that wouldn't be great. Imagine if all exchanges, you know, were built on unreliable infrastructure and suddenly all got hacked with zero BF, with, with the, you know, gentleman's agreement. Like we're talking about Bitcoin, it's the, the money of, of, enemies, right? So we shouldn't build on top of weak fundamentals. If they wanna go to shitcoins, roachcoins, yeah, at them. It won't last."
    },
    {
      "speaker": "stephan",
      "time": "24:31",
      "start": 1470.55,
      "text": "Yeah, I think Lasts here and maybe that's the direction the network has to go, even if it is a bit painful at the start. Maybe there's some parallels with even the whole SegWit, block size wars and taking the hard path in twenty seventeen as opposed to the what would have been, quote unquote, easy to raise the block size back then, but instead taking the hard path now to actually do it the right way with Lightning. But that said, you know, obviously I'm a big promoter and supporter of Lightning. I, I love using Lightning and I, you know, I, I am a bit just lapping here, but I think one fair criticism could be that, Lightning adoption hasn't gone to the level that, let's say, many of us were expecting or hoping in the, let's say, the twenty seventeen, twenty eighteen days. I'm curious your thoughts on that as well around Lightning adoption and the, the current level of, let's say, the average Bitcoin transaction, average Bitcoin user experience today."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "25:25",
      "start": 1525.15,
      "text": "Look, I, I can see both from, just looking at the Bitcoin industry, but also looking at Blockstream, that, yeah, Lightning needs, A lot of work and we'll need, quite a bit of work for, you know, the foreseeable years. I, I mean, i-it's possible in ten years it's gonna be done, but in, in general, I think there's so many improvements that, that can be applied that I can't see any, you know, developments slowing down for, for the next few years for sure. I, I think some system will benefit with, you know, better models, like if you have recurring customers and Lightning doesn't work well enough for you for whatever reason, well Often works like, okay, I, I need to go to the ATM. Okay, I'll, I'll use Lightning. But if Lightning isn't good enough because, I don't know, the, the channels don't really work well for the amounts that I'm trying to withdraw, well then maybe your best, bet is to send in advance. You know, you send in advance when it has at least one confirm, you walk to the ATM and get your cash out. Yeah, it's not optimal, but I mean, generally, you know, in advance when you wanna go to the ATM It gets confirmed before you even walk there or, you know, drive there."
    },
    {
      "speaker": "stephan",
      "time": "26:36",
      "start": 1596.28,
      "text": "Yeah. So I think that depends on how tech-savvy the user is, right? Because if it's, let's say someone like you or me or a listener of this podcast, yeah, probably they're happy to use the app. But let's say someone who's not as tech-savvy, they're kind of expecting to just go to the ATM and just use it then and there. I can understand from that point of view. But that said, we are seeing, for example, as an, yeah, as Withdrawal with Lightning. So there really has been a massive improvement in the user experience if you use Lightning the right way. And so to some extent, there's a criticism of, \"Oh, look, see, a lot of Bitcoin users are stuck in twenty fifteen wallet user experience.\" But if you upgrade and use some of the, you know, the new twenty twenty two stuff, it is actually very slick and it is very fast and easy. But I think part of it is getting the word out to people who are, without knowing, they're just kind of stuck on older wallets."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "27:31",
      "start": 1651.07,
      "text": "So you're basically saying Which is liquidity there and, the fact that people haven't, you know, opened channels beforehand."
    },
    {
      "speaker": "stephan",
      "time": "27:39",
      "start": 1658.66,
      "text": "And I think some of them maybe, and in fairness, right, the early days of Lightning, let's say the user experience wasn't that great, right? Unless you were an advanced user, and even then, you had to do a lot of manual fiddling around. Whereas nowadays, if you pick up some of these easy Lightning phone wallets, like even if you're not an advanced user, even if you're not running your own Lightning node, like at home kind of thing or on, on Lightning wallets, it is pretty slick. So, you know, we'll see what happens with that, and then on-chain will obviously still work today, and many do still use it today, obviously, but maybe that becomes more useful for the higher value transactions. You know, as many of us were saying, the idea is lightning for the small stuff and Bitcoin on-chain for the bigger things."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "28:22",
      "start": 1701.87,
      "text": "Yeah, I, I think naturally, Lightning will have more channels and more capacity, and as it has more capacity and it's cheaper to use Lightning than, than on-chain, of course. Then yes, I, I, I expect this move right where higher value transactions are all on chain and, and the rest, if possible, on Lightning. Yeah."
    },
    {
      "speaker": "stephan",
      "time": "28:42",
      "start": 1722.08,
      "text": "So yeah, so I think anyway, I guess to sort of round off the discussion then, in a way, just to summarize, there's this concept of RBF, replace by fee, and that is basically giving you the possibility to increase the fee that you attach to a transaction. This recent debate or controversy was about what the defaults and what the mempool policy should be across Bitcoin. Bitcoin's network of nodes. So I think, at least from my po-per-spective, I think we were going to full RBF anyway, but it's probably-- you could argue that maybe it was a bit premature. I think that's probably a fair point. But nevertheless, the option is there now and it's default off. But there's users out there, if they want to, they can go into their Bitcoin dot com for their configuration file, set that mempool full RBF equals one, and then now your node is basically treating all the transactions like they have signaled for RBF, is how"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "29:33",
      "start": 1772.92,
      "text": "Yeah, it's as if everything signaled or-- but the signal-- but, but the flag can be off. Well, so it's not just the fee that you can change, you can actually change, all the outputs and potentially, all the inputs are minus one, and that's a replacement. But yeah, no, as for the rest, that's correct."
    },
    {
      "speaker": "stephan",
      "time": "29:50",
      "start": 1790.21,
      "text": "So let's chat a little bit about Bloxstream Green and, you know, what the latest is. Oh, and also, I, I thought you would like this. I-- So I It's called Meprima Bitcoin, and as part of that, they got a bunch of us to come, a bunch of, well, like Bitcoin people to come from the conference and just come along and be a, a verifier or a tester, for the student, and these are young students in school, obviously, and as part of their test, they had to create a Moon wallet, right, and create, write down the, the backup from that, and then recover a backup into Blockstream Green, and then spend out of Blockstream Green into that Moon wallet. So, you know They had to actually use Blockstream Green as part of that process, so I thought you'd like to hear that story. It's an interesting one that, and, the idea is that they're hoping to roll that program out to more and more schools if they can demo and show, \"Hey, it worked here. These kids now know how to use Bitcoin, they know how to use Lightning, and so on.\""
    },
    {
      "speaker": "lawrence_nahum",
      "time": "30:52",
      "start": 1851.67,
      "text": "That's very cool, and I think it's, you know, very interesting that they're also, they're also teaching like the recovery part, which is, very"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "31:03",
      "start": 1862.84,
      "text": "Too, too late. So I think it's great. Yeah."
    },
    {
      "speaker": "stephan",
      "time": "31:06",
      "start": 1865.62,
      "text": "So, let's chat a little bit about the latest with Blockstream Green. So I guess for listeners who aren't familiar, it's a single signature or multi-signature wallet. You can use Bitcoin or Liquid on the wallet, and you can also connect it with your own full node. And then, I guess the, the i-- the other big idea is that it's connected with Blockstream Jade, or you have that integration, so you can use it more easily with that. So do you wanna tell us the latest"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "31:33",
      "start": 1892.82,
      "text": "Exactly. I was gonna say we also support ledger and Trezor on, on Jade, and I'm hoping that we will support, you know, all major, you know, other wallets, out there. Like I'd like to support Coldcard, I'd like to support, BitBox and so on. What, what are the latest? Well, so- At the moment, we, we have, you know, the apps on, Android, iOS, and desktop. We're adding some support for single-seek, liquid hardware wallets, which we didn't have. We had multi-seek support, but single-seek, we were still missing. we're doing a UX revamp again, where we're really focusing on simplifying the user experience while leaving, you know, still, some space for advanced users to do their thing. I don't know if you used recently, we have a coin selection. And, and yeah, we're also, you know, looking at improving the integration with Jade, obviously. In the future, mind you, things that I'm particularly interested in focusing in Green that are relevant to this co- to this interview, I'd like to-- We don't have, child piece for parent in, the wallet, I would like to add it. And also at some point, you know, enable replacement regardless of the RBF flag, so stop signaling once it becomes reliable enough. We're gonna add in Lightning, all"
    },
    {
      "speaker": "stephan",
      "time": "32:46",
      "start": 1966.13,
      "text": "right, on Green About how that would work or what kind of ideas you have, like is it going to be sort of like an on-the-fly channel model or is it going to be more like, you manually set up your channels or what's the idea?"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "33:00",
      "start": 1979.62,
      "text": "So, yeah, we're, we're still working a little bit on, on that part in terms of onboarding, in terms of, opening channels, whether it's, you know, the user can choose AdHoc and just open channels on, you know, simply when there's no route, or whether we want the user to, you know, have the option to open a number of channels, ahead of time with the big liquidity providers and so on. So for that part, we're still working on it, and the model is that you can use this wallet from, Like whether it's your Android or iPad or a desktop device, and it's like an instant on, Lightning wallet. We'll probably, you know, start with less features and, and, and add them as, as we go along. I can't really say yet what's gonna be inside, you know, the MVP, the minimum viable product that we're gonna come out with, but it's really interesting times, you know, in terms of, n-n-not just the features themselves, but also the, the, the whole integration in terms of UX within the wallet You know, to support the whole, single sig on chain as well as Lightning."
    },
    {
      "speaker": "stephan",
      "time": "34:04",
      "start": 2043.96,
      "text": "Yeah, that's, that's a tricky one to balance for users as well, and I know some wallets to kind of go for this all or nothing approach, right? It's just kind of everything is Bitcoin native or it's everything is Lightning native, but to manage kind of different balances is, a different, is kind of a-- you have to think about that for the user."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "34:23",
      "start": 2063.49,
      "text": "Yeah, for sure. And I don't know if I mentioned it, but also we're adding QR I have with Jade with QR code support. By the way, did you receive yours?"
    },
    {
      "speaker": "stephan",
      "time": "34:33",
      "start": 2073.4,
      "text": "I have ordered some, I haven't got it yet, so unfortunately I haven't- Oh, so back when I was in Australia, I had a Jade, but when I, when I left Prison Island, I didn't have it, so I bought two more and I'm, I'm still waiting for those. I haven't had the chance to, play around yet, but I know you guys have QR code, you've recently enabled QR codes on Jade, so that's, that's really cool also."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "34:53",
      "start": 2093.34,
      "text": "Yeah, I mean, we had QR code support from the beginning, but only to scan monograms, and that was, in a format that wasn't, that basically required a printer, 'cause nobody, you know, created, ways to, to put these QR codes on paper or metal until more recently, right? The seed QR stuff, yeah. Exactly, exactly. So that, that was the second thing that we added support for, normal seed QRS and compact seed QRS, as well as BCUS. QR mnemonic QR. So BCQR is this protocol used, by, you know, all the wallets out there that deal with QRs, and it's a way to encode a message that may be potentially bigger than one single QR code into multiple QR codes. So like a PSBT transaction can be a little bit larger, right? And, it may not fit in a, in a QR code, or maybe does fit in a QR code, but the device display, you know, doesn't have a resolution high enough for, Yeah. To show it, yeah. So, you know You know, you basically cycle a number of QIs until the, the other end captures enough QIs to reconstruct. And i-it's interesting, it's, it's a little bit complex, but it's interesting and it has some error correction built in, not just in the QI codes themselves, but also in the messages. So potentially you need any five of these thirty messages, so you don't even need to cycle. If you keep five, you don't need to go all the way back to the beginning, you, you get another three, you're good to go of any of the Next twenty years. so it's interesting from that point of view. And yeah, it's, it's, it's, it's a decent standard. It's, it's great because now, you know, Jade doesn't need to know about, those software wallets, and those software wallets don't need to know about Jade, but they can be compatible automatically as long as we all, you know, use the same standard."
    },
    {
      "speaker": "stephan",
      "time": "36:42",
      "start": 2201.93,
      "text": "We'll be back to the show in a moment. The lead sponsor of Stephan Livera podcast is Swan Bitcoin. Swan is an easy way to learn Bitcoin have a good educational pathway and learning journey, which Swan provides with a range of free books and resources. Now, the holiday season is coming up, and if you haven't thought yet about what you're gonna do in terms of gifting for your family or your friends, think about swan dot com slash gift. This is an easy way to gift Bitcoin to somebody. It goes to them with a custom message in an email. They can then sign up with Swan and then purchase Bitcoin with the fiat that you gave to them. But the benefit is you're also giving them the benefit of Swan's World-class education and customer support. It's one thing to gift Bitcoin, but also with Swan, you're gifting them that ongoing customer service and support, that educational material which is crucial to helping somebody go down the rabbit hole. So give the gifts of Bitcoin with swan dot com slash gift. When it comes to using Bitcoin and making Bitcoin transactions, you need a Bitcoin explorer, and Mempool dot space is my favorite. It's not just a plain old block explorer, it shows Bitcoin's multi-layer ecosystem. It's a comprehensive- Bitcoin explorer showing the mempool, the blockchain, second layer networks like the Lightning Network, and you can use this to explore the Lightning Network and see what are some of the well connected Lightning nodes, what channels do they have, and all kinds of statistics and information about transactions. So you can use mempool.space and host it yourself, so that means you don't even have to trust a third party. Now, if you are with an enterprise, mempool.space offers customized mempool instances with your company's branding, increased API limits, and more. Learn more at mempool.space Enterprise. And finally, when it comes to Bitcoin hardware, CoinKite dot com makes some of my favorite products in the space. They have a range of hardware that you can use, whether it's for yourself or as a gift for your family or friends. The Coldcard Mark IV is the latest and greatest Bitcoin hardware wallet. It's an extremely reliable performer, it's very secure, it has more RAM and CPU for faster signing of transactions. You can set up this device without even touching a computer, so that is a fantastic feature. Now, on the cheap- Side there are devices such as the TapSigner, which is about forty dollars. Now, this is a lower security but also cheaper device that you can use easily with NFC and wallets like Nunchuk. I think a lot of people are sleeping on the TapSigner, and this is gonna be a fantastic tool for the developing world or for people who want to use it as part of a multi-signature or perhaps as part of their WORM setup. So if you're interested, go to CoinKite dot com, get yourself a cold card, and use the code Livera for a discount there. Yeah Just to replay that for listeners to make sure everyone's following along. So the idea here is that you could compose or construct a transaction on, let's say, your desktop computer, and it shows a QR code or a, a, a series of QR codes that you can then scan in to your device, and then your device can then read that and say, \"Oh, do you want to spend, you know, point one Bitcoin to this address?\" And you hit yes or no, and then to in-- then you have to do the other way around, you have to ingest the signed transaction Back into the computer to then broadcast it out, or so I guess the idea is you could either do that to the computer with the webcam or on the phone itself with, obviously with the phone camera. So is that, that's generally the, the flow that you're talking about here, right? Yeah, exactly."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "40:08",
      "start": 2407.61,
      "text": "Yeah, exactly. And my opinion is that, is that it's not the best user experience because, I mean, wait, it's the best user experience when it comes to compatibility because I can use anything out there, it works. It's not the best user experience because, yeah Distance between the devices and the display and the camera and bad lighting and focus and, you know, there could, there can be headaches, and it can take longer than having a USB cable connected. I think it's safer than a USB cable because you choose when the device talk to each other, it's not up to them. With the USB cable, it's up to them, they can talk and you may not even notice if there's, you know, message or exploit or whatnot. That being said, I mean, an exploit can happen either way, with USB or with camera. The library that does this, PC, you know, BCUI thing, it's relatively complex, it has been reviewed by us, but could have bugs. But then again, the USB stack has bugs, the SD card reader has bugs, Bluetooth stack has bugs potentially. And so, yeah, I mean, camera is not bad. I think SD card is probably better than camera, because again, you choose when they talk. It's, it's not up to the devices. And yeah, I like USB as well. It's, it's fast. And ultimately, it's really, I mean, SD card is, is good for firmware upgrade and for signing transaction, but it's also not the best UX, like taking out an SD card and into different devices, not the best. Yeah, I think from a user pers-p experience point of view, USB or Bluetooth even are the best."
    },
    {
      "speaker": "stephan",
      "time": "41:40",
      "start": 2499.77,
      "text": "Yeah, and I think it also depends what we're talking about here. Like, are we talking about this user's, their big, big cold stack, right? And they need, you know, they're, they're not going to be signed, they're not Use it. Well, then, okay, you might be willing to deal with a bit less, easy user experience because you're, you're only spending out of this once a year or not even. Whereas, let's say if it's more like, okay, I keep this here by my desktop and I'm regularly scanning and signing things, then that's a different case, right? And so then it's kind of a bit more of a, you know, finicky endeavor to do it if it's really like tricky, but, you know, it is also interesting to see Even like with Coldcard and them, they're doing NFC now as well, so that's like another way to even move this stuff back and forth. Although I think, you know, everything has a trade-off in terms of how, let's say, easy it would be to slip some malware or to feed a malicious transaction to the device, I suppose. So that's something that we have to always balance, right?"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "42:44",
      "start": 2563.93,
      "text": "Yeah, I, I think NFC is very interesting. I think that the, you know, the market needs to explore it because it could be the, the easiest thing out there. And NFC tends to have a better stack than Bluetooth in terms of security and so on, so, you know, it's smaller and simpler and so on, so I, I quite like that. I, I like that there's, you know, a lot of, options in the market for, for this. And, you know, on, on some devices you're kind of forced, like on iOS, you either use the camera or you use Bluetooth, you can't really use the USB. Maybe you can if you pay Apple, you know, a hefty fee or"
    },
    {
      "speaker": "stephan",
      "time": "43:15",
      "start": 2594.93,
      "text": "something, I don With a PSBT. So I'm curious your thoughts on that idea that having, like, you know, a Jade as one of your keys and other devices as part of a multisig, and presumably this could work as part of a, some kind of a PSBT transaction formed on the desktop, let's say."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "43:38",
      "start": 2618.11,
      "text": "Yeah, so I think the best thing in, in security at the moment in, in the Bitcoin world, which is in different hardware wallets manufacturers in multisig together, PSBT or not. But yeah, that's, that, that's the non plus ultra of security. It comes Of extra complexity, you know, the, the backup of every individual key or at least the n of m trade-off, threshold, but also the public keys obviously, because then, otherwise you're not able to reconstruct the scripts and, and, and so on and so on. So there's that complexity. I really think you should go and, and, and, and, and do that work and take the complexity in if you're holding, you know, super vast amounts of Bitcoin, you know, like exchanges or, big family office or, you know,"
    },
    {
      "speaker": "stephan",
      "time": "44:21",
      "start": 2661.4,
      "text": "or"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "44:21",
      "start": 2661.46,
      "text": "if you're Michael S Yeah, I was gonna say. So yeah, you, you, you, you should. I wouldn't trust a single hardware wallet, I wouldn't trust, you know, pretty much anything for, for those big amounts. And yeah, for everything else, it's, it's all about trade-off. a mobile generally is better than a desktop, especially if it's like a Windows laptop or desktop used with, the kids and video games and stuff. Also Android and iOS are not great if, you have, you know, kids installing random apps or And whatnot, but in general, yeah, mobiles are better in terms of security features than, than, you know, your vanilla laptop. And then you have hardware wallets, and, and then you have multiple hardware wallets. I would like to see in hardware wallets more lightning support, 'cause I think right now it's, you know, you can probably sign a transaction, but it's, you're not gonna see on screen, you know, the capacity of the channel and the old capacity and, yeah, you know, right, yeah."
    },
    {
      "speaker": "stephan",
      "time": "45:18",
      "start": 2717.73,
      "text": "So as I understand Channel from a hardware wallet or maybe close the channel to the hardware wallet, something like this, but not the overall thing. And I know there is also another project out there, I'm sure you've seen it as well. I think it's called Validating Lightning Signer. So this is like this idea of having like a specialized hardware device that has policy rules that is specialist for, specialized for use as part of a lightning setup, and it's like a kind of warm signer but with policy rules. So maybe that's the way it could go with lightning, warm wallets, let's say"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "45:52",
      "start": 2752.5,
      "text": "I think I heard about this, and if I understand correctly, the hardware wallet trusts an external validator, and the validator creates, you know, some signature that the hardware wallet validates after it has validated, each, you know, transaction. That's cool. You still need to trust this validator, but it's cool because, you know, it could be fairly well secured. What I would really like to see though, is the validator running on the hardware wallet. I know it's not easy, and obviously the validator can't be online. I mean, the, the hardware can't be online. But it could be connected to something online through, maybe not a camera, because you want this automated, but like a USB cable. You probably want to avoid video for performance reasons, for many reasons. But, you know, a nice USB cable, and then you can automate all these transaction signing based on this, you know, at the moment, this external validator, it could be for a powerful enough, hardware device, it could be run on board, I'd imagine, with some proxy of, of the relevant information from a companion, you know, app thing. Yeah, I was talking well, not, not CEO now, but, Nicholas Paka, I was talking to him about, you know, the ledger devices and what they're playing with or thinking about, and they're considering, like a programmable, like, like, like some sort of, virtual machine or interpreter that you can give it some code. I think they were talking about RISC-V, if you, if you know the architecture of RISC-V, like ARM or, you know, x86, but different, and, You can say, \"Well, this code that you can compile externally gets this transaction, decides yes or no, and then the device signs it or, or doesn't sign it based on what the script that run decided.\" I was thinking of something similar for Jade, I was thinking WASM, so a WASM interpreter, you write some WASM in C or in Rust or in JavaScript, TypeScript, whatever, and, you know, you could say, \"If, if the funds go to my cold wallet, I check the addresses, if it goes to my cold wallet, then Otherwise, don't. So that could be, you know, like a fail, fail over thing, fail switch over, where my wallet will always sign to move them to cold storage, but not anything else. So, you know, as long as it's going to an xPub that I'm, pre-approved of, then authorize it without asking me. Or, you know, as long as it's a transaction, through Lightning, like a routing transaction, and I'm making money through the fee mechanism, then authorize it. Or as long as it's a coin join, like, Because they're paying me some fees, authorize it. Because I'm, you know, the sum of the outputs it's, that I'm going to receive, it's larger than the inputs I put in, then just authorize it, because I'm making money. So it's like having keys online without really having them online, because it's a separate device that enforces the rules and signs, and, the, the device doesn't need to know the rules in advance, and the rules aren't really hard-coded or, or, you know, very, well-defined. They, You can write code, you know, literally C or Rust code that takes in the transaction, decides, some stuff, maybe even have some history or, you know, like storage to save, you know, the last transaction I checked. I mean, you have many options. I would like that, which basically makes every hardware wallet like an HSM of sorts that can, you know, it'd be nice for Lightning, for coin joins, for swaps, on platforms where this works, you know, like Liquid or RGB or, I don't know, Taro"
    },
    {
      "speaker": "stephan",
      "time": "49:23",
      "start": 2963.1,
      "text": "Yeah, cool. So I guess the idea then is you might have your home node running and you might plug in your Jade as an example, and if the Jade is becoming like a validator, it's helping secure some of your Lightning stuff at happening as opposed to everything being directly on the machine itself, on the PC that you're running your home node box on. Absolutely."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "49:46",
      "start": 2986.31,
      "text": "It means, that they would need to hack both your, your, your, the box to the, the server where you're running Celani. Or, you know, LND and to have a wallet, whether it's Jade or co-coldcard or other."
    },
    {
      "speaker": "stephan",
      "time": "50:00",
      "start": 2999.64,
      "text": "Yeah."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "50:00",
      "start": 2999.96,
      "text": "You could probably simulate something similar with a separate box, you know, to, maybe, maybe on a different architecture, maybe, you know, with a very limited stack, maybe, you know, BSD or like, I, I, I can't say a Raspberry Pi because Raspberry Pis don't really, they're not top security, in my opinion. You probably want something else. But there are things out there that, that you To improve the security compared to what we do today, you know, with having keys online for Lightning nodes or for CoinJoin, you know, people into sign in order to participate, right?"
    },
    {
      "speaker": "stephan",
      "time": "50:32",
      "start": 3032.18,
      "text": "Yeah, that's interesting, right? Because, yeah, currently those are probably the two main ones where you need some amount of hot wallet or some level of access to the private keys, and that's where Lightning and obviously CoinJoin are probably the main ones. So as an example, there, there might be people who are running a joint market maker, or they might be running, you know, some, something where they Want to participate and for liquidity and maybe earn some Sats, maybe not a massive amount, but something, or Lightning, running a Lightning routing node obviously, and so then as the channels are-- sorry, as the transactions are coming through, you need to sign a new channel state, and as part of that, well, you need, you need to be able to do that operation, and so maybe that's another way. So one other thing with Jade is, the blind PIN server. So do you wanna explain a little bit about what that is, how that works? Sure. Where"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "51:21",
      "start": 3080.99,
      "text": "do I start The Trezor has a, an MCU or, you know, a chip, a CPU that it's, you know, what drives the display and, receives inputs from the buttons and, it stores the private key of the, I mean, the mnemonic of the user and either has a PIN to protect the mnemonic, it can have a, or alternatively, it can have, or, or additionally alternatively, it can have a passphrase, right? And, generally the advi-advice is with Trezor, use a passphrase because the secret on the- On the device can be extracted with, I don't know, a few hundred dollars worth of equipment and some skill that may or may not be easy to, to, you know, pull off. Then there's the ledger model where they use a secure element. On the Nano S, they have both an MCU and the secure element, so it's a two-chip, model, design where the MCU, the, the additional chip talks to the screen and to the display. And, and then the chip is used for the signing of, transaction and, and safe holding of the, the money or private keys, right? Then you got the cold card, which is a bit different. Again, the latest model has two, secure elements of sorts. They're a bit different from the ledger one, because in this case, I believe they only hold the key, they don't actually perform the signing, because what happens is in the ledger, in the cold card model, in, in some, they only had one secure element, in the latest they have two Either way, the through, through your PIN, the secret is revealed by the secret elements to the MCU, and then MCU goes on and, you know, signs transactions. Now, the ledger model, it's, it's, it's interesting. It's, the, the low level firmware, it's, closed source, but the apps that run on top of it are open source, and in a way, they say it's the, the most secure because you're running everything on the secret element. The secret element is a close, specification, or, You know, you need NDAs to know more about it and, and, and so on. And there's no way you can check these things yourself. Like you can check that it has the, you know, the stamp that it was certified for all these things, and but you can't check anything else. And, and actually, on any of the chip, whether Trezor or Ledger or Coldcard or Jade or any other chip out there, you can't verify anything. Once you have a device with you, you have no idea if you're running the legit device or a different one. With Ledger the ledger can say, it's called remote attestation, the ledger has a private key internally and can sign something, and this private key is authorized by ledger, so you know that's a genuine ledger device un-until, you know, someone breaks the security because then they can sign and say, \"Yes, I'm a ledger,\" and they're not. But for now, it seems that ledger is the only one that can safely say, \"I'm a ledger,\" and you can trust it. Trezor cannot do that, Jade cannot do that, I don't think Coldcard But I don't think, you know, there's a way to, to check any, that it was manufactured by them and not modified, other than the, you know, the plastic bag is untouched. Other than that, I don't think you can. Like if it was done before it was packaged, for example, I don't know if that's possible. But anyway, Jade, it's more similar to Coldcard than Ledger or Trezor. It has an MCU with, secure boot and flash encryption, and on top of that, because I didn't really trust this hundred percent Be able to break, you know, things like Trezor and Coldcard have been in the past broken by Ledger, and, and so I'm aware of, you know, strong, attackers what they can do, or at least I'm partially aware, right? I, I, I know at least the, the tip of the iceberg, maybe there's more, right? And so I, I couldn't really trust this security feature that Cheap offered, and I, I basically took an idea that already had for Green, Green uses a PIN server as well, it wasn't And, without being trivially to brute force, because four digits or six digits even is trivial to brute force, you know, if, the stuff is just encrypted local. Which is why, you know, the hardware wallets don't use the PIN to encrypt the secret, it would be, it, you know, basically relevant. You dump, you dump the thing, you try all the combinations, you're done in, in no time. So this blind PIN server doesn't know your PIN, it, it knows a, a hash of your PIN plus something else that is thirty-two Pin. It doesn't know your IP because we also support Tor. Doesn't remember anything about you and the data that it has about you, which is like the pin attempts left. That's basically the only information that's left about you, the-- and, and a public key that has been generated on your device that is, basically ephemeral, like if you reset the device, it's a new key every time, and it's unrelated to your mnemonic or, you know, anything like that. And yeah, basically there's a dance between Jade and, and this main server. They don"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "56:19",
      "start": 3379.25,
      "text": "But the companion app can take the messages, pass them over, and they're encrypted, those messages, authenticated, encrypted, the, the companion app cannot replay them or read them, and yeah, they pass through the pins through the pins through the pins through replies, and at, at some point, y-y-if the pin is correct, you, you get back an AES key that you can use locally to decrypt the mnemonic on Jade. Or if the PIN is wrong up to three times, both the Jade and the, and the remote PIN server, delete the secret. And, you can run your own PIN server as well. There's a Docker image that we prepared, but you can, you know, rebuild it or run it locally on a Linux box. It's very light to run, and, again, it supports Tor, and Jade supports alternative PIN server as well, so you can tell Jade, \"Hey, use this different PIN server,\" I don't, you know, when I use the"
    },
    {
      "speaker": "stephan",
      "time": "57:04",
      "start": 3423.76,
      "text": "Block You have a, it's a hash of a PIN and something else that is sent to the server, PIN that the companion app sends to the blind PIN server, and the default case is Blockchain runs it for you, but you can run your own PIN server, and then it comes back, and it basically sends back like a right or wrong, and if you get it wrong three times, you have to reset that Jade device, basically, and like put in the new, like put the mnemonic back in on it, but otherwise, if it sends yes, then it's good, and it's, and then only Signs. That's, that's the general idea?"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "57:40",
      "start": 3460.3,
      "text": "I, it's not for signing, it's, basically at the beginning when you turn it on, you can unlock it. Once you unlock it, you can sign multiple times."
    },
    {
      "speaker": "stephan",
      "time": "57:48",
      "start": 3467.69,
      "text": "I see."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "57:48",
      "start": 3467.97,
      "text": "It, it works almost the same as the Pin on Ledger or, or Trezor and possibly both card when it comes to- Right. So it's like logging into the device, yeah, yeah. it's just that it doesn't have locally the, the key to decrypt, it's somewhere else. The company doesn't see anything"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "58:08",
      "start": 3488.36,
      "text": "The, the can, the, the server and the Jade authenticate these messages so that there can't be, you know, anything foolish happening. And yeah, I mean, if you don't like this being serving, not only you can run your own, but you can also use the QR or compact QR standard so that, you know, i-i-is what they now call stateless hardware wallets, right? Stateless because you don't, you never store the secret, you reset it every time after you use it."
    },
    {
      "speaker": "stephan",
      "time": "58:33",
      "start": 3513.2,
      "text": "I see, yeah, so you would scan in the, it's like sc-scaning in Another way to use the device."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "58:40",
      "start": 3520.46,
      "text": "Okay. Cool. The reason I didn't go for, you know, a secure element is because I think that the best secure elements are the ones where you sign inside the secure element, in my opinion, not the ones that just hold the secret until, later. I think that every hardware device can be, you know, modified or replaced before it reaches you, or maybe it already reached you, but someone in your house has access to, to change some things, unless you're really careful, right? Yeah. I, I think that the DIY, You should only do that stuff if you know what you're doing, really. But, something like the Pin Server is really the only way to be safe with, with the DIY, in my opinion, other than, you know, the stateless stuff. Because if you're not gonna be stateless, if you're gonna store state, those devices are easy to reflash or change or, update, and it's trivial to decrypt the, the memory without something like Pin Server."
    },
    {
      "speaker": "stephan",
      "time": "59:30",
      "start": 3569.97,
      "text": "But I guess in some cases there's a benefit for the statefulness if you are doing that thing where you register To the other devices into your device, so it knows, my change, the change address belongs to, you know, to me, right? I guess that's one benefit, but the downside, as you were saying, it changes how you think about things if you're having, if you're holding state in the device versus not, right?"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "59:54",
      "start": 3593.87,
      "text": "Oh, that's something I wasn't, even thinking about right now. I mean, when we were talking stateless, I was mostly thinking single sig, but yeah, I mean, obviously for multi sig, it's better if the hardware commits to"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "01:00:08",
      "start": 3608.44,
      "text": "So on belongs to you and nothing has, you know, changed the multisig policy. Yeah."
    },
    {
      "speaker": "stephan",
      "time": "01:00:14",
      "start": 3614.08,
      "text": "One other thing we, I wanted to chat about is, so I know this is a Block three initiative, it's called Build on L2. So what can you tell us about that?"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "01:00:22",
      "start": 3622.33,
      "text": "Well, it, it's an initiative to get people generally interested in Lightning and in Liquid, building on top of, c-lightning and/or, you know, elements for other Liquid components. And, and yeah, making easier in general to use Lightning. Yeah."
    },
    {
      "speaker": "stephan",
      "time": "01:00:39",
      "start": 3639.04,
      "text": "Yeah. And so as I understand, there's going to be some hosted activities, I think hackathons and virtual events and things like that. I suppose it looks like, as well from the site, there's going to be some mentorship and coaching and development programs there also."
    },
    {
      "speaker": "lawrence_nahum",
      "time": "01:00:52",
      "start": 3652.93,
      "text": "Yeah, yeah. I mean, I can't really add too much, and I think some of these things are still, I mean, not exactly work in progress, but we're still organizing the people, organizing the sessions and, and the infrastructure for, for some of this stuff. I"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "01:01:08",
      "start": 3668.96,
      "text": "About Signet, because using something like Signet provides stability where you can play with this technology without really using neither real funds from Mainnet or unreliable Testnet, right? Right. So Signet, you can have reliable blocks, you can have a nice faucet that always, always gives you fund and funds, and you can reset it anytime. And, yeah, 'cause the other thing I was hearing is that Lightning doesn't work that well on Testnet, like the, the- Not that many, there's, there's no nice, you know, network there compared to mainnet for whatever reason, and maybe on Signet, we could have a more stable, better, you know, lightning network, obviously not for real money or, that kind of use, but only for testing and learning. Yeah, but for testing purposes and things and yeah, yeah, and reliability when, when doing so."
    },
    {
      "speaker": "stephan",
      "time": "01:02:00",
      "start": 3720.21,
      "text": "Fantastic. Well, yeah, I think that's probably the key, points, but, yeah, in terms of any, I guess, Listeners, anything you wanna close off with? yeah,"
    },
    {
      "speaker": "lawrence_nahum",
      "time": "01:02:12",
      "start": 3732.28,
      "text": "well, thank you for having me and, enable, mempool for BFF equals one. and that's it really."
    },
    {
      "speaker": "stephan",
      "time": "01:02:21",
      "start": 3741.03,
      "text": "Fantastic. Well, yeah, great to chat and, hope to chat again soon. Thanks, Larry. Thank you. Get the show notes and the transcript over at stephanlivera dot com slash four three eight. Thanks for listening and I'll see you in the citadels."
    }
  ]
}
