{ "episodeId": "SLP482", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "burak": { "name": "Burak", "role": "guest", "tag": "BURAK" }, "guest_2": { "name": "Guest 2", "role": "guest", "tag": "GUEST" } }, "segments": [ { "speaker": "stephan", "time": "00:09", "start": 8.53, "text": "Hi and welcome to Stephan Livera podcast, a show about Bitcoin and Austrian economics, brought to you by Swan Bitcoin. Today for episode four hundred and eighty-two, my guest is Burak. He is a Bitcoin researcher and developer, and he joins me to talk about ARC. It's a new protocol for Bitcoin scaling and privacy. Now, we get into a lot of details on this one. Now, fair warning, this is a more technical- Technical episode, of course, I do my best to try and break it down and put it into simple terms, but just so you know, it is a more technical show, and so we get into some more details around this. We talk about the downsides of Lightning Network, a high level overview of ARC, ASPs, vT xOs, as well some of the criticisms, is it vaporware, as well as talking about the interactive and non-interactive versions, and also covenants and what they would mean for Bitcoin. Now, as I mentioned, this show is brought to And this Swan app are great for safe and easy Bitcoin buys. You can do recurring purchase plans, you can do one time buys. Swan offers free custody in your own legally owned trust account, as well as free automated withdrawals. Now, many people know Swan for the DCA or auto DCA feature, but Swan is also available for people who are high net worth investors and they need a trusted partner. It's also available for those of you in or running a business who want to future proof your business, your nonprofit or trust with Bitcoin trust Treasury services. Swan also offers an IRA product for those of you in the US. So to sign up for all of these, go over to swan dot com. Before I send an on-chain transaction, I check out mempool dot space. Mempool dot space is the leading Bitcoin explorer covering the multi-layer ecosystem of Bitcoin. You can see all kinds of things, whether it's the mempool, the blockchain, second layer networks like the Lightning Network, and with mempool dot space, you don't have to trust a third party. It's free and open source software, and of course, you announcement, mempool dot space are coming out with a transaction accelerator, so keep an eye out for more details here. And of course, if you are with an enterprise, mempool dot space has custom mempool instances and custom features available, so go and find out more at mempool dot space slash enterprise. Now, as we all know in Bitcoin, it's not your keys, not your coins. CoinKite dot com are helping us with all kinds of hardware products and accessories that we can use to secure our coins. So you need to think about your Bitcoin security, don't leave your coins with an exchange custodian, if you are able to take them out into self custody. CoinKite make the Coldcard, which is the latest version, the Mark IV, has two secure elements, it has NFC support, and it's a very reliable performer. You can use it in a range of setups and configurations, and actually you'll end up learning a bit more about Bitcoin as you learn how to use those different features. So CoinKite have a range of products, the Mark IV is the latest and greatest, of course they have the Q1 coming out later in the year with QR support, and for those of Try the Tapsigner. This is a credit card sized device, it has NFC support, and you can use it easily with wallets such as Nunchuck or Sparrow with the attachment. So go to CoinKite dot com and get a discount on your cold cards with the code Livera. And now onto the show with Burak. Burak, welcome to the show." }, { "speaker": "burak", "time": "03:18", "start": 198.01, "text": "Oh, yeah, thank you for having me. it's exciting, huh? Exciting times ahead. yeah, for sure." }, { "speaker": "stephan", "time": "03:24", "start": 204.26, "text": "So I saw you recently announced- Arc at the Bitcoin conference in Miami, twenty twenty-three. And I know you did do a talk about it, previously at BTC++, and you've been talking about it in previous, let's say, iterations, I guess previously known as TBDX-X-X. so do you want to just start with a little bit about- What got you here? And I guess you were talking about some of the issues that you saw with Lightning that caused you to actually try and create this. So, do you want to elaborate a little bit on that?" }, { "speaker": "guest_2", "time": "03:54", "start": 234.03, "text": "Yeah, sure. so yeah, maybe to give a bit a story of myself, you know, I started initially in a big block sort of camp, like a big blockers camp, later I got introduced to Bitcoin through Liquid, and then I did some like, current research and development for about two years. And, and, and recently I, I started to shift my focus to Lightning, like about a year ago, I shifted my focus to Lightning. and, you know, the more I explored the Lightning, the more I realized, well, there's, there The cen- my objections were centered around the UX, the end user, UX, UX hurdles, the onboarding and at the entry barrier to on- onboarding, like from, you know, inbound liquidity to, you know, interactivity requirements, and to, you know, async receiving and all that. and I, I wanted to address these problems because, like, you know, I don't know, like I'm, I'm obsessed with UX, you know, I'm obsessed with Bitcoin scaling and privacy too. So I, I really wanted If really something works like ninety, ninety-five percent of times, it's, it doesn't really work. It has to be like frictionless, and from what I've learned, like, you know, over the past few years, like people are lazy, like people don't want to manage liquidity, they don't wanna, you know, self-host a Lightning node. It just has to be frictionless, like it should just be, piece of dom- a piece of software, a software you download, just like an on-chain wallet, like, just like an on-chain wallet UX. On-chain UX. The ideal UX should be as, as, as convenient as an on-chain, well, unlike Lightning, in Lightning, while you have invoices, you have to be online to receive, you ideally have to self-host, you have to make sure that you have enough inbound liquidity to receive payments, you have to take care of your management, you know, rebalancing, you know, splicing and all that, yeah, you know, you have to acquire liquidity in the first place to receive like a payment protocol. So Lightning is a, you know, is a and Layer 2 by definition is like, it's a piece of different software, you transact Bitcoin off the chain without polluting on chain, and you can unilaterally exit on chain at any time. By that definition, Lightning is the only Layer 2, but it has its own problems, complications, you know, for the end users. End users, it just has to be frictionless, and I-- that's what I try to do, like that's what I try to address, in the first place, like to, to address these, UX problems." }, { "speaker": "stephan", "time": "06:22", "start": 381.85, "text": "So To, let's say that, as I'm sure you have seen, obviously I'm sure you're looking at the space, that there have been some pretty big improvements over time, at least if we compare Lightning in twenty eighteen and twenty nineteen to Lightning today in twenty twenty-three, there are at least consumer-grade wallets and things, as an example, things like Phoenix or Breeze or things like this that at least smooth over some of those aspects for the consumer level. What would you say, about those? Would you say it's still not good enough in your view in terms of the rela liability or the async receiving capabilities. Yeah." }, { "speaker": "guest_2", "time": "06:57", "start": 417.33, "text": "Yeah. It's not, yeah, it's not about being good enough or not, it's, it's about like being proper, like it's about being like, it's like to me like it's a binary option. It's like either it works or not, and it's just not me-- I'm not really a like improvement. Well, we are seeing improvements, yes. Lightning can be improved, yes, with PTLCs, and for instance, with PTLCs, you can tackle the off-chain receiving problem, like on-offline receiving Which no, no problem, no solution can solve. To me, like it's a bug, like it's a fundamental issue. Now, Lightning is a, is a, is a protocol, like it's a network of payment channels, and it is fundamentally constrained by liquidity deployed on these channels. So, like, I don't see like how you can improve on that. What you can do is like you can do submarine swaps and all that, and you know, some Lightning wallets we've seen, like, how, who claims to be non-custodial or based on this submarine swap model, but it Quite more in a short term, like in, in a short sort of short term, but it's, it's, it's gonna blow up. And, and we're seeing that right with recent incidents like Ordinals craze, fee market, because Lightning is a layer two that ha- because Lightning heavily relies on the base layer to operate, it's heavily reliant on the fee market. And if, if, if the fee market goes crazy, it, it makes, and in, in fact, it made, we've seen, the key Lightning infra unreliable. and Like it has to be well-taught and it has to be frictionless, yet should be footprint minimal. and in fact, like we're not seeing an increase in, I think, like when you see the Mempool dot space data, like we're, we're not seeing an increase in number of- number of like, of li-lightning nodes, especially after this, you know, like twenty twenty-three, since the beginning of twenty twenty-three, we're seeing, in fact, the opposite, a, a spike in, in custodial lightning usage, when you look at like, top ten custodial lightning wallets download statistics, apps and play store, we're seeing a spike because I think it plays, you know, not sure in the apps, they play a huge role in this, because they highly incentivize," }, { "speaker": "guest_2", "time": "09:03", "start": 543.44, "text": "the custodial X is the only UX we have, like, is the only Lightning UX that can work because of the, mainly, mainly because of the, the entry barrier to onboarding. So that's the main Lightning, that's the main problem Lightning faces, right? Like, you have, you need money to receive money, and in order to onboard the system, you need money, like, you need, in balance liquidity. so I, Orange Peel, you, i-e, for the first time, and you want to, if you want to send you some Sats over Lightning, you, For some reason, like, somehow you have to acquire liquidity, like, like in the first place, and it's, it's not only like not convenient, it also doesn't really scale, like, like, both in terms of footprint and in terms of liquidity allocation. Like, inbound liquidity doesn't scale to entire planet. And I know that might sound an utopic idea, right? Like, onboarding the whole planet in an uncustodial way, in the end, we'll probably end up having like, like spectrum of solutions from full custody and to, to Custody, maybe some like federations and in the middle. maybe, probably, yeah, realistically, but at least I think we should give the entire planet an option, the sub-custody option, the option at least should be there, it should be available to people. but I, I don't see the option today, like I don't see a way of Lightning achieving that with, with its current form, and in fact, in, in, in any kind of its future form, because it's fundamentally constrained by inbound liquidity. but that's, that on ORIC, and, and in fact, it started as a lightning wallet idea, so I wanted to address these problems, especially in mon liquidity. the initial idea was, you know, I wanted to build a lightning wallet, not to solve the, I mean, it kind of, it kind of tr- I mean, I, I try to address mainly the, like the offline receiving problem and the footprint. Like, we can't, we can't tackle the non-interactivity, like interactivity issue, i.e., using like one directional, like unidirectional channels So when you have like a unidirectional setup, a channel setup, all channel states are always in your favor, so that you don't have to be online to, to sign for channel bridges and all that. And we can tackle the on-chain footprint using like a shared UTXO model, a CTB style or N-of-N multisig style. But I really couldn't find a cure, you know, for the inbound liquidity. And I, I think it's like, it's like a fundamental of a problem of Lightning. Lightning, I think it works great for vendors, because like if Your cash inflows are predictable, right? You demand instant settlement, and you can run a specialized software in a PPO stream or something BTS-based server, right? It's, it's okay. But if you're an end user, you just don't-- you, you don't-- it's unpredictable, like how much you're getting paid is unpredictable. You sometimes receive as donations, remittances, it's highly unpredictable, and you simply can't acquire liquidity, like, like it's just, just not convenient, right? and that, that's what ORIC tries to address The end user UX, frictionless, friction free, there are trade-offs certainly, I think you'll come to that, but it, it's, it offloads complexity from end users to the service providers. So on Lightning, like, it's, it's a channel setup, I, I, I, that's, it's me and my channel partner, and, and we are equally responsible, right, for the liquidity. me and my channel partner are equally responsible for liquidity, for managing liquidity, for making sure, in my, at least from, from my standpoint, Me having enough amount of liquidity to receive. But on ORK, ORK offloads my complexity on my end, complexity on my end, on my edge of channel, right, on my end, into, into the, the service providers. So service provider's job is like my-- service provider is akin to, the my channel partner, right? It's kind of a channel design too. It has similarities with Lightning, ORK, so it, it offloads complexity into my channel partner, and channel partner's job is like ten times more difficult now, like my channel partner has to But my, in exchange, like, for my c-convenience, you know, I, I don't have to take care of anything. Like, I can receive without a second thought, just like how, how an on-chain mode, like, how on-chain funds flow, just like in how on-chain mode works." }, { "speaker": "stephan", "time": "13:23", "start": 802.55, "text": "Okay, so let me just summarize a little bit there, because there's a lot in that. So as you were saying, I think the main criticisms you have, like fundamentally, the main criticism you have is the one of inbound liquidity, right?" }, { "speaker": "stephan", "time": "13:36", "start": 816.18, "text": "Or in your, in some cases, you might open a channel and make payments, and now you've got inbound liquidity. But I think the point you're trying to make is that in terms of scaling that and having lots of people have inbound liquidity, maybe there's a capital requirement problem there. now, I guess the lightning bull answer would be, oh, look, there's LSPs to do that, lightning service providers. But I think part of what you're saying is this idea that- Having a different protocol might smooth the user experience. I think that's, I guess that's essentially the argument you're making, which is that by having this new protocol, ARC, which we're gonna talk about in more detail, basically it allows people to receive without first having inbound liquidity, or having to have an LSP open a channel to you, but there are other trade-offs associated, right? It's not a free lunch, there is no free lunch, but we would be using an ASP instead of an LSP in this example, right? So, do you wanna just explain a little bit But, let's, let's try to keep it accessible for people, as accessible as we can. Can you give us like a high level explanation of ARC and how it works for people?" }, { "speaker": "guest_2", "time": "14:42", "start": 881.64, "text": "So guys, ARC is a layer two, just like Lightning, it's an option protocol. You move Bitcoin, just like Lightning, off the chain without polluting on chain, in a privacy preserving way. it does a bit of a b-better job compared to Lightning in terms of privacy, but it scales Bitcoin transactions off the chain. It's a Bitcoin scaling Just like Lightning, but in, in a better UX. You have a better UX, like, I would say like, 10x, it's Lightning, but with a better, like, 10x better, 10x better UX for end users, and it's inter-interoperable with Lightning too. And in fact, ORK is, feels like, ORK feels like a subnet of Lightning, although it's a separate, distinct protocol. Like, ORK is a distinct layer two, right? ORK is a layer two, Lightning is a layer two Like there isn't a third, I mean, obviously today there isn't a second. When ARC is there, when-- once we ship ARC, I guess we'll come to that, in, in a second, but once ARC is there, right, on mainnet rollout, after mainnet rollout, it's, if it's there, like, there isn't a third. I mean, assuming we have-- assuming we don't have Simba City, no, nothing on rollups, there is Lightning and there is ARC. ARC is a layer two, it's Assumptions, UX assumptions, without introducing hopefully non-interactivity. assuming we have covenants, I guess we'll come to that in a second also, and also pre-p-preserving the receiver privacy. So it is-- Ork does what Lightning does, but better for end users. There are trade-offs obviously, but Ork is a liquidity network similar to Lightning, so it has similarities with Lightning. So just like Lightning, you have liquidity providers, i.e., service- Providers. On, on Lightning, we call them Lightning service providers. it's a hub and spoke model. There's central, central hubs on Lightning. There are also some like, small scale routers on, on Lightning too. Same goes to ARK too, but ARK can ideally have, I mean, in order for the ARK to work really on scale liquidity to entire planet, we should ideally have Smaller hubs, but are federated ones, like less but federated instead of, more, and but single-sig. so we have liquidity providers, service providers. I mean, we have service providers just like Lightning. Service providers provide liquidity just like Lightning, and they charge liquidity fees just like Lightning. So it has a bunch of similarities. And Org is kind of, like, Org isn't a state channel design, it's not rollup either. It is kind of its own category. Like, I don't know what the category for this should be. Like it is a distinct layer two with a distinct design, like it's, it's like, it's like a recipe from different sort of ingredients, but it's not a stage chain. It is, I don't know, what, what, what, what would, what would the, what would the category-- I mean, what would be ca-- I mean, what, what category could this be? Like, I, I have no idea. But, it's like, it, it has similarities with Lightning, it has similarities with eCash, it has similarities with," }, { "speaker": "stephan", "time": "17:52", "start": 1071.5, "text": "so, so let's just try and walk through some s- like a simple, I guess, I'm gonna explain how I, how I'm understanding it in a simple way, and then you tell me what did I get wrong or what to add to that. So, as I understand, the user, in this case, is he might have some on-chain Bitcoin and he wants to put it into ARC, and he goes to an ASP and he, he's creating VTXOs, like virtual TXOs, virtual outputs, and we can trade them all around in, like, using the ASP And then the, the important point, as you mentioned, is that the user can unilaterally exit, right? He doesn't have to ask the ASP for his coins back, he can just unilaterally take them back after, I think, a twenty-four hour window. And so as I'm understanding, it's, it's sort of each round, it's like a round-based mechanism where the, it's sort of like a coin join and there's like continual transactions going to sort of advance the rounds forward, but there's also a time lock aspect, where if you put your coin into an ASP or into a VTXO, it takes-- there's a four-week timeout, where you-- your wallet needs to come online to refresh, or otherwise the ASP can take your coin basically. But is that kind of a high-level understanding there? That's," }, { "speaker": "guest_2", "time": "19:09", "start": 1149.19, "text": "that's a qu- quite an ac- accurate, yeah, explanation. So I think the better analogy, the- Yes, analogy would be a side chain analogy. So you can think of Org as a side chain, a trustless but a trustless one, a trustless two way peg side chain. I know side chains are a different category. I mean, because we don't have trustless side chains, we have merge mine and federated ones. But the better analogy would be, you know, positioning Org as a side chain, a trustless two way peg side chain. So it's like a piece of, it's a piece of software you can peg in and you can peg out. Gotcha. Yeah. So you possess a set of UTXOs on your cold storage or hot wallet, as their own chain funds, you have own chain UTXOs, and you wanna pick in, and you pick in, through a process called lifting, it's a buzzword, but you basically lift your UTXOs off the chain by depositing your UTXO to a script, we call it an ATC script, an encrypted contract script, or, but the better analogy would be here like depositing to a, to a multisig because It's also a taproot, you know, ARC is much lighting on that. Like you pick in to ARC with your real utxos by simply funding a Bitcoin address, and the Bitcoin address is a taproot, just like lightning, just like how you open a lightning channel, you fund a taproot, but this is a special type of taproot. And once you fund that twelve-two, and this is that twelve-two is between you, right, the user and the service provider, just like Lightning, it's like a channel, yeah. and from there you're in the system, and when-- once you're in the system, you have a virtual UTXO. That twelve-two is a virtual UTXO, right? You funded that VTXO with your actual Bitcoin, and, and you have a VTXO, you're in the system. So far we pollute the on-chain, right, by making an on-chain transaction, This VTXL on chain, but further steps from here are minimal, footprint minimal. everything takes place in a coin join, like an off-chain coin join, in, in rapid off-chain coin join rounds. So I have a VTXL, I have, I could have, I can have a bunch of VTXLs. There are other people, other protocol users, they also have their VTXLs. They can either acquire VTXLs from exchanges, from friend, from someone, a third party, or They can directly peg in to the protocol with their own UVT- UTXOs, it's up to them. So I have UTXO, and we call it a UTXO set, just like a UTXO set, and you have a piece of software, right? A wallet, a client, an ARC wallet, and you have a set of UTXOs. There are other people, could be, and they, they could use different wallets, different softwares, different ARC-compatible wallets, they all, they have their own UTXOs, and when you Like when you make a transfer, you coin select, just like how an on-chain wallet works, right? It's like an on-chain wallet, you coin select your VTXOs, and you join a coin join round. But this coin join is weird, right? This coin join is-- doesn't have hundreds of inputs, hundreds of outputs. This coin join is weird in that it only has like one input and like three outputs, and you aren't-- so you aren't supplying your VTXOs as inputs to this coin join because they are not on-chain. Like you can only supply on-chain funds during Bitcoin transaction. VTXs, they li- they live off the chain, right? You can't, you can't supply funds to CoinJoin, a non-chain transaction. So what happens is you redeem your VTXs in exchange for the service provider to provide funds to their own CoinJoin transaction, and this CoinJoin transaction is like five inputs, and these inputs are provided by, again, the service provider, and they provide inputs In exchange for redemptions, redemptions at a later point, just like eCash, right? Like, they're like eCash tokens are like short-lived notes, right? and when you make a payment, when you make a payment on, in eCash, you redeem your tokens in exchange for a Lightning payment. It's very similar, you redeem your tokens, in this case, VTXOs, in exchange for a coin join, right? In exchange for the service provided to provide their own money, their own on-chain funds to a coinjoin, and they can claim it at a later point on-chain, my, my funds at a later point after four weeks. the, so the inputs are minimal, right? Inputs are provided by the service provider, one or more inputs. So this is an actual in-- Bitcoin transaction, right? This coinjoin, it was like one or more inputs and three outputs. So output, like output, the first output is a shared UTXO. So that's, that's how, like that's That's what makes ORK like, ORK like, it's based on a shared utxo model. And this shared utxo, perhaps some of you are familiar with, coin pool, channel factories, and all that. So s-just like how a coin pool works, right? It's a shared utxo model. You have a shi- like, you have a single utxo, and you have a bunch of outputs that nests in that utxo. in a high level, you have a s-transaction output, and you constrain the- The scan of the, the transaction output, like the subsequent transaction, spending transaction from the output, you constrain the outputs of that transaction in advance of funding the output. So that's what covenants are. Covenants is a, are a way to constrain, outputs of a spending transaction in advance of funding the out-- a Bitcoin output. and these outputs are the VTXs, and they're kind of like, they're like, kind of like aggregating, batching bunch of VTX cells onto a sheet It takes so, which can be re-revealed at a later point. You can reveal them on-chain if you want to, like, covenants give you that assurance, a scripting, in a scripting level, you can reveal outputs at a later point, but you don't have to, and you do it only in a, in a dispute resolution case, just like a forced closure on Lightning. So that you have a coin join with three inputs, like, like three outputs, forget about rest, you have like one output as a shady txo, and that shady txo, contains the intented reci-like the vtx of the intented recipient among other recipients, and you, like, you are redeeming your vtxo in exchange for the intented vtx of the intented recipient and the inputs, the fund, the, the shady So are provided by the service provider." }, { "speaker": "stephan", "time": "25:55", "start": 1555.26, "text": "I see. And so can we talk a little bit, is there like a change output here or is it more just like, as an example, let's say I, I quote unquote, peg in, I don't know, ten million sats just as an example, and I make an ARC payment to you for two million sats, is it sort of like the my balance, let's say my quote unquote balance with the ASP goes down to eight million sats because I've made a two million payment to you, and as part of the ASP, so Manage that shared UTXO, and because I've paid out, let's say, two million sats to you, now my new balance is eight million sats, something like that, but we're using covenants to sort of restrain the outputs." }, { "speaker": "guest_2", "time": "26:33", "start": 1593.31, "text": "Yeah, yeah, yeah, of course. Like, so if you have like ten million sats, you have like ten coins, like ten VTXOs each one million, right? Each one million worth ten, ten UTXOs, ten VTXOs. And if you are sending two million sats, you coin Each worth two million, e-each worth one million, right? You coin select two vtxos, again each worth one mil, you join a coin join, you register for your vtxos, and then you register for the outputs, the in-of the intended recipients, right? and this is based on the public key, like, you know the public key of the intended recipient already. It's like a silent payment style, but m-maybe we can come to that in a second. But, you join a coin join, you register, you coin select two One meal, and then you register for the outputs of the intended recipient, and then you, in the third phase, it's, it's just like a coin join, like it's in three phases, input registration, output registration, and a signing phase. in the first phase, we register for the VTX that we're spending, and the second phase, we're registering for the VTX sales of the intended recipients, and which goes under the shared VTX, and then in the third phase, we sign, and we call it anchor, we, we anchor Or, or coins, like, like, two coins we coin selected into the coin join transaction using ATLCs. So, ATLCs is the magic, like it's, it's like, it's how we ensure the atomicity here, like the, atomicity, between my ATL, my coin, my, my two coin each one meal, and, the coin join transaction. and ATLCs are based on, TX locks. So TX lock is, it is a new kind of primitive I made up. you're probably familiar with TX and, and hash lock and time lock, right? A hash lock is a condition in which you satisfy preimage against this hash, time lock is you satisfy, the current time, existing time against, the predefined timeout. In a TX lock, you've, you satisfy Bitcoin script against predefined transaction ID. so in order to convince, like- Of satisfy Bitcoin scripts, you have to prove the scrip-- Bitcoin script that a particular transaction ID exists. And in the our context, when-- in the anchoring phase, right, in the third coinjoin phase, when I do the anchoring stuff, anchoring my two coins, right, each one mil, into the coinjoin transaction I sign, a TX lock from my ATLCs. So, you know, we have like two coins, they're like lightning channels, right? We made this analogy. We have two coins, they're each, these, each one of these coins are two of two, just like a lightning channel. And just like in a lightning channel, you attach HTLCs to a channel, right? You have, you attach HTLCs to two of the channel. In Auric, you attach ATLCs to each coin. and in, in this our context, it is like a channel, it's a 12 of 2. I attach a TLCs to my 12 of 2 coin BTO, and from there, I, I, I form a TX lock, between my a TLC and, and the CoinJoin transaction. and the TX lock, in order for the a TLC to be claimed by the service provider, the transaction ID of the CoinJoin transaction has to exist If there is a double spend, right? I anchored my coins, ATCs into CoinJoin transaction, 'cause it contains the CoinJoin con- it contains my intended recipient, right? I want this transaction to be confirmed. if it's double spend in the mempool level, right? I-- you cannot, as the service provider, cannot claim my ATC, aka H- attached HTLCs. In order for them to be claimed, the transaction ID of the CoinJoin- It has to exist, it has to be confirmed, so that it creates an atomic single hop, payment schedule from sender to the recipient, the recipient." }, { "speaker": "stephan", "time": "30:57", "start": 1856.52, "text": "Okay, so one, one point I'm not quite following there is, you're saying the transaction has to exist and, this part, is that the part where the ASP has to regularly do, on-chain transactions to keep the protocol running?" }, { "speaker": "guest_2", "time": "31:10", "start": 1869.57, "text": "no, that's not that. that's another thing." }, { "speaker": "stephan", "time": "31:12", "start": 1872.03, "text": "Okay, so can you explain what's the- Point about the transaction has to exist." }, { "speaker": "guest_2", "time": "31:16", "start": 1875.54, "text": "Yeah, transaction has to exist. ASP has to make sure that it exists, and it should be do-- I should take care of fee bumping and all that to make sure that it exists. Because if it's not, you can't claim the funds, you, you, you can't-- the recipient's funds." }, { "speaker": "stephan", "time": "31:31", "start": 1891.43, "text": "When we're talking about transaction has to exist, do we mean like my peg-in or what transaction are we talking about here? No, this" }, { "speaker": "guest_2", "time": "31:37", "start": 1896.75, "text": "is not peg-in. So we are already in the system, right? Right," }, { "speaker": "stephan", "time": "31:41", "start": 1901.09, "text": "we Inside the ASB, you know, Ark system." }, { "speaker": "guest_2", "time": "31:47", "start": 1906.76, "text": "We destroy, yeah, we destroy VTXOs, we create new VTXOs, we destroy coins, we create new coins, just like how blockchain funds work." }, { "speaker": "stephan", "time": "31:54", "start": 1913.7, "text": "Yeah. Okay. Gotcha. And that" }, { "speaker": "guest_2", "time": "31:55", "start": 1914.52, "text": "takes place in a coin." }, { "speaker": "stephan", "time": "31:56", "start": 1915.64, "text": "Okay. And so then, I guess one other question around receiving, like obviously today when we're doing Lightning, you know, I say, \"Hey, Burak, give me a Lightning invoice, and I'm gonna pay you,\" etcetera. How, how would it work in an Ark context?" }, { "speaker": "guest_2", "time": "32:14", "start": 1933.58, "text": "It's, it's a silent payment style construction. So you have, an address, from which you can get paid and you can pay to, right? You can add that address to your Twitter tipping, you can send it to friends and family, it's reusable forever, and it doesn't violate the privacy. There is no address reuse, although it's a dedicated address, and it's going to be your end pop. In the our context, so it's gonna be your mPub, it's gonna be like WhatsApp UX, you have like an address book, and people you're following, and then you pick one, you know the p- and mPub of the recipient already, and then you type in Sats, and then you're good to go." }, { "speaker": "stephan", "time": "32:54", "start": 1973.56, "text": "Okay. And so I guess one other question related to that is, how do you know when you have been paid? So let's say Burak, you generate your mPub or your arc public key, I send you two million Sats" }, { "speaker": "guest_2", "time": "33:06", "start": 1985.72, "text": "Yeah, so I do like, I know the recipient, I know the mPub of the recipient, and then I add, tweak, add some ephemeral value to it. This ephemeral value is a random value, and because I tweak add, it obfuscates the, the, the, you know, the dedicated address, right? the trace. I, I mean, it, it prevents the address reuse, 'cause it, you, no one can tell what and, and this, what this public key is belong to, 'cause it's, we, I, I've Address on, on the protocol, you can't associate it with, like the, the dedicated address to the intended recipient. And this ephemeral value, I send this ephemeral value, right? like a thirty-two byte string, byte string, along with some additional info, right? The payment value, payment amount, maybe some payment note out of band to the intended recipient." }, { "speaker": "stephan", "time": "34:00", "start": 2039.86, "text": "I see. So I might, I send you an out-of-band message to, to tell you, \"Oh, hey, Burak, here's my payment for two...\" Two million satoshis that I'm making through the Ark system. I guess this is kind of like Lightning has gossip and Lightening's, you know, peer-to-peer layer where people, where the nodes are talking to each other. It's just a similar kind of thing, but maybe it doesn't have to be through one particular way. I could have sent you that through, could it be through like an email or a Nostr DM or some other thing?" }, { "speaker": "guest_2", "time": "34:23", "start": 2063.3, "text": "Yeah, exactly. It can be outbound in any way, but, it's gonna be, Nostr DM by default So you're gonna receive a DM on your, a DM pops up on your DM, like a, like a payment info, like a payment, info, your, you, you, the, the recipient, the center of the payment, lets you know about payment info, the fair mail value and a few additional info. And you receive a DM, you go check the, the pool transaction, the coinjoin ID, right? Like the, the center lets you know about your destination, the destination of your coins, the destination of your VTX sales the pool tr- the, the transaction ID, the coinjoin transaction ID, and the output index of your VTXs and the ephemeral value in one DM, in one, in one package, and you go check out the on-chain data like when you're offline. So when you're back online, you receive, you realize you received a DM from someone, a friend, who claims that you, they send you a payment, say five hundred Sats, you know, under this coinjoin transaction ID A B C X Y That and your outpoint, you know, the VTXO index is like one, two, three, five, and then you go check our on-chain data, you'll see that, okay, there is this transaction ID, it's legit, it exists, confirmed like a while ago, like hours ago, and you got also check my out, you know, your outpoint index, the index, the vault index of your coin, the VTXO, that it's also legit. also a few other validations. Then you say, okay, I, I see it, it's legit. So," }, { "speaker": "stephan", "time": "36:07", "start": 2166.79, "text": "so can you just explain that part? How do-- How are you checking? So let's say you've received this, you know, five hundred satz, how are you, where are you going to check that? Like, where is your wallet going to check that information to see, oh, yes, I got the payment?" }, { "speaker": "guest_2", "time": "36:18", "start": 2178.44, "text": "So you first check the transaction ID, right? The coinjoin transaction ID. It's like one input, like three output, transaction on chain. you have that transaction in" }, { "speaker": "guest_2", "time": "36:32", "start": 2192.05, "text": "Contains a transaction ID, so you first you gotta check the ID, and then the message also says, tells you about the destination, the overall index of your vTXO." }, { "speaker": "stephan", "time": "36:42", "start": 2201.71, "text": "Yeah." }, { "speaker": "guest_2", "time": "36:42", "start": 2202.09, "text": "Plus the whole content, the whole content of the shared vTXO, your v- not, it's not, it tells you the destination of your vTXO, but also tells you about the rest of vTXOs," }, { "speaker": "stephan", "time": "36:56", "start": 2215.82, "text": "okay." }, { "speaker": "guest_2", "time": "36:56", "start": 2216.08, "text": "So that you can compute, the root, I mean, the, the script pub key, precompute the, And, recompute the script pubkey of the, the shady TXO based on the content of all, all VTXOs nests under that TXO, shady TXO. you do the computation and you see, okay, I see the whole content, right? There are like, say, like hundreds of VTXOs under this shady TXO, and here is mine, my index is like one, two, three, five, right? I'm like thousands of VTXOs in my index, one, two, three, five. Thanks. I see it, I see, I see it, right? I see it, it's there. I mean, I recomputed it. and I also see that, okay, this ephemeral value and my dedicated public key, when I tweak it, it also match. It's a match, right? my vTx index is a match, the script copy of my vTx index is a match. s-it matches the tweak, the tweak, the ephemeral value and my dedicated public key. And I also reconstruct the scripting like, the The ATLC script and the VTXO script, so that, okay, this transaction exists, the, the whole content is available to me, the, the shared VTXO content, and I know m-what my VTXO, like, vote ID is, and I see that it's legit, the scripting, the ATLC scripting and the VTXO scripting is legit, so this is a properly built, payout, it's, it's a proper payout, it's a legit payout. Yeah. and then I come- Consider this payment, if it's confirmed, right, final, if it's not confirmed, if I'm not, if I'm on, online, I'm receiving, right? you have to wait a confirmation, on-chain confirmations, to consider it final, but it doesn't prevent you from spending it, like it is immediately available to you. The payment you receive, it's, if it's not confirmed, it's an example, it can in theory be double-spent, double-spent by the service provider, not the sender. It can be solely double spend by the service provider who created this transaction, the one in three out transaction, the coinjoin in the first place. It can in theory be double spend in the mempool level, then that's why you have to wait for confirmations in theory, but it has immediate availability to you. The funds you receive in the mempool, VTX cells, they have immediate availability just like on chain, just like how you can chain unconfirmed transactions on mempool Mempool on Bitcoin. Yeah. You can't hand over vTX cells to others." }, { "speaker": "stephan", "time": "39:37", "start": 2377.41, "text": "Gotcha. So, I guess to explain that, so the point is you can immediately spend them forward, though theoretically it's possible that you kind of get rugged in terms of the mempool, like the ASP trying to double spend that coin. But as I understand from what I was reading in the dialogue and some of your, what you were saying, some of these ASPs might also be an LSP as an example, and then you might have made- That payment, like you might have received that, you know, let's say I pay you two million sats on ARC, and you might pay for, you might be making a payment to some other guy one million sats on Lightning or something like this, and at that point the ASP has already sent out the Lightning payment, so, you know, they would be out their own money if they try to rug you basically." }, { "speaker": "guest_2", "time": "40:22", "start": 2422.44, "text": "Yeah, rug you, yeah. And you already paid a Lightning invoice anyway, so in that case, again, because it has immediate availability, you can also pay Lightning invoices with it. Transfers, like just like eCash, you can make internal transfers, eCash style, or you can make, you can pay Lightning invoices. And when you make a Lightning invoice with the entire money you're receiving to a vendor, to a Lightning vendor, you can consider it final, although it's not confirmed yet, you already paid the invoice, you obtained the payment from the vendor, so it is a final payment. So ORIG is a protocol with, delayed finality but immediate availability. Funds are immediately available to you, you can hand over the- Someone could pay you money with them, but they are final at some point, you know, after several confirmations." }, { "speaker": "stephan", "time": "41:08", "start": 2468.21, "text": "So just to expand or just to, just so I can understand the finality versus settlement component or availability versus settlement, I'm not sure the right term here, but as you were saying, it sounds like there's five second intervals. So basically, on five second intervals, you could have been paid money, but in terms of considering that confirmed, we would wait until there's an on-chain confirmation really for there to be like, in theory, final settlement or at least On-chain, to the level that you can consider an, an on-chain confirmation final, right?" }, { "speaker": "guest_2", "time": "41:38", "start": 2497.79, "text": "Yeah, that's true. Yeah, funds are available to me after five seconds, but it's final after ten minutes. So if I'm receiving payment, it's available, it, it, my balance is credited after five seconds once it's in a transaction, right? but it's confirmed, once it's confirmed, it's final." }, { "speaker": "stephan", "time": "41:56", "start": 2515.5, "text": "Gotcha. One other question there around the ASP side. So let's say it's on the ASP now to get that confirmation with- Within ten minutes. What if the ASP, what if the block space fee market runs away from them? Like they put this transaction in at ten sat per byte, and all of a sudden it rockets up to fifty sat per byte? Is it on the ASP now to do some kind of RBF or some kind of operation to make sure it confirms in the next block?" }, { "speaker": "guest_2", "time": "42:19", "start": 2538.92, "text": "It is ASP's burden and responsibility to make sure that a pool transaction, the coin joins that they create, ends up in a block. It's their responsibility to do that." }, { "speaker": "stephan", "time": "42:31", "start": 2550.51, "text": "Okay. So let's talk a little bit about About the ASP side of this, right? So can we just walk through a little bit what's involved from the ASP side? As I, like, I guess at a high level, I'm thinking, and from what I've read as well, it sounds like there will be, if we're calling them an ASP or ASP coordinator, that there will be a high capital requirement, right? That they need to have a lot of coin themselves, in order to really run a big, a proper ASP, because users might need that, like, it's kind of like, it's, it's like To be able to manage people's channels, it's a similar kind of thing, right? So could you just explain a little bit the, from the ASP point of view, what's going on?" }, { "speaker": "guest_2", "time": "43:10", "start": 2590.41, "text": "Yeah, so it's very similar to, like, ASPs, ASPs, have a bunch of outgoing on, inbound channels, right, to make sure that they, they provide a service pro-properly for their end-users. It's, it's similar, similar to ASPs, like you have to provide liquidity, a bunch of channel, not, not channels, a bunch of On hand, like on-chain funds available to you, so that you can provide liquidity, for these coin joins, and you lock up funds for four weeks, in every five seconds, so on an ongoing basis, you're, you're, you're constantly providing liquidity, and liquidity gets exhausted at some point, so you have to make sure that you have enough liquidity for the ongoing coin join transactions, and the liquidity you lock up, i.e. for four, four weeks, only be revealed to you, like, available to you after four weeks, so you have To have, make sure that you have enough liquidity to provide liquidity for a whole month." }, { "speaker": "stephan", "time": "44:07", "start": 2646.51, "text": "I see. So it's kind of like it's, you aren't able, you are basically not able to use those coins for four weeks, I guess. And because obviously this is a full reserve system, right? There's no fractional reserve here, right? So, also in terms of the ASPs, do they need to get a transaction confirmed into every block or how does, how does that work?" }, { "speaker": "guest_2", "time": "44:25", "start": 2665.14, "text": "Yeah, so ideal, so in theory, yeah, like there could be just one transaction a block, Ie, you have a coin join session in every ten, twenty, twenty minutes, right? Like in every two blocks. Here we got a, we, it's, we went a bit extreme, right? we have rapid coin joins because ORK is, is, is more of a scaling solution than a privacy protocol, and we have to optimize for the most optimal, best mobile experience because coin joins are interactive by nature. you, it should ideally be done, and because we are making a payment in a coin join, right? Inherently, at the core, at the core of the, you know, protocol at its core, everything is a coin join, whether it's a payment or, you know, regular mixing, it's in a coin join. And if I'm an end user, right, if I'm using a non-interactive client such as a web wallet or a mobile wallet, it should be a seamless UX, and I-- it shouldn't take much long, it shouldn't take long for me to make a payment on ORIC, whether it's paying a Lightning invoice or making an internal transfer, everything is" }, { "speaker": "guest_2", "time": "45:31", "start": 2731.45, "text": "in Complete, I have to wait ten minutes on my smartphone to make a payment. So to optimize for the UX, like, the better UX, we have to make this compromise, right? Each-- there should be, there has to be a new coin transaction in every five seconds so that we can bring the most optimal UX to end users." }, { "speaker": "stephan", "time": "45:49", "start": 2749.02, "text": "Okay, so let me just summarize a little bit my understanding then. So the user is opting into this system, it's like a, he puts his UTXO in. Let's say I wanna go into the system, I put ten million satosh Virtual TXO system, I've got this virtual ten million sats. Now the ASP is helping me sort of manage that, and as you mentioned, there is this TX lock, sorry, the TX locking system. and what's really what's going on is every five seconds there's a coin join round, and as a result of that The ASP is having to make on-chain transactions to help confirm those, to provide the liquidity, right?" }, { "speaker": "guest_2", "time": "46:29", "start": 2789.17, "text": "Yeah, yeah, they provide liquidity and they make sure that they're confirmed. because if it's not confirmed, it breaks the atomicity. If you want to ensure the atomicity, in order for an ASP to claim the sender's money, ASP has to make sure that the transaction's confirmed, the coinjoin transaction that they create, they end up in a Bitcoin block, and they provide liquidity for them obviously." }, { "speaker": "stephan", "time": "46:47", "start": 2807.4, "text": "And so the ASP has to- Really make sure. Now, of course, like we're saying, this is scaling, so the idea is there may be thousands of users, maybe hundreds of thousands of users, all with one ASP, and there would be multiple ASPs, right? And they can kind of-- Can they route to each other or how does that part work?" }, { "speaker": "guest_2", "time": "47:03", "start": 2823.05, "text": "Yeah, so they don't, there's, ASPs on ORIC, they're self-isolated with each other, so they're not quite intr-- They're not interoperable, they're not even aware of each other, and they don't have to" }, { "speaker": "guest_2", "time": "47:19", "start": 2839.44, "text": "You can pick your own ASB, like in the initial onboarding phase, you remember, like you pay in the protocol, to a Bitcoin address, and the Bitcoin address is a two of two. The client software you're using, the or client, whether it's a web client or mobile client, it gives you an on-chain Bitcoin address to pay in your funds, right, in the first place, and that address contains a two of the co-signer of your ASB of your choice, and that can be any ASB. Your client can pick it automatically or based on the fee market," }, { "speaker": "guest_2", "time": "47:50", "start": 2869.88, "text": "you can, you pick in the protocol, into the ASP, right, the virtual set, and you can pick, you know, whichever PSP you want, and from there you're in the system, and from there you can only transact through that ASP, you can't transact through other ASBs because the trust is between me and the ASP and subsequent ones, I have to join that particular ASP's coin joining round. If that ASP blacklists me for some reason, and that also- Also goes to LSPs, I can do an unilateral exit, I can trigger a unilateral exit just like a forced withdrawal on my own. You can take" }, { "speaker": "stephan", "time": "48:26", "start": 2906.26, "text": "your coins back without asking permission, yeah?" }, { "speaker": "guest_2", "time": "48:28", "start": 2908.27, "text": "Back on chain, and I can switch off my AS, ASP to someone else. could be a Frost Federation, could be someone else who isn't block-listed, block-listed me, I don't" }, { "speaker": "stephan", "time": "48:38", "start": 2917.81, "text": "know. So in terms of the really frictionless payments aspect, the best case you're saying would be obviously if two people are part of the same ASP, but if you've ASPB, there's not really an interoperability there. Maybe you would have those two ASPs have like lightning channels with each other, and maybe they would settle that way or how, like what are you thinking there?" }, { "speaker": "guest_2", "time": "49:00", "start": 2940.39, "text": "You don't have to make them interoperable. So if I'm using ASP A, and the intended recipient doesn't matter which ASP it uses, it can be just, it, I mean, just got, it could be someone just onboard the protocol, right? so let's say I'm Bob, there is Alice, right? And Charlie is the operator. I have a two of two between me and Charlie, right? Bob and Charlie, I have some BTXOs, let's say one meal sets, and then I wanna send some sets to, to, Ol-Olives, right? And Olives can use Dave as the pre- I mean, as her pre-preferred ASP or not? It could, could be just onboard the protocol, right? And what happens is I join the coinjoin session, with, with Charlie, the ASP, I'm Bob, and I join the coinjoin session to send Olives In a coinjoin, and the coinjoin intended that the recipient is Ollis, and the v t x o of Ollis is also a twelve-two between Ollis and Charlie, ASP, and Ollis. So when that transaction confirms, Ollis's client software realize Ollis now has v t x o between her and her ASP, Charlie. and from the subsequent runs, he-- I mean, he, i.e., to send someone, right? Ollis, Ollis sends, Joins the Charlie's coinjoin round two to create another vTXO between the new intended recipient and the Charlie on an ongoing basis. If, if you're paying an invoice, and you're connected to you have vTXO set among different ASBs, say you use ASB A B C X Y Z K L M, different ASBs, and you're paying, a vendor a lightning node, you can pay it through an, a v- like, you can pay it, pay a lightning invoice, a single lightning invoice. Via MPP style pair, so that you are, you're forwarding HDLs, like you're pushing HDLCs in a coin join, right? Instead of attaching ATLCs like VTXOs, like instead of registering for VTXOs in a coin join on the output registration phase, you register for HDLCs and you, you attach them to your factory, like you have like three service providers, you, you join them one by one, to- To attach the hdlc, you attach three hdlcs, and from there, these two, three hdlcs, they're also routing routers, they're also lssps, and, and from there, they forward inflight hdlcs to the end destination, in a one mpp payout, but in the internal transfer case, it is a self-isolated payout. If I have like three coins, one mil each, one is between me and a ASBABC, the other one between me, ASBXYZ, and the third one between me, ASPM and ASPKLM. So" }, { "speaker": "stephan", "time": "51:58", "start": 3118.19, "text": "as I'm reading you, then the concept is you could have, let's say, one ARK wallet on your phone, as an example, and you could be connected to multiple ASPs, and there's no-- there's nothing wrong with that. I mean, I guess it's like having a, you know, a lightning node, and you're connected to different channels, partners, right? It's kind of like that, right?" }, { "speaker": "guest_2", "time": "52:17", "start": 3136.82, "text": "Yeah, yeah, yeah Between you and XYZ, you have channel with the ABC, but it's interoperable because you can forward it to a C's and an MPP style, like pair. I" }, { "speaker": "stephan", "time": "52:27", "start": 3146.72, "text": "see, okay. And so if somebody is, I guess put it this way, if somebody is not already a member of an ARC or with an ASP and you wanna make a payment to them, you basically need to get them to set up with ARC, right? To set up an ASP, an ARC wallet and create an NPub or use like their Nostra NPub as an example and take a payment that way." }, { "speaker": "guest_2", "time": "52:49", "start": 3168.72, "text": "Not Of anything, not even aware of the ASP that he's receiving from, right? Is the recipient just downloads a piece of software, right? And, and this, and, and it, it makes the, their end pub available to everyone else, i.e. adding to the t-tip, t-tip, t-tip, right? The center knows, all it takes is the center knowing the end pub of the, of the destination." }, { "speaker": "stephan", "time": "53:10", "start": 3190.23, "text": "Of course, yeah, yeah, of course, yeah. You just need to know the other guy's public key in this case." }, { "speaker": "guest_2", "time": "53:14", "start": 3194.06, "text": "Yeah, and then the recipient ends up having" }, { "speaker": "guest_2", "time": "53:20", "start": 3199.74, "text": "You receive the payment and the payment is between you. Right. That's the" }, { "speaker": "stephan", "time": "53:23", "start": 3202.6, "text": "out-of-bound message to say, \"Hey, you received a payment. Gotcha.\" And yeah," }, { "speaker": "guest_2", "time": "53:26", "start": 3206.26, "text": "and then the message says, \"You have a payment between you and ASP XYZ.\"" }, { "speaker": "stephan", "time": "53:31", "start": 3210.85, "text": "Okay, gotcha. So yeah, it's complicated, but I-- it's like a whole new concept to learn, but I'm, I'm, I think I'm slowly understanding part of it, probably misunderstanding other parts of it, but, anyway. One other question, how do ASPs profit? Do they charge a" }, { "speaker": "guest_2", "time": "53:50", "start": 3229.62, "text": "The service, like service providers are service providers. There are like three things. There are liquidity providers, there are service providers, and service I mean, blinded coinjoin pro-like coordinators, they provide the coinjoin service, but they're also lightning, lightning service providers, they're also lightning routers. They, they, they, they have to provide liquidity to the arc, but also lightning. They ha-they have to make sure they have enough channels on, on lightning, like to a broader protocol. And I also like, I also like giving this lightning, sub Subnet analogy, like, is more like a subnet of Lightning. It's like, it's like this end user subnet. You can internally do coinjoins and all that, like you can mix VTX cells, you can do internal transfers VTX cells with each other, with friends, with family, and all that, or, you know, even nostrutipping. And but you can forward HTLCs to broader Lightning, you can get paid from the broader Lightning, but internally at its core, it's a different sort of design internally. It's, it's a Rapid Coinjoin protocol This only shared with you to Excel model. Internally it's different, but externally it is interoperable with Lightning. You can pay invoices, you can get paid from invoices. so it is, it's a distinct layer two, but with, Lightning interoperability." }, { "speaker": "stephan", "time": "55:03", "start": 3303.29, "text": "Yeah. One other question around users refreshing their coins. So, from reading the documents, it looks like the user needs to come online at least once every four weeks to stop the ASP basically being able to run away with the coins. So how does it work in terms of coming online to refresh? Do you need to do an on-chain transaction for that refresh or is it just like going online?" }, { "speaker": "guest_2", "time": "55:24", "start": 3323.66, "text": "You do a remix, we call it remix. It's a cool term, remix. Like, so like, once you're in the system, once you pick in and once you-- you only pull it on-chain, once, when you pick in and pick out. For internal transfers, it's footprint minimal. They're all often coin joins, right? I mean, there is the on-chain part of it, but it's minimal. One in three, out every five seconds, The off-chain part is the internal transfers or paying lightning invoices, and your coins, your vTXOs, unlike on-chain, has an expiry, like they expire at some point. in an on-chain wallet, unlike on-chain, it they're in, in the, infinitely there, you can do the cold storage or even hot, but they will be there forever, right? if, if they're not spent. on the ORIC, your coins expires at some point, which- I think this isn't a trade off at all, I'll come to that. so your coin expires after four weeks, so imagine you have a UTXO, but it expires, right? You have to spend it before it expires, or o-otherwise it's gone. in the art context, so you have a coin, you send it to someone, the recipient receives it, and the recipient now has a four week time lock, right? Four week time lock. After four weeks it expires, so the intended recipient Bitcoin has to spend that UTXO, VTXO, in that timeframe, four week timeframe. And if it's about to expire, right? it's, you haven't spent it yet, you're holding it, you're a holder, you wanna hold Bitcoin on the network, you're not spending, and your VTXO is about to expire, what you do, you do a self swap, you return coins back to yourself. It's like a self send," }, { "speaker": "stephan", "time": "57:13", "start": 3433.07, "text": "gotcha." }, { "speaker": "guest_2", "time": "57:14", "start": 3433.81, "text": "Self send. You join a coinjoin session to send yourself 12 to reset the four week timer. And this, and this is called remix, and remix are not charged liquidity fees." }, { "speaker": "stephan", "time": "57:25", "start": 3444.86, "text": "Gotcha. And this is like in the coinjoin protocols where they call remix, the idea is to get multiple mixes, to give yourself additional privacy. So I guess it's kind of mimicking that idea, remixing." }, { "speaker": "guest_2", "time": "57:35", "start": 3454.76, "text": "So that, yeah. So if your coin is about to expire, you do remix, and remix are not charged liquidity fees." }, { "speaker": "stephan", "time": "57:40", "start": 3459.63, "text": "I see. In terms of picking ASP, how do you see ASPs competing? Would you see that as like a, Do they compete based on how much liquidity they have? Do they compete based on uptime, availability? Like, how would you pick one ASP versus another ASP?" }, { "speaker": "guest_2", "time": "57:57", "start": 3477.0, "text": "Yeah, so yeah, I mean, you, you only pick your ASPs in the initial onboarding phase, as you remember, like you're not actually able to pick it, like once you're in the system, because it's heavily reliant on who are you, who are you receiving from, if your, the, the, if your, the sender, your friend, i.e., sending a payment or zap or donation or whatever, using ASPs Xyz and you, you, then you have a coin which is absorbed between you and Xyz, and you have to join Xyz session to send it for-forward the payment fur-further, right? And you're subject to fee policies, that AxBXyz charges, like, like dictates, right? You're, you're subject to it. If you're not, you know, if you're not, happy with the policy, the fee rates, which is totally customizable, like it's a free market, to, to, I mean There, there will be many competing ASBs with different fee schedules, fee rates and all that, both in terms of on-chain fees and, you know, liquidity fees, basis points. you or you are subject to the, the policy. Like, there isn't nothing you really can do. It's, it highly depends on who the, who, what ASB the, the, the, the center, you're receiving from. Like, who is sending" }, { "speaker": "stephan", "time": "59:13", "start": 3552.53, "text": "it. So I guess worst case you would try to withdraw out and take it back on-chain into your hardware wallet Multisig or whatever, right? Or you" }, { "speaker": "guest_2", "time": "59:19", "start": 3558.85, "text": "can pay a" }, { "speaker": "stephan", "time": "59:20", "start": 3560.17, "text": "Lightning invoice, yeah. Or pay a Lightning invoice and get out that way, right? Yeah. Okay, gotcha. So you're-- and so I guess even though we're talking about the protocols in a competitive way, like a ARC versus Lightning and so on, you're also seeing it in a complementary way that some of these providers might be both, right? You might be both an ASP and an LSP, and then the user is sort of able to use both functions, and then it's on the ASP side to kind of manage their All those other aspects of it to give the user the better experience, right?" }, { "speaker": "guest_2", "time": "59:52", "start": 3592.0, "text": "That's all about, that's what orga-orga is all about, yeah. Giving their end users, a frictionless, proper UX, payment experience in a subcostal way. And ASBs are, they have to be AS-ASBs. I mean, it's not quite optional, although it might seem optional, ASBs, they should be also ASBs." }, { "speaker": "stephan", "time": "01:00:11", "start": 3611.49, "text": "Oh, I see. So it's not optional. Okay. I didn't quite get that part. Okay, thanks for clarifying" }, { "speaker": "guest_2", "time": "01:00:17", "start": 3617.55, "text": "No, like you're using ORK to pay Lightning invoices too, right? I mean, obviously, I designed ORK like that's how it all started. ORK started was a Lightning wallet idea." }, { "speaker": "stephan", "time": "01:00:28", "start": 3628.46, "text": "Yeah, gotcha." }, { "speaker": "guest_2", "time": "01:00:29", "start": 3629.08, "text": "And ORK is a Lightning wallet, like ORK is like a subnet again. Gotcha, gotcha, gotcha. And the ORK wallet is a Lightning wallet. Gotcha, gotcha. Okay. Yeah." }, { "speaker": "stephan", "time": "01:00:37", "start": 3637.11, "text": "Okay. and so I guess as we, I think we touched on this before, but I guess the idea is, let's say I" }, { "speaker": "stephan", "time": "01:00:47", "start": 3647.47, "text": "The, ASPs on there because I have coins with them or vTXOs with them. I guess the idea is my wallet would need to periodically check to do that four week remix thing, right? To kind of periodically remix so that I don't lose my coins. So basically the idea is the wallet needs to come online every now and again at least, to do that remixing, but it's doing it across multiple ASPs, not just one, right?" }, { "speaker": "guest_2", "time": "01:01:10", "start": 3670.27, "text": "Yeah," }, { "speaker": "stephan", "time": "01:01:11", "start": 3671.75, "text": "yeah," }, { "speaker": "guest_2", "time": "01:01:12", "start": 3672.45, "text": "that's true. Gotcha. Okay. That's true. Li-Lightning" }, { "speaker": "stephan", "time": "01:01:16", "start": 3676.71, "text": "has the similar, Channels, etcetera." }, { "speaker": "guest_2", "time": "01:01:19", "start": 3679.09, "text": "Twenty-four seven, yeah. Here it's more, it's, it's, it's more, it's just for weeks, but it's also, I don't see this as a trade-off because like in extreme cases, like in a boat accident or some inheritance-related issues, if, if you're, if you lose your funds for some reason, you can just reach out to your LSP, your service provider for a refund." }, { "speaker": "stephan", "time": "01:01:38", "start": 3698.01, "text": "I see, yeah. And of course, I think the idea here is this would mainly be for spending amounts, right? Wallet or hardware signing device or multisig and stuff like that, and this is seen more like a spending wallet amount, right? Or no?" }, { "speaker": "guest_2", "time": "01:01:54", "start": 3714.48, "text": "Like in, in, in like, if you are seeking proper cold storage, yes, but, you can also seek a cold storage, you know, if you are interested in storing your Bitcoin, like, in a, in a more secure way, like, on Ark, 'cause if you're, you're concerned about on-chain fees and all that, you can do it on Ark too, with customizable, like, pools with custom, expiries, expire, custom expiry." }, { "speaker": "stephan", "time": "01:02:22", "start": 3742.04, "text": "Right. So instead of the four week expiry, you, you-- It could be extended." }, { "speaker": "guest_2", "time": "01:02:25", "start": 3745.22, "text": "Like, well, one, one week, like, like one year, it could be two years. Gotcha. Obviously, you're being charged more fees for that because the liquidity allocation requirements are higher, right? The ISP has to provide like liquidity, lock their liquidity for one year, you know, or three months, right? In that, in that case, you're being charged more fees ideally, but if you're seeking, Storing your Bitcoin, without dealing with all this interactivity, i.e. for six months, one year, you can do it in theory, yes, with your, with a, with an LSP of your choice, an LSP can provide that service for you, like a custom, pools with, pools with custom pools and coinjoin transactions with a custom CLTV deltas." }, { "speaker": "stephan", "time": "01:03:07", "start": 3787.18, "text": "I see. Okay, so let's talk a little bit about some of the criticisms I've seen as well. One of the criticisms I've seen is this idea of, I guess it's kind of like a vaporware criticism or this idea of, \"Oh, you're putting out all this idea, but where's the working code? Where's the software?\" I'm curious if you have any thoughts on that as well." }, { "speaker": "guest_2", "time": "01:03:24", "start": 3804.49, "text": "Oh, yeah. So there is, I, I love the saying like, \"Cyberphiles write code, wizards craft magic.\" So I'm a, I" }, { "speaker": "guest_2", "time": "01:03:37", "start": 3817.0, "text": "I don't qualify myself as software engineer, although I did some software engineering stuff in the past. like I did some mobile development, I did some Bitcoin development, but, but I, I really don't think I fall into that category. I'm not quite a software engineer myself. I'm more like a, I, I'm more like a wizard, right? that, that's, I think the right category for me. and I, you know, I, I speak with my experience, right? I did like a two years long covenant research on the Alameda Lightning, how this evolved from lightning bolt idea, and it, it's based on my experience and knowledge and confidence. And I, I've, I have been obsessed with lightning scaling and privacy, and that's how ORK started in the first place. And I speak with my experience, yes. I, lightning isn't, I mean, ORK is an idea, it is in the, early protocol iteration phase, yes. it's gonna, it's gonna take a long time, yes. we're gonna do some prototyping. I'm currently Assembling a team of Bitcoin, like an Avengers team, of Bitcoin engineers and devs, we, we are aiming to build help ship, like a prototype, like a primitive version, hopefully Q3 this year, later this year. we, we're trying to figure out like where to do prototyping first. Sh-should could be, should it be like a Signet or Inquisition or should it be Mainnet? like interactive version of Mainnet, because like there's like two different versions we can do, like interactive Mainnet versus like Interactive?" }, { "speaker": "stephan", "time": "01:05:07", "start": 3907.62, "text": "Gotcha. That was the other question I was gonna ask. Can we, can you explain a little bit about the interactive version versus the non-interactive version of this? So as I understand, the non-interactive version requires APO, any proof out, or check template verify, or some other alternatives that basically give us covenants, or it's gonna be an interactive protocol. So could you explain the differences there for us?" }, { "speaker": "guest_2", "time": "01:05:28", "start": 3928.27, "text": "Yeah, so ORC is, is something we can build on Bitcoin today, but we have to compromise on non-interactivity to do so. An, an interactive version of ORK, just like Lightning, like just like how you self-host a Lightning node, CLN-LN or LDK node, you can self-host your ORK client, a hypothetical ORK client, ORK Daemon, C-L-I, on your Umbrella, you know, or your Raspberry Pi, or, you know, could be on a server. You can self-host it, you're online, and you can receive payments, you can send payments. the, the receiving part, is why you have to be online, because, I mean We can use the only way to emulate covenants, covenants I mean, restricting the transaction outputs of a spending transaction using n of n multisig. We can use n of n multisig to emulate covenants behavior, and that requires you to be online as a recipient to sign from the n of n xpub to constrain your own portion of your xpub among others, from the n of n. To be online, so you have to be online to do so." }, { "speaker": "stephan", "time": "01:06:40", "start": 4000.02, "text": "Right, and that's just like with Lightning today, that you need to be online to receive, et cetera." }, { "speaker": "guest_2", "time": "01:06:43", "start": 4003.9, "text": "Just like Lightning? Yes. I mean, in theory, you can be offline on Lightning too, but I mean, you can't receive, yeah. I mean, part of the reason is you can't create pre-images when you're offline. But PTLCSolve that, really? but you have to be online anyway to, to sign over channel breaches. In order, you also" }, { "speaker": "guest_2", "time": "01:07:04", "start": 4024.21, "text": "have to be online in If we are here to build our own Bitcoin today, if we have covenants of it, we have covenants, such as CTV, TXS, CBSK, like there are a bunch of different combinations you can do, if you have covenants in Bitcoin, you-- it becomes non-interactive. You don't have to be only, you don't have to self-host. Simply the shared xPub is constrained to a set of transaction outputs containing yours, containing your vTXO, and it can be offline, it can be on the go, you can receive it, you don't, you don't have to resume in that case. but, but I'm just dreaming, right, at, at this point. so we're trying to figure it out, right? Should we do an Inquisition, because Inquisition has CTV and, and, and APO, it's a Signet with ex-experimental features, but Liquid" }, { "speaker": "guest_2", "time": "01:07:56", "start": 4076.83, "text": "Value, right? so it might, it might more sense, right? It might make more sense to do a liquid, if you are to do a non-injective version," }, { "speaker": "stephan", "time": "01:08:04", "start": 4084.94, "text": "it might help prove out the demand for CTV or APO, right? so that might be interesting to sort of show, oh, hey, there's actually a working use case here, but, in terms of, real-world usage, it's probably gonna be-- that would be a slower path, but, it would, it would be interesting at least from that" }, { "speaker": "stephan", "time": "01:08:27", "start": 4107.07, "text": "Or something. So I guess, we should probably just quickly explain a little bit about covenants for people who aren't familiar with that. Like, I guess, let me just offer my kind of poor man or layman's explanation, and you, you tell me where I'm getting it wrong, right? So, I guess, set in the context a little bit, because I understand people can get a bit concerned about covenants, so let me explain how I'm seeing it. So, in Bitcoin today, we have time locking and we have multi-sign" }, { "speaker": "stephan", "time": "01:08:56", "start": 4136.97, "text": "What you can spend in terms of already existing outputs. The idea with covenants is more like, what can you restrain in terms of future outputs? What is the future output of that transaction and what is the way that it can be spent, right? It's like a, a future restraint. And I understand where some people have a concern because, okay, does that lead to-- could there be a risk where the government says, \"Oh, you may only, you know, transact, inside the purview of the government or the state or with KYC, et c" }, { "speaker": "stephan", "time": "01:09:26", "start": 4166.83, "text": "It would be like an opt-in system, right? So for example, if you are generating an address to get paid today, you are the one determining whether it's a covenant or not. You are the one who's saying, \"I just, you know, I'm generating an address that's single signature that I can unilaterally control without a government, without anyone else, or without a third party.\" Or if you are opting into a covenant system, you would be the one to generate that, you know, like an address or, you know, some kind of covenant-based thing on which future And it sort of works as part of this system as we've just, as we've been talking about with ARC and with, you know, even there might be improvements with Lightning as well, who knows? So that's how I'm seeing it. How do you see it?" }, { "speaker": "guest_2", "time": "01:10:08", "start": 4208.5, "text": "I 100% agree, we're on, on, online with this. We're on the same page, we're like on the same table, yeah. So coverings is a way to constrain, spending, the outputs of a spending transaction of a future transaction versus today, you can't really constrain" }, { "speaker": "guest_2", "time": "01:10:26", "start": 4226.91, "text": "Already know in advance that you're part of the covenant script, so you are part of the covenant, like on the, on the output you're spending, right, in the next transaction, you're already part of the covenant, you know it, you know in advance that you're part of the covenant, you already opt in to covenant. and in terms of like, you know, the, the, the, the, the, the blacklist censoring stuff state level, well, it's also possible to do on Bitcoin today, like with multisig, multisig, you know, a state could On protocol level, in, in, in general level, but, it's already possible on Bitcoin today, and it's entirely opt-in, and I, I don't really understand why, why people are so scared of it. it's just a very simple primitive, it unlocks a bunch of use cases, and it's entirely opt-in, and it, it just, you can do that also to blacklist the evil stuff on Bitcoin today too with multisig." }, { "speaker": "stephan", "time": "01:11:16", "start": 4276.85, "text": "Yeah, so I think the main thing is really fear of the unknown, and it's, it's another whole technical concept With the concept of time locking, it's used as part of Lightning today, CSV, Check Sequence Verify, so I think it's just that people aren't comfortable with that, and I think this is part of the educational journey that everyone has to go on. And in fairness, I think what happened with, well, with Jeremy, with CTV, with Check Template Verify, I think a lot of people, I think people got spooked a bit, people got a bit scared because of the activation attempt, when I think at the time it was really only developer and Kind of insider circles who really knew what that was, and I think there were a lot of people who were just sort of instinctly, instinctively saying, \"Well, hold on, what's this like? I, I don't want people to change Bitcoin, I don't want to change things,\" but, and this is where there may be some tension, right, on that aspect of whether Bitcoin should have a soft fork, because there'll be all these arguments coming up about, \"Well, if we don't have soft forks in Bitcoin, will that mean a lot of people end up And otherwise, because, you know, without having these covenants and these kind of extra features and things like CTV and anyproverout and maybe OpVault and things like this that maybe scale the self-custody element of it, I guess, I guess that's how I'm viewing that anyway. But what do you think?" }, { "speaker": "guest_2", "time": "01:12:42", "start": 4362.28, "text": "We have to do a more job on educating people, yeah, people for some reason are scared of it, especially for, like recursive covenants stuff, though CTV doesn't enable recursive covenants. In fact, I'm not, I'm in" }, { "speaker": "guest_2", "time": "01:12:56", "start": 4376.95, "text": "Communicating with the community better on this, like, covenants educating them, you know, the trade-offs always-- there is a trade-off everywhere, right? You're changing Bitcoin, there could be risks involved. But I mean, covenants have been-- they are there, like, they are there on Liquid, like, already, it's been there for like four, four, four years, and, you can think of it Liquid as a test bed, and I did some, some work on Liquid in the past, and from what I can A bunch of use cases and let's bring them. And in fact, I'm seeing, and I, I appreciate it, like I was in favor of CTV activation at the time, I was on the, on the pro CTV camp, and I appreciate like the people who are, who were against it, because in, culturally in Bitcoin, we tend to preserve the protocol and this is the way to go. I appreciate it a lot. But, I'm, I'm luckily I'm seeing like people changing ideas, shifting their ideas and like getting, you know," }, { "speaker": "guest_2", "time": "01:13:56", "start": 4436.63, "text": "I you know, on, on CTV and, and Covenants in general. So, h-hopefully, yeah. so we, we're seeing the trends, yes. Hopefully, hopefully we'll get there at some point." }, { "speaker": "stephan", "time": "01:14:06", "start": 4446.44, "text": "Yeah. A few other smaller criticisms or ideas that I've heard, in relation to ARC, and maybe some of these also apply to Lightning, in fairness, but, this idea of if a lot of people all unilaterally exit at once, does this create a rushing to the exits problem? And I guess just one thing to add to" }, { "speaker": "stephan", "time": "01:14:26", "start": 4466.87, "text": "Roast beef. He was saying if everything has to unroll, the amounts still have to be economical relative to the chain fees, right? So do you have any thoughts on that idea?" }, { "speaker": "guest_2", "time": "01:14:35", "start": 4475.8, "text": "Yeah, so the, the former concern, right, if everyone r-rushes out for an exit, like on-chain mempools, it will be a disaster, yes. that trade-off also goes to Lightning, but I have a design in my mind that can, address this further, like in, in the long term, it's like more like a lo-long term feature" }, { "speaker": "guest_2", "time": "01:14:57", "start": 4497.17, "text": "In my head, I mean, obviously I'm working on the specs, that's what I'll be working on in the next few months. the way how it works is like, if something goes wrong, you'd trigger a unilateral exit, but before doing that, you have to reveal all nested like vTXOs from the shared vTXO, you have to reveal them from the shared vTXO, all in one. and that's how it works. but a future extension of this would be, it would be hopefully a, a withdrawal tree. In a withdrawal tree, like And you can withdraw VTXO from the tree one by one, and once you withdraw like a VTXO from the tree, we are adding like, a relative locktime in addition to an absolute locktime, and the absolute locktime being the end of four week, right? But also adding a relative locktime, i.e. at twenty-four hours, to this tree, so that whenever I with- whenever someone withdraws a VTXO from the tree, the, the twenty-four hour timer resets back to zero. And the- Remainder, like the other vTXO's and the three remains, so that although the four-week timer is over, it could take years," }, { "speaker": "burak", "time": "01:16:05", "start": 4565.78, "text": "you know," }, { "speaker": "guest_2", "time": "01:16:06", "start": 4566.02, "text": "decades to withdraw from the shared vTXO in a, in a disaster scenario in that case. This is, because every time twenty-four hours resets to zero, right? this is theoretically possible in Bitcoin, like we can do it today, even like with our covenants, in theory, because again, we can emulate CT with N of N. But even with CTV or TX hash alone, you know, it is really hard, like because we have to-- because we don't have Tapleaf Update Verify, right? and without that, we can, with Mast, we can emulate it with CTV. CTV or TX hash can emulate a withdrawal tree, Tapleaf Update Verify itself." }, { "speaker": "stephan", "time": "01:16:49", "start": 4609.87, "text": "Okay. So with the, with the withdrawal tree, is the idea then that you're staggering the exits?" }, { "speaker": "guest_2", "time": "01:16:55", "start": 4615.57, "text": "Yeah, the, the other sweet- Sweep larger like the ASP, the service provider sweeping it, is, is it got delayed every time, twenty-five by twenty-four hours, every time you, as someone, withdraws from the sweep." }, { "speaker": "stephan", "time": "01:17:08", "start": 4628.88, "text": "Okay. Okay, cool. So, I think those are probably the key questions. I mean, there's, I'm sure there's like a thousand rabbit holes we could explore, but trying to keep the episode manageable for people, hopefully this is a good overview. We've gone through a lot, so I guess let me just kind of summarize again, just so people are sort So the idea is, this is an off-chain protocol. The idea is the user can opt into this ASP, as an example, they can lift his UTXO. The ASP helps him manage that, and there's ATLCs, and there's all this technical stuff in the background to sort of make it atomic, right? To make it, you know, and so that he can unilaterally exit. But the, the, the long and the short of it is that he can essentially peg in some coins into ARC, let's say. He has a VTXO. Those VTXOs can And because of, because there's a five second round, every round there's a remix, the ASP is managing that. The ASP has a lot of liquidity and capital costs But the ASP is also an LSP and it's managing all of these aspects. And in terms of the user being able to exit unilaterally, he can still do that, and the way payments would work is basically, you would need to know the other guy's public key, his ARC public key, I guess, And then you can just make payments without the inbound liquidity problem, which is what we have today in Lightning. The, yeah, so it seems the main downsides though are, to do it, in the best case, it requires a soft fork to get some kind of covenant, and the o-- I guess the other big downside is it seems like the ASPs require a very, it's a very high capital cost, because the ASP has to have enough Bitcoin to basically back or kind of bankroll all the transactions going on inside their ASP for four weeks. Fair summary?" }, { "speaker": "guest_2", "time": "01:18:55", "start": 4735.69, "text": "So that's, that sounds everything well, yeah. But it's a great one, thank you." }, { "speaker": "stephan", "time": "01:18:59", "start": 4739.11, "text": "Okay, great." }, { "speaker": "guest_2", "time": "01:18:59", "start": 4739.85, "text": "I couldn't, I couldn't understand better yet, to be honest." }, { "speaker": "stephan", "time": "01:19:02", "start": 4742.47, "text": "Okay, well there you go. Alright, so we'll see what other feedback people have. Are there other criticisms and other ideas people have out there? Of course, everyone, leave your comments in the, you know, in the Twitter threads or on YouTube or whatever. Burak, where can people find you if they wanna follow, follow you and find out more about" }, { "speaker": "guest_2", "time": "01:19:25", "start": 4765.69, "text": "Short, it's not, it's a quite, it's a quite a unique name in the Bitcoin space, but we also have a Telegram group, like our community group on Telegram, you can find it out on Telegram, Arc Community, or also, we also have a website called arc pill dot me So on, on, on the website, we have the, like a brief one page overview, a protocol overview, plus a deep dive if you're technical enough and interested in learning more. Also we have a short, we also have a f-f-faq, if you have any, any further questions. We also have a get involved page, and on page you can, you can find a link to our Telegram channel, and feel free to join our channel if you have any, any questions or, or of any kind really, it could be stupid or not," }, { "speaker": "guest_2", "time": "01:20:08", "start": 4808.26, "text": "feel An on-chain address, and if you, if you are a Bitcoin talent, if you're a Rust talent, feel free to reach out us, on, on the get in more page, we have an email from which you can, you can, you can, you can reach out us, if you, if you wanna contribute and if you're a Bitcoin talent." }, { "speaker": "stephan", "time": "01:20:21", "start": 4821.42, "text": "Fantastic. Okay, well, thank you. Hope it's a very, optimistic vision of what, an alternative L2 could offer to Bitcoin. So, thanks for joining me and helping explain this," }, { "speaker": "stephan", "time": "01:20:38", "start": 4838.23, "text": "Get the show notes at stephanilivera dot com slash four a two, and if you enjoyed this one, make sure to share it so other people can learn also. Thanks for listening, and I'll see you in the citadels." } ] }