Read_843 - Soft Fork, Covenant Review - Part 1

[00:00:00] Speaker A: A layer two is a bitcoin denominated system with the purpose of allowing bitcoin to be transacted more often than the number of on chain transactions would allow. [00:00:10] Speaker B: Such that either no one is able. [00:00:12] Speaker A: To profitably steal funds in the system and that the true owners of the funds are able to unilaterally withdraw them. With this definition, things like lightning are considered layer two systems. However, systems such as liquid cashew and fediment are not genuine l two SDE because another party or parties has control of the funds. Lightning is the current best in class layer two system out there. However, it does have limitations in evaluating layer two systems. Our goal will be to improve on these key limitations, ideally without adding new ones. The best in bitcoin made audible I am guy Swan, and this is bitcoin audible. What is up, guys? [00:01:18] Speaker B: Welcome back to bitcoin audible. [00:01:20] Speaker A: I am guy Swan, the guy who. [00:01:22] Speaker B: Has read more about bitcoin than anybody else you know. And we got a little bit of proof of work. [00:01:26] Speaker A: Today we are going to be reading. [00:01:29] Speaker B: Peter Todd's fantastic new layer two review, the softwark and Covenant dependent proposals for advancing for kind of taking layer two to the next level, extending out lightning to the logically obvious next step in scaling where there's no longer one utxo per user. But we have shared groups. [00:01:54] Speaker A: One utxo is a network of users. [00:01:57] Speaker B: A shout out to coinkite and the. [00:01:59] Speaker A: Cold card hardware wallet for supporting this show. [00:02:02] Speaker B: Don't forget that you can get a discount, discount code, bitcoin audible, and the details and everything is right in the show notes. [00:02:08] Speaker A: Please hold your own coins. Please. Please withdraw from the exchanges. [00:02:12] Speaker B: Wherever you buy your coins, just withdraw, get it on your cold card, and. [00:02:16] Speaker A: You can sleep soundly at night. All right? And in today's commentary after this, we're breaking this up into two parts. And in the commentary after this gets. [00:02:25] Speaker B: Pretty deep and it gets kind of technical, and I want you to listen through it. And then the commentary afterward is just. [00:02:32] Speaker A: Kind of to refresh all of the. [00:02:34] Speaker B: Ideas and kind of paint broader, simpler pictures with hopefully less jargon. Because I know a lot of this. [00:02:41] Speaker A: Stuff can get confusing, but these are. [00:02:43] Speaker B: Really, really important ideas and also kind of understanding the goals and the big picture of what each of these, what each piece of this actually does so that we can understand what we want and what we don't want and kind. [00:02:59] Speaker A: Of the risks of all of this. [00:03:00] Speaker B: Stuff, as well as obviously the, the awesome benefits. But the trade offs, you know, every. [00:03:07] Speaker A: Every piece of this puzzle has trade offs. There is no course of action that doesn't have trade offs offs. [00:03:12] Speaker B: Ossifying now and never getting any soft work or covenant upgrades is a trade off. [00:03:17] Speaker A: It's a risk. Going to any covenant proposal is a risk. [00:03:21] Speaker B: It has trade offs. [00:03:23] Speaker A: The entire bitcoin system itself is kind. [00:03:25] Speaker B: Of just a big giant economic trade off system. So understanding those, understanding the nuances and how each of these things work is important. So I do my best to re explain it so that hopefully it's a little bit more, a little bit simpler for those who aren't just kind of like deep in the weeds on Utxos and lightning channels and punishment clauses and happy states and all that good stuff. But I think the best way, and. [00:03:51] Speaker A: Basically the way that I've learned, is. [00:03:52] Speaker B: To constantly read past my level of understanding and I pick up just a little bit every single time with every single new piece and then try to. [00:04:03] Speaker A: Go back and explain it to myself. [00:04:05] Speaker B: So I think it would be really. [00:04:06] Speaker A: Valuable, even if this seems to be over your head, to listen to it. Then hopefully listen to my explanation and. [00:04:12] Speaker B: Maybe a lot, a couple of those pieces fit together, and then listen to part two as well as my commentary afterward. And hopefully, hopefully you'll be able to get a lot of useful information out of it. And honestly, this is one that a lot of people probably just won't get around to reading because it is kind of long. So that's why. [00:04:31] Speaker A: That's why we do the audible version. [00:04:33] Speaker B: Here on bitcoin audible. [00:04:35] Speaker A: So with that, let's go ahead and dive right into it. And it's titled Sawfork Covenant dependent layer two. Review by Peter Todd published September 2, 2024 on chain wallets achieve a roughly one to one mapping of transactions to transactions. For every economic transaction that a user performs, roughly one blockchain transaction is needed. Aggregations, coin join, cutthrough payments, etcetera change this statement a bit, but its roughly correct. Lightning achieved a many to one mapping of transactions to transactions. The magic of lightning is that an effectively infinite number of economic transactions can happen in a single lightning channel, which itself is tied to a single unspent transaction output, or Utxo. Essentially, weve taken the time dimension of transactions and achieved a significant scaling by collapsing that dimension. But creating even a single Utxo per user is arguably not good enough. So there are many proposals out there to achieve even greater scaling by allowing multiple users to share a single Utxo in a self sovereign way, again collapsing another space dimension of scaling users into one Utxo, our goal here is to do an overview of all of these proposals, figure out what technical patterns they share, figure out what kinds of new opcodes and other softwork upgrades they need to function, and create a comparison table of how all the parts fit together along the way, well also define what an l two protocol actually is, what kind of scaling lightning is already capable of, and get an understanding of what improvements we need to do to mempools to achieve all this. Thanks goes to Folger Ventures for sponsoring this research. They had no editorial control over the contents of this post and did not review it prior to publication. Thanks also goes to Daniela Brazoni, Sarah Cox, and others for pre publication review section one definitions what is layer two? Often the term layer two is defined broadly to the point where even a bank like entity, for example liquid, could be defined as a layer two. For the purposes of this article, we will adopt a strict definition. A layer two or l two is a bitcoin denominated system with the purpose of allowing BTC to be transacted more often than the number of on chain transactions with other parties, such that either one no one is able to profitably steal funds in the system, taking into account in system punishments and costs. Out of system costs and punishments like reputation loss, legal consequences, etcetera are not considered in our definition and two preferred the true owners of the funds are able to unilaterally withdraw their funds minus transaction fees, without the cooperation of any third parties. The first option is required because we want our l two systems to be able to represent amounts and transactions of such small value that they are unable to be represented on chain. For example, in lightning, htlcs can have a value too small to represent on chain. In that circumstance, the HTLC value is added to the transaction fee of the commitment transaction. When a lightning node can steal a dust HTLC by closing a channel at the right moment, doing so is more expensive than the HTLC is worth, making the theft unprofitable. That said, unilateral withdrawal is always our primary design goal. With this definition, things like lightning are considered l two systems. However, systems such as liquid cashew and fediment are not l two s because another party or parties has control of your funds. Client side validation schemes like RGB are also not l two s under this definition because they are unable to trustlessly transact bitcoin itself. Finally, state chains fails to make the cut because the state chain entity can steal funds if they do not follow the protocol. Section 1.2 what are covenants and why do more scalable l two systems need them? In bitcoin scripting covenants are mechanisms by which the way a TX out can be spent is restricted in advance, such that the form of transactions used to spend that transaction output are predefined or otherwise restricted in a way that is not purely limited to signatures. L two systems that share utxos between multiple parties need covenants because they need ways of constraining how the Utxo can be spent to implement the rules and incentives of the l two protocol recursive covenants. A recursive covenant is a covenant with the property that the rules constraining how a Utxo can be spent can be applied recursively to child utxos of the spending transaction indefinitely. Recursive covenants have long been considered to be undesirable by some because they can encumber coins indefinitely, or at least indefinitely without the permission of a third party, such as a government section two goals lightning is the current best in class layer two system out there. However, it has limitations, namely one, scaling. Lightning currently requires at least one Utxo per end user. Two, liquidity lightning requires that funds be tied up in channels. Three, interactivity. Lightning requires the recipients of payments to be online in order to receive them trustlessly. In evaluating layer two systems, our goal will be to improve on these key limitations, ideally without adding new limitations. Section 2.1 lightnings scaling limits what does one Utxo per end user mean in practice? Since lightning channels can operate indefinitely? One way of looking at this is to ask how many new channels can be created per year. Creating a taproot output has a marginal cost of 43 v bytes. If channel creation is amortized with many channels created in a single transaction, the other transaction overhead can be made negligible and fairly large numbers of channels can be opened per year to onboard new users. For example, suppose that 90% of block capacity went to opening new taproot lightning channels 52,560 blocks per year times a million v bytes per block times 90% times one channel per 43 vbytes equals 1.1 billion channels every year. It's estimated that about half of the global population own a smartphone, 4.3 billion people. So we can in fact onboard a significant percentage of the entire population that is likely to be able to make use of a lightning channel per year. However, channels do not last forever. On occasion, users will want to switch wallets, increase or decrease channel capacity, etcetera. The most efficient method to change the capacity of a channel is via splicing notably implemented in Phoenix, wallet like channel opens splicing could also be done in an amortized fashion to improve efficiency with multiple splice operations. Sharing a single transaction to reduce the number of inputs and outputs necessary to add and remove funds. Thus, the delta block space required per users splice, assuming the use of music is the 43 virtual byte taproot output plus the 57.5 virtual byte taproot keypath spend for a total of 100.5 v bytes. If we again assume a 90% block space usage, we get 470 million splices per year. Finally, note how switching lightning channels between wallets can be done in a single transaction by either trusting the next wallet to sign a commitment transaction after the funds have been sent to the commitment address, or with cooperative close to new channel support. In both wallet implementations, of course, there are competing use cases for bitcoin beyond. [00:13:45] Speaker B: Lightning channels, and how that will translate. [00:13:47] Speaker A: Into fee rates is difficult to know, but these numbers give us a rough ballpark that suggests that with current technology, it is at least technically possible to support hundreds of millions of self sovereign lightning users. Section three l two overview under our definition of l two systems, there are two main design patterns being discussed in the bitcoin development community, one channels and two virtual Utxos. In the channel pattern, of which lightning is the main example, the protocol progresses by exchanging pre signed transactions between the parties that could be mined but are not in the happy path. These pre signed transactions split a Utxo between the parties. Transactions happen by repeatedly changing the balance of that split with new pre signed transactions. Since there will be many different possible valid transactions spending the same Utxo, some incentive mechanism is needed to make sure the correct transaction is the one actually mined in the virtual Utxo or Vutxo design pattern, of which ark is the most prominent example. Vutxos are created via covenants or multiparty agreement via the creation of transactions that could be mined to actually create the desired vutxos on chain, but are not in the happy path. [00:15:14] Speaker B: In that respect, vutxos are similar to. [00:15:16] Speaker A: Channels, but unlike channels, vutxo schemes do transactions by spending the vutxos themselves in. Conceptually, a single pre signed transaction, the happy path design pattern is the use of an all parties agree script path, such as a in of n multisig. Taproot is designed specifically for this concept, allowing the keypath to be an n multisig via music. Assuming that all parties agree, the happy path allows for the coins to be efficiently and privately spent. Interestingly, since virtual utxos are real in many senses. [00:15:57] Speaker B: It is quite easy to build channels. [00:15:58] Speaker A: On top of virtual Utxos by simply creating virtual Utxos that, if mined, would lead to the creation of the Utxos required for the channel. In that sense, virtual Utxo schemes are a slightly lower layer than channels section 3.1 lightning the status quo implemented in production as the lightning network primarily based on the bolts standard, lightning is a combination of a number of things, including lightning channels and htlcs, the P two p routing network, onion routing, invoice standards, etcetera. Notably, lightning is not a consensus system, so different elements of the lightning system need to be adopted in the exact same way by all users. For the purpose of this article, when we say lightning, we'll use it in the broad sense, including easily foreseen upgrades to the current typical lightning protocols that are widely used. As discussed above, the key characteristic of lightning is its end user scalability limit due to the need to have at least one Utxo per user. That said, for the core routing element of lightning, the public lightning nodes that route the vast majority of transactions, the scalability limits arent much of a concern as lightning functions just fine if there are far more end users than routing nodes, because each public channel used for payment routing can easily support a large number of transactions per second. This is also why so many future l two systems are expecting to also participate in the lightning network. We also see this in how existing not quite l two systems like cashew rely heavily on the lightning network to actually be useful. The primary usage of cashew is probably to send and receive lightning payments non interactive channels. This construction improves on lightning channels by using OPCTV to reduce the interactivity requirements. However, as it doesn't improve on the one utxo per user scaling limit, we won't discuss it further. Section 3.2 channel factories here we have multiple parties negotiate a single n of n multisig address along with a transaction, spending that multisig address to create n different Utxos, splitting up the funds. Those Utxos in turn are used for payment channels. The channels can be used with the same security as if they had been directly opened on chain, because in the event that the channel state needs to be put on chain, the split transaction can be mined. This potentially saves on chain space when the channels are closed, as the end parties can in theory cooperatively close all n channels at once. Since channel factories are negotiating Utxos that could be mined but are not expected to actually be mined in the happy path they are a very primitive example of virtual Utxos. Channel factories by themselves do not require any soft forks to be possible. However, the simple channel factories described above are probably impractical beyond small numbers of parties due to the coordination required to actually achieve a scaling benefit. Thus, covenant proposals such as opt evict or CTV via TX out trees aim to allow more fine grained outcomes where individual parties can be forced on chain without forcing everyone on chain at once. Section 3.3 l two as in eltoo ln symmetry since l two is a terribly confusing name, well only use the updated name ln symmetry going forward. While pundraja channels encourage the correct state to be published on chain by punishing incorrect states, ln symmetry instead allows incorrect states to be updated with an additional transaction. This has the advantage of simplifying lightning channels by removing the complexity of penalties. However, this is likely to be disadvantaged in untrusted scenarios, as penalties are arguably needed to discourage fraud. Ln symmetry needs a soft fork to enable sigh any prev out which is required to allow state transactions to respond other state transactions during updates. By itself, ln symmetry offers no scaling improvements on conventional lightning channels, but proponents have argued that it makes things like channel factories easier to implement. Section 3.4 ark ark takes a new approach to transaction scaling, fully transferable virtual utxos that can be merged and split in atomic off chain transactions. In Arc, a central coordinator, the arc service provider, or AsP, provides vutxos for users with a defined lifetime, for example, four weeks. These periods are known as rounds. These vutxos are created via pool outputs, one per round via some kind of mechanism such as CTV, to allow a single on chain output to commit to a tree of vutxos. The round expiration is how ark achieves a scaling advantage. At the end of a round, the pool output unlocks, allowing the AsP to unilaterally spend it with a single signature in a small transaction. Due to the round expiry time, the vutxos themselves expire when the pool outputs, creating them expire. Users who own a vutxo must either spend that vutxo prior to the pool output expiry time being reached or put it on chain a unilateral withdrawal. To transact vutxos between parties, the ark coordinator cosigns transactions that spend one or more vutxos such that the transactions are only valid if one or more other vutxos are created in a different round in combination with some careful timeouts. See the arc docs for full details. This dependency is what makes spending vutxos trustless. The vutxos can't be claimed on chain unless new vutxos are created in a different pool transaction. There's a few potential ways to actually implement that dependency, but the exact details aren't relevant to the purpose of this article. Notice how this means that a given ASP will have many different active rounds happening at once. New rounds are frequently created to allow funds in existing rounds to be transferred, but the existing rounds overlap the new rounds, as they will generally expire sometime after new rounds and new pool TX outputs are created. Arc economics when a vutxo is spent, the ASP must provide matching VTC in a new pool output representing a new round, but they can't recover the value of the spent vutxo until the round expires. Thus, the economics of vutxo spins has a time value of money cost due to the liquidity that the AsP has to provide. Specifically, the cost is incurred when the vutxo is spent. While the vutxo is unspent, it represents a very real potential utxo that could be put on chain to unilaterally withdraw the funds. The user owns those funds. However, to spend the vutxo, the AsP must create a new pool tx out using funds the AsP obtains elsewhere, while the funds in the spent vutxo are not available to the AsP until the expiry time is reached. Thus, spending a vutxo requires a short term loan borrowing funds to cover the time interval between now and when the round expires. This means that liquidity cost to spend a vutxo actually declines as the Vutxo gets older and the expiry time gets closer, eventually, in theory reaching zero when the round finally expires. Finally, remember that the cost to spend a vutxo is related to the total size of the vutxo spent, not the amount paid to the recipient. This means that wallets intended for transacting vutxos directly, as opposed to managing one. [00:24:57] Speaker B: Vutxo for the purposes of for example. [00:25:00] Speaker A: A Vutxo based lightning channel have to make tradeoffs in how they split up funds into vutxos. A single Vutxo minimizes the cost of unilateral withdrawal while maximizing liquidity based transaction fees. Splitting up funds into mini vutxos does the opposite. This is entirely unlike the economics of on chain bitcoin or lightning transactions what is this liquidity cost? As of writing the lightning wallet, Phoenix charges a 1% fee to reserve channel liquidity for one year. At worst, Phoenix would have to tie up their funds for one year. However, that assumes that the liquidity isn't used. It's quite possible that the cost of capital to Phoenix is in fact higher, and they are assuming that the average customer uses their incoming liquidity in less than one year. Phoenix also earns money off transaction fees, potentially subsidizing channel liquidity. Finally, Phoenix might not be profitable. The US treasury bill rate gives us another estimate. As of writing, the three month treasury bill rate is about 5% per year. Since there is an argument that this rate is inflated due to us dollars being inflationary, we will assume the cost of liquidity for BTC denominated funds is 3% per year. For our analysis, if the round interval is four weeks, this means that a transaction would start off with a liquidity cost of 3% divided by 52 divided by four or 23%, eventually declining to zero. Assuming the user tries to move their funds to a new round two weeks prior to the round expiring, the user is paying about 1.5% per year in liquidity costs to achieve self custody of their funds. On the other hand, if the user waits until the last moment, the cost could be nearly zero. At the risk of missing the expiration time, users may not see this as a trivial cost, and this cost assumes that fixed costs of each round have been made insignificant by amortizing transaction fees and other costs over large numbers of participants. What if fixed costs arent so insignificant? Suppose that the ASP has 1000 users and pool outputs are created once an hour on average over a four week period. Thats 672 on chain transactions, which means to simply hold their funds, the ASPs users collectively have to pay for almost as many transactions as users. It would probably be cheaper for them to all open their own lightning channels, even though the ASP is requiring them to wait an entire hour for a confirmation. Bootstrapping ark the new ASP with few users faces a dilemma. Either ASP rounds happen infrequently and users have to wait a long time for the proposed round to gather enough vutxos to achieve a useful scaling and transaction fee reduction, or ASP pool transactions happen frequently with high transaction fees paid per user. As we showed in the previous section, it can take a lot of users to amortize frequent rounds and their underlying pool outputs because rounds expire. This problem is an ongoing one, even worse than that faced by lightning channels, at least a lightning channel can continue to be useful indefinitely, allowing a channel to be open now and amortized gradually over many months. Secondly, because rounds expire, there is less flexibility as to when to create the new TX outs backing these rounds. If fees are high for a week or two, users whose pool transactions are expiring have no choice but to collectively pay those high fees to maintain their custody over their funds. With lightning channels, there is much more flexibility as to when to actually open a channel. While the authors of Ark initially imagined a very optimistic scenario where new rounds are every few seconds, initial bootstrapping will probably have to happen with use cases that can afford to wait multiple hours for an Ark transaction to confirm if transaction fees are not subsidized. Interactivity non custodial arc is a highly interactive protocol since your vutxos expire, you have hard deadlines to interact with your Asp, or else the ASP could choose to take your funds. This interactivity cant be outsourced either. While lightning has watchtowers that discourage counterparties from trying to rip you off even. [00:29:42] Speaker B: If your channel hasnt been online, Ark. [00:29:45] Speaker A: Coin owners must use their own private keys to refresh funds without trust. The closest thing possible in Ark to watchtowers would be to sign transactions, allowing a watchtower to unilaterally withdraw your funds on chain towards the expiration time, which has a significant transaction fee cost. Consider what happens to a Vutxo if the owner goes offline after the round expires. The ASP needs to recover the funds to get their liquidity back for further rounds. If a Vutxo owner goes offline, putting that Vutxo on chain has significant transaction costs, as the ASP now needs to recover funds at multiple levels of the Vutxo tree. The ASP can recreate the spent vutxos in a new round, but this isn't trustless from the perspective of the Vutxo owners, as they can't spend these vutxos without obtaining data from the ASP. The ASP can also simply record unspent. [00:30:49] Speaker B: Vutxos as a custodial balance, or maybe. [00:30:52] Speaker A: Even have a policy of seizing the funds. Personally, I suspect that given the non trivial cost of self custody in Ark, many users will instead choose ASPs with a policy of rolling over funds into a new round and simply accept the potential for fraud at the end of each round. This is cheaper than proactively moving their funds early enough to guarantee safety in the event that, for example, they fail to turn their phone on in time for their wallet to move the funds to a new round. Advanced ark it may be feasible to reduce the liquidity requirements of Ark through more advanced covenants if it is typical for liquidity to be used up partway through a round. For example, let's suppose that 50% of the total v utxo value in a pool output has been spent. If the ASP could redeem just that. [00:31:49] Speaker B: Part of the round's pool output, they. [00:31:52] Speaker A: Could recover liquidity quicker, reducing overall liquidity costs. While no concrete proposals on how to do this have been published, it certainly seems like it should be possible with sufficiently advanced covenants, most likely through some kind of script revival salt fork that adds many useful opcodes at once. Similarly, through sufficiently advanced trademark covenants, the entire TX out tree structure could be replaced with some kind of rolling withdrawal scheme, potentially offering space savings. We'll cover this in a further section, as this technique is potentially useful for other schemes. The end of round custody issue is another case where sufficiently advanced covenants could solve a problem. A covenant, in particular a ZK proof covenant, could force the AsP to recreate all unspent vutxos in the next round, removing the problem of custody reverting to them at the end of a round. While it is probably not possible to make this trustless, as the user will likely need some data from the ASP to spend their vutxo in the new round, it could prevent the ASP from financially gaining from fraud against offline users on chain fee payment in unilateral withdrawal. Similar to lightning, the economics of on chain fee payment and the actual value of a vutxo after fees determine whether Ark usage meets our definition of an l two via unilateral withdrawal or fraud failing to benefit the AsP. We'll discuss the specifics of this further when we discuss the tx out tree design pattern. Section 3.5 validity roll ups a large class of sidechain like constructs generally propose to use various forms of zero knowledge or ZK proof technology to enforce the rules of the chain. The ZK proof technology is the critical difference between validity roll up technology and other forms of sidechain. If the ZK proof scheme works, the validity of the transactions can be guaranteed by map rather than trusting a third party. The zero knowledge aspect of a ZK. [00:34:14] Speaker B: Proof is not actually a requirement in this use case. [00:34:17] Speaker A: It's perfectly okay if the proof leaks information about what it is proving. It just happens to be that most of the mathematical schemes for this class of proof happen to be zero knowledge proofs. From the point of view of bitcoin, a validity roll up scheme requires a covenant as we want to be able to create Utxos for the scheme that can only be spent if the rules of the scheme are followed. This is not necessarily a decentralized process. Many validity roll up schemes are in fact entirely centralized. The rollup proof is proving that the centralized transaction sequencer followed the rules for a particular sequence of transactions. As for what covenant zero knowledge proof technology is still a very new field with advancements still being frequently made, so it is highly unlikely that we will see any opcodes added to bitcoin that directly validate any specific ZK proof schemes. Instead, it is generally accepted that specific schemes would instead use more general opcodes, in particular OpCat to validate ZK proofs via scripts. For example, starkware is campaigning to have Opcat adopted validity rollups is such a large potential topic with so many low substance and high hype projects that we won't discuss it further beyond pointing out what opcodes potentially make this design class viable. Section 3.6 BitVM very roughly speaking, BitVM is a way to construct a lightning channel between two parties such that the rules of the lightning channel are enforced by a zero knowledge proof. Since it doesnt actually need covenants to be implemented on bitcoin today, and because it cant directly be used to create an l two system that scales beyond the one Utxo per user limit, we wont discuss it further. Section 3.7 hierarchical channels hierarchical channels aims to make channel resizing fast and cheap. Hierarchical channels do for channel capacity what the lightning network does for bitcoin. However, they still don't fundamentally exceed the one Utxo per user limit. They also don't require any changes to the bitcoin protocol anyway, so we're not going to discuss them further. Their proponents should simply implement them. They don't need our permission. Section 3.8 coin pool coin pool allows multiple users to share a single Utxo, transfer funds between different users, and unilaterally withdraw. The coinpool paper proposal requires three new software features, sigh any prev out a. [00:37:06] Speaker B: Sigh hash group allowing a signature to. [00:37:08] Speaker A: Only apply to specific utxos, and an op Merkle subdivide to validate the removal of specific branches from a Merkle tree. The latter could also be accomplished with OpCaT. At the moment, coinpool development seems to have stagnated, with the last commit to the specification website being two years ago. Section 3.9 enigma network. While I was asked to cover the Enigma network, there seems to be a lack of documentation as to what the proposal really is. Bitfinexs blog post makes a lot of claims. The MIT page is empty. Since the blog post doesnt really make it clear what exactly is supposed to be going on, we wont discuss it further. Section four mempool considerations current mempool policy in bitcoin core is not ideal for l two systems. Here well go over some of the main challenges they face and potential improvements. Section 4.1 transaction pinning ultimately an economic exploit transaction pinning attacks refer to a variety of situations where someone can intentionally or unintentionally make it difficult to get a desired transaction mined due to the prior broadcast of a conflicting transaction that does not get mined. This is an economic exploit because in a true transaction pinning situation, there exists a desirable transaction that miners would profit from if they mined it. The conflicting pinning transaction is not mined in a reasonable amount of time, if ever. The simplest example of pinning comes from. [00:38:47] Speaker B: The fact that without full RBF transaction. [00:38:50] Speaker A: Replacement can be turned off. Thus, we can have a low fee rate transaction with replacement turned off that will not be mined, yet can't be replaced. Essentially, 100% of hash power has fixed this issue by enabling full RBF, and as of writing, full RBF should be enabled by default in the next release of bitcoin core after eleven years of effort. That leaves BIP 125 rule number three pinning, the only remaining pinning issue that is relevant to multiparty l two protocols and unfixed in bitcoin core. For reference. BIP 125 rule number three states the a replacement transaction is required to pay the higher absolute fee, not just the fee rate, than the sum of feed pays by all transactions being replaced. This rule can be exploited by broadcasting a large low fee rate pinning transaction, spending the outputs relevant to the multi party protocol. Alternatively, a group of transactions since the transaction has a low fee rate, it will not be mined in a timely fashion if ever. Yet since it has a high total fee, replacing it with a different transaction is uneconomical. Rule number three pinning is fairly easily fixed via replace by fee rate, and this fix works in all situations. Unfortunately, it's unclear if RBFR replaced by fee rate will be adopted by core in the near future as they've spent a substantial amount of effort on an inferior partial solution. Truc or v three transactions section 4.2 fee payment RBF child pays for parent sigh. Anyone can pay anchors and sponsorship since fee rates are undead, predictable, reliably and economically paying in situations where transactions are pre signed is difficult. The gold standard for fee payment is to use RBF, starting with an initial lowball estimate and replacing the transaction with higher fee versions as needed until it gets mined. For example, the open timestamps calendar software has used RBF this way for years, and L and D added support for. [00:41:15] Speaker B: Deadline aware RBF in version 0.18. [00:41:20] Speaker A: RBF is the gold standard for fee payment because it is the most block space efficient in almost all situations. The replacement transactions do not need any extra inputs or outputs relative to what would have been necessary if the correct fee had been guessed the first try. Efficiency is important because inefficiencies in fee payment make out of band fee payment a profitable source of revenue for large miners. Smaller, decentralized miners can't profit from out of band fee payments due to the impracticality and uselessness of paying a small miner to get a transaction confirmed. Out of band fee payment also seems to invite AML and KYC issues. At present, most of the out of band fee payment systems actually available right now require some sort of KYC process to make a fee payment, with the notable exception of the mempool Space accelerator, which as of writing August 2024 accepts lightning without an account. To make use of RBF directly in situations with pre signed transactions, you need to pre sign fee variants covering the full range of potential fees. While this is quite feasible in many cases as the number of variants necessary is usually small, so far the production lightning protocol and other proposed protocols opted instead to use child pays for parent or CPF, usually via anchor outputs. The idea behind an anchor output is you add one or more outputs to a transaction with a minimal or zero value with the intent of paying fees via CPFP by spending those outputs in secondary transactions. This is of course very inefficient when applied to protocols such as lightning that have small on chain transactions, almost doubling the total size of an ephemeral anchor output using lightning commitment transaction. It would be less of a concern when applied protocols making use of larger transactions such as anything using Opcat to implement covenants. A less obvious problem with anchor outputs is the need to keep around additional utxos to pay fees with in a typical client application this can be a significant overall burden as without the anchor outputs theres often no need at all to maintain more than one Utxo. Indeed, its likely that some existing consumer focused lightning wallets are vulnerable to theft by the remote side of the channel in hi fee environments due to the inability to pay fees. Sigh. Anyone can pay can be used for fee payment in some cases by allowing additional inputs to be added to signed transactions. Sigh single allows outputs to also be added. Lightning uses this for HTLC transactions. At the moment, this practice can be vulnerable to transaction pinning if not handled carefully, as an attacker could add a large number of inputs and or outputs to a transaction to create a high fee, low fee rate pin. RBFR fixes this issue, replaced by fearate. The approach used in truck or v three transactions is unable to fix this issue. This style of fee payment isnt as efficient as RBF, but it can be more efficient than anchor outputs. Finally, there have been a variety of software proposals to add a fee sponsorship system to the bitcoin protocol. This would allow transactions to declare dependencies on other transactions, such that the sponsor transaction could only be mined if the sponsored transaction was also mined, most likely in the same block. This could be much more efficient than a traditional CPFP, since the sponsor transaction could declare that dependency using significantly less v bytes than the size of a transaction input. Section 4.3 replacement cycling the replacement cycling attack takes advantage of transaction replacement to attempt to replace a desired l two transaction long enough to get an undesired one mined instead. Essentially, replacement cycling attacks are, for the attacker, an alternative to transaction pinning techniques, in that they aim to prevent a desired honest transaction from being mined long enough to allow an undesired, dishonest transaction to be mined instead. Unlike transaction pinning attacks, a replacement cycling attack can't happen by accident. The canonical example is against a hash time locked contract or HTLC. While it's easy to think of an HTLC as being a contract to either allow a transaction to be spent via the revealing of a preimage or via a timeout. In reality, due to bitcoin scripting limitations, an HTLC allows a transaction to always be spent via revealing a preimage and then after a timeout additionally, via the timeout mechanism, replacement cycling takes advantage of this, using the preimage after the timeout to replace the transaction, trying to redeem the HTLC output via the timeout mechanism without the victim learning the preimage. A successful replacement cycling attack does this long enough for a different channels HTLC to time out. A main challenge in profitably exploiting replacement cycling is that each replacement round costs money. A deadline aware lightning implementation will spend higher and higher fees attempting to spend the expired HTLC output before the expiry of the next HTLC output in turn expires. Secondly, anyone can defeat the attack by simply rebroadcasting the replace transaction once the replacement cycle is finished. As with transaction pinning, replacement cycling is also an economic exploit on miners. At the end of each replacement cycle there exists a transaction that has been removed from mempools, yet is fully valid and could be mined if only miners still had it in their mempoles. Section five feature patterns and soft forks this episode is brought to you by the cold card hardware wallet. For anyone intending to hold a even slightly substantial amount of bitcoin, I always recommend before anything else, get yourself a hardware wallet. Now this isn't before you buy your first bitcoin. If you want to buy $10 worth dollar $50 100 worth, there's no reason to get a hardware wallet. [00:47:58] Speaker B: But if you are buying $10,000 worth. [00:48:01] Speaker A: If you are putting your life savings into this, you are an absolute fool if you do not get a cold card and importantly, take the short amount of time necessary to understand what it. [00:48:13] Speaker B: Is doing for you. [00:48:14] Speaker A: How many hours did you spend getting that $10,000? How much risk did you take getting that $10,000? Might it behoove you to take 1 hour to get yourself a good hardware wallet and understand how to use it? Which it doesn't even take that long. But if you want to be thorough and kind of go over it a number of times and make sure you've got it right, an hour seems very. [00:48:37] Speaker B: Reasonable, but you can set up the. [00:48:39] Speaker A: Cold card in just a few minutes. The instructions are very easy to understand, the steps are very clear, and all of the pieces are given to you. [00:48:47] Speaker B: Right out of the box. [00:48:48] Speaker A: Write down your seed words, verify them. Set a pin, connect to your wallet. Sign a transaction. That's really it. Can you write down twelve or 24 words without making a mistake and then easily verify that it was in fact correct? Can you remember a short pin number to get into your device? And can you tap your cold card to your mobile wallet? See the transaction details on your cold card screen? Verify that it's the same thing as on your wallet, and then hit yes. Confirm if you can do those things. You know how to sovereignly use your bitcoin to own it without question and know that it is safe, even if something happens to your mobile phone, even if you get hacked, and even if you lose your cold card. And then best of all is you'll. [00:49:32] Speaker B: Kind of feel like a cypherpunk when. [00:49:33] Speaker A: You break out your cold card to tap it to your phone every time. [00:49:36] Speaker B: You want to do a transaction. [00:49:37] Speaker A: Trust me, you will thank me and you can get a discount, which also lets them know that I sent you with my code bitcoinaudible. The link, the details, and everything you need to be a sovereign bitcoiner is right in the show notes. [00:49:50] Speaker B: All right, we are going to stop this one here on section five, which I think this will actually turn this into just two episodes. [00:49:59] Speaker A: Yeah, yeah, yeah, yeah. Because there's a. [00:50:00] Speaker B: There's a bunch of footnotes at the bottom. So we're basically halfway through this one now. But there's. And I know there was a lot of technical stuff. And so I'm just going to kind of briefly go over a lot of the things before we kind of talk about the implications of them more explicitly. But I just want to make sure. [00:50:16] Speaker A: That this one kind of sinks in. So we're going to go over a lot of things. First, the definition of layer two. [00:50:23] Speaker B: It's that no one that is running a layer two system can profitably steal funds. [00:50:31] Speaker A: And that it is specifically an in system punishment or an in system cost that makes it so that those funds can't be stolen. [00:50:39] Speaker B: And then the other is part two is that the true owners can, without. [00:50:44] Speaker A: Any third party or without the operator or without the group, whatever it is, can take their funds out. They can broadcast a transaction on chain and take it to their wallet, to. [00:50:56] Speaker B: Their cold card, to whatever address that they pre signed or that they have. [00:51:02] Speaker A: Available to them and own it unilaterally. That this is my Utxo behind my. [00:51:07] Speaker B: Keys, and basically no one can stop me from doing that. [00:51:10] Speaker A: That is a late. [00:51:11] Speaker B: That is a l two. That is a layer two, a genuine. [00:51:14] Speaker A: Layer two on bitcoin. And that's why specifically liquid cashew, e cash systems and fediment are not actually real l two s. They are layers. [00:51:25] Speaker B: On top of bitcoin. They are bitcoin denominated, but you cannot unilaterally exit. You have to have a third party's. [00:51:32] Speaker A: Permission, which in the case of liquid. [00:51:35] Speaker B: Is a huge multisig of a bunch of different institutions. And while you can verify by running liquid nodes and such that they are being honest and that all the rules. [00:51:48] Speaker A: Are being followed, it's really kind of. [00:51:50] Speaker B: Like a full reserve system of a collection of institutions that are basically all. [00:51:58] Speaker A: In it together, or they're all screwed at the same time. Either everyone is corrupt all at once. [00:52:03] Speaker B: Or any individual attacker or thief or a hacker or anything like that cannot unilaterally cause a problem in the system. So that's kind of the benefit. What you're doing there is you're basically. [00:52:18] Speaker A: Distributing trust among many institutions and hoping. [00:52:20] Speaker B: That these institutions are mutually untrustworthy or untrusting of each other so that you kind of have. [00:52:29] Speaker A: You just have distribution of the trust. [00:52:31] Speaker B: System rather than being reliant on one. [00:52:35] Speaker A: Institution or one person who would then. [00:52:38] Speaker B: Have the incentive to screw over everyone else. This is why specifically I've talked about on the show before, I think liquid and fediment and these things are ingenious ways to utilize bitcoin, and they are, in fact, novel. I think just purely calling them, oh, it's a bank or it's a custodian, really lends itself to dismissing a potent. [00:53:02] Speaker A: A really powerful improvement over it, because this is something that doesn't exist in the fiat system. It can't exist in the fiat system. There's no such thing as multisig. [00:53:11] Speaker B: You can't like. [00:53:11] Speaker A: Fiat is the money itself is permissioned. And in the context of liquid, or. [00:53:17] Speaker B: In context of bitcoin itself, the money is not permissioned. [00:53:20] Speaker A: You can have a genuine multisig. [00:53:23] Speaker B: That money isn't going anywhere without two thirds of the signature of all of. [00:53:27] Speaker A: Those institutions that are. That are participating in the liquid network or participating in the federation. That is a profound breakthrough. [00:53:35] Speaker B: That is a crazy. And then the idea to have confidential transactions, or in the case of fediment and ecash, to have complete privacy of. [00:53:44] Speaker A: Transactions inside of that system is also a huge breakthrough. [00:53:49] Speaker B: It's a massive step function improvement over the fiat system. And a lot of the limitations and a lot of the deep negatives and surveillance elements of how we think of. [00:54:00] Speaker A: As institutions today, but they are still custodial. They're just advanced custodian systems. And you can do really cool things like distributing the trust across many institutions or companies, and specifically distributing trust across many different jurisdictions. So it's not even the regulatory environment or the cultural environment that is specifically enforcing the use or the honesty of this system. You can make it as broad and. [00:54:26] Speaker B: I as quote unquote, complicated as you. [00:54:29] Speaker A: Want it to be in order to try to distribute that trust. But at the end of the day, you can't unilaterally exit. You need a majority of the participants of the federation, of the liquid side. [00:54:42] Speaker B: Chain, or whatever it is, in order to sign your redemption of coins from that system. And if they all disappear, all those coins are locked. They're stuck there until those keys come back to life or come back active and start signing and executing withdrawals again. [00:55:07] Speaker A: So that's why they're not considered genuine. [00:55:09] Speaker B: L two s. When it comes to bitcoin because those are our two criteria. [00:55:13] Speaker A: We want the punishments and the cost in the system are to be in the system. They're in band costs. And punishments like lightning channels, is I can enforce my own punishment on the channel party. [00:55:25] Speaker B: And I don't need outside permission. I don't need to call up a judge or, you know, dial 911 and be like, oh my God, my channel partner screwing me. Because that also presumes that we have a proper rule system outside of it. [00:55:36] Speaker A: Which is the whole point, is that we know we don't have. [00:55:38] Speaker B: We're presuming we don't have a proper rule system, that we have deep unfairness, we have deep levels of corruption all over the place. [00:55:47] Speaker A: And bureaucracies are so inefficient and stupid. [00:55:49] Speaker B: That to think that we would rely. [00:55:52] Speaker A: On the government to enforce this rather than mathematics, rather than the cryptography itself. [00:55:57] Speaker B: That's the whole point of the whole system, right? Is to have cryptography, mathematics and mathematics. [00:56:02] Speaker A: And definable, explicit rules be the arbiter of the truth, and that the user themselves can unilaterally enforce that truth. If that is not present, then it's. [00:56:14] Speaker B: Not really an l two. [00:56:16] Speaker A: And with that definition, understanding that those are the critical criteria, lightning is just the layer two system. [00:56:24] Speaker B: It's kind of the only real one. [00:56:27] Speaker A: All the roll ups and optimistics, roll. [00:56:30] Speaker B: Ups and validity things, all this stuff. [00:56:32] Speaker A: Are almost all inherently centralized or permissioned. [00:56:36] Speaker B: Now, you might be able to prove. [00:56:37] Speaker A: That they're being dishonest or not. That's the value of the roll ups themselves, is their quote unquote, validity proofs. [00:56:44] Speaker B: But I don't think I know of. [00:56:45] Speaker A: A single one that allows you to have unilateral exit. [00:56:48] Speaker B: Like, if they just. If everybody just disappears, everybody's still just screwed. However, the only comment that Peter Todd. [00:56:54] Speaker A: Said in this one that I don't. [00:56:56] Speaker B: Quite understand, because it seems to be maybe I do understand it. Okay, so the comment is, is finally, state chains failed to make the cut. [00:57:07] Speaker A: Because the state chain entity can steal funds if they do not follow the protocol. [00:57:13] Speaker B: Okay, I think I just. I think I just realized what he means by that. So you can unilaterally exit from a state chain, that you can, you can. [00:57:23] Speaker A: Pull those funds, but it requires multiple signatures. [00:57:26] Speaker B: And if the state, that you require the state chain to actually work in your favor, because you have to have. [00:57:34] Speaker A: Their signature as well, even if you're holding on to it. And if they cooperate with a previous state. [00:57:40] Speaker B: So let's say someone you send a transaction to, my brother and my brother. [00:57:44] Speaker A: Sends a transaction to Charlie. Charlie sends a transaction to me. [00:57:48] Speaker B: But Charlie is actually really good friends with statechain operator and I try to. [00:57:52] Speaker A: Take mine on chain. [00:57:54] Speaker B: Well, the state chain I guess. [00:57:58] Speaker A: Would I have a signature to begin. [00:57:59] Speaker B: With before I exit? I guess I would have a time lock. Man, I've forgotten the specifics of time chains, excuse me, of state chains and how they work. Um, but I do know that if the state chain colludes with Charlie or colludes with my brother, they can actually. That's right. Okay, I have a time, I believe this is how it works is I have a time lock exit that revokes Charlie's exit and my brother's exit like the previous states. However, if the state chain colludes with Charlie specifically and has both signatures, while. [00:58:40] Speaker A: The state chain operator will not listen to me or will not sign a. [00:58:44] Speaker B: Valid output for me, I now have. [00:58:46] Speaker A: A time lock whereas Charlie can spend his now. So the state chain can basically cheat. [00:58:52] Speaker B: To and you know, you know, basically maybe he says all right, we're going to split this 50 50, Charlie, because guys trying to take a bitcoin out of this and I would really like to just have half of that. [00:59:02] Speaker A: So the cost of my signature is half a bitcoin. [00:59:05] Speaker B: Why don't you go ahead and send me that and then we will let. [00:59:09] Speaker A: You steal the funds. [00:59:10] Speaker B: Okay, so that makes sense. I wasn't putting two and two together and it seemed like state chains have the unilateral exit, but the state chain can basically revoke that they are a trusted or semi trusted party in that, in that system. Okay, so now we go on to covenants. So covenants are, right now we have a couple of different ways to lock up transactions or to lock how transactions are spent. I mean that's what a transaction is, right? Is it's just putting my lock for who can spend a transaction onto the coins. So I have a, like this is the whole public private key system, right? [00:59:50] Speaker A: Is you have a secret key. [00:59:51] Speaker B: That's your twelve words, your 24 words, they generate your secret keys and then. [00:59:57] Speaker A: You have a public key which is an address. [01:00:00] Speaker B: It's really kind of a, you have. [01:00:02] Speaker A: An actual pub key that generates addresses. [01:00:04] Speaker B: But hashing all multiple steps ignored, that's not really the point. [01:00:09] Speaker A: The address is a lock. [01:00:11] Speaker B: So when I give you a bitcoin address, I'm giving you a lock. And what you do is you just say, here's one bitcoin transaction, I'm going to put your lock on it and then now only my key can unlock that lock. And everybody can just publicly see that. Okay, without this signature, this lock doesn't unlock. So that's a who can spend it transaction restriction. Then we have a when can it. [01:00:37] Speaker A: Be spent transaction restriction. [01:00:39] Speaker B: This is what allows lightning channels to exist is, okay, here is a lock, and here's a script that says this lock can spend this transaction after one week or at this block height. So if it's block 850,000, I can make a block. I can make a transaction with your lock on it that is not spendable. With the absolute time lock, I can say it is only expendable at trans. [01:01:08] Speaker A: Or at block 860,000. So you have to wait 10,000 blocks. [01:01:13] Speaker B: Before for your key can actually unlock this transaction. [01:01:17] Speaker A: And this allows us to have multiple. [01:01:18] Speaker B: Spin paths or to use multiple spin paths with multiple time locks in order. [01:01:25] Speaker A: To basically create a quote unquote covenant. [01:01:27] Speaker B: A way where together, if we agree, we can spin transactions now. And if we don't agree, the other. [01:01:35] Speaker A: Person has to wait. [01:01:36] Speaker B: And maybe there's another secret, a piece of secret information that if I have to wait, because we're not agreeing on. [01:01:44] Speaker A: What the output is, you have the ability to contest it. You have the ability to send a. [01:01:49] Speaker B: Transaction with different details or with that secret key that unlock it and prove. [01:01:54] Speaker A: That I'm being dishonest. [01:01:56] Speaker B: That's what a lightning channel is. So it's like having, you know, it's like building in a couple of weeks or a day or something like that in order to force you to be public about the fact that you're trying. [01:02:07] Speaker A: To exit this channel so that the other party has time to see. [01:02:11] Speaker B: And now they have to go to. [01:02:12] Speaker A: Quote unquote, go to court, which is their, which is the bitcoin network. They have to go to the bitcoin network and prove that they are actually. [01:02:18] Speaker B: The ones with all the correct cryptography. They're the ones with the math that. [01:02:22] Speaker A: Allows them to actually own a sub amount inside of a. A bitcoin account. [01:02:27] Speaker B: I know none of this is the. [01:02:28] Speaker A: Correct terminology, by the way. I'm just trying to make this easy. [01:02:31] Speaker B: To picture in your head. Hopefully, this is easier than the article if you're having trouble. [01:02:37] Speaker A: So that's. [01:02:37] Speaker B: So we've got two of those two locks, right? [01:02:40] Speaker A: Who can spend it and when can it be spent? [01:02:43] Speaker B: And that allows you to build some really interesting things. [01:02:45] Speaker A: The third and critically important piece, I. [01:02:48] Speaker B: Think, to building some really fascinating and truly layer two protocols is what can. [01:02:57] Speaker A: Be spent out of it. [01:02:58] Speaker B: So rather than having Utxos denominate amounts, you can actually have sub restrictions, sub scripts inside of a Utxo that break it up among many different people. So you can have one output, one transaction, or one address that actually through just a series of cryptographic proofs and quote unquote covenants that say, let's go back to that one bitcoin is that I actually own like on the, on the bitcoin system itself. In the bitcoin network it's just one address, one bitcoin. However, that address was created with the. [01:03:39] Speaker A: Signatures and the transactions pre made. [01:03:42] Speaker B: Where I get 0.5, you get 0.4 and my brother gets 0.1. So now we have a transaction on. [01:03:50] Speaker A: Chain that just sits in one Utxo and privately and off chain, the only. [01:03:56] Speaker B: Math, the math required to sign or unlock it requires that Jeff gets .1 of it, you get .4 of it. [01:04:06] Speaker A: And I get .5 of it. It is unspendable without meeting those requirements. That is a covenant. [01:04:14] Speaker B: And then thinking about how these primitives lead to more elaborate constructions and more. [01:04:21] Speaker A: Elaborate agreements and stuff, is that now. [01:04:23] Speaker B: This means that if we want to change that, well we could all three get together and cooperatively sign it and. [01:04:30] Speaker A: Update that so that Jeff gets, .2 I get .4 and you still get your. [01:04:36] Speaker B: .4 I basically made a transaction of 0.1 from my ownership to my brother's ownership. [01:04:45] Speaker A: But on chain it's still just one address to one address. [01:04:48] Speaker B: There's no, none of that complexity. [01:04:50] Speaker A: That transaction, that shift is seen. It's just, it's still just sub that Utxo. [01:04:56] Speaker B: It's itself, it's just sub that one. [01:04:58] Speaker A: Address and that one balance of one bitcoin. Still that's what covenants allow us to do. That is a what can be spent, which we can then combine with a who can spend it and when can it be spent? [01:05:12] Speaker B: And this is where you get a lot of these other protocol designs, coin pools, ark channel factories, all of these things. [01:05:20] Speaker A: Granted, lightning itself, a lightning channel is. [01:05:23] Speaker B: Kind of a really complicated interactive covenant. [01:05:26] Speaker A: Is that you're basically setting it up. [01:05:29] Speaker B: As if there's a covenant because you're holding, you're each holding on to transactions like a lightning channel between me and you is basically a system where I have the ability to exit in exactly the same way, literally, is that I have the ability to exit with 0.5. [01:05:44] Speaker A: And you have the ability to exit with 0.5. [01:05:47] Speaker B: But the only way we can do that is actually by having three different. [01:05:50] Speaker A: Spend paths and updating and pre signing a bunch of different things at multiple times. [01:05:56] Speaker B: Like, basically there's a lot of interactivity. And this is what causes that. [01:06:02] Speaker A: The number of limitations for lightning that. [01:06:04] Speaker B: We really want to overcome is you have first the scaling limitation of. And this is the goals that he breaks down right at the beginning of this. The scaling limitation of lightning still requires basically one address per user, one output per user at the least, by the. [01:06:23] Speaker A: Way, that's the limit or best case. [01:06:26] Speaker B: Scenario of lightning as a truly functioning non custodial layer. Two, then there's liquidity that requires the. [01:06:34] Speaker A: Funds to be tied up in channels. And then, of course, the interactivity. [01:06:38] Speaker B: That's the. And that's really the big one, I think the interactivity and the inability of push payments on lightning and what he. [01:06:48] Speaker A: Refers to as ln symmetry and what. [01:06:50] Speaker B: A bunch of people have been talking. [01:06:51] Speaker A: About, which allow far simpler constructions of. [01:06:54] Speaker B: Lightning channels that aren't so multi stepped, so to speak. And covenants really, really simplify this entire interaction and this structure. I mean, you think about technically with lightning channels and covenants, you could just have the lightning channel update the covenant state. Just like we talked about with the. You, my brother and me in a channel is you could just keep updating that and you could have a simple channel relationship where you're signing and then we just cooperatively sign the new CTV outputs. And that really simplifies the organization of this. And the cooperative clothes or the non cooperative close can just have a timeout. And now, interestingly, is that you could actually have it so that one party could actually push a payment to the other person by having the public key. [01:07:53] Speaker A: By paying to a public key of the user in the channel. [01:07:57] Speaker B: Now you'd still have to have some way that, you know, they can come back online and update the information. And it would be entirely trustless in the fact that you still have to update and ensure you still can't get. [01:08:09] Speaker A: To that final state if you don't. [01:08:10] Speaker B: Come online and actually get the data. But the payment can still be reliably or provably locked behind your keys where. [01:08:21] Speaker A: The user themselves, who's making the payment, not the other person in the channel. [01:08:25] Speaker B: But like across the channel, can pay to specifically to your lock, so to speak. [01:08:30] Speaker A: And so again, without your cooperation in the signing of the closure, they still. [01:08:34] Speaker B: Have to wait a time lock. And you can still come back online and find out what was going on. [01:08:38] Speaker A: But there's still some elements and some. [01:08:39] Speaker B: Dynamics and ways like alternative paths to. [01:08:43] Speaker A: Getting the information from or to the end user. To the person who received the payment, even if they were offline. But the point isn't to get into the weeds there. [01:08:52] Speaker B: It's just about understanding that the non interactivity of covenants are actually a really big improvement. And that's why it specifically enables a lot of new things and could simplify the. Both the construction, the security profile and. [01:09:12] Speaker A: The simplicity of what you have to back up and how you have to. [01:09:16] Speaker B: Back it up for lightning itself. So the breakdown of layer two stuff. [01:09:22] Speaker A: Just in general, is that basically the. [01:09:24] Speaker B: Main two layer two ideas that have been implemented in any form or fashioned fashion and that are required, the primitives. [01:09:38] Speaker A: So to speak, that are required to. [01:09:39] Speaker B: Build and understand and redesign anything and everything else have been channels. And now virtual Utxos, which a channel is the three path system of punishment and basically creating a covenant, whereas virtual Utxos are utxos that we could spend. And in the example again of the you, my brother and myself in a covenant address where my brother gets 0.1, you get 0.4 and I get 0.5. Well, because that address cannot be spent. [01:10:19] Speaker A: Without sending specifically to the addresses that. [01:10:22] Speaker B: Have my five, your, .4 and my brother's 0.1, that even though those addresses don't exist on chain, the only way. [01:10:32] Speaker A: To validly spend the one that is. [01:10:34] Speaker B: On chain is by creating yours, mine and my brothers. It's kind of like putting locks inside of a lock, is that you can say that, you know, there's a. There's a storage container at the train, like a storage, like safety deposit box or something. But then when you unlock it and open it, only then do you reveal that there are three more security boxes. [01:11:01] Speaker A: Inside that have actually split up the funds. [01:11:04] Speaker B: And you have to have those individual. [01:11:06] Speaker A: Locks in order to unlock those different groups of funds. [01:11:10] Speaker B: So some of the funds are in. [01:11:11] Speaker A: Yours, mine and my brother's. Except that in the digital sense, those. [01:11:15] Speaker B: Other three boxes don't even exist until you unlock the first one. It's kind of like Schrodinger's outputs. They're. They don't exist yet. It's just that they mathematically. Mathematically, the only way to create or. [01:11:27] Speaker A: Validly get rid of the old one. [01:11:29] Speaker B: To move the funds at all, is to create them. These are virtual utxos. My brother's point one balance, your .4 and my .5 are all virtual Utxos. [01:11:41] Speaker A: They are. [01:11:42] Speaker B: They're virtual addresses with virtual balances. Because, you know, without, like, at any point, I can take my .5 and I can publish and send the address that we own altogether to my .5 at any time that I want because. [01:12:00] Speaker A: All it requires is my signature and. [01:12:03] Speaker B: That proof of those outputs of in. [01:12:05] Speaker A: Order to redeem it. [01:12:07] Speaker B: So it satisfies all the requirements of a genuine layer two protocol. However, because the addresses don't actually exist. [01:12:15] Speaker A: It'S a virtual utxo. [01:12:17] Speaker B: It's a virtual output rather than a real one. Now the really cool element of this, and the really cool thing about arc. [01:12:25] Speaker A: And all of these layer two protocols. [01:12:27] Speaker B: That use virtual utxos or virtual outputs is that the output itself can be a channel. So rather than my brother just owning 0.1, you owning 0.4 and me owning 0.5, my .5 can be a channel between my brother and me, and your. [01:12:51] Speaker A: .4 can be a channel between you and me. And now without updating that balance, we can actually use these addresses that don't exist on chain, but we know they must exist in order for the spin to be valid. [01:13:05] Speaker B: We can now use these to open to as lightning channels and we can. [01:13:11] Speaker A: Make tens, hundreds, thousands of payments inside of them. And if we want to update the balances or the splicing or the liquidity in those channels, then we would just. [01:13:23] Speaker B: Update that top address, that, that, that. [01:13:26] Speaker A: Top account and the balance. [01:13:28] Speaker B: So that ends up behaving a lot more like a channel factory. [01:13:31] Speaker A: We now have three people who are. [01:13:33] Speaker B: Distributing these funds inside this, even though this is a covenant proposal concept specifically. You can also do this with a channel factory where everybody has to be interactive and everybody has to be online, which is which is why Peter Todd. [01:13:45] Speaker A: Specifically mentions in this one that is. [01:13:47] Speaker B: Not very scalable because you already have the problem of two channel parties not being online at the same time, and kind of how difficult it is to coordinate that. Well, that gets exponentially worse and worse when you have three people, four people, five people, six people, one person not online causes a headache. But covenants could specifically simplify that process and also allow certain funds and things to continue to move or continue to. [01:14:11] Speaker A: Update even when one person wasn't online. [01:14:13] Speaker B: Because everybody can unilaterally exit or cooperatively exit within the same pool. But regardless, what you're doing is you're. [01:14:22] Speaker A: Basically using a covenant to distribute out funds. [01:14:25] Speaker B: And then each one of those fund distributions, those virtual utxos, is itself a channel. [01:14:33] Speaker A: And now everyone has a connection into. [01:14:34] Speaker B: The lightning channel or lightning network with virtual channels. And so this is actually a scaling improvement over lightning in the naive sense or in the current implementation, because it means rather than one utxo per user. You have one virtual Utxo per user. [01:14:55] Speaker A: And potentially one Utxo, one actual Utxo per, let's say, four or five users. [01:15:01] Speaker B: Or if this construction can be made really non interactive and you have, you know, some advanced setup, you could potentially. I mean, hopefully this. And I don't know of a system that does this, and he doesn't talk about one in this article specifically, but the idea of. I mean, like, that's the holy grail, right? Is that you can have 100 participants where if only three of them are online, they can still operate within their three thing and still aggregate and combine. [01:15:31] Speaker A: With the other hundred later with their. [01:15:33] Speaker B: Updates, et cetera, et cetera. And everyone has unilateral exit, and no one, not even an operator, has the. [01:15:41] Speaker A: Ability to steal funds. Like, that is the holy grail. [01:15:44] Speaker B: And whatever it is, if that's truly possible. I mean, I genuinely think it is. And we'll probably have to continue to. [01:15:52] Speaker A: Innovate and invent a lot of new. [01:15:54] Speaker B: Things in order to get there, but I think one day we will, just. Because, I don't know, that's. [01:15:58] Speaker A: That's how humans innovate. [01:16:00] Speaker B: Like, I could have just as easily. I mean, 20 years ago, I could have said bitcoin wouldn't exist. Is. That's not possible. How wrong would I have been? I just don't think human innovation has a cap. There's. There's not a limit on it. But I do not see how that. [01:16:15] Speaker A: Construction becomes possible or it can be. [01:16:19] Speaker B: Possible without covenants, because I think specifically, you need a. [01:16:24] Speaker A: What can be spent? Who can spend it, and when can. [01:16:28] Speaker B: It be spent in order? Like, just in a naive sense, you have to have those three pieces, those three legos in order to build the Lego tower. That is the. The perfect layer two. Now, we also. Or he also talks about Ark and Ark economics, and this is the big limitation of Ark. And we just had Burak back on the show, which was today. [01:16:51] Speaker A: Today is Tuesday. [01:16:52] Speaker B: So I'll probably. I think I'm gonna publish this one today, which probably means tomorrow we will have the conversation I had with Burak about Ark and about roll ups, which is another protocol he has designed. And we talk about the trade offs. [01:17:07] Speaker A: And limitations of each of those. [01:17:09] Speaker B: But the. The economics of Ark, the two big drawbacks in. In my thinking, and that Peter Todd kind of breaks down here, is the liquidity requirements, of which I'm not 100% sure about. The advanced. The advanced liquidity correction, where if, like, 50% have already been moved, then that 50% can be restored, because I was. [01:17:35] Speaker A: Under the impression that, like, I think. [01:17:37] Speaker B: It was Matt Corrallo and Barack basically solved that problem, or they figured out a way to do that. But I could be wrong and I'll actually have to relisten to my conversation with Burak to see exactly what he said, because I've forgotten it. [01:17:52] Speaker A: But there are some improvements there in order to redeem liquidity so that the. [01:17:56] Speaker B: Cost of locking up capital is less. But the simple version, the simple way to think about it is that if I. If the LSP locks up one bitcoin to me because a one bitcoin payment was made, then I spend that one. [01:18:11] Speaker A: Bitcoin to you, then you spend that. [01:18:13] Speaker B: One bitcoin to my brother, and my brother spends that one bitcoin to a bitcoin mechanic. [01:18:19] Speaker A: And this is all within the four week period of the original locking of those funds. [01:18:26] Speaker B: Well, that means that that one bitcoin. [01:18:28] Speaker A: Exists in four different rounds of the Ark that have to be rolled over, and the Ark has to lock up one bitcoin in each one of those rounds, which means the first bitcoin that was sent to me is not unlocked. In other words, the Ark service provider. [01:18:44] Speaker B: Has to have four bitcoin to fulfill and guarantee the ownership of each of our bitcoin in each of those rounds. And my original bitcoin that was sent to me doesn't get unlocked in the. [01:19:00] Speaker A: Ark until four weeks have passed. [01:19:02] Speaker B: Then the Ark provider can. Let's say that then BTC mechanic sends. [01:19:09] Speaker A: That one bitcoin to simple Steve. [01:19:11] Speaker B: Well, rather than having to lock up. [01:19:12] Speaker A: Five bitcoin, if it's now been four. [01:19:14] Speaker B: Weeks since I originally received, well, now simple Steve can actually receive, can get the ownership by locking up the one bitcoin that was originally to me to now to him. But you can see how big the. [01:19:28] Speaker A: Liquidity requirements are for ark as this continues forward. [01:19:31] Speaker B: And lots of people make lots and lots of payments. [01:19:34] Speaker A: And importantly, if I don't come in. [01:19:36] Speaker B: If I don't come back on, or. [01:19:37] Speaker A: I don't spend the bitcoin within that. [01:19:40] Speaker B: Four weeks, I don't come back online. [01:19:42] Speaker A: Well, then it expires and the AsP can then take it. Basically, that one bitcoin is still unlocked. [01:19:48] Speaker B: To the service provider unless I roll. [01:19:51] Speaker A: It into the next round myself by. [01:19:53] Speaker B: Basically spending it to myself or I spend it to my brother, BTC mechanic, you, etcetera, etcetera. So the liquidity requirements are a huge. [01:20:04] Speaker A: Burden there, because they are going to. [01:20:05] Speaker B: Raise the cost substantially. [01:20:07] Speaker A: Then the other one is the fact. [01:20:09] Speaker B: That it only works in aggregate. And this is the one thing that I've talked about a bunch, and we also talk about, we bring this up again on the show with our kind of like revamp or our re exploration of all these things with Burak. And that Peter Todd talks about in this article is that if you have 1000 participants and you have 672 transactions, well, you're still amortizing costs on 672 transactions because you're still having to update that one UTX, that one input to one output transaction every single time to ensure that every single person has that unilateral exit. So without a lot of activity, it doesn't even really help the cost savings that much from a fee perspective. [01:21:00] Speaker A: Now it does from a Utxo perspective. [01:21:03] Speaker B: Because all thousands of those people are. [01:21:05] Speaker A: Actually sharing one UtxO. So their footprint on chain is a. [01:21:10] Speaker B: Single address with a single balance, but their footprint over time is, you know, let's say there's 672 transactions and none. [01:21:20] Speaker A: Of them happened together. [01:21:21] Speaker B: They were all an hour apart. Well, then that means it was 672 different outputs, different transactions on chain, but it still just exists under one unspent transaction output. [01:21:34] Speaker A: So at the end it's still just. [01:21:36] Speaker B: One address with one balance, but it. [01:21:38] Speaker A: Had to be on chain updated 672 times. [01:21:42] Speaker B: Now, if all 672 of those transactions happen within the same block, like if we're, if there's a thousands of a. [01:21:49] Speaker A: Thousand of us and we're super, super. [01:21:51] Speaker B: Busy, we're doing lots of different transactions, there's an explosion of, I don't know, gambling or we're all zapping. It's a zapathon and we're like going nuts and we're all inside this arc. [01:22:02] Speaker A: We're sending 672 transactions in under ten minutes. [01:22:06] Speaker B: Well, then that is all amortizing 672. [01:22:09] Speaker A: Fees across a single update to the Ark pool. [01:22:13] Speaker B: So we're going one output to one output with 672 updates and now it's just one fee. [01:22:19] Speaker A: So if like the fee was 50. [01:22:20] Speaker B: Cent, well, then it's that divided by 672. But if we do that over a. [01:22:24] Speaker A: Four month, four week period and nobody's. [01:22:26] Speaker B: Really using it, well, then it sucks. It's nothing. It doesn't really help a lot from. [01:22:32] Speaker A: A cost savings perspective. [01:22:34] Speaker B: In other words, the bootstrapping problem is. [01:22:38] Speaker A: Very significant in Ark. [01:22:39] Speaker B: If you have few users and nobody's really using it that much, it doesn't really do anything for you. [01:22:46] Speaker A: Whereas a lightning channel can just kind of sit there indefinitely. [01:22:50] Speaker B: It's like, okay, it's not, it's not really hurting you, it's just not helping you. Now I have to admit I haven't. [01:22:58] Speaker A: Dug into coin pools in a while. [01:23:00] Speaker B: And I'm very sad because he hits a bit vm, which again BitVM doesn't really solve the one utxo per user limit. It's really just a channel construction which I thought when we had super testnet on and we had. Wait, was Burak on with that one? [01:23:22] Speaker A: Who was on with with him? [01:23:25] Speaker B: I feel really bad because super testnet didn't even create BitVM, it was somebody else. And I'm kind of giving super testnet. [01:23:32] Speaker A: Credit even though he was the first. [01:23:33] Speaker B: One who made something with it because. [01:23:36] Speaker A: That'S kind of his thing. He just, he just likes to hack. [01:23:38] Speaker B: Stuff together and then move on to. [01:23:39] Speaker A: The next cool project. [01:23:40] Speaker B: I'm really sorry for not remembering who that was, but BitVM there basically theorized that we could do this with a big group of people, but we don't. [01:23:52] Speaker A: Have a concrete way in order to do that. [01:23:54] Speaker B: So it's a little bit like, you know, sufficiently advanced TM covenants that sure. [01:24:00] Speaker A: We can do this with it if. [01:24:02] Speaker B: We can figure out how to do this with it, but we don't really know. Theoretically it makes sense, but we don't have a concrete, we don't have a real way to actually pull that off yet. BitvM, despite its kind of heftiness, like the fact that you're doing, you're essentially building programs in bitcoin script or in bitcoin signature, you're not even building programs, you're building hardware. You're like building hardware circuits in digital code. So it's like ten layers, inefficient from the context of like a programming language or what you're actually doing, but you're also kind of hard coding any arbitrary computation. And the idea would be to do this with ZK rollups or some cryptographic trick to essentially just prove that whatever. [01:24:53] Speaker A: Application you're running underneath it is running honestly. [01:24:57] Speaker B: And then that honest proof is then the thing that unlocks this kind of hefty signature requirement and that only with that can you unlock it. And thus you can basically enforce the ownership of something, or you can enforce the operation of any sort of network, maybe even like a cashew thing where you can still redeem your funds, or you can prove dishonesty, or the reverse, or honesty with a provider of some sort. So Bitviem is really cool, but it's one of those things that's like super theoretical in the sense that it's potentially so complicated to work with or has. [01:25:41] Speaker A: So many unknowns in its operation. [01:25:43] Speaker B: It's kind of like a hyper advanced lightning channel. Like, we may be able to just. [01:25:48] Speaker A: Build anything we want with it at. [01:25:50] Speaker B: Some point, but it's. There's so much. It's not low hanging fruit at all. There's so many things to get there. And in the naive implementation or the way that we think of it now, and the only way that we have seen it work is a one to one. So it's basically just a lightning channel. And at the end of the day, what else we really want to do in a lightning channel that we can't just do with the way lightning channels already work? So it's like, why don't we just build a really more inefficient and really more complicated way to do lightning channels when lightning channels already work? This, I think, is why it hasn't gotten a ton of research is because we kind of need something entirely novel. [01:26:29] Speaker A: To do with it. [01:26:30] Speaker B: And this is also why Peter Todd just kind of was like, this is a completely new thing with bit VM, but it doesn't really solve our scaling problem, which kind of the purposes of this is how do we make that one TxO per user thing solved? How do we. How do we solve that scaling limitation? And so it's just kind of like, well, we'll. We're just going to pass this off now. [01:26:54] Speaker A: Coinpool is one that. [01:26:58] Speaker B: I would really like to see more discussion, because coin pool is much more. [01:27:04] Speaker A: Much more similar. [01:27:05] Speaker B: Or much more in theoretical or mental. [01:27:09] Speaker A: Construction to the thing that I talked. [01:27:11] Speaker B: About before, where you have a group of 100 people and things can be updated and you can have individual transactions and virtual. Excuse me, individual channels and individual virtual. [01:27:23] Speaker A: Channels inside of this thing. [01:27:24] Speaker B: And you have a big pool of. [01:27:26] Speaker A: People that are basically aggregating all of these things. [01:27:29] Speaker B: And a nice feature or benefit of this is that it also grants a lot of potential for privacy. And the fact that basically chaining or tracing Utxos online, excuse me, on the chain no longer really tells you anything about any individual. And this is just conceptually, this is something that I've talked about numerous times on the show and I think is just kind of default. I think looking at the trajectory of all of this technology and where things. [01:27:57] Speaker A: Are going, and then also at the just unbelievable demand of the bitcoin system. [01:28:03] Speaker B: And what we will use it for, I just think it makes sense that every single Utxo will not be equated to a person. A UTxO will not even be equated to a channel that the majority of Utxos on the bitcoin network will be. [01:28:20] Speaker A: A network in itself. [01:28:22] Speaker B: A UtxO will be a transaction pool, a group of transactions, a group of people. [01:28:29] Speaker A: And only when things go wrong, only. [01:28:31] Speaker B: When trust needs to be the only when conflict occurs within these pools, do. [01:28:39] Speaker A: We then need a single Utxo to. [01:28:41] Speaker B: A person, which would then go back into another group, or a better pool. [01:28:46] Speaker A: That is now deemed trustworthy, or where the dishonest person has been evicted from the pool. [01:28:52] Speaker B: And I honestly think that's just kind. [01:28:55] Speaker A: Of philosophically and technologically where this is all going. And so the question is, how do. [01:29:00] Speaker B: We get there in the most trust. [01:29:02] Speaker A: Minimized way, in the most sovereign way. [01:29:05] Speaker B: Where enforcement, with the, the unbelievable assurance and immutability of a single Utxo per. [01:29:16] Speaker A: User, per balance, is essentially the ultimate. [01:29:20] Speaker B: Arbiter of what the truth is of who owns what. [01:29:24] Speaker A: So there is total sovereignty by enforcement. And during conflict, it can always be redeemed. And that enforces the honesty of all participants and of all signatures and of all transaction constructions. [01:29:39] Speaker B: That is the goal. Now, real quick, I just want to give examples of transaction pinning, because this gets a little bit specific. That is not entirely necessary. But just in case you're trying to wrap your head around this and understand what he means by it. The replacement cycling attack and transaction pinning. So basically how bitcoin transactions work, and with RBF involved, is that if you send a higher fee transaction, it will. [01:30:10] Speaker A: Replace the lower fee transaction. [01:30:11] Speaker B: So if I have a transaction from me to you, and it's got 100 sats on it for a fee, and it doesn't get confirmed, I can send. [01:30:22] Speaker A: That same transaction from me to you again with 200 sats as a fee. [01:30:27] Speaker B: And everybody who has a node can see that both of those transactions exist, and it will remove the one with 100 sats and replace it with the. [01:30:36] Speaker A: New one with 200 sats. Very simple, very straightforward. [01:30:40] Speaker B: However, the reason this doesn't always work and what transaction pinning does, especially when we're talking about like groups of people or something, is, let's say you have a transaction that's in a pool, or you're aggregating with a bunch of different people. And so my output to you is actually included in a transaction with a. [01:31:02] Speaker A: Hundred other outputs to 100 other people. [01:31:06] Speaker B: And the fee rate is really low. It's like one sat per v byte. And basically the only thing that's confirming. [01:31:15] Speaker A: Right now is five sats per v byte. [01:31:17] Speaker B: Well, the fact that the transaction is. [01:31:19] Speaker A: So huge, the fee for the total. [01:31:21] Speaker B: Transaction might still be like $2 or $5 or something like that because there's tons of inputs and outputs. [01:31:29] Speaker A: But the rate for my one output. [01:31:32] Speaker B: From me to your, or my input to your output might be just 100 sats or just 50 sats essentially allocated for my, the weight, the portion of. [01:31:45] Speaker A: Our transaction in the big one that. [01:31:47] Speaker B: Is actually related to us, which means that I would want to just add. [01:31:51] Speaker A: Make it 100 sats or 200 sats. [01:31:54] Speaker B: In order to replace my piece of that transaction. I can't do that. The simple replace by fee now weights. [01:32:01] Speaker A: It against the $5 fee for 100. [01:32:05] Speaker B: Inputs to 100 outputs versus my $1 or 50 cent transaction fee for the one, my one input to your one output. So unless I go back to the. [01:32:17] Speaker A: Entire group and we all rebuild this whole thing with a new fee that's. [01:32:23] Speaker B: Higher enough to actually get my transaction. [01:32:26] Speaker A: Confirmed, my transaction has been pinned. It's stuck there. And now for one input to one. [01:32:31] Speaker B: Output, I literally have to pay like 30,000 sats for that one transaction, even though that's way over the actual fee. [01:32:41] Speaker A: Rate to get it confirmed. Like I could do it with 100. [01:32:43] Speaker B: Sats, but I have been pinned down by this big transaction because I have to replace that one. Otherwise that's the, the, that one's going. [01:32:53] Speaker A: To stay in the mempool for a. [01:32:55] Speaker B: Really, really long time. Essentially that policy where I want all. [01:32:58] Speaker A: Of the nodes to see the new. [01:32:59] Speaker B: One and replace the old one isn't going to work because they're going to, it's going to look like the reverse. It's like, well, you were in this old transaction, you were paying me $5 in this new one, you're only paying me 100 sats when really it's the. [01:33:11] Speaker A: Fee rate that I have bumped up. [01:33:13] Speaker B: Not the fee itself. This is why Peter Todd says that the, the obvious solution to this is. [01:33:20] Speaker A: Replaced by fee rate RBFR. [01:33:24] Speaker B: And so nodes would just naturally look. [01:33:26] Speaker A: And be like, okay, well, you're paying a much higher fee for just your. [01:33:29] Speaker B: One input output than this 100 input to 100 output transaction is paying for like per your one input one output. [01:33:37] Speaker A: Therefore we're going to confirm yours before we confirm this giant thing over here. [01:33:42] Speaker B: And importantly without that actually encourages out of band fee like acquiring fees outside. [01:33:51] Speaker A: Of the network itself. [01:33:53] Speaker B: So if you're not actually publishing fees. [01:33:55] Speaker A: To the chain and miners are making. [01:33:57] Speaker B: Private agreements in order to confirm transactions, well then you actually, you threaten the. [01:34:04] Speaker A: Decentralized and open nature of the protocol itself. [01:34:07] Speaker B: You're making it more profitable to de decentralized, to recentralize, or to quote unquote, privatize or seclude the actual operation of. [01:34:19] Speaker A: The network itself, of the elements of the system. [01:34:22] Speaker B: So you want to get those that cost and that balancing back inside the cost of the system so that the. [01:34:29] Speaker A: Incentives are actually right. [01:34:31] Speaker B: So that all you have to do is broadcast to the chain and any miner can pick it up and it's. [01:34:36] Speaker A: Just going to be correct. [01:34:38] Speaker B: The, the highest fee is going to. [01:34:39] Speaker A: Be paid and the most profitable thing for the miner is to just participate in the system. [01:34:44] Speaker B: Now the replacement cycling attack is actually kind of similar to the transaction pinning, but it's a little bit more complicated. [01:34:51] Speaker A: Just because you're trying to do this. [01:34:52] Speaker B: In like a channel or something, like you're trying to screw somebody over by. [01:34:56] Speaker A: Disallowing them to, you're taking advantage of. [01:34:59] Speaker B: RBF in a malicious way. So if you aren't running, and really the solution to this is to just. [01:35:07] Speaker A: Keep rebroadcasting and run a fully full node. But when you have a channel with. [01:35:12] Speaker B: Somebody else and you basically pre sign an output with your transaction in it. [01:35:20] Speaker A: Or with your input in it, well. [01:35:22] Speaker B: What can actually happen is that if there is another input, which obviously your channel partner is going to have an input in this as well, because you both have the same, you both have this have the same channel. Well, you broadcast to the chain with. [01:35:39] Speaker A: Their other input in it and with a particular fee, let's say it's 100 sats. [01:35:44] Speaker B: And then you just wait. [01:35:44] Speaker A: You're waiting for it to confirm. Well, because of that extra input in. [01:35:49] Speaker B: There, that transaction can actually be replaced in the mempool, can actually make other nodes delete it without you knowing, by. [01:36:00] Speaker A: Spending that out that input in a. [01:36:02] Speaker B: Different way, without those transaction details, without your exit. So let's say we've got your individual input, then the other party's just kind of random input and then your output. And you're trying to get your point. One bitcoin and that other endpoint is just like another 0.1 bitcoin that just goes to them or is just like arbitrarily sent somewhere. It doesn't really matter. [01:36:28] Speaker A: Well, you are going to be watching for your output, for your transactions, specifically your transaction details. Specifically that other input doesn't really matter to you. [01:36:36] Speaker B: It's just been included in the transaction. However, if they respond that input with a higher fee, without including all of your other transaction details, well, it's actually going to replace your transaction that you're. [01:36:52] Speaker A: Trying to redeem because theirs has a higher fee. [01:36:55] Speaker B: They're going to pay 200 sats or. [01:36:56] Speaker A: 300 sats in order to get their transaction in there. [01:36:59] Speaker B: It's going to replace it in everybody else's mempool for, you know, the transactions. [01:37:03] Speaker A: That are just waiting in line to be confirmed because like, oh, well, this. [01:37:05] Speaker B: One'S got a higher fee, so we don't want this old one anymore. [01:37:08] Speaker A: But your redemption is no longer in it. So now you have to rebroadcast again. [01:37:14] Speaker B: And this fight basically goes back and. [01:37:16] Speaker A: Forth, back and forth. And what they are trying to do. [01:37:18] Speaker B: Is trying to continue to amp up that fee over and over again so that your fee, your redemption basically doesn't get in a block before the time lock runs out. So if the time lock on like. [01:37:33] Speaker A: An HTLC is like 4 hours or. [01:37:35] Speaker B: Something, they are constantly doing this over. [01:37:37] Speaker A: And over and over again for 4. [01:37:39] Speaker B: Hours in order to prevent your redemption from getting confirmed. Because if they can prevent it for that 4 hours, well then suddenly the. [01:37:49] Speaker A: The old redemption, the dishonest version, is. [01:37:53] Speaker B: Now valid because of that four hour time lock expiring. [01:37:56] Speaker A: And so then it just becomes a race of who can get their transaction confirmed the fastest. [01:38:01] Speaker B: Because now both the old state and. [01:38:04] Speaker A: Your rightful ownership of the latest are. [01:38:07] Speaker B: Valid at the same time because they. [01:38:09] Speaker A: Managed to prevent you from. [01:38:13] Speaker B: Getting yours. [01:38:14] Speaker A: Confirmed during the time lock window, which. [01:38:17] Speaker B: Is your right to the time window for the honest transaction to get confirmed before somebody tries to commit fraud or tries to cheat you out of it. And so if you don't, if you're not watching, if you don't have a. [01:38:28] Speaker A: Full mempool and you don't have a full node watching the entire blockchain and. [01:38:31] Speaker B: Watching for those other outputs or other. [01:38:35] Speaker A: Inputs to being replaced, and see that. [01:38:38] Speaker B: That transaction actually dropped from the mempool entirely and you're just running a light client or a mobile client or something like that. Well, that can be done to you and you're just like sitting around waiting, why isn't this thing getting confirmed and it's not obvious, and then you can like look it up on Mempool or. [01:38:53] Speaker A: Memple space or any blockchain explorer and you're like well, where the hell's the transaction? What happened to it? [01:38:59] Speaker B: It just looks like there's no obvious reason that something went wrong, but it's also pretty easy to mitigate. [01:39:05] Speaker A: As Peter Todd said, in this thing. [01:39:06] Speaker B: You just kind of keep rebroadcasting the. [01:39:09] Speaker A: Cost to the attacker is the constant ramping up of the fee to keep. [01:39:13] Speaker B: Getting it kicked out. So these are just ways to kind of exploit the natural incentives of miners and the open rules of the, of. [01:39:24] Speaker A: The mempool, which the mempool doesn't actually exist. [01:39:26] Speaker B: It's just kind of a policy on top of bitcoin clients. Like in bitcoin itself, it doesn't actually exist. It's an abstraction of just the broadcasting of transactions and how to keep them and until you're ready, until they're ready to be confirmed. But that's really kind of beside the point. [01:39:44] Speaker A: These are just ways to exploit that. [01:39:47] Speaker B: In order for the seemingly most profitable path to actually not be the honest path in some way, shape or form, but also the situations and the parties that you have to be interacting with have to kind of be like, the. [01:40:05] Speaker A: Situation has to be pretty specific for. [01:40:07] Speaker B: These problems to occur. But absolutely, they could occur. And it is exploiting the, quote unquote, best path for the miners and the bitcoin system itself in order to actually make a dishonest layer two state get. [01:40:27] Speaker A: Confirmed before the honest one. So it's important to consider and actually. [01:40:31] Speaker B: You know, fix ends, consider these exploits. [01:40:35] Speaker A: In how these things are designed. [01:40:36] Speaker B: And it does, how they are designed. And it does seem like RBFR seems to kind of be the, that doesn't quite, that doesn't really work for replacement cycling. Replacement cycling is kind of different, but. [01:40:48] Speaker A: Just at least for the transaction pinning. [01:40:50] Speaker B: Attack, I mean, it does seem pretty obvious that that's the simplest, simplest construction and this the most naive interpretation of. Yeah, just, just go by the fee rate per byte of how much somebody is paying and then have that replace any older transaction. So anyway, let's see, is there anything else to replacement cycling feature? Nope, that was, that was basically it. So hopefully, hopefully I kind of went over a lot of the basic ideas here to kind of paint a picture and if nothing else, just kind of refresh the idea so that we can get into actual software proposals and the different pieces of the different op codes and things that will enable these things and what they will do, what their potential risks are. And we will finish with part two. I believe it will be this Friday. [01:41:46] Speaker A: If I'm not mistaken. [01:41:50] Speaker B: I'll. Yeah, it should, it should be this. [01:41:53] Speaker A: Friday, but it'll be the next read episode. [01:41:55] Speaker B: So just stay tuned. [01:41:57] Speaker A: And I will also probably have this. [01:41:58] Speaker B: One available just as a flat audio for anybody who wants to listen to it somewhere. I'll figure it out and I'll let you know, in the show notes or in the description of the episode so that you can get it without all. [01:42:10] Speaker A: The commentary if you want and you. [01:42:11] Speaker B: Just want to refresh or read this article, maybe I'll actually just send it. [01:42:15] Speaker A: To Peter Todd and he can just. [01:42:15] Speaker B: Put it on the link itself so you can listen to it that way. But anyway, that'll wrap us up for today. Stay tuned for part two because we go even deeper and there's a lot of extremely important information and I love this. [01:42:30] Speaker A: This is such a good overview. And a shout out to Folger ventures. [01:42:33] Speaker B: For sponsoring this, for basically commissioning, to. [01:42:37] Speaker A: Have this full review put in place. [01:42:39] Speaker B: Because these are the important discussions. This is how we. [01:42:44] Speaker A: Spread this information to the community, to everybody, so that. [01:42:47] Speaker B: People understand what the point of all. [01:42:49] Speaker A: Of this stuff is, what the goals. [01:42:51] Speaker B: Are and what creates or what gets us closer to those goals, and what. [01:42:57] Speaker A: Potential risk or drawbacks each one has. [01:43:00] Speaker B: So shout out to them for making this possible. And a shout out to coinkite for. [01:43:05] Speaker A: The cold card, hardware wallet and the many amazing bitcoin tools that they have available. [01:43:09] Speaker B: Don't forget my discount code link and. [01:43:12] Speaker A: Details are right in the show notes. [01:43:13] Speaker B: And a shout out to everybody who boosts on fountain, who leaves me a note on Noster, who responds, who zaps and who does value for value. Thank you so much. I appreciate it more than you know. You help make this work. With that, I will catch you on the next episode of bitcoin audible and until then, everybody take it easy guys. [01:43:51] Speaker A: The bitcoin protocol can encompass the global financial transaction volume in all electronic payment systems today without a single custodial third party holding funds or requiring participants to have anything more than a computer using a broadband connection. Joseph Poon entaj dryja the Lightning whitepaper.