{
  "episodeId": "SLP584",
  "speakers": {
    "stephan": {
      "name": "Stephan Livera",
      "role": "host",
      "tag": "STEPHAN"
    },
    "tiero": {
      "name": "Tiero",
      "role": "guest",
      "tag": "TIERO"
    }
  },
  "segments": [
    {
      "speaker": "stephan",
      "time": "00:13",
      "start": 12.99,
      "text": "Hi everyone, welcome back to Stephan Livera podcast brought to you by Swann Bitcoin. Over at swann dot com, there's free buys on Bitcoin on your first ten thousand dollars of buys. Joining me today is Tierno, from Ark Labs. Now, Tierno is prob- Tierno is his nickname, Marco is his actual name, but he's probably known as Tierno in the Bitcoin Bitcoin world. So, Tiero, do you want to just, you know, welcome to the show and, give us a bit of a background on yourself, just people know, for people who don't know you?"
    },
    {
      "speaker": "tiero",
      "time": "00:39",
      "start": 38.87,
      "text": "Stefan, first of all, I'm honored to be here, really. I've been following the show for many years, and yes, I'm really, really excited to be here. yeah, I've been working the Bitcoin space for, for a while. when I was 18 years old, I, created one"
    },
    {
      "speaker": "tiero",
      "time": "01:00",
      "start": 60.04,
      "text": "There, you know, I started, you know, working the industry and I did many, many things. In two thousand and seventeen, we co-founded Wulpen Ventures, which is this like venture builder and R&D lab with, you know, an investment wing. So, yeah. And now I'm, super excited to be here and talk about Taro and talk about Taro Labs."
    },
    {
      "speaker": "stephan",
      "time": "01:18",
      "start": 78.21,
      "text": "Great. So, yeah, a-as I, I know you have a very technical background and you kind of-- I mean, you've been around Bitcoin for a while, so you kind of are And explain some of this. So now, I do have an earlier episode on ARK, but it's probably a good thing to just kind of walk through very basic level for the non-technical listener. Do you mind just giving us a bit of an overview to ARK kind of as it is today?"
    },
    {
      "speaker": "tiero",
      "time": "01:46",
      "start": 106.39,
      "text": "Sure, sure, absolutely. I really think that the best way to have an intuition of what our key is and, what's the approach is really looking at if it was a bank, a trustless bank. So this trustless bank is issuing to you a VTXO, which, you know, in normal terms, it is really is like a bank check But with an expiration, which means that every time, you wanna, you know, transact with someone else inside of this trustless bank, you need to, you know, take your check and ask to, the coordinator to, you know, create a new check for someone else. And the interesting part is like this check allow you to get your money on Bitcoin, on chain, every time, even if this coordinator, even if this bank disappear. So I think this is, the important caveat, and the expiration is Part of the protocol to allow an, an efficient, liquidity for the bank itself. but yes, I think this is really like the, E-5, you know, better that you can get in terms of like trying to get an intuition, what it is."
    },
    {
      "speaker": "stephan",
      "time": "02:51",
      "start": 171.46,
      "text": "Yeah, gotcha. So in simple terms, it's a way to send a virtual UTXO, right? A VTXO, around, and you need an ASP, an Arc Service Provider, or I guess the coordinator as well, that kind of plays both roles. And there, the idea you're saying is that there might be multiple ASPs out there, the user might have, you know, a different app that kind of deals with it, and it's, I guess, the idea, and in terms of the- The main benefit, right, before we get into the technicals, the main benefit, as I understand, is that people can onboard without having to onboard into a lightning channel, right? Because in lightning, if I wanna open a channel with you, or let's say I'm a, let's say I'm a noob and you're trying to onboard me You have to either open a channel to me, or I need to somehow-- someone has to open a channel to me, and that's currently today an LSP is doing that with a, what's called a just-in-time channel, but that requires hitting the chain. And so I guess the idea is you can have a kind of off-chain onboarding per se, but I still have something that I can claim on chain if I need to. What do you think?"
    },
    {
      "speaker": "tiero",
      "time": "03:59",
      "start": 238.85,
      "text": "100%, 100%, and I think the important piece, is that ARC as a protocol has been designed for the last mile, where, as you can imagine, you go in the street, you find someone else, and you convince them to accept Bitcoin. In 2013, I was doing this, you know, I w- I was going to every shop, every merchant, and I was convincing them to, you know, download a simple wallet at the time, non-custodial for Bitcoin, and boom, I send one That time was possible, but was so super easy, super easy to onboard a new participant in Bitcoin with Lightning. Well, the things start becoming more complicated because you need to-- you have a leak abstraction basically, right? So you need to explain many things to low level, things to people. Like inbound liquidity is one of the most controversial thing to explain. For example, hey, I'm sending you one dollar, but why ninety cents have been, you know, deducted to my-- to what I received? You told me Bitcoin is fast and cheap, right? So I think it's very- Very hard on that, on that side. and in general, yes, allow you to receive offline, and you don't need to be online, you don't need to be a server, you can be a light, light wallet, and this is very important for, you know, lowering the barrier for everybody to enter at the beginning. So I think yes, the, you know, this is totally correct."
    },
    {
      "speaker": "stephan",
      "time": "05:16",
      "start": 315.58,
      "text": "Yeah. Okay. And so taking it maybe one step more complexity, let's think of it like this, that your wallet, so let's say the end user has his His wallet is gonna receive this vtxo and it needs to periodically watch what's happening, right, to understand that you're not getting stolen from or whatever. But you've set that up on like a, is it like a one month cycle or what kind of cycle? And can you explain a little bit about that?"
    },
    {
      "speaker": "tiero",
      "time": "05:43",
      "start": 343.24,
      "text": "I think it's obvious right now to every researcher, but in general to the general public, that if you wanna scale, you need to have trade-offs. And I think the liveness trade-off, which means that you can't just disappear. I think the beauty of Bitcoin on chain is for an investor is you just throw your funds in a su-multi sig or a single sig, but you can forget about it, right? In ten years, likely you will be able to recover, no need to have a any other participant to help you. And I think this property is very- To keep in any second layer, you can guess. So yes, ARC is, you have a liveness requirement. I think it's important to notice that, it doesn't require you to be constantly online, but you only need to be online for, let's say, very briefly, couple of seconds before your check expire, before your virtual utxo expire, you need to be just to be online and say, hey, I want a new one, right? I don't want, I don't want it to expire. You can redeem it on chain if you want, but Pay on-chain fees every, every month, let's say, so you wanna refresh it, right? So I think this is very important because in Lightning, you constantly need to monitor, your channels in case, you know, you need to broadcast your justice transaction. It can be someone else, but you see, you start depending to someone else to be, to have your own funds. Here, really, it's very super simple, you just need to be online once. And if you think about the use case of Ark as a checking account or in general, normal day I mean, I personally check maybe my, my bank, bank, bank app every day, right? So there is a push notification every spend. So I think it's very acceptable for that specific use case. Again, for cold storage, there is no second best like on chain, right? But this is not definitely not for, long term saving. Maybe you keep having ARK, you accumulate on ARK, and then you can redeem on chain when, you know, the fees, are good enough or you can, you can afford to pay, on chain, you Yeah."
    },
    {
      "speaker": "stephan",
      "time": "07:41",
      "start": 461.18,
      "text": "And so can you also just explain, is it gonna be a similar concept where, let's say, nowadays if somebody's getting onboarded with a Fed Mint or a Cashu, and then they wanna make payments over the Bitcoin network and they wanna do like a Lightning payment, is it gonna be a similar concept here with Arc, like the Arc wallet that the end user is gonna use, actually when he wants to make a Lightning payment, it's g-- the ASP is also gonna be an LSP who does the Lightning payment for them. Is it gonna be a similar concept there?"
    },
    {
      "speaker": "tiero",
      "time": "08:08",
      "start": 487.9,
      "text": "Sure."
    },
    {
      "speaker": "tiero",
      "time": "08:11",
      "start": 490.96,
      "text": "is that being, is really a way for entities to settle between each other, especially when you have frequent, you know, back and forth payment, right? So if you have two banks or two server or two financial institution, maybe every month you go, you go back and forth on the same path. And I think Lightning there shines, it's perfect. And again, these are entities, they can run server, they can have, you know, devops team, and I think the beauty here is like every coordinator can definitely be connected to other Other coordinators or to other services through the Lightning Network, and Lightning Network really is becoming this lingua franca, you know, to connect all this kind of layer and all this kind of, you know, entities, and that's what, what I really see personally is really see ARK, as an application, you know, that is using Lightning under percent, and, and, yeah, I totally think that that will be, will look like, so people will use Lightning, will use ARK at some point, they don't even know, what they're using, For the right, you know, use case and, and the right approach,"
    },
    {
      "speaker": "stephan",
      "time": "09:15",
      "start": 555.29,
      "text": "Right. Yeah. So I guess in this way, it's important to spell out it's not necessarily a competitor to Lightning, it's kind of like using Lightning, with different trade-offs, right? Because again, as we've kind of established, not every-- Like, I think it's fair to say in 2017, the Bitcoin community made a choice That we didn't wanna kind of do this kind of big block scaling, right? That was the choice we made. That's the trade-off we, I guess, implicitly are making. And so that necessitates some trade-offs. I understand, you know, now I'm a, you know, a fan, a promoter of Lightning myself, but there are times where people criticize it and say, \"Well, see, look at this trade-off you're making, da da da.\" But ultimately, it comes back to 2017. This is the trade-off we made. There's always gonna be certain trade-offs that you're making somewhere. Now, one aspect that we can probably get into as well is around the liquidity and, you know, in a Lightning context, if you are using, you know, Phoenix or some, you know, Zeus or Mutiny or something like this, you have to have an LSP channel, right? And so the LSP is having a capital requirement there. Now, in ARC, it's not taking it away, it's just placing it in a-- it's kind of using it in a different way. Now the capital requirement is at the"
    },
    {
      "speaker": "stephan",
      "time": "10:26",
      "start": 626.5,
      "text": "Level, so they're kind of managing, let's say, an overall balance. Maybe it's a bit more like that. so, I mean, before we get further into that, I, I just wanna, I guess, understand from you H-Has the ARC concept shifted a bit over time? Because I've heard people talking about, as an example, Clark, which is kind of covenant-less ARC, or this idea of out-of-kind of out-of, what's it called, out-of-transaction or out-of-something-round-payment. Yeah, out-of-round payment, sorry, that's the one. Yeah. So if you could maybe just explain some of the updates on ARC as a concept? Absolutely,"
    },
    {
      "speaker": "tiero",
      "time": "11:00",
      "start": 660.04,
      "text": "and I think the, the interesting part of ARC is being a client-server protocol. It doesn't require the consensus of every peer of the network. It doesn't need to form really a peer-to-peer network, so every client, every piece of software need to run the same subset of rules. I think this is an advantage because going back to my analogy at the beginning, you can have a bank that is charging you a different liquidity fee, but not only that, it really, it can have different rule and maybe even the past people- People have read, you know, specific terms or s-s-specific numbers, and they are just magical number, you know, five second round or one month expiration. Those are totally arbitrary, and I think every SP based on his own use case will have his own, set of parameters. I see. Right. So I think it's,"
    },
    {
      "speaker": "stephan",
      "time": "11:46",
      "start": 705.66,
      "text": "it's, so the, yeah, I guess it's not as helpful to think of it as like, what, one transaction every five seconds in the block and one month expiration. It's really more like The ASP will tune that based on what they wanna provide as a service. And you know, maybe there'll be kind of different trust models, maybe there'll be certain trust models where you're kind of like, \"I know my ASP, so I'm gonna trust him more, and he's gonna trust me more.\" Maybe there's element of that too. And then maybe there's another element where maybe you don't-- there's kind of like less trusting environment, so they kind of have more, I guess, paranoid, trade-offs."
    },
    {
      "speaker": "tiero",
      "time": "12:18",
      "start": 737.89,
      "text": "No, absolutely, and I think it will be an emergent property, right? So there will be a discovery phase where every SP based on his own use case will really tune, the right parameter and the right sub-substitute trade-off. One thing, one thing is also important, you know, to notice and maybe, I mean, you know, you're an Austrian, you know, fan, but, you know, maybe can emerge a new SP that, is under collateralized. So it's maybe saying to you, hey, there are zero point eight, BTC, out of one. I mean, this is really controversial, I'm telling around, but just saying that, you know, every SP can really have its own rules and if the client agrees, because in the"
    },
    {
      "speaker": "tiero",
      "time": "13:01",
      "start": 781.4,
      "text": "We can really go, go forward, this way. And in general, I think, when people talk about liquidity issue or liquidity problem, it's very important to understand that every liquidity problem, you know, is different to each other. which, for example, if you are in a B, B, B2B or enterprise, let's say ASP, so where you're like maybe twenty player doing maybe huge settlement, you will have different parameter and also different kind of liquidity issues, right? So I think that's, really will be a There will be a discovery process where, you know, every SP will tune based on its own use case and, and every community will also form around, this SP. that being said, every SP can also federate or can be also a peer-to-peer version of an SP, which we are researching, we're very excited about that. But, yeah, let's not, Yeah. Okay. So let's bring it"
    },
    {
      "speaker": "stephan",
      "time": "13:52",
      "start": 831.55,
      "text": "back to some of those, key, concepts that have maybe e- either innovated or been discussed. So this"
    },
    {
      "speaker": "stephan",
      "time": "14:02",
      "start": 841.5,
      "text": "payment. So I guess my previous understanding was, okay, again, as, as I said, it doesn't have to be every five seconds, but the idea is it's kind of-- you can sort of think of it like it's like a coin join happening every five seconds that the ASP is putting transactions into the block. Now, my understanding is one trade-off that the teams are looking at now is maybe instead of having one transaction every five seconds, we can make that round time longer, but the trade-off or one thing that allows us to do that is to have this concept of out Round payments. So can you explain what is an out-of-round payment in ARC?"
    },
    {
      "speaker": "tiero",
      "time": "14:36",
      "start": 875.68,
      "text": "Yeah, I think, as you mentioned before, I think ARC when it started was just, you know, an idea, and of course, maybe there were some opinionated, let's say, parameter or opinionated way on how to implement, but as you know, in software, you have great ideas at the beginning, but until you get actually building, I mean, you can get very detailed with specification, but I think like the, until you are there, until you are actually implementing the software, you don't Shown after the initial year of prototyping we've done with the, with the team is really that there are potentially an emergent, layer on top of ARC, which we, we call ARC out of round, which basically, in a very simple way, allow you to just cooperate just with the coordinator, just with the ASP, and say, hey, please co-sign this, v-tixo, to Bob, right? So this is Marco, I want, I want to, I want to pay Stefan, like, please, can you co-sign with me We think so, to Stefan, but let's not never broadcast in a round. Like broadcast is an improper term, I'll say let's never include in a round, right? in an arc round. And of course, the model here, here, here is, is me with the SP, we can revert that payment until you, Stefan, don't join the round, because we'll change, right? So instead of being me with the SP to join the round for you, right? We will simply, you know, send out of bound, maybe on Telegram, on email, and say, Payment link, right? So this is very common in every fintech application, right? I send you a simple link, very similar to eCash, right? So I just send you, piece, a piece of data, and with that piece of data, you will be able to claim your VTX in actual round, and maybe you don't claim it now, you claim in two weeks. This is very similar to how credit, credit card payments work. This is very similar to, you know, all the digital commerce work. You have this concept of, you know, chargeback and reversible payments"
    },
    {
      "speaker": "tiero",
      "time": "16:31",
      "start": 991.28,
      "text": "And so yeah, I think that, that will-- the beauty of that is like it doesn't require liquidity. So the SP, well, it, it's not really doesn't require liquidity, it's just that for the SP, the liquidity will be known. So he knows that there is like two weeks, in two weeks, potential there will be need for the liquidity. And I think like all the people complaining about liquidity, especially if you came from software and not came from finance, it's like, it's not about the amount of liquidity, because if there is, you know, reward for Is not knowing in advance the inventory that you need to keep, is not knowing in advance the, the cash flow that you have. So that is a very important problem. So imagine that, you know, most of these art payment will be done out of round, basically you are doing a list of request to the SP and say, hey, there will be that amount, that amount of payment to expire in the, in this month, so you need to source the liquidity. So I think this is a very interesting, trade-off and definitely for payments, you can have instant payment, Almost free, payment and, yeah, it will help the protocol definitely to, for more com-commerce retail use case."
    },
    {
      "speaker": "stephan",
      "time": "17:38",
      "start": 1058.23,
      "text": "Yeah. Now, my understanding of the trade-off here, now I saw, Stephan Rus give a talk at this, in Bitcoin Seoul, and so he was explaining a bit around, this idea, and he was saying it's similar to a state chain kind of trade-off, like it's kind of like you're trusting that the- State chain coordinator doesn't collaborate with the prior sender. Is it, is that right or what's the main trade-off around doing this out-of-round arc payment?"
    },
    {
      "speaker": "tiero",
      "time": "18:07",
      "start": 1086.97,
      "text": "Yeah, there are, I think there are maybe potentially two approaches, for this out-of-round, approach. One is being proposed by, Ruben Sampson, the shortcut. And I think the state chain approach is a little bit different than what I, I try to explain in the sense that you may not have the reversible, property, but At the same time, you need to trust that at least one, of the, of the participants isn't basically, you know, colluding, with you. I think you, you have both this emerging property where basically if you really want to have a non-revertible payment, you need to join around. So I really see this as a layer on top of it. So you, you are always free as a recipient to say, \"Hey, I wanna join around now, and I will pay the liquidity, right? So I will pay the liquidity fee But DSP, you can keep it longer, let's say, right? So that-- but in general, that's, about you. I think there are two different property, I think they are not that different to each other, but yes, like, there is also the state chain, approach, on top of it."
    },
    {
      "speaker": "stephan",
      "time": "19:11",
      "start": 1151.35,
      "text": "I see, okay. And then while we're here, we might as well talk a little bit about fees. Now, again, this is again, how long is a piece of string question? It can really vary. Even in the Lightning world, it kinda depends, okay, which LSP are you using, right? As an example, if you use Phoenix today, I think it's, one percent inbound liquidity fee and zero point four percent on your outgoing sends, right? And then, now let's say you run your own Lightning node, maybe if you can run your own stuff, maybe kind The typical fee rate you'll find is maybe more like zero point two percent, but you're doing your own channel open and close and all this kind of thing. So can you give us an idea in arc what kind of fees could the end user expect to see, or is it just even too early to even give an idea?"
    },
    {
      "speaker": "tiero",
      "time": "19:56",
      "start": 1195.54,
      "text": "No, sure. We've done some simulation and, and that was also important for us to touch with our hands what will look like in a real life scenario. I think in the end, the fees are a function of, you know, the age of your check, of your vTixo. So, if you're spending a vTixo very closer, to its expiration, that will be much better for the liquidity OSB. And the other, component, is how much capacity is left in the arc. If you are like, imagine, ten of ca- of available capacity, which means that, you know, the ASP for the future can process all, all ten BTC of volume. If someone is coming and say, \"Hey, I wanna make a five BTC,\" Payment, like in, in around, well, that's fifty percent of the capacity, that should be priced. That should definitely say, \"Hey, I need to discourage you to do this because you are emptying my, my capacity for others that may need. So if you really need, if you really need to do this, you need to pay a little bit more.\" So I think that these two, component are important to determine, what will be, what will be the fee. It's definitely not like percentage based like people are used to credit cards, but I think it Much more similar to that, right? Because it removes the inbound liquidity, in terms of like concept to understand for user, it's just a matter of function of things that he can impact. So you can say, okay, my wallet with coin selection will be more smarter, right? virtual coin selection will select the coins that are like with, you know, close expiration and maybe, you know, I will be wary to fat fingers and, you know, a lot of Bitcoin, if the fee is, is too high. But I think this is something the user can, Remediate from a UX standpoint. so yeah."
    },
    {
      "speaker": "stephan",
      "time": "21:40",
      "start": 1299.75,
      "text": "Back to the show in a moment. This show brought to you by CoinKite dot com, the creators of the best Bitcoin hardware security devices, such as the Coldcard Mark IV and the new Coldcard Q. Now, we use Bitcoin hardware security devices to keep our keys offline, our private keys offline. Now, the way these work is you can do that setup, write down your twelve or twenty-four words on those, the seed word cards, and keep that secure. Now, you can- You can use this device to interact with the Bitcoin network using software such as Sparrow Wallet, Electrum, or Befiktor Desktop or Nunchuk as a few examples. Now, you have a range of security features that you can use with these devices, such as passphrase, you can use seed x or, or my favorite is multi-signature. Now, if you're starting in a basic way, just start with the device and the USB-C cable, plug it directly to the computer and use it that way, and then later improve your setup. But I believe these- These devices are great at helping secure your coins, especially as you start to migrate up into multi-signature security. But don't be disheartened or don't be, scared away. They are accessible, and I think you actually do learn about Bitcoin in the process. So to get yours, go to coinkite dot com, use code livera to get a discount on your cold card. This show also brought to you by mempool dot space, the leading Bitcoin and blockchain visualizer. I use it all the time when I'm checking transaction fees and trying to understand what is the state of Bitcoin's mempool. You can search transactions, historical as well as unconfirmed ones, and also see a great way to visualize things across the Lightning Network, Liquid, mining, and so much more. Also, for those of you with an enterprise, they offer a mempool dot space enterprise program. So for those of you as- Part of that enterprise program, you might wanna get increased API limits, and you might wanna have increased access to the team in terms of feature requests. You might wanna have special branding in terms of how your custom instance of mempool dot space looks. So to sign up for that, go to mempool dot space slash enterprise. And now, back to the show. Yeah. And so I guess summarizing then, there's an expiration component to it and a capacity component to it, and let's say each ASP will set The fee obviously according to what they, what kind of model they're working on, who they're working with, are they working with enterprise level people, are they working with maybe high net worth people, or are they just kind of everyday, you know, regular people who are using the ASP? and so I guess, you know, that's one aspect of it. And then when it comes to the, you know, now we're thinking about the ASP level, who's gonna run these? How many will there be? Do you have any ideas around that?"
    },
    {
      "speaker": "tiero",
      "time": "24:25",
      "start": 1464.64,
      "text": "Yeah, it's Will tend for, for obvious reason, the capital will tend to be allocated. I think the SP is doing two jobs, right? One is coordinating, and one is providing liquidity. In the real life scenario, these two roles, likely they won't be the same entity, because if you're good with server, usually you're, you're not good with money, and vice versa, right? So I think one thing we are really, researching here is making sure the coordinator can be a piece, where can scale to zero. When I say scale- To zero, it means that if tomorrow a piece of software disappears in the system, the speed doesn't go down at all, right? So this is really like more similar in a cloud infrastructure where you have like little microservice, so if someone goes down, you, you have a new one. So the coordinator is very dumb as a job, is really just a single point to facilitate all people to, join, rounds and, and, and distribute all piece of information to everybody. And I think that part likely, it's a perfect candidate for a peer-to-peer approach or let's say a more bespoke model or more like, let's say, using, you know, you know, more like, encrypted channels or anybody really can do that, maybe get a fee just for the job of running, of being an online server, right? Without even providing capital. On the other side, we see who is allocating capital, and to me, unlikely those will, will run servers. So likely I see structured financial product that, you know, you can create a bond that basically saying, okay We, we are, you know, borrowing from, lassers or lenders, and then we are basically lending because that's what, you know, I, I did a talk in Bitcoin Plus Plus about this, but I really see the operation of a liquidity provider in ARC to be a lender, really. What he's doing is lending to you on UTXO, in exchange of some fees, and then you have an expiration, so you, you're getting back your, your, your loan, right? Your, the principal. So I think that's very natural"
    },
    {
      "speaker": "tiero",
      "time": "26:27",
      "start": 1587.1,
      "text": "In QTE, regardless of the coordinator, right? So it will be more complex than a single server that does both job. That's the easiest way to understand, the easiest way to implement, but as you know, like We are in Bitcoin, either you go Bitcoin style from the beginning or, or not. So I think that would be the, the case then, on, once you have this, let's say, more peer-to-peer infrastructure, you can build a vertical, you know, vertical centralized, very efficient, let's say, server, and that will be something, you know, SP will do on top. I definitely don't see, especially in Bitcoin, a huge number, right of, of SP, but remember, behind an SP can be a frost, you Without having a script, just a single, you know, cryptographic, multi-party, you know, wallet with using Frost and any other way. So really that will allow everybody to join and just provide liquidity without trusting other liquidity provider, right? So it will really be, a way. And the interesting part, like compared to providing liquidity to Lightning, right? In Lightning, it's not just, \"Oh, I need to have money.\" In Lightning, you also need to understand the network. You need to understand the topology of the network. You need to understand where to deploy. You need to be, you know, Bitcoin and Lightning network aware of where the capital is going. In Arq, the beauty of that is like you maybe are sitting in your office in New York and you don't even know what Bitcoin, how Bitcoin works, you're just providing liquidity, fire and forget. Of course, like, you need to run a piece of software that is, By liquidity in a single place and everybody is drawing liquidity from that, single place. So it's much more, you know, financial, you know, it's much easier to create a financial asset, around this. I see, yeah,"
    },
    {
      "speaker": "stephan",
      "time": "28:11",
      "start": 1691.37,
      "text": "okay. So yeah, interesting because, yeah, as you said, in Lightning, you have to think about Which direction the channels are going, where's the liquidity, and kind of where are-- you, you wanna ideally open channels in the direction that someone is trying to make payments so that you can collect routing fees, and maybe if you're an LSP, so that you can provide, provide a good service. But at an ASP context, in an ARC context, it's more just kind of like a, a blob, right? It's like a blob of capital that, you're using to, let's say, create this ASP concept, and individuals who are using that, who are onboarded to ASP or ARC, they are getting these VTXOs, and that's kind of their, their claim on that. so I guess the other thing that comes to my mind now is kind of, and, you know, people have spoken about this idea of thundering herd in Lightning, right? This idea of, oh, what if lots of people all need to exit at once? What if lots of Lightning channels all have to hit the chain all at once? And, you know, in Bitcoin, let's say an average block might have three thousand, maybe four thousand transactions in it, and so once Numbers, that could be a lot of people who all need to hit the chain very quickly. So do you have any thoughts on how to manage that with ARC?"
    },
    {
      "speaker": "tiero",
      "time": "29:24",
      "start": 1764.25,
      "text": "Yeah,"
    },
    {
      "speaker": "stephan",
      "time": "29:24",
      "start": 1764.45,
      "text": "I think like the"
    },
    {
      "speaker": "tiero",
      "time": "29:25",
      "start": 1764.99,
      "text": "initial idea being proposed by, you know, I mean, Jeremy Rubin has been, you know, championing this, with CTV at the beginning, I think the congestion control approach is, okay, we know that we can't fit right now, in the, in the chain, but if you trust the Bitcoin script, we can really making sure that, you know, the, the withdrawal is like, you know, step by step, let's say, you know, you don't, you don't go everybody like, let's say, one hundred BTC all at once in, in the mempool, but every, you know, every layer of the tree,"
    },
    {
      "speaker": "tiero",
      "time": "30:00",
      "start": 1799.83,
      "text": "Every leaf, you start rolling away that first, goes there, so you wait, so you know that maybe you will get your money in six months, right? You know, you know for sure that in six months you will get your money at that fee rate, right? So you're not going to burn everything in fees, because, you know, the fees building up. So I think congestion control is one approach. Of course, the Trade off there, I mean, like the issue there is the UX isn't that, you know, great and because for a user you need to wait all of this, and every time there isn't, you know, A delta, right? the, the out point is changing. So the process of unilateral exit congestion control is long, and you need to keep monitoring, right? Because your out point on chain are changing every time someone is exiting, so you need, like, the round out point is-- So, you, you know, it's a bit complicated. Of course, like, we, we hope that there will never be unilateral exit, but that's the, the point of our, right? To have this unroll that everybody can do, at any time. So congestion control is definitely one We can be like, you know, full whiteboard, you know, like we don't need to think about, Bitcoin script constraint right now. I think using, proposal like from Salvatore, you know, with MAT, right? So, using that type-- And that applies all"
    },
    {
      "speaker": "stephan",
      "time": "31:16",
      "start": 1876.38,
      "text": "the things, yeah."
    },
    {
      "speaker": "tiero",
      "time": "31:17",
      "start": 1877.44,
      "text": "Yes. Any type of a code, it doesn't need to be the CCB, right? So any type of a code like just if I stack plus CAT or any type of, you know, opcode that enable those type of approaches, you You exit, but just yourself. And this will be optimistic, so there is a, a game, right? So a bond game, so you're putting there some bond, so you, you sure, so you want to guarantee, you want to put your word, your money, you will say, yes, I'm not, cheating. If someone call you cheating, you will slash you, right? So I think this approach definitely is another way which is much more light, better UX, just a single exit, a single hop exit, and, and definitely like it"
    },
    {
      "speaker": "tiero",
      "time": "32:02",
      "start": 1922.01,
      "text": "The difference between looking at ARC or in general to any scaling proposal with, you know, a full, you know, full spectrum without being constrained on what is possible. Initially maybe ARC was like a lot CTV oriented because, you know, maybe seemed that CTV was getting traction or whatever, so it tried to stuff, you know, what was possible with CTV, with ARC. But actually, I think if you have like a clean design space, you can really like do the best version of ARC, at least propose the best version of ARC. I'm personally not in a So many years, so I, I available to be here and working on this for the next ten years of my life at least, so I'm not in a rush. So I'm pretty sure that, you know, all this design research, will definitely also inform the covenants, research in general in Bitcoin without being pushed, right? We, we have nothing to sell. So if, if covenants are there or not, ARC is possible today and with the code, you know, we, our club's release, you know, last week, But at least it's a way to start."
    },
    {
      "speaker": "stephan",
      "time": "33:04",
      "start": 1984.47,
      "text": "Yeah, interesting. Okay, so while we're here, let's talk a little bit about some of the different approaches and what, which one requires a covenant, which one requires CTV or TX hash, or which one is possible today on Liquid versus what's possible today on main chain, like if you could just kind of spell out what are some of the possibilities today? And then we can get into more about like what specific covenants would work for Ark or what, what would be ideal for Ark."
    },
    {
      "speaker": "tiero",
      "time": "33:28",
      "start": 2008.39,
      "text": "Yeah, absolutely. I think, right after Ark was being proposed, a many researcher, I remember SuperTessen was the first one to say, \"Hey, you can do it right now with the pre-sent scheme,\" and I think he created the name, Clark, right? So covenant-less, covenant-less, Ark. And as I explained before, with this Ark out of round or, Rubin Simpson shortcut, you can definitely improve A lot, the, how it will look like with a pre-signed approach without any governance, without changing Bitcoin, without any software. So I think that's definitely possible. I think the trade-off, is important to notice, to, to explain here is you start having more bandwidth requirement, especially when you join a round, you have an extra round of communication, an extra step of communication. This may seems okay, especially if you're a server It's just an API call, it's just an RPC. If it fails, it will retry. I mean, this is like thirty years of software engineering already solved this between server. But if you're a client, you're a mobile phone, you're under a, you know, under a tunnel or, you know, whatever. I, when you are a mobile phone, you are retail consumer, anything can happen. And, I mean, in my experience working with consumer, retail app in my pre-Bitcoin experience, when you have like millions or, you know, requests per you know, an RPC API that you need to call, a network call that you need to make, that will, you know, double your chance of failure, and that is very problematic for retail and, and UX in general. So I think that's very important to keep in consideration. Depends who we are, who we are building for, right? So I think this bandwidth requirement is important because in the pre-signed approach, you need to share not only the forfeit between the server and the client, but you also need, to share the nuances of, you"
    },
    {
      "speaker": "tiero",
      "time": "35:21",
      "start": 2121.19,
      "text": "senior pre- signatories. So this is, this is the first. The second is the storage requirement. With Coinence, you can, like, very similar to backing your seed, your twelve, twelve words, you're good to go, right? Ideally, you need to find in some Gita, public open source, the script, right, the unrolled script, but on with that information, you can deterministically create your unrolled transaction, right? You don't need to ask anybody. So you understand And this is very self-sovereign and it's very easy to create light wallet, right? It's just twelve words, nothing, nothing more, nothing else. Instead, with, without governance, with Clarke, you need to keep Like very similar to Lightning, you need to keep all of these pre-signed transaction un-until up-until the expiration of the shared output. Which means, let's say one month, it means that you need to keep one month. It's not as bad like Lightning, because Lightning you need to keep forever, right? Your, your, your, your backup. That's why we, we talk about toxic backup in Lightning, right? So if you lose that, your seed, your twelve words aren't enough, to recover your, your Lightning channel. So you also need these,"
    },
    {
      "speaker": "tiero",
      "time": "36:30",
      "start": 2189.78,
      "text": "In Clark, it's very similar, right? So you need to keep, those pre-signed signature, otherwise you don't, you don't know how to reconstruct the exit, right? The exit, the exit transaction that allow you to unilateral exit. It's not that bad, again, because you only need to keep it until the, that shared output expires. After that, you can trash it. So it's a pretty good, compared to Lightning, but still you need to be considerate. That's why, personally, from my experience, but that's, that is the Component are very important when you think about retail UX, especially if you have less dependencies to any server assisted or any other piece that keeping you things. And normal people are very bad at being database administrators, very, very bad. So if you can have a protocol that is stateless as much, right, as possible, or at least not, no more than on chain, right? So on chain only those twelve words, well, that's, that's when it start becoming easy for retail. And the third point, which is very important also for me, is the interactive boarding. Which means that with CLARK, without covenants, we need to have a specialized wallet, much similar to Lightning right now, to basically do this interactive process to enter the ARC. If I have Bitcoin on chain and I wanna do CLARK, I wanna enter a CLARK I need to cooperate with the SP, right? And this for me is very important because I think this limited the adoption of Lightning. With Lightning, we need like many people convincing, begging Coinbase or Binance to say, \"Please add Lightning withdrawals,\" you know, like, \"Please do it.\" But with Covenants, the beauty of that, and this will be even true with Lightning, right? So if you get Covenants, we can do cold channel. Even here, ARC has been designed around the fact that you have only a Bitcoin address, and the sender doesn't know that that, that Address that, that is an ARK address. It doesn't know. For him, it's just a simple, Bitcoin Taproot or it can be even SegWit. It's just a simple address anybody can send. By now, Coinbase, we don't need to talk about, talk with Coinbase to please integrate ARK, and that's very important because ninety percent of normal user were ARK, you know, user, potential ARK, people that are using day by day Bitcoin for remittances or stuff like that, they don't really want to have a special, specialized wallet, right And that's it. So I think that's for me also very important, that's why I think, you know, Covenants really gets us, you know, the tools to really be a mass retail consumer, right? Yeah. So you went through a lot there. So let's just, let's just quickly,"
    },
    {
      "speaker": "stephan",
      "time": "38:57",
      "start": 2337.4,
      "text": "yeah. So let me just quickly summarize because that was a lot there. So what we're talking about in the case of Clarke, which is Covenantless Ark, there's three main trade-offs, as you said. One is the bandwidth and communication part, which is again hard when we"
    },
    {
      "speaker": "stephan",
      "time": "39:15",
      "start": 2354.93,
      "text": "In Lightning, you've got to keep your static channel backup and all the backups, the to-toxic backups, et cetera. And three, as you said, this interactive onboarding component where if we had CTV or TXHASH or one of these ideas, then, maybe it would be a more stateless and simple kind of onboarding path. So that's, I guess, the Clark component if you were to do Clark today on mainnet, let's say. Now, what about in the context of Liquid, because I know Liquid already has certain, extra opcodes? Yeah,"
    },
    {
      "speaker": "tiero",
      "time": "39:46",
      "start": 2385.58,
      "text": "I think Liquid is really, one of the most flexible UTXO chain out there, without talking about LBC or, you know, the federation, but just from a technical perspective, from what allow you, it really gives you the best possible, the most flexible subset of opcodes, right? Of, so Bitcoin Script is at the maximum there, right? So you can really do a lot of things and you can experiment, and for us has been very important because again, this is my approach, I really wanna go and talk with user and- I heard their feedback. I don't wanna be in my ivory tower or super researcher, I really wanna get some hand dirty, so that's why we have been also working with the aversion with covenants on Liquid, right? So we just, we don't want to convince them people, right? They're a researcher, we really want to get some feedback from the user, and, you know, Liquid is mainnet in terms of like there are real money there, so I think that's important for us. And I think on Liquid you can really do all these kind of approaches, and for example, beside congestion control exit, with common and beside non, you know, non interactive boarding, which we already implemented and are very, very, cool to have there, I think the interesting part will be also to research, you know, with Salvatore proposal, how to do an optimistic unilateral exit, for example, or even a way to reclaim your liquidity when a bitex-- so when a check expires, right? So thanks to this current, we can really- Really try those things live and potentially having some dedicated, wallet that is already retail, really, really consumer oriented, and we can really, you know, try on and be a test bed for what will be the future of, on, on Bitcoin."
    },
    {
      "speaker": "stephan",
      "time": "41:21",
      "start": 2480.61,
      "text": "Back to the show in a moment. The lead sponsor of this show is Swan dot com, and Swan has a mission to onboard millions of people into Bitcoin. I also work at Swan, helping on some educational content for the team. Now, the team have also put out a new version of the Swan Bitcoin application, which is available on your smartphone, whether it's Apple or Android. Now, this app has a really fast onboarding experience. It's now just a few minutes to go from zero to Bitcoin. So if you are standing there with your family or friends and you might have been having trouble trying to get them onboarded, well, try this now. Recommend Swan Bitcoin, and you can do this while you're standing next to them. They can click through, and most of them will be able to set up and do this in just a few minutes. Also, the team at Swan have rolled out a New promotion, there are zero fees on your first ten thousand dollars of Bitcoin buys. So this is a great way to go from zero to Bitcoin and in a guided and managed way. So reminder, go to your app store or Play Store and search Swan Bitcoin to get onboarded with Bitcoin today. This show also brought to you by Nomad Capitalist. Nomad Capitalist is a leading provider in terms of offshore tax and lifestyle strategy planning and implementation. They can help you go overseas And legally lower your taxes. As many of you know, I grew up in Australia, but I left. I was sick of it in terms of the taxes and the COVID tyranny and all these other things. And so that's why I left, and now I live in Dubai. But that's not necessarily the place for you. You have to think exactly what works for you, for your family, for your business. And Nomad Capitalists have worked across dozens of different countries. They've helped people get passports, residences, bank accounts, and all kinds of other things. And importantly, it's not just about Maybe also about making the pieces fit together in terms of how your business fits with your family and you as an individual. Nomad Capitalist have helped many, many people in terms of going overseas, and if you're interested, go to nomadcapitalist dot com slash apply. This is applicable for people with a net worth above one million US dollars. That's nomadcapitalist dot com slash apply. And now back to the show. Gotcha. Okay, so we've spoken about L-Clark and Liquid, and then I guess the other alternative is hypothetically in the future, if Bitcoin mainnet gets CTV or TXHash or something, could you spell out a little bit what covenant would be? Okay, so put it this way, what covenant would be the minimum kind of required? What would be optimal, for, for ARC purposes, just so people understand?"
    },
    {
      "speaker": "tiero",
      "time": "43:57",
      "start": 2636.88,
      "text": "Yeah, I think CTV is definitely, good, good enough, and, and will be totally okay. Of course, we have some issues potentially with the fee, and me-- and this, I think, this is the main concern of CTV, is like you need to use try paid for parent, to, you know, because you need to set, a not too good fee, a to be broadcasted and then you need to bump it with some other UTXO, which maybe is okay, but it's not liked by, by many people. And again, this kind of maybe yearly, reclaim of UTXO spend and also this optimistic, unilateral exit, you know, all these new research, field area won't be possible with CTV. So that's why I think it's very cool if you get it, and I will love, and I've always been like one of very vocal about in, in favor of CTV, but I understand our Bitcoin Work and I think it's just not gonna get, get being, you know, merged. It's better to try any possible solution. And one thing, one decision we, we had with our clubs, and we have this dual mandate, right? The first is really, you know, stewarding and moving forward with an open source reference implementation, and we really want our implementation to be flexible enough with a single, you know, tweak or option or configuration to go from Bitcoin with pre sign to Liquid with covenants or to Liquid with pre sign or even one Signet You know, Mutini or whatever that has CAT, so we really want to be a place where people can experiment with all these covenant proposal and see how different covenant proposal will impact of the versions. Of course, this is extra work, but we really think it's necessary. And again, I'm not in a rush, and, I think that's the, the best approach and also to serve the covenant discussion, out there. Yeah."
    },
    {
      "speaker": "stephan",
      "time": "45:38",
      "start": 2738.32,
      "text": "And so then, any thoughts on, Great Script Restoration? So I presume then, from what I'm sounding from you, what I'm hearing CTV would be good, but not optimal because of the fee inlining problem and the need to CPFP and so on."
    },
    {
      "speaker": "tiero",
      "time": "45:52",
      "start": 2751.65,
      "text": "I guess I should just quickly explain that. And the limit, the limit is your designer service fee. Yeah. So I'll just quickly explain"
    },
    {
      "speaker": "stephan",
      "time": "45:55",
      "start": 2755.05,
      "text": "that for the, you know, now, you tell me if I'm getting something wrong here, but my non-developer understanding of this is, this is kind of, in developer circles, some of them view CTV as like, it's not powerful enough per se, and the re-- one of the reasons for that is, as you When you come, when it comes to attaching fees to our transactions, you might need to bring them, bring your own fee from outside. Whereas if you took a more, quote unquote, powerful covenant or, proposal, something that has more, let's say, introspection, then you could start doing things where you don't need to kind of separately bring the fee, you can kind of introspect into that output and use that for some of the fee. I'm kind of loosely summarizing, but that's my understanding there, and that's where some developers are looking more at like TX hash Or maybe in the future, hypothetically, if there was great script restoration with, with kind of more advanced scripting features available, then you could sort of do the fee part more efficiently. Is that broadly what, what's going on there?"
    },
    {
      "speaker": "tiero",
      "time": "46:54",
      "start": 2814.02,
      "text": "Yep, sure, and that's, main component. And, and as I said before, it really limits you what you can do, just CTV only, for example, you can do these optimistic unilateral actions like Matt, comments like, Salvador proposed, and, you know, like it really limits you On trying to stuff it what is possible with, with that opcode, but, yeah, you're right. of course, like T-Sash will be the best because it will allow granularly to pick parts of the transaction, but I really think that, you know, the without Say, okay, I want this, I want that. That's not my, whatever you want, but I think the great restoration, great script restoration has the right approaches because it's not like picking names, it's not picking, you know, person. And you know, people have ego, right? So that's great because it's basically saying, okay, we are doing the best version of script, and there's no like someone proposed what you really like the best version, what, you know, Satoshi wanted at the beginning and put at the beginning, there."
    },
    {
      "speaker": "tiero",
      "time": "47:56",
      "start": 2876.45,
      "text": "I'm totally in"
    },
    {
      "speaker": "stephan",
      "time": "47:57",
      "start": 2876.95,
      "text": "favor if that happens. Okay, yeah. And then, do you have any thoughts? I guess we've been ta-we've been touching on this, but any thoughts on the- \"Quote unquote ossification,\" but I think really that's maybe a bit of a, a straw man. Really what it is is more like extreme conservatism, right? Maybe there's a bit of resi-- there's been a bit of resistance, and I think ossification is maybe the wrong term. I think it's just that there's a lot of people who are saying, \"Hey,\" I'm okay with, you know, Bitcoin as it is, and they, that, a-and to be fair to these people, they would say, \"Look, Bitcoin as it is doesn't need to...\" Have covenants to kind of have the whole world on board. The, the, the, let's say this extreme conservative view, this kind of person might be okay with, let's say, ten to one hundred million lightning banks or something like that. Do you have any thoughts on that idea?"
    },
    {
      "speaker": "tiero",
      "time": "48:49",
      "start": 2928.8,
      "text": "Yeah, I totally, side with the, the goal in terms of like, let's be careful, right? We are not Ethereum, like, let's really be very careful in all our changes. but I really think that, I mean, especially if you look at Taproot, Taproot has been done in a way that seems someone from the future came and basically built, you know, the foundation, let's say, what we call refactor of, you know, the, of the scripting mechanism because we want enable to do more in a better way. So to me, it's like, okay, if we are stopping now, it's like defeat, right? So it's like, oh, we, we don't know how to do it. So why we did all the SegWit ta-stuff, why we did all the Taproot stuff, like, what's happened? I understand what happened in terms of like people are potentially scared of, of, of, of these new changes, but if you look from, you know, logical perspective, like SegWit, what we did for Lightning was super dangerous. We Transaction serialization, and that thing was being super easy, super fast, because there was drama, right? There was drama, and, you know, most of the Bitcoiner didn't want the, the option of increase the block size, right? And we really said, okay, whatever, like, whatever, like, I, I, I lower my, you know, my radar, my, you know, my concern because I don't want that. You know, it's very like, it's been a very dramatic sense that really pushed to huge serialization change to upcodes, you know, because without time I think there we did the mistake of maybe now to take the minimal things and try to stuff a protocol in what is possible with this minimal thing, because if we maybe wait maybe six months or one year before doing that, that thing with the new protocol, oh, maybe we also need introspection to do better lightning, right? time lock are not enough. And I think this is important to mention to everybody, especially who came after 2017, in that period from a technical perspective. It's not that now with Covenants we're gonna do more, it's just that Coven It's a shame was not there already, you know, before when was time, and now it's so minimal, so simple because it's not touching Bitcoin cons- I mean, it's not touching that serialization, so it, it can't create, breaking, in Bitcoin. It's just making sure that, you know, some new version script may be dumb because people create dumb things, but again, you need to send your money to a dumb thing, and you can't really do, do all this dumb thing two of two multisig, so there is really no concern if Slow and not rush it, don't, don't create drama, right? Because we, you know, that's Bitcoin is for the next one hundred years, right? So I totally understand that point and I'm totally okay with this. I'm, if we will take ten years to get covenants, I'm totally okay. That's, I think it's, where I s- I, I side with them. Let's go, together. But again, we've done tremendous job to make a short script can be better. For Bitcoin, so to me it will seem a defeat now to never change Bitcoin, never add, you know, any new scripting capability. That would be a defeat of, of everything, and everybody should be fired, you know, it's, it's a joke, but, you know, it's, it's not, not what, you know, the technical consensus always has been, right? So let's make Bitcoin better, where, where we can see."
    },
    {
      "speaker": "stephan",
      "time": "52:05",
      "start": 3125.24,
      "text": "Yeah. And, yeah, personally, I'm not an, you know, ossificationist myself per se, although I think the term is maybe a little bit of a straw man. I think maybe really the, the steel man of that argument would be bug fixes and maintenance only, no upgrades to fe- functionality. But even then, I still think, personally, I'm probably more in the-- I like, the way AJ Towns frames it of more like slow and steady, right? Like, let's, you know, I think as long as it's safe, right? I think as Really be an improvement that would actually help more people use Bitcoin. You know, personally, I would be, you know, I'd be okay with it, but I'm not, I don't wanna sort of push any change that's out of consensus, right? I don't wanna like ram anything down that, you know, people don't actually want. So that's kind of where I'm seeing it at least. So, let's see where people go with that. so, I guess, in terms of, ARK Labs, where things are going with ARK Clubs."
    },
    {
      "speaker": "tiero",
      "time": "53:06",
      "start": 3185.9,
      "text": "Sure. I think, the interesting part, like, you know, we've been the last year prototyping at least, and we've been a little bit stealth for sure, and but that, that was necessary because, you know, it was important to really touch with our hands and, and build things and see how they look like. So we've been super happy and super excited to, you know, release it and finally the code is open source, everybody can start tinkering with it, build their own arc, and that has been super interesting because many, many And that's been, yeah, super, super nice to, to see the excitement also, from outside. We, we were in, Bitcoin, in Austin, Bitcoin Plus Plus, where I went around with the, mobile app, with Ark and, and sending payments, physically to everybody at the venue, and people were super excited and say, \"Oh, wow, like you guys are already there with the mobile app.\" And to me, it was like, \"No, guys, I've been one year, too much. We Bitcoin, so it needs to take time. so now going forward, again, what, what I said, I think that we have this dual mandate on a side, keeping the open source reference implementation, total MIT license, so everybody can build on top of it, and the other side, of course, is to build commercial service on top of this. And, definitely we have many ideas and we are talking with many partners, in, in the space, but even outside the space, because I think, what we really want for ARC is, to bring Bitcoin to out, outside our inner circle. So the people don't, will not talk about Ark or Lightning, will talk about Bitcoin, and I think Ark will help to do that last mile, in commercial service so we can get the broader, let's say Community that this need of Bitcoin that maybe now is every too clunky or isn't like the Bitcoin of 2013 that was super cheap to do it and very simple to use. So we wanna really bring that initial, Bitcoin kind of use case. Of course, this goes a bit against sort of the sort of value, you know, like cold storage only, but definitely, like, I think we are early in that sense, but we definitely, excited to do that, right? And I think all the commercial stories we are looking will definitely be A Bitcoin, a Bitcoin product we are releasing this summer and will mostly cater around to, help and be compatible with the Lightning Network. So we really wanna focus on what are the early adopter of Bitcoin and there are like the, the tinkers and people that really wanna try it. And it's, it's very interesting because in 2018 when just Lightning was out, you know, I work on the first, UI for our v-balancer service because we saw that was a, the interesting part, was necessary for the ecosystem. I think I think now finally we are at a time where we can, try and help, you know, Lightning, especially in the rebalancing, process. So yeah, expect, some products from us, this year, which, you know, we're really heads down working on those, on those. So yeah, I'm super excited to, to share as soon as possible."
    },
    {
      "speaker": "stephan",
      "time": "56:05",
      "start": 3365.36,
      "text": "Great. yeah, so that sounds good. let's, turn now to a few of your views on some other things. I know you're working, you've been, you've been in this space for a while, so I think you have some interesting, perspectives to share. So on, you know, stablecoins or fiat coins, as I prefer to call them, I know you were previously working with, let's say, Fuji Money and doing liquid stuff as well, I'm curious where you see the opportunities there, and I know that can also sometimes be controversial for some people because maybe they would see that as like, \"Oh, that's a platform maximalist view.\" If you're like a monetary maximalist, you just want Bitcoin only and you don't really care about other things. But at the same time, I will say It's, it's hard to stop these things, right? Like now, I don't like the spam myself, but at the same time, there's already things like RGB, there's already Taproot assets, which you can't really stop, you can't filter those. So will there be people who try to build out- Stablecoin or fiat coin features into, you know, quote unquote, on Bitcoin, and we can't really stop them. So I'm curious if you have any reaction on that or where you see that going?"
    },
    {
      "speaker": "tiero",
      "time": "57:13",
      "start": 3432.54,
      "text": "Yeah, I mean, I always thought, and this is my personal opinion, that, you know, is stablecoin can mess with consensus at some point, not from a technical standpoint, from A financial standpoint, right? So if there is too much, stablecoin liquidity deployed on Bitcoin, it can mess a little bit. I don't know how, so this is, again, it's more like on, like, you know, ossifier. So I'm just, you know, worried about things I don't know. but at the same time, as you said, if happens, I will follow in the sense that I will not, you know, wage war to anybody, is doing, and that's why I've been working, especially because I think stablecoin Work a lot on Liquid in the last two years when, you know, I actually work with covenants in production with real customer, real use case, so I think that's has been interesting and ninety percent of those were stablecoin, base. And the beauty of Liquid, you have twenty million Tether already issued there. And I'm not saying it seems that I'm a Liquid shell, I'm not, but I'm just saying if you wanna use Tether right now, there is there. And it's a UTXO chain, so your tooling ninety percent will Bitcoin is there. Maybe you don't, you don't like the L-LBTC, Liquid Bitcoin, you don't like the federation, but again, you are using Tether, you're not using Liquid Bitcoin, and Tether is already centralized issue. So I don't, I don't see why if you wanna use Tether, you need to use on Ethereum or Bitcoin and not on Liquid. But that being said, RGB is there, Taro, is there, you know, any other pro-meta protocol, always been there, colored"
    },
    {
      "speaker": "tiero",
      "time": "58:54",
      "start": 3533.8,
      "text": "Happens, and I think the beauty of ARC will, a, a, be able to scale, even stablecoin, right? So anything you can done on, at the layer one at Bitcoin level, any type of script can be, you know, brought, at the level of ARC. And I think, you know, if, there will be traction, I don't know which, so that, that's why I'm saying I will follow any of this meta protocol will get traction, I think ARC can also benefit there to at least move all the potential M Of Bitcoin and things around on another layer, which again, as you rightly said, also for your stablecoin. So I think that's, how we see it."
    },
    {
      "speaker": "stephan",
      "time": "59:31",
      "start": 3570.56,
      "text": "I'm curious, more controversially, do you see that as a potential centralizing vector or some kind of legal attack vector that, let's say, I don't know, if hypothetically, you know, now maybe now it might be a little bit different with the US government seemingly like, especially Trump being more pro-crypto per se, but hypothetically if the government didn't like it or maybe the government just went to the Bitcoin miners to say, \"Hey, censor this, this RGB transaction or this Taproot assets transaction,\" or, you know, if there were to be a lot of volume, maybe the other scenario would be like some kind of fork, you know, people were sort of saying, \"Would, the government Chain because of all the USDC kind of happening there. I'm curious if you see any similar concern that could happen in Bitcoin on that, in a similar vector or no, not really."
    },
    {
      "speaker": "tiero",
      "time": "01:00:19",
      "start": 3619.44,
      "text": "In the first layer, everything is public, so yes, definitely miners have the Capacity to, to do that. Of course, if you do that on a second layer like ARC, that's, at least a, e-enough Eden, right, from the base layer, so it'll be hard to go to miners that are like potentially findable. Of course, the ASP will then be the next one to, to be talked. But you understand, like, you are giving the optionality to move to another layer and to, you know, spread among many players so that will make even more harder. but I think also this is the, another thing was Having confidential transaction makes the functionality blinded to what they're actually including. So either you stop all the li-liquid network, which is very hard to coordinate, you know, in all the world, it has to be really like, you know, a huge campaign to do that, or, you know, it will be very hard for any regulator to go to find every functionality and tell them because they don't have power. So I think any product, any meta protocol that don't think about how to, you know, plausibly, in a plausible way, conceive, you know, your trail or"
    },
    {
      "speaker": "stephan",
      "time": "01:01:26",
      "start": 3686.75,
      "text": "Yeah, interesting. But as, as we were saying, in many cases, it might not be feasible to detect what's happening there, right? So as an example with RGB, my understanding is they're using Tap Ret, which is kind of like a tweak of a- A public key signature. So how are you gonna censor that? Like it's just a standard Bitcoin Taproot transaction, right? So it's kind of like some of these things are just gonna be hard to censor by the nature of them because they're kind of, they're sort of masked in how they're kind of in the standard Bitcoin transaction anonymity set. Now maybe there's certain indicators or maybe there's IP, there's other ways, but it's not quite-- Yeah, yeah. It's not, it's not just like, just censor this type of transaction. It's just not like that. It Or, or even, maybe stamps isn't even a good example. It's not like BRC20 or something like that. It's just not that easy to just, say, s-sensor this kind of thing. So, it, yeah, it's a more complicated argument I would say. and not to, again, not to say I endorse creating shitcoins or whatever, it's more just I'm recognizing that people can do these things and I can't stop them. You know, that's kind of"
    },
    {
      "speaker": "tiero",
      "time": "01:02:32",
      "start": 3752.9,
      "text": "where"
    },
    {
      "speaker": "stephan",
      "time": "01:02:36",
      "start": 3756.83,
      "text": "I see it. 100%, 10 So, I, I believe you see Nostra as maybe it's more interesting from like a web of trust and maybe some web interface aspect rather than Nostra as it's used today. I'm curious Can you elaborate a bit there?"
    },
    {
      "speaker": "tiero",
      "time": "01:02:55",
      "start": 3775.27,
      "text": "sure. I was a proposer of NIP forty-six, last year when I saw Nostr, I mean, it's been super, you know, interesting for me, one, because it's a very simple protocol and simplicity wins, especially in, the centralized or peer-to-peer scenario. if it's simple, it can be run with, you know, low, you know, hardware, you know, like at, by everybody, and everybody is easy to build, while that's a good recipe for"
    },
    {
      "speaker": "tiero",
      "time": "01:03:22",
      "start": 3802.75,
      "text": "But to me, Nostr, the social media component of Nostr was a necessity rather than the goal, in the sense that these social media needs of running these relays or people talking freely, is basically a way to subsidize the server to be online. And once you have that, and for me, I always research about this kind of incentive, in my password for Bitcoin wallets and, and so on. Is the way for you to create, independent network to share messages, between light clients or light peers. It can be a browser can talk to another browser thanks to a relay in the middle, and the beauty of being that if this relay censor you or doesn't accept your message, the authentication is inside your public key, inside your signature. So it's like I bring my own identity. If you're not relaying my message, I'm going to n-n-otherwise. This I think is genius, and this is for me was necessary for Bitcoin Wallet. Wallets to create this sort of wallet connect, right? So you wanna have your, your, your phone and you wanna, and maybe it's a browser, maybe it's a mobile app, and you wanna connect to a browser or to another mobile wallet or someone else, and you don't want to have a centralized iCloud, you know, like, routing message, but you wanna have, you know, this untrusted relay, and that's why I built Nostr Connect. It was really a way for you, with your own keys as a Bitcoin wallet, to connect to a web browser, and Connect and, and this kind of approaches, but this will be a decentralized wallet connect, and so that's why I propose Nostr Connect, and we are really actively researching on how to use Nostr as the medium of communication, you know, between our client and our server. So yeah, I really see a bright future, for, for Nostr even beyond the social media, which is a necessary component, which is like giving this, you know, base of server that are incentivized to be run, because again, if you're building just, a Nostr just This case of mine would be just two server of me and wouldn't be decentralized, but this way we can really have like, multiple, multiple relayer, run by many people that don't, maybe don't agree each other, but they are relaying messages encrypted potentially. So, yeah, that's, I think, super powerful for, for Bitcoin, for Bitcoin wallets and, and the Bitcoin infrastructure."
    },
    {
      "speaker": "stephan",
      "time": "01:05:37",
      "start": 3937.69,
      "text": "Yeah, really interesting, because then it allows, I guess, easier coordination, right? And now there are people trying to do things like CoinJoin coordinated over Nostr, or there are people trying to do, you know, maybe in the future people will find other ways to coordinate their PayJoin or other privacy or UX improvements that could come by sort of understanding, oh, I know Tiero's Nostr key, let me encrypt a payment to him using that, or I know Stephan's Nostr public key, I, I can encrypt a payment to him that way. And so- This is kind of like another way that people can coordinate in an age when maybe it's not that easy to coordinate to each other, where otherwise you might have to run a web server or run your own web server, right? Like now nowadays, if I wanna run my own lightning address, now, yes, I have my own lightning address, but not everybody can do that. And so this would be an easy way to kind of make the UX really easy and, there might be some interesting collaboration and opportunities here, from Annostra and Bitcoin perspective."
    },
    {
      "speaker": "tiero",
      "time": "01:06:36",
      "start": 3996.07,
      "text": "100%."
    },
    {
      "speaker": "stephan",
      "time": "01:06:37",
      "start": 3997.63,
      "text": "Yeah. Alright, well, great. I think that's a great spot to finish up here. So, let's just kind of summarize, 'cause again, we, we covered a lot of stuff today, but the basic idea, you know, I'll, I'll try and summarize it as I understand it, and then you, you, you, have a closing thought as well. But my understanding is ARC is this kind of combination of like CoinJoin, maybe a bit of state chain, a bit of, you know, it's kind of and like, is a way to easily onboard people and these people can make all these small payments to each other. Yes, there's and maybe there's a bit more complexity and a bit of capital requirements at the ASP, at the ASP level, but you know, there's a market and people might find ways to make that work. There is some complexity, but again Most of that complexity would be at the ASP and the software developer, you know, nerds level. The everyday users are just gonna have an app on their phone and they're just gonna use that, and, you know, that would be the The end goal. Now, it's gonna take some time to get there. There's a few different forms, as we've spoken about. There's Clark, Covenantless Ark, with certain trade-offs, we said, bandwidth, storage, interactive onboarding. on Liquid, you can do it today with less trade-offs, and then maybe someday in the future, if we got CTV, TX hash, MAT, great script restoration, something like this, it would be Also more feasible in terms of on-chain in Bitcoin today, and, the idea is that it interacts with Lightning, so it's not really a competitor, it's more like a, another piece to the puzzle. so that's my, I guess my high-level summary. Any closing thoughts on your part?"
    },
    {
      "speaker": "tiero",
      "time": "01:08:14",
      "start": 4094.85,
      "text": "Totally, yeah, correct. I think again, anyone can start get-getting started right now and building on Arq today. you know, the code is open source and we release it, so we're very excited to see how people will take care of it. And, and yeah, you know, new Arq commercial application are coming also this year, both on Bitcoin and both, you know, more retail, consumer-oriented. So, yes, if you have any ideas or if you wanna support the project or help, you know, the project Please reach me out, like we are really, looking forward to collaborate with the broader community."
    },
    {
      "speaker": "stephan",
      "time": "01:08:49",
      "start": 4129.23,
      "text": "Fantastic. Well, listeners, I'll put the links in the show notes so you can find Tiero, aka Marco, there. Marco, thanks for joining me. Thank you so much. I hope you enjoyed the show. If you did, make sure to give it a thumbs up and share it out there with your family and friends. Check out my website at stephanlivera dot com, and I will see you in the citadels."
    }
  ]
}
