Chat_111 - Brollups, Ark 2.0, and 1000 tps with Burak

[00:00:25] Speaker A: It. [00:01:00] Speaker B: All right. [00:01:02] Speaker A: Hey, what's up? [00:01:05] Speaker B: Hey. Hey. Hey, Al. How's it going? I think this is our second time, right? [00:01:10] Speaker A: Yes. [00:01:13] Speaker B: Is it record only or audio only or video two? [00:01:17] Speaker A: I was going to do video, too. I can do it audio only if you want. But I usually try to publish these to YouTube and rumble as well whenever I can. [00:01:26] Speaker B: I mean, either works, really. It's up to you. So is the. How about my lighting? Is it okay? [00:01:34] Speaker A: It's a little dark, but, I mean, I can see you if you can. [00:01:38] Speaker B: All right. A bit more shadowy. Super quarter wipe. I can put on more light, maybe, and see. Actually light it up. [00:01:52] Speaker A: Oh, there we go. I love the axle in the wall. [00:01:57] Speaker B: Yeah. Yeah. I mean, hence the name suggests it's bitcoin audible. I thought it was. It was bitcoin. Audio only. [00:02:10] Speaker A: It was for a really long time. It was for a really long time. [00:02:14] Speaker B: Okay, that's fair. I don't. Because I don't remember the first time, but it was Audi only or what, but. Okay. Anyway, here we go. Funny, right? [00:02:25] Speaker A: Is there anything in particular you want to bring up or you want me to lead you into that? Because I'm mostly my. Two big things that whenever you come up that are or that pop into my mind that I wanted to talk to you about were the Ark 2.0, basically. And then also you basically came up with the idea of brolups. Right. [00:02:52] Speaker B: Like, yeah, yeah. Roll up. Yeah. Not the plural one. Yeah. Yeah. That was my Badlande tiger s come from. Yeah. So, yeah, basically two main things. Right. There's Ark. Yeah. Also v two. V two isn't really much of a big thing, really. I mean, we'll come to the biggest. It's maybe I'll briefly mention v two, but, yeah, it's mostly about brawl up. [00:03:21] Speaker A: Okay. [00:03:21] Speaker B: I want to go, like, basically covering two main topics and, like, arc and brawl up. There is lots to cover and I guess that should pretty much sum it up. [00:03:31] Speaker A: Okay. All right, cool. Sounds good. [00:03:34] Speaker B: All right. [00:03:35] Speaker A: All right, well, I'm good if you're good. You're not just going to get into it. [00:03:39] Speaker B: Yeah, we can get into it. Just give me a second, though. [00:03:43] Speaker A: Yeah, yeah, yeah. Take your time. [00:04:35] Speaker B: All right. All right, I'm here. I'm back, so. All right. Yeah, I guess. Yeah, it's good to go. I just got my border. [00:04:43] Speaker A: All right, sounds good. Let me close out some stuff, make sure I don't have too much shite running in the background here. Log sec. You shouldn't be open. [00:05:01] Speaker B: Now. [00:05:05] Speaker A: And quit. Sorry. I had way more stuff open than I thought. [00:05:11] Speaker B: Right? No worries. No worries at all. [00:05:26] Speaker A: Okay. I think we're better. We're better. All right. [00:05:29] Speaker B: Okay. All right. All right. [00:05:31] Speaker A: Start recording. 54221. [00:05:33] Speaker B: What is up? Here we go. [00:05:38] Speaker A: Here we go. All right. We are back. We're back. This is our second show together, and you came on when Ark was still an idea and you had not basically put code to computer for that one yet. And a lot has happened on that front. But then you've also started into additional projects and additional ideas that I think extend. As I was reading, it seems to extend what you had built kind of as the premise for Ark, if I'm not mistaken. But I'll let you kind of get into that. But for those of you who do not know, you should definitely go back if you want to kind of get a deep dive on the edge. Cases of Arc, we already did that episode. We'll be covering some of it here just because there are new things with Ark as well. And now there's actually an implementation of it, which is super exciting. But Burak man, welcome to the show. It's really great to have you. I'm glad we got to schedule this here at the last minute. So thank you for coming on. [00:06:44] Speaker B: Yeah, thanks for reminding me. It's promised to be on this show about a month ago, so sorry for latency, really. I was really tied up with things. [00:06:53] Speaker A: No worries. [00:06:56] Speaker B: Yeah, I guess this happens to be our second ever show, and time flies. It's been a year, so I guess it's been almost come along, like, since the announcement, but things have changed a lot, right? Since then. I mean, things. Well, it's exciting times overall now. Well, what's happening? Lots to cover. I don't know where to start. Yeah. So basically, Arika. So Arc is great, actually, no. So Arc, it's been more than about a year because I've been working on the idea about two years by now, but I really envision ark to be this payment scaling tech and such. In fact, as many of you know, it started off as a lightning bullet idea, and later it turned out to be like, it's. It seemed. It seemed more like a distinct layer, two of its own and such story. And, like, it turns out over time, of course, like, we've got a great reception overall. People overall had good reception and good. Got some. Quite. Quite some good feedback and, like, I mean, people equally, like, got a good reception equally. People were equally skeptical, though. People had some concerns in and around liquidity issues and mock up and interactivity. And such. But like, yeah, liquidity so far has been the main concern. Right. Because it's a liquidity network, like lightning. But to the extreme, the more, like, the more volume gets, the more liquidity, like the service provider has to look up. It's a different sort of design. [00:08:50] Speaker A: But like, like out of curiosity, just so I can give my vague view of it, I don't have like deep specifics, but as I understand it, because you are guaranteeing the funds for each transaction as it happened, but you still have funds in previous transactions that the, the Ark service provider now basically has the final key essentially to take. But there's still that lock. Like it's, what is it, a month lock or something like that. Is that right? [00:09:25] Speaker B: Yeah, that's right. [00:09:27] Speaker A: So that means that, let's say there's a million sats and an exchange exchanges hands ten times in that month. That means you need 10 million sats worth of locked up until the month rolls over and it starts unlocking those funds again. Right. [00:09:42] Speaker B: Timestamp. Yes. [00:09:43] Speaker A: Okay. Gotcha. [00:09:44] Speaker B: Yeah, yeah. Like the more, if you hand it over ten times, say during that one month period you got, it means that you got to log up that, that many times of the funds. Ten times x more liquidity. That sort of trade off. But like, it turns out, like, of course I've also announced the retail design in which, which I guess removes a bit of a friction there. I mean, in fact, it makes streamlines the liquidity problem a bit. Well, actually, like to a certain degree too. I mean, in fact, it kind of fixes the liquidity problem. Like there's some non unknowns and non unknowns, of course, but the v two design it relies on, it's a counting design. It needs a counting opcode like checkstick from stag and ctV. And frankly, covenant discussions are beating up lately. But it needs covenant. But it turns out if you can run arc on a server, none of these problems hold. It's a big if, though. If you can run arc on an umbrella. Liquidity is not an issue. Right. Because you can run Oric on like daily. Like daily, like 24 hours rounds, right? Yeah. [00:11:09] Speaker A: You don't have to do the month. [00:11:11] Speaker B: Lockup necessarily because like when you can run a server, you can opt into your reactive model. And when you can opt into your reactive model, that means you don't need to necessarily wait like months. You can. All it takes is just like 24 hours round and you can opt in more. But if you want. But I mean, like daily rounds is okay. That means like the service provider that they, liquidity gets recycled daily then monthly. [00:11:41] Speaker A: Are those parameters easily configurable? [00:11:45] Speaker B: Not quite, really. Like, I mean, yeah, of course. Like it's up to the protocol design implementation. But like for, if you were to set it for another, like time lock time period, then it means you need another on chain outputs. Like, because like each transaction outputs. If you to say you like for each setting you need another transaction output. Like for 24 hours rounds you need one. For one month rounds you need another. [00:12:12] Speaker A: Okay. [00:12:12] Speaker B: Because the time lock condition is explicitly hard coded. Like yeah, and that's the output. So ideally the fever configurations the better. But um, like arc is great. Like if you can run a server, it's great. Like not only big liquidity becomes like, like not only it, it's, it solves the liquidity problem. It can also opt into a common model. Like you can emulate covenants without a soft work by, because if you're online running a server, you can emulate common with music and music it's basically pre signing transactions. Kind of like lightning. Lightning is kind of a convert, but. [00:13:01] Speaker A: It'S kind of a pseudo covenant. Yeah. [00:13:02] Speaker B: Yes. Like if you're running a server you don't need, like you can emulate a comment. And not only that, also liquidity gets efficient. So it works. It's not, it's, you can deploy to bitcoin today, literally if you think about it. And that, that's awesome. Like all you, all you need to do is to run a server. [00:13:25] Speaker A: Mm hmm. [00:13:26] Speaker B: I know that's a big exception. And of course in bitcoin, which are, and such, we're all surrounded by bitcoiners and you know, nerds and such. But like normies don't run. No, they get it. But like I think it's, it's a great fit for retail. Like lightning, retail merchants and b, two b, you know, like businesses can run a note. Like ie, merchants can too. Like I'm not sure if like there is a BTC pay plugin for like Oric. I'm not sure. But like you could simply run a server in instance in software. And like you don't need to take any additional steps because like it's not like because it's all taken care of. I mean that's the inherent design. Like inherent design. Like the choices we made, right. I mean the benefits you get versus lightning. Like you need to take care of liquidity and channels. Not necessarily because it's complex complexity. It's not a concern because you can run stuff on autopilot. Concern is like on chain, like channel liquidity management takes on chain action. [00:14:46] Speaker A: Yeah. [00:14:46] Speaker B: Right. If you were to say, feel like, you know, like liquidity is like two edge sword, right? On one edge, you have liquidity abundance, and you have to splice it out. Right. Swap out. Right. And because that's underutilized, unutilized liquidity, it needs to be swapped out or whatever, or like to the opposite. To the. On the other edge, you have liquidity scarcity. In that case, you need to acquire liquid or rent liquidity. Well, it's under on chain transaction. So that's what our solves mostly. And if you do it in like very short time frame rounds and that, and then if you can run a server, you can do it. Well, it's pretty much streamlined. And like, it just works. Right. I mean, it's also great for privacy, right? [00:15:41] Speaker A: Like, yeah, I wanted to ask about the privacy attributes, exactly how our exchanges happen. Like, if I'm using, if I'm running an orc service provider and you and my brother are making an exchange, what does that look like from my side? [00:15:57] Speaker B: Yeah. So it's like arc has built in privacy. One could argue if lightning has privacy or not. Depends really on the LSB model, right? Like, if you pick LSB, then, well, speed interior can collude versus oric. Like, oric, you don't necessarily need like a node, a node id, an entity to really be part of it. Like, like, ie, like. And the dark merchants would never use lightning, right? Because, well, you need a node id, an entity. Well, no, like, I mean, it's a no, right? Like, you would never run ever, like, even attempts to think of, like, running a node, right? Lightning node. No, like, it's a no. But versus oric, it's. You're not a node or entity. All you are is you, is entropy, right? You're not an entropy public key, right? You're just a public key with like, like salon payment style tweaking. So it's like, that means, like no address reuse a convenient way, just like on chain bitcoin, but in more convenient way also, it's built in mixing, like built in confidentiality, right? Like, by default, coins gets mixed in each round. And so it's like in a scalable and convenient way. And so it's all. So it's all private. It's. You can't tell who pays what and when and what amount, really. It is great and appealing for privacy people. I can see arc dominating dark that really quite literally from dark merch. I rather run an ark note and it's hustle free really, because it's not only convenient, that's not the point. It's also private. It's a mixture of some sort. And it's convenient for normal merchants, like merchants who sold papusas and estelle is great convenience for end users. Like for institutions, it's great too because like, you can't run b two b volume on arc. It's simply because like you're running it on daily rounds and institutions run nodes. Liquidity is not an issue there. And I can run b two b, like retail, like daily commerce and such on arc, it's great. But like there's a big if and that if is running a node, it's fine, I guess. But for normies, yeah, that's where the problem comes. Right? Like that's, like, that's what, like what I've envisioned Arc to be was to really be this, like this consumer facing products, like scaling. [00:19:04] Speaker A: It's like the solution to retail. It's like the solution to wallet of Satoshi, right. Is how do you scale and make wallet of Satoshi non custodial while still enabling kind of a lot of those features and expectations of wallet Satoshi and enabling a service provider to essentially take all the complexity out of it. So everybody can always redeem their coins with or without wallet of Satoshi being around and also be able to get privacy from wallet of Satoshi and the general, the anonymous, the anon set of everybody using it and not have this huge on chain footprint at the same time. [00:19:48] Speaker B: At the same time. Right, yeah. Problem. Well, actually this will brought up kind of solves accept privacy. Well that's, we'll come to roll up in a bit. But well, for arc. Yeah, end users, like, yeah, like first, like to draw like two barriers there, right? First you need a comment right here for end users. You need a comment for like institutions and like merchants now. Because you can run a server for everybody. [00:20:16] Speaker A: Can just run one all the time. [00:20:17] Speaker B: Yeah. Is a smartphone. Right, right. [00:20:19] Speaker A: Like. [00:20:24] Speaker B: Maybe some watchtower of some sort, but no, that's interested. But like, again, all you have is e cache. Right? Or some custodial solution for now. [00:20:37] Speaker A: Oh, I actually got a question I didn't realize. I'm not 100% sure if I knew how this worked is since you have kind of like a silent payment tweak to the public key when you're making a payment, is it, is it much more similar to from the user side? Much more similar to a, like an on chain address where like it's push it's a push payment. Like, do you have to be online to sign to receive or can someone push a payment to you through the arc? [00:21:11] Speaker B: Yeah. So for arc, assuming you're running a server. Well, it's. It could be. It depends on implementation. But in theory could just like, it's just like an address, this dedicated address, you know, provided to you. Right? Like dedicated piece of string. Could be an n pop too, I guess. Like in theory it does, yeah. It's just dedicated piece of address. Right. And, you know, and when you. Whenever you attempt to make a payment, you join around, kind of like coin join, you register inputs and such. But like, then the output is, though it's tweaked, the operator cannot tell who you are paying to or attempting you're paying to. That's by some data only known between the two parties. Some defeat helm and key exchange magic in between. Like, it's a dedicated address, but the resulting output is unlinked or unidentifiable. The dedicated address. So that's for an imagined gotcha. [00:22:16] Speaker A: So the address isn't like an expo, doesn't expose all of the payments that go to you. It's just a way to have a way for someone to generate something that will only be unlockable by you. So it's not like a pub key. If I post my pub key, everybody could just know all of my addresses and all of my balances. [00:22:33] Speaker B: You're not getting paid to the dedicated address. [00:22:35] Speaker A: Yeah. [00:22:35] Speaker B: The dedicated address or information piece of string is only used to derive. [00:22:41] Speaker A: Gotcha. [00:22:43] Speaker B: The destination, which is unlinkable to the dedicated address. Of course, amounts and everything is public, but it's a mix. It's a mixer. Right. So it's not a big much of an issue. Like, yeah, so versus art, like, so brawl up to the opposites. It's a privacy nightmare. It's a nightmare. [00:23:12] Speaker A: Okay. [00:23:12] Speaker B: If you're in privacy or privacy guy. Well, it's not your type. Like, it's trade offs and engineering of trade offs. So it is an account model, like roll up is. And I can't follow an account model you're familiar with Ethereum and evMs. It's very much like that. It's much worse than on chain bitcoin because on chain bitcoin you have like, at least address. You don't address. You don't have address reuse there, right? [00:23:41] Speaker A: Yeah. If you don't address, you can separate addresses in the same wallet and as long as you don't cross sign them, it won't be obvious that you own them both. So, right, you have coin control. [00:23:52] Speaker B: If you put privacy, bitcoin privacy in the spectrum, like Oric is on the far edge, right? Edge, super private. Like superior privacy. You not only tweak the keys, you also mix them by default, baked into down into protocol. Right? Default by privacy by default. And maybe one chain, bitcoin in the middle spectrum. Not bad, but not that great. Well, brawl up. It's an account model. It's a Gotham account model. It's always the same address and publicly available. Everyone knows who pays who and whatnot. Just look there. Bitcoin. Bitcoin BTC, like literal BTC. It's not a federated BTC of some sort. It's trustless. It's a real bitcoin self custody. I'll do come the details. But like it's bitcoin, it's self custody. Like it is. It's all public. Not appealing to many. Perhaps to some it is. Like maybe to some people. Some people might prefer publicity over confidentiality for verifiable reasons of whatever. But like it is a public design. It's all public. Like we'll have explorers like mempool like can see who pays you. Literal. Like that's not the case. It's kind of like on g in bitcoin. But it's even worse because you know who pays who, literally what MPAP paid mpub and what public. Well the. But that's a downside. Well, to some it's not a downside, but to some it is to many bitcoiners. Like for the average defi user, like that's what you're used to. That's what they like. Like use it anyway. The same for bitcoin as well. Yeah, it's not quite like not nice. Like they might pop into this kind of trade off, this type of construction. This is probably a non starter for them. But like, like the pro is. Well, the upside it is. Maybe it's better to dive more into specifics. So brawl up is a payment channel design. It's maybe the broader category for this would be the state channel. State channels. The broader category. It's not chain state channels, but maybe better. [00:26:20] Speaker A: So it's a little bit like lightning architecture wise. [00:26:23] Speaker B: Yeah, it's like lightning by category. State channel. But maybe Barry call it payment channel. [00:26:29] Speaker A: Right. [00:26:29] Speaker B: Simple, simpler for the better. It's a payment channel design like lightning, but it's all public. Like you have channels, a bunch of channels. And there's global stage and global state is channel state aware. So if channels, and you make payments between the channels and everyone sees and knows audits. Who pays to like what? Like you make channel from a channel to another channel, everyone sees it. Versus lightning, you have a channel and it's all private. Only the involved parties. [00:27:09] Speaker A: You know the. Know where the route went? [00:27:11] Speaker B: Yeah, yeah. Like. Like late lightning. It's all between the two parties, me and the counterparty self. And only to two parties know what's going to on versus bro up. Well, it's a channel two. It's me and channel partner. My channel partner is the operator. Kind of like Clispy or ASB, but like everyone knows who pays you and from what channel to what, like to from the channel to the destination, what amount. It's all made public. It's all public. And we do so by putting it on bitcoin data in a very compact way, in such a compact and compressed way that it could get. It scales. Well, like get like three gps numbers. Maybe we can come to that in a bit. But like the benefit for doing that, of course, the downside is it's public, since the privacy is bad for privacy. [00:28:13] Speaker A: But, well, from the context of privacy, is there anything that exposes who you are on the network? So like, let's say I wanted to create an anonymous account, do 200 payments and then exit the roll up. Is there anything explicitly that exposes me other than the fact that that account, if I post it publicly from my noster id or something, well then obviously it's mine, or I'm attesting to the fact that it's mine. I. And so people can then connect all those payments, but if it's just random and out there, and let's say I used a VPN or I did it over Tor, is there anything specific that links it in any other way? Or is it just that all payments are visible to that account? And if you can find out who owns the account, then you have no privacy. [00:29:00] Speaker B: All payments are visible to everyone at all times. Lifetime start, lifetime till the end. Like, okay, whatever. Like it's all the same address, keys and pubs. [00:29:13] Speaker A: It's basically like handing out your public key to somebody else and then making. [00:29:20] Speaker B: That public even, you know, you know who you're still loving. [00:29:25] Speaker A: Exactly. It's like zaps. Zaps are completely open. Yeah, yeah, yeah. [00:29:30] Speaker B: But it's more like a check in a more checking account manner, right? It's more account. So it's like this payment layer. It's a layer two, but it's all public and pubs and everyone sees who pays through kind of like an EVM setting. And we do so by inscribing more in bitcoin terms, maybe for the better. Instead of inscribing data like the payment info, kind of like maybe compact block filters, sort of, but not really, like describing very minimal data, like putting data on bitcoin in such a compact way that it gives you, it leaks who pays who and what amount and whatnot. And the benefit is that you don't have to deal with backups. No backups. [00:30:26] Speaker A: Wait, what? [00:30:27] Speaker B: No. How does that work? Because it's public. And what we're putting on chain is also it lets you reconstruct the channel state by just looking at the data. Bitcoin on chain data. Yeah, you can reconstruct. You can reconstruct your channel stage simply. [00:30:47] Speaker A: So you can just check against it with your seed. I mean, you still have your seed backup. You just don't have to have a wallet backup. [00:30:54] Speaker B: Exactly. All you need to remember is your private key. Yeah, right. Your NSEC or whatever, Navonix. And like, you don't have to deal with the wallet like the channel states, you don't have to back up them. It's all on chain. Like, you can reconstruct the whole thing from the bitcoin on chain data. I guess I'll happily trade privacy for that. But to some, it's appealing. It's kind of like own chain bitcoin. Right. You don't have to deal with wallet backups. All you need to remember is your private key. [00:31:30] Speaker A: Yeah. [00:31:31] Speaker B: So the trick is storing data, putting data on bitcoin, like the entire state, it's a global state. Right? It's effectively roll up is a payments roll up or bitcoin roll up, hence the name suggests. Yeah, it's a, it's. It's a payment roll up, of course. Plus smart contracts. Maybe, like, we'll come to that later. But, like, it's, at its core, it's a payments roll up for bitcoin. It's a layer to unilateral exits. Right? It's. It's true. It's. There is no trusted setup of any. It's like lightning. It's probably like. It is a true layer two. Of course, people have different definitions on why layer two is and whatnot. And my definition is like a piece of different software. You transact bitcoin off the chain, you can settle back on chain unilaterally without asking for. I guess that's the broader, different, broadest definition. My definition, too. And by that definition, is a truly or two. There is like well, covenantless arc is also another layer too. If you can run a server, roll up is another layer too. Sidechains are just in category of their own. Not only quite real, layer is a multi sick. There's also this trust minimized protocols and bit vm as its own category. [00:32:56] Speaker A: Side chains are just kind of like multi sig service provision. Multisig isn't possible in the dollar realm. So it's literally its own category of thing of like a conglomerate of companies or service providers. [00:33:13] Speaker B: Like yeah, yeah. Like it's multi sig or merge mine of quorums. You're trusting certain entities which could in theory take your coins and not of course side chains are not exciting enough for that reason. To some, I guess trust minimized protocols or like I guess cool thing like one of n trust assumption instead of n of m because such is an at least m minus n needs to be trusted versus one of n. At least one needs to be trusted. So that's cool. That's in orders of magnitude. You'd like improvement over self custody. But like lightning here. Like roll up. It's not that. Like it's true layer two in the sense that it has unilateral exits. So just like lightning. Of course there's certain trade offs. Like liveness. Lightning has to. You have to be calm. Check online. If there is an invalid state, there's certain, like it's a reactive model you're opting into certain. Certain security model. But like of course it's. But it's trusted at its core, right? Not any. You're not relying or asking permission from anyone. You are the sole owner of their funds with unilateral exit. The early version of brawl up relied on a trusted setup. But the new version, it's a state channel design versus the early version. It was a virtual Utxo based model. Here it's virtual Utxo plus virtual channel. So brawl up. It extends on arc. It's an extension. I was thinking to name it arc Vmdez, actually. Arc Vm. [00:35:00] Speaker A: Arc Vm. [00:35:02] Speaker B: But I thought then Pro lab is more catchy. Yeah, it expands on Arc. It is an extension. It's kind of like a layer. A layer on top of arc, if you think about it. I wouldn't say it heavily borrows from Arc. Its concepts. It's. It's extends on art like it is arc plus state channel design plus VM dA. Like, there's more to it. There's the arc. It has arc characteristics, but it also has roll up characteristics. And I thought roll up is a catchy name. So like it's a shared Utxo model. Like Oric, we shared Utxo and virtual, virtual UTX cells and connector outputs. The liquidity provider. It's a liquidity protocol like arc. In fact we're using dynamic frost like defrost. It's the new cutting edge thing. So it's like there's the operator, the entity, and who provides liquidity. It's like a quorum, it's a quorum entity, but it's represented in a single key. And if you can add remove members without changing the key, it's a single entity, immutable, unchanged, fixed at all times. You can add remove members or change the setup parameters and of n parameters without changing the key, the full key. [00:36:31] Speaker A: So it's like interesting. So you can actually update inside the brollup without actually an on chain footprint during the footprint. [00:36:41] Speaker B: Well actually there's footprint in every session, right? But yeah, like without in a more convenient way. Let's say you can like the design relies on updating the key actually. But that's another thing. But like, yeah, like you have two keys, the dedicated key, the well known key who represents the operator operator is the block producer who produces the rollout blocks, who's also your channel counterparty to remote. It also provides liquidity, but we represented in a single key at all times. But there's also the dedicated, like there is also the dynamic key, so dynamically changed and used in the channels. And the dedicated key sort of the dedicated key signs dynamic keys. And we did this before doing this for dynamic, for deterministic non selection, for signing channel states. So to save bytes in the data availability layer, signature is like the Rvalue S value, 32 bytes, like 32 bytes each. To save 32 bytes from the nonce, we keep it dedicated. So if it's sort of like we are hard coding a set of nonsense in a pool, hard coded in the client, okay, you can like also inscribe them in bitcoin, but like have this pool of hard coded pre selected gnosis and you are sort of, whenever you sign a state update from a channel, the virtual channels are also virtual. Here, like virtual channels, we're from virtual utxos. And whenever you to update a channel state, you create a signature. The operator signs state update in favor of the recipient. There is a signature and the nonce, the signature, the public nonce is pretty selected from the pool and you only put the s value only inscribed. So to spend, you only put the data on bitcoin. The S value and that's also, it's also subject to like witness discount. Like 75% witness discount. So it's eight v bytes in size plus very compact data that represents the transaction, right? The summary, the transaction summary data, like who pays to by index, not the full keys, but like two byte indexes. It's an account model and we are indexing the keys. We like this unpub directory which is, gets dynamically changed according to a ranking system. So like we represent like who pays to like from to value, like according to a rank based ordering sequencing sequence system. And only the compact index number gets like ends up in the block, basically. [00:40:09] Speaker A: A reference rather than the actual database, so to speak. [00:40:14] Speaker B: Exactly. The reference, not the key. Plus the s value signature. S value, which is eight v byte in size, ends up in a block. Like it gets produced. Like operator puts the value in block in DA, but it's all atomic from sender to recipient. The data, you're making a payment from a channel to another, plus data. It's like a payment, plus the data in bitcoin versus lightning, no data at all. It's all off chain here. It's very minimal data. If you run the numbers, you get three digit tps. Like you have 150 ish tps with this construction, well actually even more like something like 200 for plain transfers. If you were to do a plain transfer from an account. And value especially, it's a common, it's a common recipient, a common value. Like if you, if you're sending to someone who you are frequently transacting with frequent value gets even higher. But like there is, we can also further reduce this. Like you can also further optimize the DA with a soft work. Like if we have cats and checks from stack for instance, we can aggregate these individual s commitments in one. And that gives us, in theory, like if you have cat and stack, instead of like putting individual s values, we can only can put their sum, the root factorless, remarkable route, only published a root on bitcoin and then, well, it gets us like four digit tps. Like it gets us like I run the numbers up to like 1600 gps, like 1000 gps in bitcoin yet catch exit from stack. Like assuming it can optimize di even further, like ten, like orders of magnitude, like ten x more. But like always room for optimizations. But the trick is like it's a state channel design, right? Like it's like lightning, but it's public, you know, you know who pays who in a publicly verifiable way. You can reconstruct the state by just reading the bytes. Of course, bitcoin only sees the bias and the secondary clients introvert debyes. And so that's the payments part. [00:42:57] Speaker A: I'm curious about something. I'm curious about something. This is a little bit of a tangent here, but since we've kind of brought it up a couple of times right now, is there are a number of covenant proposals. Like, there's a ton of them, actually. Now it seems like. And Czechsig from stack, is that also essentially a covenant proposal or is that more like, when you mention cat and Czechsig from stack, are those interchangeable or does the model actually need both of those to work as designed? [00:43:34] Speaker B: Yes. Checksick from stack is not a Conan code. Okay. [00:43:37] Speaker A: What is check six from stack then? [00:43:39] Speaker B: Many people claim that. So it would effectively check six. And you also have control over the. What message is being signed. Right. So in the checksake, you don't have control really, over what. What message is being signed. The message being signed is the transaction you're transacting. [00:43:54] Speaker A: Okay. [00:43:56] Speaker B: And such, the seconds numbers and like the transaction you're signing the transactions. [00:44:00] Speaker A: Is this attached to the signature? [00:44:02] Speaker B: Yeah. Transaction hash. Right. That your transaction is the message you're being signed. You don't really have control over that. Like a full control over inverses checks from stack. Well, you. It's like an arbitrary signature check operation, right. [00:44:18] Speaker A: You can sign anything in the, anything. [00:44:21] Speaker B: Like an old signature data. Yeah, yeah, yeah, yeah. Also, there is some trick to, like, combining check sick with checks from stack to like to get the, the sick hash three, image the sick hash data onto stack. But, well, it doesn't quite really work because you don't have control over the odd points, the input being signed. So it doesn't get as common, contrary to what many people claim checks it from. It's just an arbitrary signature checking operation on bitcoin. [00:44:48] Speaker A: Yeah. [00:44:49] Speaker B: You like, you can sign hello world and. Well, it's valid. Let's go. Here we go. Well, it's not a code. And opcode when combined with cats. Well, Czech from stack combined with cat gets us confidence. Well, cat alone in theory, also gets us comments. [00:45:10] Speaker A: Yeah. What is your feeling on cat? So the, everything that I thought, everything that I was exposed to, especially towards the beginning of this, it seems extremely unintuitive, like. And the difficulty is that, like, if I don't understand something, I am far less likely to just be like, sure, whatever. And I have slowly come more towards this direction just because Kat has the discussion about, like, how to put in clearer limits as to exactly how it can be used or what level of computation would be limited in how cat is used. But what's your thoughts on the various covenant proposals like Opvault, CTV cat, I guess TX hash I think is a covenant thing as well. Give me, give me your breakdown. What do you want out of it? Which one is the best one in your estimates estimation? And which one do you, would you say is the most secure or the one that you're least concerned about? I guess that still solves your problem. [00:46:26] Speaker B: I really don't know, man. You don't know politics and everything now. Like, I mean, I'm pro covenants. [00:46:37] Speaker A: Yeah. [00:46:38] Speaker B: I mean, I've covenant research and development for almost four years by now. Like script wizard and the all common and stuff, cutting edge stuff. I built Amm with cat and liquid and it's live in production today and built the script id. Like I've been doing common stuff for almost four years by now. In fact, prolapse is a result of like four years long con research in development. I think it's the best form of what a bitcoin roll up could be. But like, you know, politics. But like, yeah, aside from politics, like in terms of pure tech, like a technical aspect, like, I'm pro covenants. Yeah, I wish. I mean, we really had covenants in bitcoin today. I mean, for obvious reasons. I mean, brawl up works without covenants. Yeah, but common make it a lot, a lot better. [00:47:40] Speaker A: Yeah. [00:47:41] Speaker B: A lot more efficient. A lot more. It scales it further and makes implementation easier. I mean, I'm pro covenants, period. I do really wish. I wish we had CTV. Really? In bitcoin. Yeah, like, I really wish we had CTV in bitcoin today. I really wish. That's all I can do. Yeah, I can only fish. [00:48:08] Speaker A: CTV has seemed to me the simplest, like the most naive implementation in the sense that it's kind of easy to see its edges, what you can do with it. And it's also been around the longest, it seems like from everything I've seen. [00:48:28] Speaker B: In terms of technic technicality. Yeah. Like it checks all the boxes. It's been around for years. And unlike it's, I guess, most relatives, there's some bounties. And unlike it's been the most, the simplest form of a comment you could get and it's quite efficient and what it does. But none of these things matter, right. Like when it comes politics, you know, politics not, yeah, you know, explain these things. But like, I mean, of course it's good thing to like culture and bitcoin, we tend to be more on the, like, conservative, like, nanny side of things. Like, more on we are tend to, like, you know, when you push for software, get, like, naturally triggers the immune system. Bitcoin. And I like the preserve it, like, on a conservative size preserving bitcoin. And, like, sort of, like, not quite receptive to changes, protocol, stuff from bitcoin. That's. That's understandable. But, like, CTE, I mean, I really wish it. But, like, bitcoin is above all of us now. Like, it's. My opinion is not quite relevant. I mean, I really wish we had CTV and we might have it, like, I don't know, or something. Like CTV V two. Like TX might work as well. Introspection of codes, I think. It's not like, I mean, it's super simple. Like, we have them on liquid and up and running for years. [00:50:06] Speaker A: You're talking about things like cat. [00:50:09] Speaker B: Cat is simple too. Like, implemented. Like, it's simple, very simple. But, like, it's a bit of a gray area. Unknown unknowns. Known unknowns better. It could enable certain things that might harm bitcoin. Well, I'm not sure if it's true, but, like, you never know. It's bitcoin. [00:50:30] Speaker A: Yeah. [00:50:32] Speaker B: Like, cat is. I mean, I do like cat. Like, I mean, I wish we had cat again. Like cat. When it's combined with Chexy from stack, it gives brawl up ten x scale. But, like, it's in the end up to the community to decide. It's really hard. It's a rough consensus. If I had to pick one, software get the BCTV. Really? Just one CTV. If I had to. If I had. If it could pick three, that would be. If I had to pick two, that would be cats plus check seq from stack because you can emulate CTV that way. If I had to pick three, well, cat. CTV C from stack. [00:51:18] Speaker A: Or, I mean, does CTV and Cig from stack give any benefit together? [00:51:25] Speaker B: Sorry, what? I'm lost. [00:51:27] Speaker A: Does CTV plus cuxig from stack give any benefit to, like, how a burlap arc with scale. [00:51:36] Speaker B: We need cat plus, like, checks from stack. Really? [00:51:40] Speaker A: Gotcha. Okay. [00:51:42] Speaker B: Plus anything else. Don't work here in this construction. Well, I mean, to give brawl up a scale. [00:51:48] Speaker A: Yeah. [00:51:49] Speaker B: I mentioned earlier there needs cats plus Jackson stack in cat, you could emulate anything. Almost, like, almost again, like, I mean, there's. There's been some fud around catinous. Like. Like, let's. You know, let's be real. I mean, cat. Cat is not going to magically, like, somehow, like, um, triggers some, like, unknown unknowns and harm to bitcoin. Like, it's not going to weirdly somehow break bitcoin now. Like, come on. Like. [00:52:19] Speaker A: Like, you don't find it realistic to the concerns that are typically pushed? [00:52:24] Speaker B: Yeah, like, I mean, there's this whole concerns around. I mean, I understand his concerns. [00:52:31] Speaker A: How long has it been on liquid? [00:52:33] Speaker B: Oh, been. Oh, my God. Okay, well, been, like, I guess since 2015. Oh, wow. [00:52:38] Speaker A: So it's been there the whole time, basically. Yeah. [00:52:41] Speaker B: Like, yeah, yeah. I mean, cat, what it does is simple, but I'm not quite really buying into, like, it enables everything narrative. No, that's not true, because you know what? Because you need tweak ads to do recursive components. Actually, cat alone is not powerful enough. If you have cat alone, you cannot do anything. All you can do is introspection. You introspect stuff. Great. You can do some mercury verification and such. Great. You could do, like, one time show signatures, like, zero conf transactions on bitcoin. Great. But, like, you cannot do anything. Come on, let's settle on that. At least. Let's be real. Like, you cannot do anything. To do anything. You need tweak ads combined with cats. And by that, you can do full introspect. Like, you can do, like, fully recursive common. Because with taproot. Because we're adding taproot to, like, we're adding cat. Not to segwitzen. We're adding it to tabriz. [00:53:47] Speaker A: Okay. [00:53:47] Speaker B: Yeah. And we want outputs work with tweaking. Like, it's not. It's not enough to introspect the script pub key. You also need to be able to introspect its tab script effectively. Tab script all the way to root is tweaked at it with the inner key, and then you get the script pub key. With cat, all you do is introspect the output, the script pipe, and that's not enough. You also need to be able to untweak the inner key out to get all the way down to the script that the tab script, to be able to actually introspect and change, to basically. [00:54:37] Speaker A: Require information again, that was already previously required in a sense, so that it could carry with it across time state. [00:54:48] Speaker B: Yes. And change state being carried. You need opt we catch. Combined with cat and up to week ad is what makes things scary. [00:55:01] Speaker A: Mm hmm. [00:55:03] Speaker B: Cat alone, it's a fault. Right. It enables everything as a fuds and bitcoin transactions are self isolated. Right. What transaction is self isolated from another and doesn't affect the other? It's an opt in model, right? If you're using cat in your construction does not affect your trends like any other. It only affects the transaction being that uses the cat. It's like the cat. The cat. The transaction that contains cat in it. Because cat constrains only the transaction. It contains itself. Like it's that that contains the cat. Transactions are self isolated and cat alone is not. If in fact does not enable everything because all you do is introspection plus miracle proof verification. And in fact one time shop signatures is great too. Like for roll up. In fact, it could make things work. Zero call. I've been trying myself to do zero conf. Like um, constructions on bitcoin with one time she of signatures. But I couldn't find a way really to do it. Like bitcoin. Like no, you need really cats. Something like some bitwise stuff like. Or some data manipulation opcode of some sort or some checks. Deterministic nose. Like cat adds a lot of value. It adds immense like value to brawl. Like I can always speak to my project. It adds a lot value. I am not buying into the fud. It doesn't enable any like no, but it's irrelevant in the end, right? It's not my say, really. What merged the bitcoin. It's not my say. I'm sorry. It's irrelevant. I really try to stay away from politics as much as I can sometimes get involved a bit. But no, I like drama in general. I like drama. I wish we had more drama. I guess discussions were heating up lately in DT. Great. Let's go to print out some. Something anti opcat just to trigger drama, you know, I'm pro cat. Like let's be on the other side of like, like on the opposition side. Now for the drama. Like I'm thinking of the print has some anti op cat stuff, you know, like just to draw for drama for the sake of drama. I don't know. But like yeah, so covenants regardless. I think I'm optimistic. Like I'm optimistic in general. Like we'll get. We'll get comments, I think at some point, I guess. I don't know, at least I hope. But like I think eventually, right? [00:58:11] Speaker A: It seems likely. It seems likely there's enough. Like most of the argument is about what proposal, you know? Like most of the. The frustration about it is the lack of consensus on which to do rather than consensus on whether to do it. [00:58:30] Speaker B: I guess is really like you need a proposal. Like you need like soft fork. An opcode takes a champion not only in the form of the author, but also in the form of projects. You do really need a project to champion the coach. That could, that could be brawl up, could be any something else. Timeout tree. Brawl up is a form of timeout tree or oric. Like, could be anything really. Like some vault construction or whatever. Like you need one or more projects worthy enough, compelling enough for bitcoiners, people to consider, for them to run signal, run the consensus changes in their nodes. For them, it needs to be compelling enough and perhaps more. There is perhaps more to it. Compelling enough, perhaps isn't enough. But, like, again, in the end, like, I don't. It's not a paradox, right? If it's good enough, like if people really find value, it's rough consensus, right? If people. Enough people find value in something, well, then it's compelling enough for them to activate it. And otherwise, not, like, I don't know how to describe. Like, it's not self contradictory, you know? Like if there's value really, then they'll activate it for their own benefits. Otherwise it's like natural selection. It's like either one or zero, right? Like there's no middle ground. If it's beneficial, if people benefit, they'll activate. If not, no. [01:00:11] Speaker A: Yeah, yeah. [01:00:13] Speaker B: It's not a paradox. I guess we'll have some compelling enough use case, it's rough consensus, right? It's not like full consensus. So I guess people, at least not like blindly opposing comments, right? Like they are somehow open because things have changed. Things have been changing over the past two years. Like people been opposing covenants, I guess becoming more and more in favor of covenants lately. [01:00:44] Speaker A: I guess the controversy around it seems to have died a lot. Like there's a lot less people arbitrarily against it. It seems like maybe just the energy has been snapped out of it. [01:01:01] Speaker B: Low iq. Like, literally, it's low iq, guys. Like, no, please don't be. Of course. Like at some point, yes, but classification now is low. Psych. You know, I don't even have respect for these people. [01:01:20] Speaker A: Yeah, no, I have a couple questions about Ark and roll up in a slightly different context. So talking about transactions per second and how these things scale, am I correct in understanding that the scaling capacity is largely in the volume within these systems? In the sense that if we have an arc with 100 people in it and only one person does a transaction within ten minutes, let's say I'm the service provider, I will still update it with one transaction and it will be a one to Utxo. To one Utxo. Update on chain. And essentially there will be no scaling benefit. It will just be a normal on chain transaction. [01:02:17] Speaker B: Like a normal as if it were using an on chain bolt. [01:02:21] Speaker A: Gotcha. And then this is basically the same with Brola, correct? [01:02:25] Speaker B: Yeah, that's right. It's like art in that sense. I guess that, that, that goes for all shared Utxon based models. Yes. I guess suffer from this onboarding problem. [01:02:39] Speaker A: Yeah. [01:02:41] Speaker B: I guess operator ideally should subsidize maybe fees for users to use. Yeah, please go. [01:02:53] Speaker A: It would basically be like a tiny little futures contract for the Ark service provider is like what fee I pay to bring on this community. Like you would almost want a community already built out in order to deploy this to for the volume. Now in addition is there is no reason to send out a transaction to update if nobody does a transaction, right? [01:03:18] Speaker B: That's right. [01:03:19] Speaker A: So you're just waiting for transactions to come in before any activity occurs to. [01:03:24] Speaker B: Not like transacting in regular intervals. You're transacting as long as there is a transaction. [01:03:30] Speaker A: Gotcha. Gotcha. Okay. [01:03:34] Speaker B: Yeah. Like the same for roll up for, I guess, time at trees or for, I guess, JTX based models. [01:03:43] Speaker A: Okay, cool, cool. And is there any reason, is there anything specifically that limits this where the transaction that goes to the end user is actually a lightning channel and then people can still pay and use it as lightning and the liquidity changes happen as an arc shared UtxO or a roll up shared UtxO. [01:04:15] Speaker B: That's what Brolap works. [01:04:19] Speaker A: Oh, I guess that's right. Roll up is channels. So, so the, the updates only occur when you're changing balances. [01:04:25] Speaker B: Yeah, yeah, yeah, yeah. So to clarify, enough is one way only. Like unidirectional, like, like you have bitcoin, you spend a coin, you create new coin on an ongoing basis up until the time it's like, like an ongoing basis. And the more velocity the protocol like it gets, the more liquidity have to look out. And that's the problem. The concern people brought. Oh, yeah, great. And of course if you run it on 24 hours rounds, that's not an issue. We covered that earlier with versus roll up. Well, roll up. You can run roll up like on. You don't need to run a server, obviously. Roll up runs on like three month rounds. You have a check that expired in three months. And that means that's quite a reasonable amount of time. Right. For normies. And that means in every three months and like on a monthly basis, you need to refresh your coins back to yourself to retain the self custody. And the reason it works is because it's channel design. Right? It's not unidirectional, it's bi directional. So you earn these Utxos effectively. Don't get me wrong. We also have Utxos here, like VTX. Virtual utxls. Shared Utxo. But what we do is we turn these VTX into virtual channels. Right? I mean we like this term virtual. It's kind of bitcoin. Everything like the virtual bytes. Virtual trick. Txid. Virtually. [01:05:53] Speaker A: Yeah. [01:05:55] Speaker B: You know, we like this prefixing stuff. Prefixing. Like prefix. This. This specific prefix. [01:06:01] Speaker A: The naming convention. Yeah. [01:06:04] Speaker B: Yeah. So virtual channel. It's a virtual channel. It's a payment channel. Yet to be broadcasted, but can be broadcasted unilaterally in any time instead of back on chain. Great. So it's all here too. It's not like a bear channel. It's virtual. Still, too often it's a channel. Maybe we can come to channel specifics a bit because it's kind of Ellen symmetry. It's not like channel in the lightning sense. It's Helen symmetry. Symmetric norrification or nothing. Comes in a bit, but like. [01:06:33] Speaker A: So you and I as channel partners would hold the exact same state. Rather than enlightening where I hold a state that punishes you and you hold a state that punishes me to make sure that we agree on the current state. [01:06:48] Speaker B: We don't have punishment here. Yeah. Like el t o the project. [01:06:53] Speaker A: Yeah. Yeah, yeah. [01:06:54] Speaker B: Yeah. It's like l two. It's. It's surprisingly, it's Allen symmetry. Like, turns out we can be Allen symmetry in bitcoin. Like today. You don't need apo. I figured out how to do it. That's how broadband works. [01:07:10] Speaker A: Yeah. [01:07:10] Speaker B: It's ls. It's symmetric channel design. You've got. It's got the same state for both parties to self to remote, it's the same state. And you don't block the old states. You always overwrite them versus like. Well, it's really complex to design. Roll up channels are super easy to reason about. Like norvication. You don't revoke all. And also you overwrite the earlier one. Higher pressure with a higher precedence. [01:07:40] Speaker A: Yeah. [01:07:40] Speaker B: Using a degrading time lock scheme with tap trees. There's a bunch of like. [01:07:46] Speaker A: Basically just with a later sequence. So that I. It's always the. The latest one that will outdate the previous one. So as long as it just gets broadcast at some point. It will just replace it. Yeah. [01:07:58] Speaker B: Yeah. We'll replace what they higher one, the proud, the higher precedence one. It's kind of like, it's basically like a tap dream with like say 64 leaves. That means channel can get 64 state updates throughout its lifetime. And in each leaf you have a degrading time lock scheme. And when this channel gets broadcasted, then that's when this time lock starts. Triggered. Gets triggered because it's relative lock time, not absolute. And that means because it's a degrading scheme and you got two of two in each leaf plus a time lock. It means that you start from the first leaf, say, has like with an expiry of say 64 days and secondly, two of 263 days, third leave, two of 262 days and fourth leave, and 61 and so on. And that is the grading setup. And each and the more state updates you sign, the higher precedence the current channel state gets. That means in the unilateral closure case, with the forest closure case, the channel state gets ends up in the block is the one that has the highest precedence system. Factory mass plus degrading scheme. It's kind of a novel scheme, I guess, bitcoin, I guess I made it up myself. Like it's a symmetric design and notification. Also known middle stages. Like we don't have middle state, we don't have hdlcs or ptlcs, nothing. It's just too self and too remote. It's just me party who owns who really. That's it. The payments are connect. We're connecting payments through like connectors. So typically works is when you're to attempt a payment, you add a HDLC along the road, all the way to recipient and it settles back and then all the way back to your note and you revoke the HDLC with the pre image. Like HDLC is being removed with the pre image. It's quite a complex process overall versus here. Well, no, HDLCs payments are atomic. Like, you have a channel. It's a payment channel. In order to make a payment, well, you are simply making like the recipient does not need to be online, it's offline. That's another thing. You don't have to be online. And what recipient? So it's me, the service provider, who's also a partner and channel partner of everyone, every individual channels. And there's recipient. And if I'm to make a payment from my note, my channel into the recipients, then what happens is the operator, who also happens to be channel partner of the recipient, signs a state update in favor of the recipient and puts the s value on witness and adds a connector, virtual connector. It's a specific technical theorem. Connector outputs is like technical thing used in BitVM roll up thing ensures the atomicity of payments. So it's basically s value inscribed in bitcoin. Puts the data in bitcoin witness and adds a connector output back to my channel. And I sign off with the twelve two to ensure the atomic city magic sprinkle. But like effectively atomic, like it's immediate atomic. Lightning payments are also atomic, but here it's immediate atomicity. Delayed atomicity payments achieve immediate atomicity simply by signing off. So basically we have two types of payments, like pay to ask commitments and this is when the channel partner, the recipient, has enough liquidity. [01:12:11] Speaker A: Mm hmm. [01:12:13] Speaker B: And second pay to VTxo and that's when the channel partner has either no channel or no liquidity, enough liquidity in their channel. In that case I pay out of it, I pay out to a VTX instead. [01:12:26] Speaker A: Gotcha. [01:12:27] Speaker B: Yeah, kind of like, it's kind of like lightning with the arc fallback. Yeah, lightning payments by default. So it scales. Scales. Now like you're using the existing liquidity you have liquidity you have in your channels. So it scales in terms of liquidity versus, or it doesn't. Well if you're, unless you're not running on like 24 hours rounds here as well because it's a channel design also. I'm lost. [01:13:00] Speaker A: So all right, let me prime this with a question then. The 64 you were talking about needing to predetermine the nonces and you have this tap leaf tree with all of these preset transactions. So you need to update this once every 64 transactions with a new state for the whole thing and or when liquidity changes for the individual users. So like let's say I have a channel with a million sat worth of receive. If I'm receiving 1.2 million, the whole state needs to be updated, which means I get a new VTXO and we get an on chain update and all that good stuff. So that's kind of where the limit of the, how this scales comes in is. How often does that, that channel itself need to be refreshed in order to keep liquidity and payments still flowing? [01:13:59] Speaker B: Yeah, that's a good one. So basically like um, that's also like um, distinct design. Um, like uh, like um. It's a distinct design choice. Like this is a distinct design. I don't say like lightning, it's um, you have a channel and it has no expiring theory. Like of course that's you interactive model and check or state updates. But like in theory channel has no lifetime. [01:14:26] Speaker A: Mm hmm. [01:14:26] Speaker B: Right. It's there to be for us. Sit there. It's, it's meant to. [01:14:30] Speaker A: There's not a countdown like it just, it's just perpetual. Yeah. [01:14:34] Speaker B: Well, in theory. Lt has one, but like kind of infinity. [01:14:38] Speaker A: Yeah. Like yeah. [01:14:40] Speaker B: Large enough of a number. Like yeah. Lending has no account number versus we do here. So we have channels with lifetimes. It's an interesting concept to many and maybe surprising, but we have a channel with lifetimes and tools. Two lifetimes, one lifetime. In terms of the number of state updates the channel can accommodate. Right. The channel expires after it hits the 24. Like 64. Well, practice is going to be 128, but for simplicity. 64 state updates. When you hit the 64th state update in your channel, the channel is expired. Then what you need to do is refresh your channel into a brand new fresh VTX. Your fresher channel into a new VTX. Or recipient has no channels, simply like recipient has no liquidity channels. And then you pay attitude, excel, or back to yourself to refresh. Same thing. Or channel experts alternate. Like channel also expires when its lifetime hits, like 90 days. Like when you hit when you have a channel and it hits like channels live under a VTX. So like channel and channel sort of discount from a VTX and a channel. A Vtxo nests under a shared Utxo and when the shared expires, the Vtxo expire. And when the VTX expire, the channel expire. Therefore channel expires when the shared Utxo expires. And. And that means a channel expires either when it hits 90 days or 64 payments. It's 64 state updates. [01:16:32] Speaker A: Gotcha. [01:16:33] Speaker B: You refresh your channel into a fresh one, a virtual one, which has no footprint, really. It's virtual, it's automatic. And then you continue to refresh, swapping out your channel liquidity into a new channel. It's kind of an off chain to off chain swap out virtual channel into a new virtual channel. Gotcha. From your own to your own in a footprint way. But you have to do it in regular on a monthly basis. And that's where liveness interactivity comes in. Which lightning has something similar, the CLT, the Delta, I think. [01:17:23] Speaker A: Is there any reason why these also can't be bridged to lightning? Either a through the arc provider or the roll up provider, or even through someone else in the brollup or the ark? Like, let's say we both have the same service provider and you're online. Is there any way we is there any reason we can't do an atomic swap where I pay you in the roll up and then you pay the lightning invoice? And only if that payment goes through on the roll up does the lightning invoice valid and vice versa. [01:17:58] Speaker B: Oh, yeah. I mean, it has a new narrative, right? This glow of all layer twos right here, too. Okay. [01:18:06] Speaker A: I figured that was the case, but I wanted to confirm. [01:18:09] Speaker B: Better double confirm, right? I mean, yeah, sure. It's a lightning compatible. You can pay to a lightning wallet or get paid from lightning wallet. Just a bit of. I'm not sure if you're going to support this. In the very first version, it's going to be more fault three features. So for some sort of a feature protocol extension thing, because there's going to be defrost, like dynamic frost, and like, that dynamic frost like entity also needs to run a lightning node. And like I said, you would need ptlcs for that because htlcs, you need to create a pre match. Well, but how could. How on earth a defrost Federation can create a premedge? You would need ptlcs. And that means we would need to wait for. For that. [01:18:52] Speaker A: Okay. That's why that doesn't require a soft work, though, right? That's just a lightning. [01:18:56] Speaker B: No. [01:18:58] Speaker A: Yeah, that's tapper. [01:18:59] Speaker B: Yeah, we probably need to wait for ptlcs for that. Okay. Protocol, like extension thing. The interoperability. But it's interoperable with on chain bitcoin. With Utxo. Like, you kids, you could peg in, peg out on chain bitcoin. Trust us. [01:19:16] Speaker A: Sweet. Dude, you've been busy. [01:19:24] Speaker B: Time flies. Really? I have no idea how time flies, really? Time flies is interesting. [01:19:29] Speaker A: Which one. What are you most excited about? Which one do you think is the better solution and do you think meets the kind of needs of where you feel the community is going and wherever people are? The direction that a lot of these tools are building for the l two proposals. [01:19:52] Speaker B: Oh, well, I don't know really. Like, I can't really speak of the other projects because I'm not keeping that. That close on other projects. Really? Like I'm selfish. No, like, I just not interested, really. Like I can barely keep up with my own thing. Yeah, I jump from an idea to another. Tend to. But, like, I'm settled on this one one. Because I think it kind of checks the boxes and kind of has the, like, kind of appealing because also the smart contract part, we haven't covered that, but, like, basically it's payments plus smart contracts. You know, lots of layer two is emerging lately. I can speak to that scam, I guess. Like, no, they're not all scam, but like, I guess they seem to be scamming. Like these layer twos emerging. They're all multi seq, I guess. But like, but like, I don't know, really. I don't know. Like, I barely can keep up with my own thing. Yeah, I don't. Can say much to the other projects. Ark is great. I think Ark is compelling because again, like, if you run a server, it's great. And for privacy. Right. But I mean, I personally don't want to build a mixture myself. Like, I don't have the bold, not, I'm like, I wouldn't. That thing. I'm not as bold as Tiero now. [01:21:22] Speaker A: Like, do you know of a implementation? Like, is there a use, does somebody have a wallet running with Ark in a test scenario or like something to play around with? [01:21:35] Speaker B: Not really, no. I haven't been keeping up in bitcoin space either. Yeah, I actually had a bit of a break, actually. Like been been months and back to like, bitcoin, I guess two months ago. A lot have happened since then, but like, yeah, so they be, I think arcs have like, please zero point, like 0.2, which has the Covenant list version and bunch of other things bundled. It's cool. It works. It's magic, really. I mean, I'm really proud of Ark. And I mean, great. I mean, I mean, I mean, I'm glad people are building on it. Like building it. I mean, building. It's not on its. [01:22:16] Speaker A: Well, yeah, yeah. [01:22:18] Speaker B: What's also interesting about Arc is it's modular in that. Like, it's not a state channel design. Like, it can't build like all sorts of use cases. Not all like, you can do on bitcoin, like escrow payments and whatnot. But like versus lightning, it's just payments rotting. Well, well, versus roll up. Well, I mean with the smart contract stuff, like, you know, roll up, it's, it's a payment roll up. Well, also got the smart contracts. But, but effectively you can run a virtual machine on top of. On top. So best way to think of roll up is like this payment layer. It's a payment layer. It's a layer too. It's an off chain protocol with unilateral and it's all public and pros and cons today, but on top of the payment layer, we can build. It's more of a layered approach. You can build another layer, the smart contracts layer. And this, the smart contracts in this context, are not like smart contracts that you, that you know and think like, they're not like as, like, I mean, they're not like, like fully capable, functional smart contracts. You think and know and like. No, I mean, I'm pretty sure bitcoiner is not quite feeling smart, but like not average defi user does like. So my contracts in this context are more like, they don't hold the custody of bitcoin, but rather they are facilitators of p two p. Like they're can execute off chain logics. Like conditions execute smart contracts and any arbitrary condition based on payments. [01:24:11] Speaker A: Gotcha. [01:24:12] Speaker B: P payments. [01:24:13] Speaker A: Like, so essentially, essentially, whatever the output of the software is will be kind of like a multisig. It's the determining factor in whether or not the exchange happens. [01:24:26] Speaker B: Right. So effectively, yeah, like smart contract checks better if the payment made or not. And what from what. And check suits and like executes the smart. The condition, whatever arbitrary condition that is according to the payment condition. [01:24:45] Speaker A: Gotcha. [01:24:47] Speaker B: Well, it turns out it's a powerful of a primitive. It's quite powerful primitive that it could give you like 90 over percent of defi use cases. Like, better. It's stable coins. Of course you can do stable coins. Like, I mean, I've been to El Salvador. No one gives a shit about bitcoin. Let's get real. They all want stables. They all care about stables. Some don't even accept bitcoin stables. Still, bitcoin. I think hyper bitcoinization is years, decades away from reality. I think we'll get there, but not now. Stables are great. I mean, at least what I see. I'm a bit of opportunist myself. Of course, I believe in hyper bitcoinization. It's going to happen sometime, but not quite now. [01:25:28] Speaker A: I mean, product management, I think we greatly overestimate what can happen in like three years, but I also think we underestimate what can happen in ten. And I have early 2030 to 2034 as like, things are moving fast. And I think the normalization of it is like, I'm not looking 20 years out in my opinion, but, okay, that's a different discussion. [01:26:03] Speaker B: But if a shorter time frame. Yeah, I guess it's. Yeah, yeah. Things don't go linear. Right. Perhaps an accelerated pace, but. Yeah, sure, but I mean, yeah, great. I mean, roll up is a payment. Payments roll up, it scales bitcoin potentially to four digit tps. But for the momentary digit TPS, it's great. Compelling enough, I guess you could run b two b on and to pee on roll up. Great. Run the entire planet. Hopefully. Hopefully. Because there could be other, certain other concerns around bandwidth and such. But in theory at least, like from pure on chain footprint point, that's the entry barrier, right? Like the upper bound, right? Or the lower bound. Yeah, lower bound. Like the block space at least standpoint, it scales, could scale in theory, the four digit TPS optimizations. It's great. I mean, it's ready. We'll be ready hopefully by then. Let's, let's hope roll up will be ready by then. Hopefully. Like when hyper bitcoin is. Well, I mean, depends. I. But like for, in the meantime, yeah, let's, let's do staples and that's what people demand, apparently. Or you can trade like stables for bitcoin, could do like amms and order books. The bitcoin on brawl up, you could do like inscriptions, nfts. So like what you can do in brawl up, you can trade NFts. Not necessarily because I'm endorsing nfts, but because like the thing is like it's a scaling tech, like prolapse scales. Not only bitcoin, but it also scales the degenerate use cases such as NFT trading or transfers trading could build NFT marketplaces and roll up. Like say you have an NFT piece, you could bridge your ordinal into here with a one bait, one BH, one way bridge. And you can trade it against bitcoin. Like, trust us, you can have like more bitcoin, like spot auctions, basically, atomic. [01:28:17] Speaker A: Swap auctions that are, have a third, have a third party or whatever that isn't even involved. They can't confiscate the exchange process. [01:28:27] Speaker B: Atomic exchanges between assets in a much, much scalable way than PS because you do atomic swaps of PSBTs that x like 300 v. I think we've seen that the climate, right, and meme clogging up the network a lot. Versus umbrella. If you do an umbrella, it reduces down to three v bytes. From 300 to three v bytes. [01:28:56] Speaker A: Yeah. [01:28:58] Speaker B: Like assets. Like it scales trading degeneracy by hundred x. So that, that's, I think scales trading. [01:29:07] Speaker A: Degeneracy by hundred x. That's the, that's the tagline of this episode. [01:29:14] Speaker B: I think that's good for bitcoin. Yeah, that's bitcoin's benefit. [01:29:19] Speaker A: That's always to me, like, aside from the explicit, which I don't think it's, I don't think it scales economically from this idea, but there's been so much push to make it as inefficient as possible on bitcoin. Like almost like a, hahaha. Look what I can do. Look how much I can put in your park, you know, and so, but the thing is, is that it doesn't, I don't think it survives like that because you're explicitly, you're explicitly incurring a cost for something that has not been able to maintain value. Like you've seen kind of these cycles of the, oh, the degeneracy comes back or the having happens and everybody wants to get their nft in the halving block, but then it like tapers off so fast, like so fast and nobody wants to pay $2,000 transaction fees to put, you know, a photocopy of their ass on the blockchain. And so whatever market does actually exist, I think the solution is to give them the most efficient place to go. Be retarded in my opinion. But whatever, like go do your thing, I don't really care, but on a roll up, it doesn't bother me. It doesn't, it's not, it's not in, it doesn't pollute the chain itself. It uses the chain for the validation and the ownership that they want. So cool. Just build a more efficient thing and the other one will just economically commit suicide. So just give it time. [01:30:53] Speaker B: Yeah, it's quite efficient. Like three digit tps. Like, like for like non bitcoin transaction types, like trading tokens for tokens or I don't know, some yield farming, whatever. Like these type of transaction types, it scales up to like 600 gps. As, as it is, like the protocol by default. Like, it scales very well. Like the transactions per second. It does it really well. I mean surprisingly. And on bitcoin and, and it's just so surprising. And like, and in like payments plus smart contracts, all verifiable public. Scalable. Scalable. Like it's more scalable with covenants, of course, because it's a state channel design. Hands. Like, the way it works is like, yeah, we have a shared Utxo which is trustless because it's owned by n of n music. And you're part of it. That's why it's trustless. But like, when you're offline and you don't have enough liquidity in your channel, that's when you receive a channel in terms of bear Utxo. [01:32:25] Speaker A: Mm hmm. [01:32:26] Speaker B: We call it the bay lift output. Lift output in prolife terms. But like if you throw two ifs, if you're not also online and you have not enough liquidity then you receive a channel like you receive a Vtxo and the Bayer form Utxo. [01:32:47] Speaker A: And that's basically the one that you need to get an update from. You need to have a copy of. [01:32:51] Speaker B: That's what covenants solve that. Like that little bit friction, the fallback, you know, it falls back to a Bayer Utxo and it's not enough liquidity. The fallback for that little bit fallback option to scale that even further, we need a common gotcha state channel design. It's a state update. Great. And channels live under shared Utic, so especially when you'll refresh them. When you refresh channels, you refresh them into a fresh one under a new ETX. So shared Utxo and that's how you're rebalancing. Sort of like rebalancing channels, the liquidity, because shared Utxo model fixes two things. First, the footprint. Second, rebalancing, rebalancing the liquidity. Here we're not with the shared etxML model, the covenantless prolapse version, the version that exists, the idea, it does not solve the footprint problem. Right? Because we don't have covenants. And you start all with bear channels, you have better channels which only when you refresh them gets into. When you refresh the channel then only it becomes part of the shade. Utxo, then it's trustless because you can bound a covenant by n of n, a trustless covenant. And that strategy. So model not necessarily for scaling again, but for rebalancing because the main problem lightning has is to rebalance the channel like in terms of on chain rebalancing. I'm talking about lightning like on chain. [01:34:43] Speaker A: Rebalancing to splice in or splice out. Yeah. [01:34:49] Speaker B: In terms of rebalancing, the actual liquidity, splicing in and out, you need an on chain transaction which is not quite efficient. You have a channel, you splice it out, the neve channels, the remaining channel states effectively with that splice out you need to form another channel, ideally one and one in and one out. So like it is, how many v bytes there five times, say 4200 v bytes versus here versus three or whatever versus here. It's just an output. Just a single output. [01:35:31] Speaker A: Okay. [01:35:32] Speaker B: And lift output also. You also need to claim it. Like when you're, when you, we have a specific term, lift up, you are lifting a bare output into a virtual. Lifting it up. [01:35:47] Speaker A: Yeah. [01:35:47] Speaker B: So when you receive a bare utxo called lift lift output and you're lifting it up to a virtual gotcha online. You can lift it up with the covenants you're involving in. And the entire process is just one out, one in sort of like 99 re bytes. No, other fields, like all other fields are shared, like n version, such, like the log time that I'll share it. It's only like 99 v bytes to effectively splice out and in. [01:36:33] Speaker A: Yeah. [01:36:34] Speaker B: Versus lightning, it's probably more than 200 b bytes. So like. And that's the fallback. That's the fallback. Right. You are doing in the fallback case versus like, default case is a channel state update. To scale that even further. You need a counter. [01:36:54] Speaker A: Yeah. [01:36:55] Speaker B: To remove that tiny little bit. That tiny little bit. Friction in the count. And like CTV, that I favor. [01:37:06] Speaker A: What's the state of roll up? Like, what's the, like, where's development on this? How long you been working on this? [01:37:13] Speaker B: Yeah, I'm single. I'm building myself. And I am, I've been doing it for. I think I made it public about two months ago. [01:37:22] Speaker A: Okay. Yeah. [01:37:23] Speaker B: Building it for about a month and a half. So I'm building a library at the moment. Like the output types, the entry types and the tap tree. I built the taproot library myself. [01:37:43] Speaker A: Mm hmm. [01:37:44] Speaker B: Like the library myself. Then realized there is already one in BDK. I'm also learning that's along the way. [01:37:51] Speaker A: Yeah. [01:37:53] Speaker B: But like. But then I've moved into the, from library into the defrost parts R and D. I'm trying to on, my goal for the next few weeks, say, is to build defrost implementation in rust for the dynamic federation quorum thing for the operator. Because we need to be able to represent the operator single key at all times and hard code the set of prefix analysis in the pool, the software. Because if. If the well known key, that operator key is to change in Paris, then the public nonsense must also change that. The pool, the heart. The pool hard coded the. And we're doing this again. Bytes and signature by half. The cut. Bytes by cut, cutting that by half. We need to hard code a set of precise analysis. And the defrosting also goes into this nonsense. And to keep them hard coded at all times and. And not update them. Not, it's not. The problem is not to update the key. The problem is to update these nons. The set of nonsense. Yeah, you don't want to update them. We want to like, keep them as it is. And like, they're immutable, they're hard coded, fixed. [01:39:25] Speaker A: Yeah. And so basically you know where you are in the sequence and like it's, it's always, it's always a static reference. [01:39:33] Speaker B: Yeah right. Software, software knows who owns what and what channel. Like it's all public, it's a global state. Maybe you have three channels, I have like six channels virtual channels. And really it's known by everyone. You're like who's channel distant? What, whose channels? Like what is like, like what your channel destinations are, what sales your channels you live in and what's your channel state is the state number is how much you own like in your channel and your operator owns in particular channel. And that's how it works. The global state works, right. That's how VM can validate payments because the VM, the virtual machine needs to be able to verify payments, right? If I'm to send you stats from my channel to yours, it needs to be known by everyone what everyone's channel destinations are and values and numbers are, but it's all publicly known and the VM can then validate it and execute, say conditions accordingly. Let's give an example. I list an NFT for sale on the brawl up. It could be bridge ordinal or it could be its own thing. And you have sets. I don't have sets, I just have this asset I listed on a brawl up marketplace on an NFT marketplace in brawl up, the smart contract. And I listed for say one bitcoin and you come in, come along and make a transaction call calling the contract the buy, the my buy method with the payments, right? It's a payable construct, it's a payable condition. And the contract check. You're paying one bitcoin to me, right? If I have enough liquidity, one bitcoin, it's going to be of type pay to VtxO gonna be, you're gonna pay a VtxO in the form of Bay Area in a Bayer form because I'm offline the payer form and it's a lift output I mentioned earlier. But enough liquidity, it's gonna be in the form of a state update, which is a lot more compact inside because you're literally not creating a rich Utxo and UtxO set, right? [01:42:03] Speaker A: It's just, you're just moving inside the tap tree, right? [01:42:08] Speaker B: So you're so, so basically whether it's pay to Vtxo or pay to s.com s commitment, the contract that verifies the payment and then considers everyone then like, and credits the NFT assets to you now credited with the NFT, like it gives you the ownership it moves the ownership because the ownership of a non bitcoin asset, it's a client side thing really is evaluated within a client side context, right, versus bitcoin. Of course, bitcoin can also be evaluated because it's all verifiable publicly. You know, VM can, VM knows all channels and their locations, the values and states, everyone knows it. But bitcoin is also enforceable on chain because you can do unilateral exits. So your coins are enforceable off chain and verifiable off chain. Smart contracts, on the other hand, they are verifiable off chain too, right? And if you combine the two, like payments and smart contracts, basically data, so you're deriving the payment info from the data. Very compact, you're calling the contract. Of course, contract is also byte data deployed back in the history. And VM executes the contract according to the payment if it's made, whether it's paid to VTxO or pay to escom, it executes the contract and credits and moves the ownership by asset. Now you're the owner and then everyone can, like you can see it on the block explorer and everyone can validate it. And I'm the owner. I'm the owner of bitcoin now in the form of virtual coin. It's virtual and you're the owner of the asset now. [01:44:17] Speaker A: But of course, the major use case here is, I mean, obviously there's all the, like, if we wanted to move DeFi on to bitcoin in some sort of a scalable way, like that's clearly something at least that has some sort of a market now in the degeneracy of just like token exchange as a market. But what's interesting about this, especially from the context of a smart contract, is that there's no need for this to be like, these are arbitrary electronic services essentially. So because this is totally arbitrary for what code is run genuinely, any kind of market can be run on top of this. Like, rather than buying an NFT, like, I don't, I love your example, but using me, I will offer you ten. No, I don't want the NFT. I don't want the NFT. I'm not gonna pay a bitcoin for the NFT. But the funny thing is, is that this could literally be digital, like genuine art. Like this could be a print for something, this could be download for a movie or a file, access to a key for a file somewhere. It is genuinely arbitrary about what is unlocking this smart contract if you just have visibility into the code that's unlocking it. This could allow a marketplace, kind of like a bisque type of marketplace to emerge from this that can essentially set, buy and sell anything that has some sort of digital piece of information as its ownership, which from the context of a digital environment a license key and, or a decryption key is like a perfect thing to just attach to this. I mean good lord, the number of times I've gotten, all I can think is like for a subscription or for getting access to software or something. This could be like a huge tool because your license key could literally be in the actual payment. It could be the thing that unlocks the payment. So all I ever have to do is go back to the payment in order to get the license key for my software to, to unlock that or whatever it is. Like Davinci resolve. Um, you have to unlock and I've installed it on my Linux machine and my Mac and like a couple other things. And uh, I have the license key but I lose it. It takes me like when I'm putting it on a new machine or like I'm swapping machines, it takes me like 30 minutes to find the license key. Sometimes they're like God bless, where the hell is it? And it would be cool to actually have it in the marketplace where I was purchasing all of those things, you know, to like actually have it built into the smart contract where my, my literal receipt number is the, is the thing that unlocks the software or the, the soft, the, the data. [01:47:12] Speaker B: Yeah, that's right. I guess it's up to our imaginations. That's the limits. [01:47:15] Speaker A: Yeah. [01:47:17] Speaker B: Could be that degenerate or non degenerate. I think. I guess number one is going to be ordered book, right? Tether bitcoin order book, right? [01:47:27] Speaker A: Yeah. [01:47:27] Speaker B: Who's going to trade bitcoin for dollars? It's going to be the major number one use case here. [01:47:34] Speaker A: A world with stable coins is going to be really interesting. It's, you know, especially on bitcoin. And when we have markets like this, the like being able to do quote unquote defi a peer to peer stable coin to bitcoin marketplace and have a genuine market price that does not have some restriction about border or jurisdiction or some explicit regulatory limit around how it can behave because it can bridge in any jurisdiction its jurisdiction or agnostic. And the interesting thing about that, because it's funny because I've been talking about this in the last couple of episodes and I read Mark Goodwin's and Whitney Webb's piece on I'm not sure if you've heard about this, about the, the problem with stable coins in the ability to actually expand to basically go from the petrodollar to the bitcoin dollar system, wherever they can tie that value in the dollar to bitcoin's rise, such that they can actually bolster the dollar alongside the success of bitcoin. But what's interesting is that this also, at the exact same time, if stable coins become more prevalent and more directly useful, like I can take a stable coin to Walmart, or I can pay my contractor in stablecoins, or I can deposit stable coins into my bank, well then that also creates, it also creates a massive undermining of capital controls and the ability to actually control pricing in the dollar market. Which means that something like this in a kind of defi setting could provide a massive amount of liquidity that is directly external to direct banking infrastructure or to a permissioned ach bank of international settlements sort of thing. You could basically build your own marketplace, like you said, is anybody who could run a server, I could run a marketplace between bitcoin and tether or whatever dollar stablecoin and actually be a meaningful amount of liquidity and volume in the global price of bitcoin versus the dollar. And I can service customers in India, in China, in Hong Kong, like it is open, like the web, you know, if you can get a connection, you can be a part of that marketplace. And it's weird. It's weird because there is this, stable coins bolster the dollar, but then they also undermine the control over the dollar market at the exact same time. And something like this, it means that we can provide service provision. We can build these markets without banks. [01:50:32] Speaker B: Not only build, but also could be our own liquidity provider. Build. [01:50:35] Speaker A: Exactly, exactly. [01:50:37] Speaker B: Your own pair maybe like your own coins, table coin version, a partially back or fully back, whatever, that you could also, you could always, you know, provide liquidity and liquidity could always be there. [01:50:47] Speaker A: Mm hmm. [01:50:48] Speaker B: And you could, you could effectively pick in and out and you could, could basically build contracts that could accept only maybe whatever arbitrary condition, only your own stablecoin type. You could scale that up to, I guess, to any use case I want. Also this goes a lot more into, I guess, level of trust and web five stuff. Because if you can think of probab as really the subset of web five, really there's no strength. There's brawl up too, because if you're using the npubs here, well then you leave a footprint behind every transaction you make for whatever reason. Like any, for any arbitrary condition like contract or executing where it's plane transfer, contract call, you leave a footprint behind and that's part of the identity that defines you, who you are really. I guess it's up to debate whether it's a good thing or bad. But I mean that's how Nostra works. That's all publicity by default. But here's the same as publicity, it's all public. And the footprint you leave behind on brawl up, it defines who you are and like your identity defines who you are. Again, like just like nostril deposits, the interactions you make on nostril pulse you like and you post shit pulse, like transactions you make and roll up collectively defines who you are based on the data footprint. The footprint here is quite like immutable, it defines who you are. And perhaps it could build some credits and like you could do blending borrowing based on reputation model and such, on brawl up. Hopefully like ie you define, can give people credit scores based on their footprint and you can basically land borrow money and like you can borrow money people based on your credit score. And like it's enforced by the, the social circle, like it's not enforced by a law or gun, like it's not enforced by a law, but it's by, but by social pressure. [01:53:10] Speaker A: Basically the value of your reputation is that, is that you kill your ability to do business with anyone else if you, if you revoke a contract. So they're, they're saying that your, your ability to do businesses in the future is based on your I capacity to pay back what you owe right now. And you can actually attach those together. [01:53:36] Speaker B: Which is it costs you a reputation to violate a social contract. Roll up is not only meant for smart contracts, it's also for social contracts of any kind you can build. And it costs you maybe not collateral, this is not collateralized, but your reputation and invalidate a contract social contract, which is really hard to build and expensive. So reputation, it's so hard to, it's hard to obtain, but too easy to destroy. [01:54:09] Speaker A: Yeah. [01:54:09] Speaker B: And it's at sake and this type of constructions and I guess works well. So. And that's unlike we've seen in the Ethereum web three space like web is because we call it web five for a reason. Right. And there is a lot, there is a lot more. There's a lot more to it, right? [01:54:27] Speaker A: Yeah. [01:54:27] Speaker B: It's not only degeneracy, there is a lot more to it. Hopefully we'll see. Well, the use case is emerging and roll up. Of course we have to first ship roll up. [01:54:40] Speaker A: Yeah. [01:54:41] Speaker B: The hard thing, it's a pain in the ass really, shipping things. [01:54:46] Speaker A: That's the hard part. That's the hard part. [01:54:50] Speaker B: We tend to, you know, build fast. Not, not build fast, break fast, but to build slow and steady, you know. [01:54:57] Speaker A: Yeah. [01:54:59] Speaker B: To get things right. And because we see it's a single shot thing, I guess. But, like, well, we can go ahead. [01:55:05] Speaker A: And just implement CTV and get that soft work in next week and then things will move right along. We'll just. [01:55:12] Speaker B: We'll just push that through. Yeah, yeah. Again, like, yeah, yeah, yeah, yeah. I think Brollock could be a good champion for CTOe. I think. I think it's a compelling, an effort for you skill, really. I believe to activate CTU because brawl off. It's first of its kind, really timeout for implementation. If you think about it. I don't think there is any other timeout tree implementation out there. Well, Ark is categorically a timeout tree, but, like, timeout tree in a sense that lightning plus expired outputs. Right. So it's effectively a time lot three. And I guess that's way to scale bitcoin well, or like scale bitcoin for p two p and to scale for b two b or p to b. Arc is the way. Right. Because you can the moment, as long as you can opt into a reactive model by running a server, you get the benefit, the privacy benefits and scalability too. Because arc in 24 hours rounds could be more efficient than timeout trees. Because timeout trees, it's still a lightning design. Although it gets spliced out and rebalanced or whatever in certain periods, it's still. Liquidity is still there for a moment for some time. Unutilized. Know what I mean? Some liquidity there sits there for a certain period. But versus arc, well, it's just day. Like, it really depends. [01:56:55] Speaker A: Rolls over really quick. [01:56:56] Speaker B: Yeah, rolls are quick and, like. And arc, I guess, adds a lot of value in there for b two. B. P to b. Privacy. Dark. But like. Like. Yeah. Something like roll up or time a tree. Some. Some time tree. [01:57:19] Speaker A: Uh oh. Do two chains on the device. It. [02:04:10] Speaker B: It. [02:05:26] Speaker A: It. [02:06:25] Speaker B: All right, I think I'm back. So we are closing out real quick, right? Because I have, like 5% battery. [02:06:32] Speaker A: Yeah, no worries. No, let's just go ahead and get right into it and we can go ahead and just close it up. So sorry we got disconnected there, but we were kind of hitting the point where we were talking about where this is going to be going and the coming year and where your development is headed and the work that you're doing and what we can apply this thing to. So how about we just, because we're dead on battery here, let's give some closing thoughts and kind of what you're hopeful for, for where this is going and then also tell people where they can find you and explore ark and that sort of stuff. [02:07:16] Speaker B: Right. So yeah, you can reach me out on Twitter and Brock because it's quite a unique name by itself. Like, I'm this like bug eating burger, burger eating bug profile on Twitter so you can find it me, you can feel free to reach out me in the end. If you have any questions and if you're interested in learning more about brawl up, you can go visit brawlup.org dot. If you're interested, you can learn some protocol stuff there and you could reach out me personally, we also have a community telegram group roll up community. Yeah. Feel free to join and ask questions, any questions that you might have. Happy to help. It's exciting times overall. I mean, exciting times to be in bitcoin as always. Exciting times. A lot's happening bitcoin. So I guess it's becoming really hard to keep out with things in bitcoin. Day after day, week after week and months after months. A lot's happening in exciting times and common discussions. We're hitting up too, overall optimistic. I mean, you know, I think brawl up is a worthy of an idea to implement and work on. I guess it's worth building something worth building and contributing to, I think. Yeah, I guess, you know, it's overall, I think it's overall good for bitcoin. I think it scales bitcoin in many way. In many ways and brings use cases to bitcoin. It works as it is. No protocol changes needed. So it's exciting. I'm excited about it and I'm optimistic it's going to, I'm gonna. It's just all it takes is to ship, I guess. Yeah. Arc lab is doing great job shipping ark and I'm working on roll up, which is another thing, an overall demistic about it, but like it's going to be a long journey for sure. [02:09:26] Speaker A: Yeah. [02:09:26] Speaker B: Again, it's worthy. Worthy of an idea. [02:09:29] Speaker A: Yeah, absolutely. It's kind of crazy because we're getting so many layer two ideas and even state chains are kind of becoming like I'm starting to see those roll out in actual implementations as well. We've got arc, we've got roll up now. We've got lightning, obviously. Then there's a couple of other iterations of improvements to lightning. Then there's this hedgehog idea that is kind of taking a big part of what you did with Ark and how you created the VT. VtXo idea. So there's literally. And then. And then you put on top of that fediment and e cash and all of these other, like, kind of like, pseudo, like, multisig things. It's just. It's exploding wide. Like it's going horizontal very, very quickly, and it's going to be very, very exciting to watch what kind of rises from that as like. Like major use case tools. And I think one of the things that Brolup and even Ark really have going for them is the degree of software and just kind of like, programmability agnostic to program that can be built, like smart contracting systems and stuff that can be built on top of it. And that's. That's really exciting because I think that's something that's been wholly untouched. It's very. It's extremely nascent when it comes to using that for bitcoin because the only use case so far has essentially been trading shitcoins. And so that's been off of bitcoin. So I'm really interested to see what comes of it outside of the explicit shitcoin market. You know, like, what else can we apply this to? So it's super exciting. Dude, thank you. Thank you so much for coming on and breaking down the details with me. Yeah, man. Yeah, man. Great to have you on. And maybe. Maybe in another year we'll roll back around and get an update on where roll up is, and we'll get to see a year of Ark as implemented as something that can actually be used. That's also something to just point out for everybody. You can use Ark. You can explore. Explore. Now you can go look at that code and you can deploy it. And if you're trying to build a wallet or something, that's something to absolutely consider, to look into because. [02:11:50] Speaker B: Right. [02:11:51] Speaker A: We haven't seen this in action yet, and it's really exciting. [02:11:54] Speaker B: Yeah. So any ideation phase and you love to build. I'll be more than happy to join again here, like, this show. Maybe in a year or two. You know. You never know. [02:12:02] Speaker A: You never know. You never know. Mandy, dude, thank you for what you build. Thank you for joining me. And I'll catch you on the next one later, boss. [02:12:12] Speaker B: Take care. All right. [02:12:16] Speaker A: All right. [02:12:17] Speaker B: I guess I really had to leave. [02:12:20] Speaker A: Yeah, no worries. [02:12:21] Speaker B: He's about to die. Thank you, man. Again, really appreciated it. [02:12:25] Speaker A: Yeah, man. Hell, yeah, it looks like we're uploaded. I think we're good to go. [02:12:30] Speaker B: Yeah, yeah, yeah. Keep in touch on monster then. Also Twitter might as well work. [02:12:35] Speaker A: For sure, for sure, man. Hit me up if you need anything. [02:12:38] Speaker B: More active on Twitter, though. But anyway, yeah, man, I wish you a great rest of day. [02:12:46] Speaker A: Yeah, same too. Same to you, man. Stay busy. All right, catch you later, dude.