Read_844 - Soft Fork, Covenant Review - Part 2

[00:00:00] Speaker A: An argument for doing a consensus cleanup soft fork first, prior to enabling any new opcodes or other features for new types of l two s, is that we learn more about how willing the wider community is to implement what should be a relatively uncontroversial soft fork that arguably benefits everyone. The best in bitcoin made audible I am Guy Swan, and this is bitcoin audible. What is up, guys? [00:00:48] Speaker B: Welcome back to bitcoin Audible. I am Guy Swan, the guy who has read more about bitcoin than anybody else you know. And this show is brought to you. [00:00:55] Speaker A: By coinkite and the cold card hardware wallet. [00:00:58] Speaker B: Get one, get a discount. The discount code is right in the show notes. [00:01:01] Speaker A: Get a cold card to protect your. [00:01:03] Speaker B: Coins to know that you own bitcoin and we are diving back into part two of Peter Todd's recent Fulgur ventures funded or sponsored breakdown of the analysis. [00:01:17] Speaker A: Of the soft fork and covenant proposals for l two s. And this is. [00:01:22] Speaker B: Where he gets far more specific with the actual tools and variations, how they are used, their trade offs, the analysis on what the benefit and drawbacks of each are, and then specifically, and I think most importantly is how realistic and concrete the proposal actually is for getting. [00:01:47] Speaker A: Support and actually for being soft forked in. [00:01:49] Speaker B: Because, you know, we can generalize and we can come up with ideas all day long, but what's the likelihood of any of this actually happening? And what would the path forward be if we were actually going to get one of these things? [00:02:05] Speaker A: What's the safest and most realistic approach according to the analysis in this article? [00:02:11] Speaker B: So I think this is a really important conversation to have. It does get technical. There is explicit jargon in this, and. [00:02:19] Speaker A: If you haven't listened to part one, you're going to be very confused because part one is all of the definitions. [00:02:25] Speaker B: And reference for why we are talking about these, what's possible with them, and. [00:02:32] Speaker A: Then this is the analysis of the. [00:02:34] Speaker B: Actual proposals and which part they play and everything that we covered in part one. So please go back and listen to part one unless you already have a framework and you just wanted to listen to this part. This is jumping in on section five of the article, which you will find. [00:02:48] Speaker A: Right down there in the show notes. [00:02:50] Speaker B: If you want to follow along or. [00:02:52] Speaker A: Go to explore all the links. He has references for all of this. [00:02:55] Speaker B: Stuff, so you can do some deep diving of your own if you would like. With that, let's go ahead and jump into part two of Peter Todd's softwork covenant dependent layer two review. [00:03:09] Speaker A: Jumping in on the section titled section five feature patterns and soft forks. Now that weve given you an overview of the variety of covenant dependent l two systems out there and mempool challenges, were going to try to distill that information down to a set of notable softwork features, mainly new opcodes and design patterns that these l two systems share. For softwark proposals, we'll also discuss the proposal, specific technical risks and challenges of getting each proposal deployed. Section 5.1 op expire we'll get this out of the way first. Op expire was proposed as a simple way of eliminating the replacement cycling attack by fixing the problem at the source, the fact that htlcs can be spent in two different ways at once. In the context of l two systems, this is relevant for anything using an HTLC like mechanism and possibly other use cases, Op expire would make it possible for a transaction output to be unspendable after a point in time, allowing the HTLC spending conditions to be a true exclusive or rather than a programmers or an actual op expire soft fork would most likely consist of two features similar to how the op check locktime verify and op check sequence verify opcodes come in two parts, one, an expiration height field for transactions most likely implemented in the taproot annex, and two, an op expire opcode that checks that the expiration height is set to at least the desired height. While Op expire itself barely qualifies as a covenant, it does appear to be useful for many covenant dependent l two systems. However, it may not be useful enough. [00:05:03] Speaker B: Given that replacement cycling can also be. [00:05:05] Speaker A: Mitigated by altruistic rebroadcasting. A very notable challenge with deploying and using Op expire is reorgs. The bitcoin technical community, starting with Satoshi, has tried to ensure that the bitcoin consensus protocol is designed in such a way that after a deep reorg, previously mined transactions can be mined into new blocks. This design principle attempts to avoid the nightmare scenario of a large number of confirmed coins becoming permanently invalid, and thus people relying on those coins losing money if a consensus failure leads to a large reorganization. In the event of a large reorganization, transactions using expiration could become unmineable due to their expiry height being reached. The op expire proposal proposes to mitigate this issue by treating the outputs of expiration using transactions similarly to Coinbase transactions, also making them unspendable for about 100 blocks. A significant barrier to deploying transaction expiration is coming to consensus on whether or not this trade off is acceptable or even needed. The types of transactions where Op expire would be useful already involve long ish timeouts where user funds are frozen. Adding even more time to these timeouts isn't desirable. Also, double spins have always been another way to invalidate coins after a reorg. With the increased use of RBF and proposed use of keyless anchor outputs, would transaction expiration make a significant difference? Section 5.2 sig hash iniprev outd BIP 118 proposes two new signature hashing modes, both of which do not commit to the specific utxo being spent. Sigh hash any prev out or any previous output which essentially commits to the scriptPubkey instead, and Sigh hash any prev out, any script which allows any scriptural as discussed above, this was originally proposed for use by Ln symmetry to avoid the need to separately sign every single prior channel state that may need to be reacted to. Sigh any prev out is also potentially useful in cases where we want to use pre signed RBF fee rate variance in conjunction with pre signed transactions, as. [00:07:36] Speaker B: The fact that the signature no longer. [00:07:38] Speaker A: Depends on a specific TxID avoids a combinatorial explosion of fear rate variance. However, the current bit 118 proposal doesnt. [00:07:46] Speaker B: Address this use case and may be. [00:07:48] Speaker A: Incompatible with it due to the fact that sigh any prev out is proposed to also commit to the value of the Utxo. An initial objection to sigh any prev out was the idea that wallets would get themselves into trouble by using it in inappropriate ways. The issue is that once a single sigh any prev out signature has been published, it can be used to spend any output with the specified script. Thus, if a second output with the same script is accidentally created, sigh any prev out allows for a trivial replay. [00:08:21] Speaker B: Attack to steal those coins. [00:08:23] Speaker A: However, as there are so many other foot guns inherent to wallets and l two implementations, this concern seems to have died out. At the moment, the general technical community seems reasonably positive about implementing BIP 118. However, as discussed above in our discussion of ln symmetry, there is debate about whether its main use case, ln symmetry, is actually a good idea. Section 5.3 op check template verify or CTV our first covenant specific opcode proposal, op check template verify or CTV as its commonly referred to, aims to create a very specific restricted covenant opcode by doing exactly one hashing the spending transaction in a specified way that does not commit to the input utxos and checking the resulting digest against the top stack element. This allows the spending transaction to be constrained in advance without making true recursive covenant restrictions possible. Why aren't recursive covenants possible in CTV because hash functions the CTV checks the spending transaction against a template hash, and theres no way of creating a template containing a CTV with a hash of itself. That said, this isnt necessarily a real limitation. You can easily hash a chain of CTV template hashes to a depth of tens of millions of transactions in just a few seconds on a modern computer with relative in sequence timelocks and the limited block size, actually reaching the end of such a chain could easily be made to take thousands of years. The current CTV proposal in BIP 119 has only one hashing mode known as the default check template verify hash, which essentially commits to every aspect of the spending transaction in the template hash. From a practical point of view, this means that in many circumstances, the only available mechanism for fee payment will be child pays for parent. As mentioned above, this is a potential problem due to it making out of band fee payment a non trivial cost savings in cases where the CTV using transactions are small. It's fair to say that CTV has the broadest support among the technical community of any covenant opcode proposal because of its relative simplicity and wide range of use cases. L enhance one proposal to implement CTV is to combine it with two more. [00:11:00] Speaker B: Op checksigfromstack and of Op internal key. [00:11:07] Speaker A: The problem is, as of writing, the documentation in that pull request and associated bips simply isn't sufficient to argue for or against this proposal. The bips are entirely lacking any rationale for what the opcodes are expected to actually do in real world examples, let alone in depth example scripts. While the authors probably have good reasons. [00:11:26] Speaker B: For their proposal, the onus is on. [00:11:28] Speaker A: Them to actually explain those reasons and justify them properly. Thus, we won't discuss it further. Section 5.4 op TX hash similar to CTV, this proposal achieves a non recursive. [00:11:45] Speaker B: Covenant functionality by hashing data from the spending transaction. [00:11:50] Speaker A: Unlike CTV, the TX hash proposal provides. [00:11:54] Speaker B: A field selector mechanism allowing flexibility in. [00:11:58] Speaker A: Exactly how the spending transaction is constrained. This flexibility achieves two main goals, one enabling the addition of fees to a transaction without breaking a multi transaction protocol, and two multi user protocols where users. [00:12:14] Speaker B: Only constrain their own inputs and outputs. [00:12:18] Speaker A: The main problem with OptX hash is that the field selector mechanism adds quite a lot of complexity, making review and testing challenging compared to the much simpler CTV proposal. [00:12:31] Speaker B: At the moment, there simply hasnt been. [00:12:33] Speaker A: Much design analysis on how beneficial the field selector mechanism would actually be or how exactly it would be used. Thus we wont discuss it further. Section 5.5 OpCat the concatenation operator that concatenates the top two elements of the. [00:12:54] Speaker B: Stack and pushes the concatenated result back on the stack. [00:12:58] Speaker A: Bitcoin originally shipped with OpcaT enabled, but Satoshi quietly removed it in 2010, probably due to the fact that the initial implementation was vulnerable to DOS attacks due to the lack of restrictions on the size of the resulting script element. Consider the following Dup cat Dup cat without an element size restriction, each Dup cat iteration doubles the size of the top stack element, eventually using up all available memory. Concatenation is sufficient to implement many types of covenants, including recursive covenants, by doing the following one assemble a partial transaction without witness data on the stack with one or more invocations of OPCAT and whatever covenant specific logic is needed. [00:13:46] Speaker B: Two validate that the transaction on the. [00:13:49] Speaker A: Stack matches the spending transaction. As it turns out, by abusing the math of schnorr signatures, it's possible to perform the second step with Opchecksig via carefully constructed signatures. [00:14:03] Speaker B: However, its more likely that an opcat. [00:14:05] Speaker A: Soft work would be combined with Opchecksig. [00:14:07] Speaker B: From stack, allowing the second step to. [00:14:09] Speaker A: Be performed by validating that a signature on the stack is a valid signature. [00:14:13] Speaker B: For the transaction, and then reusing the. [00:14:15] Speaker A: Same signature with Opchecksig to validate that the spending transaction matches. The fact that we only need to assemble the transaction without witness data is a key point. The covenant only needs to validate what the transaction does, its input and outputs, not the witness data, if any, that. [00:14:34] Speaker B: Actually makes it valid. [00:14:36] Speaker A: Modulo script size limits the combination of OpcaT and opchexig from stack is sufficient to build many types of covenants, including recursive covenants. Compared to more efficient solutions like CTV, it is more expensive, but the difference in cost is less than you would expect. Roughly speaking, using OpCAT to do this requires all of the non witness part of the spending transaction to be placed on the stack via the witness. For typical CTV use cases such as. [00:15:05] Speaker B: Transaction output trees, the spending transaction will. [00:15:08] Speaker A: Have no witness data at all. Since witness space is discounted 75%, that increases our effective transaction fee for the. [00:15:16] Speaker B: Child transaction by only 25%. [00:15:20] Speaker A: Not bad. Is opcat too powerful? This is probably the biggest political and technical obstacle to deploying OpcAT. It's very hard to predict what use cases will be made possible by Opcat. [00:15:37] Speaker B: And once the cat is out of the bag, it's very hard to put it back in. [00:15:42] Speaker A: A great example is how OpcAt is claimed to be sufficient to allow reasonably efficient and secure stark verification implemented in bitcoin script. Since starks are capable of proving extremely general statements, making it possible to implement. [00:15:59] Speaker B: Starks efficiently has significant ramifications that go. [00:16:03] Speaker A: Beyond the scope of l two systems, as it would allow many different systems to be built on top of bitcoin. A strong argument against Opcat is that these use cases may not be, on the whole, good for bitcoin users. The creation of harmful centralizing minor extractable value is a key potential problem termed MeV, that is evil or mevil. [00:16:26] Speaker B: By Matt Corallo in short, Meevil is. [00:16:30] Speaker A: Any circumstance where large miners or pools can extract additional value by employing sophisticated transaction mining strategies beyond simply maximizing total fees that are impractical for smaller miners or pools to adopt. The sheer complexity of potential financial instruments that could be created with Opcat makes. [00:16:51] Speaker B: Ruling out mevil very difficult. [00:16:54] Speaker A: Significant mevil has already appeared on bitcoin from token auction protocols. Fortunately, that specific case was defeated via the adoption of full RBF. In addition to the potential of mevil, there are many other concrete OpCAt use cases that are potentially harmful. For example, the drive chains proposal has been reviewed here and is widely considered to be harmful to bitcoin. It is believed to be possible to implement drive chains with OpCAT. Another example is token proposals such as taproot assets. While it is impossible in general to prevent them from being implemented with client side validation, there are proposals to implement them with OpCAT in ways that are potentially much more attractive to end users, while also using much more block space, which could potentially outbid legitimate bitcoin transactions. These use cases may also raise legal issues due to how often token protocols are used for financial fraud. Section 5.6 incremental hashing for covenants, OpCAT would be primarily used to concatenate data and then hash it. Another way to achieve this same goal is with some kind of incremental hashing opcode that takes a SHA 256 mid state of some kind and hashes more data into it. SHA 256 itself operates on 64 byte blocks. There are many possible designs for incremental hashing opcodes. One important design decision is whether or not to expose the actual mid state bytes on the stack in some kind of canonical form, or represent them in. [00:18:34] Speaker B: Some new kind of opaque stack item type whose actual byte value can't be directly manipulated. [00:18:41] Speaker A: SHA 256 is specified for a particular fixed initialization vector, and it appears to be unknown whether or not SHA 256 cryptographic properties hold true if arbitrary mid states or initialization vectors are allowed. Of course, since incremental hashing can do. [00:18:58] Speaker B: Pretty much what OpCAT can do just more efficiently. [00:19:02] Speaker A: It shares all of the concerns about OpCAT being too powerful. Section 5.7 script revival OpCAt was one of 15 opcodes that Satoshi disabled. In addition to restoring OpCAT, Rusty Russell is proposing to essentially restore bitcoin scripts to Satoshi's original vision by re enabling most of those opcodes, adding DOS limits, and potentially adding a few more in the same soft fork. In particular, an op checksig from stack is likely. While Opcat alone does not make recursive covenants possible, a full script revival would make more sophisticated covenants possible and much easier to implement, as parts of the spending transaction could be manipulated directly. For example, you could imagine a covenant script that uses arithmetic opcodes to ensure that the total value of the transaction outputs in the transaction adheres to some desired property. Again, script revival raises all the same concerns, and more about being overly powerful that Opcat alone does. Simplicity similar to script revival, simplicity is relevant to l two s and covenants. [00:20:25] Speaker B: By making it possible to do anything. [00:20:28] Speaker A: Unlike script revival, a simplicity soft fork would add an entirely new programming language to bitcoin's scripting system based on nine primitive operators known as combinators. In practice, simplicity is both too simple and not simple at all. The primitive combinators are so ridiculously low level that basic operations like addition have to be laboriously implemented from scratch. Raw simplicity would be exceptionally verbose in practice. Thus, any real usage of simplicity would make use of a system of code substitutions similar to library function calls, known as jets. This poses a practical or political problem. How do you decide on which jets to implement? Most likely, jets would be implemented in c like any other opcode, requiring a soft fork for each new jeth section 5.8 fancy tree manipulation stuff there's a large variety of relatively specialized opcodes that have been proposed to do tree manipulation in a space efficient manner for covenant dependent l two proposals. For example, the coin pools have proposed. [00:21:44] Speaker B: Both tap leaf update verify and op. [00:21:48] Speaker A: Merkle sub, both of which manipulate taproot trees in ways necessary for the coin pools proposal. And the mat proposal has proposed an op check contract verify opcode that basically verifies statements about Merkle trees. For the purposes of this article, we don't need to go into detail about each one of these many proposals. Rather, we can talk about them as a group. They're all relatively use case specific proposals. They make one class of layer two possible, ideally without unintended side effects. They all have the advantage of efficiency. They all use less block space than achieving the same goal with more generic opcodes such as Opcat manipulation, but they all have the disadvantage of adding complexity to the script system for a potentially niche use case. The same dynamic would happen if bitcoin adopted the simplicity scripting system. The equivalent to opcodes in simplicity is adding a jet for a commonly used pattern. Again, implementing jets for use case specific operations like tree manipulation has similar pros and cons as implementing complex opcodes for use case specific operations section six fund pools all l two systems that try to have multiple users share a single UTxo can be thought of as some kind of multi user fund pool, with users being in possession of some kind of right of withdrawal. Potentially there will also be a mechanism to add funds to the pool beyond creating the pool with funds pre assigned. For a fund pool to be useful, it must have some kind of share data state associated with it. How is the TX output value split up? If the fund pool is to evolve over time, that state must also change as funds are added or removed from the pool. Since we're building on bitcoin, adding or removing funds from the pool will inevitably involve spending the UTxo the pool controls. Remember that the bitcoin consensus system itself is based on validation of state changes. Transactions prove via their witness that changes to the Utxo set state are valid. Proof of work lets us come to consensus over which set of transactions is correct. This means that fund pools are themselves also going to be based on validation of state changes. Were proving to every bitcoin node that the rules for the fund pool are being followed on every state change. But theres another key aspect to trustless l two fund pools. When the state of the fund pool changes, the system must inherently publish sufficient data for users participating in the fund pool to recover their funds. If we havent done that, then our. [00:24:45] Speaker B: System fails to provide unilateral withdrawal without. [00:24:49] Speaker A: The cooperation of third parties. Many roll up based schemes fail here. They suffer from data availability failures where the user is unable to recover their funds if third party coordinators go offline because they have no way of getting the data necessary for them to construct a valid fund recovery transaction. With these constraints in mind, what data structures are fund pools going to be based on? Inevitably theyre all some kind of tree, specifically some kind of merkle tree. They have to be a tree because. [00:25:26] Speaker B: Thats pretty much the only scalable data. [00:25:28] Speaker A: Structure in computer science. They have to be merkelized because thats basically the only reasonable way to cryptographically commit to the state of the tree. Finally, updates to the tree are inevitably going to be published to the bitcoin blockchain because thats the one publication medium that all layer two users share and the only one that we can force users to publish on to move coins. And because any covenant implementation is going. [00:25:54] Speaker B: To need parts of the tree to. [00:25:56] Speaker A: Validate that the rules of the covenant are being followed. So with the high level theory out. [00:26:02] Speaker B: Of the way, how does this actually. [00:26:04] Speaker A: Translate into bitcoin scripts and transactions? Section 6.1 individual pre signed transactions the degenerate case of a tree with exactly one leaf in it. Here the state of our fund pool can change state. Roughly speaking, once, for example, a standard. [00:26:26] Speaker B: Lightning channel falls into this category and. [00:26:29] Speaker A: Once opened can only be closed. The data that is published when a channel is closed is the transaction itself, which is sufficient information for the counterparty in the channel to learn the TxID from blockchain data and recover their funds by spending them. The only covenant required here is the most basic covenant, the pre signed transaction section 6.2 TX out trees the next more complex design pattern we see in fund pools is the TX out tree or transaction output tree. Ark is a notable example here. The fund pool can be split up by spending the root Utxo in a tree of predefined transactions enforced with simple covenants like pre signed transactions or CTV, splitting up the value of that Utxo into smaller and smaller amounts until leaf nodes are reached that are spendable by the rightful owners. It's important to recognize that the purpose of the TX out tree is to give users options as to how to recover their funds, and those options come at a cost. A TX out tree will always be a more expensive way to split up a pool of funds, returning them to their owners, than simply splitting up the Utxo in a single transaction. Each layer in the tree adds cost because of the bytes used in the Tx outs and Tx inshore necessary to create that layer. So what kind of options might a Tx out tree provide? Again, arc is a great example. We don't want the on chain redemption of a single vutxo to require every vutxo to be put on chain. By using a tree redemption can instead split up the tree into smaller parts until the desired vutxo is put on chain. Similar to the individual pre signed transaction case, the information being published is the transactions themselves, which informs other users wallets how to spend their funds if necessary. The scalability of TX out trees has interesting economies of scale. The cost for the first vutxo to be put on chain in a fund. [00:28:41] Speaker B: Pool with nvutxos is roughly log two. [00:28:46] Speaker A: Of n times more expensive than a single transaction, as log two of n levels of split transactions must be put on chain. However, once the first vutxo is put on chain, subsequent vutxos become cheaper to redeem on chain because someone else has already paid the cost of getting the intermediary transactions mined. Recall that the total number of elements in a binary tree within leaves is two n. This means that to put all vutxos on chain, the total cost to do so via a TX out tree would be a small multiple of the total cost to do so in a single transaction. Surprisingly efficient, or maybe not. If the total size of the fund pool redemptions are sufficiently high, they may represent a non trivial demand on total overall block space. Block space is a supply and demand system, so at some point fees will go up due to high demand. At the extreme, it's quite possible to create TX out trees so big and so deep that actually redeeming every vutxo in the tree is impossible. An open question with TX out trees is who pays the fees and how? One obvious solution is to use keyless anchor outputs on the leaf transaction and allow whomever wants the leaf transactions to get mined to pay the fees via CPFP or child pays for parent. In some use cases, the vutxos themselves can be spent immediately after creation without a CSV or check sequence verify delay, so the vutxos themselves could be spent to add fees to via child pays for parent. RBF is complex to implement due to permission. The obvious place to take fees for RBF from is the vutxo value, but how do you ensure that only the owner has the ability to sign for a higher fee transaction? In many circumstances, it's not obvious how to do this in a way that is more efficient than a keyless anchor output. However, failing to do that does pose serious challenges for schemes used by end user wallets that may not have a Utxo to spend to perform a CPFP if the vutxos themselves can't be spent immediately. Finally, careful thought needs to be put into what incentives there are in TX out tree systems taking fee payments into account. For example, in an arc like system, if a set of vutxos individually cost too much money to be worth taking to on chain vutxos, an uncooperative coordinator could refuse to allow those vutxos to be redeemed off chain and then make a profit by stealing the value of those vutxos in a single utxo spend once a timeout is reached. If this is the case, arguably such a system would fail our criteria to be an l two for small virtual utxos. Section 6.3 balance based schemes the state machine of a TX out tree is still relatively simple. Either the fund pool exists or it is spent to create two or more smaller fund pools with more advanced covenants. We could instead treat the fund pool as an evolving balance with the ability to add and subtract funds from that balance. To do this, we need to implement a non trivial state machine, but we also need what is essentially a shared database. Why? Because the goal here is to share one utxo across many different owners. Finally, if we're actually going to get a scalability improvement, we must do so in a way that puts as little as possible of that ownership data on chain these requirements inherently lead us to some kind of tree like merkelized data structure, such as a Merkel sum tree. Manipulating that data structure is inherently going to require something like OpCAD, some kind of zero knowledge proof verification opcode, or a purpose specific tree manipulation opcode. Interestingly, as in TX out trees, you cant do better than order log in scaling while maintaining similar security properties. Why? Lets suppose we had a hypothetical op ZKP or zero knowledge proof, which through some advanced mathematics needed a mere 32 bytes to prove any statement. While this ZK proof could prove that the mercurys data structure had been manipulated according to the rules of the layer two system, it would fail to provide the data necessary for the next user to also make a state change. This fails our preferred criteria of enabling unconditional withdrawal. At best, one user might be able to achieve an unconditional withdrawal, but no further users could do so. By contrast, if the modified parts of the merkelized data structure are published via the covenant script Sig, for example, the sibling digests in a Merkle tree. The next user has enough data to update their understanding of the system state and themselves make an unconditional withdrawal. A potential way around this problem is if the covenant requires proof of publication on a different publication medium than the bitcoin chain, however, the security guarantees will be weaker than is possible via bitcoin. Finally, notice how Tx out trees and a balance based approach can be combined. If the data structure being manipulated is a Tx out tree, funds could be added to the txout tree by spending the output and adding new funds with a covenant script that validates that the funds were in fact added to the txout tree. Equally, funds can be removed by all the mechanisms normally available to a Txout tree. Advanced arc is an example of this class of scheme. Section seven failure data ratio l two s achieve scaling by adding an interactivity requirement in adversarial situations. In nearly all cases, this means that honest parties in the protocol have deadlines by which they need to get transactions mined. If the deadlines are not met, funds can be stolen. The maximum block capacity in all decentralized and centralized blockchains is limited by technical constraints. In bitcoin, the maximum block size is such that bitcoin operates essentially at capacity 100% of the time. Since bitcoin mining acts as an auction system, auctioning off block space to the highest bidder. In practice, this means that the minimum fee rate to get a transaction mined goes up and down as demand increases and decreases. Fearate always factors into l two economics and failure modes. For example, in lightning dust sized htlcs that are too small to be profitably redeemed on chain use a different security model than larger htlcs. While the lightning protocol doesn't properly implement this yet, in theory this threshold should be dynamic based on fee rates as they go up and down, ideally to the point where a party could choose whether or not an HTLC even exists in a given commitment transaction based on fee rate. A variety of attacks have been proposed where this situation is intentionally triggered on lightning such as flood and loot and the mass exit attack. Since bitcoin blockchain capacity is shared across all use cases, attacks between different l two systems are also possible, for example triggering a mass exit on ark to profit from lightning channels l two s that share Utxos amongst multiple users inherently make these problems potentially worse as the worst case, block space demand during a failure is proportionally higher. As of writing, weve never actually seen large scale failures on lightning where large numbers of channels had to be closed at once. Theres a good argument that we should get additional operational experience with lightning and its approximately one Utxo per user scaling before pushing the limits even further with Utxo sharing schemes. Secondly, before new Utxo sharing schemes are widely adopted, careful research should be done on the potential profitability of attacks during high demand for block space. For example, in a system like Ark where the ASP can redeem funds using much less block space than other parties, it may be the case that intentionally triggering high fee rates and then seizing funds that cant be profitably unilaterally withdrawn is a profitable fraud, violating both our conditions. For a true l two system. Section eight consensus cleanup there's a number of things that Satoshi got wrong in the initial bitcoin protocol, in particular, scripting DOS attacks, the time warp attack, and issues with the merkle tree. Previously, a number of other consensus bugs have already been fixed with sawforks, such as the switch to evaluating time based in lock times against the median time past attempting to fix the duplicate transaction id issue, et cetera. The most recent software, Taproot, had a relatively contentious deployment process, taking quite a long time to actually get deployed. An argument for doing a consensus cleanup soft fork first, prior to enabling any new opcodes or other features for new types of l two s is that we'd learn more about how willing the wider community is to implement what should be a relatively uncontroversial soft fork that arguably benefits everyone. Section nine testing soft fork dependent l two s developers do not need to wait for a soft fork to actually happen to test out their ideas. One particularly sophisticated approach being used by the Ark developers in covenantless Ark is to simulate the covenants they need with pre signed transactions. This allows them to test out the ideas of Ark with real bitcoin on Mainnet with the same trust characteristics as Ark is expected to achieve with covenants. The tradeoff is that covenantless Ark requires all parties to be online to sign the pre signed transactions. Since Cl Ark does work with real BTC, it may prove to even be useful enough to use in production for certain use case transfers that can tolerate the interactivity trade off. A simpler approach is to simply pretend that certain parties can't do the actions that covenants would prevent. For example, if a proposed protocol wants to use CTV to enforce that a tx out tree is spent in a transaction tree, each use of CTV could be replaced with a no op or checksige, while in reality the txtree isnt actually being enforced, every bit of code interacting with the tree and each party can be tested as though it is. And since Nop and Cig are allowed in standard scripts, the protocol can be tested on mainnet with real funds. Section ten potential soft forks whats the path forward here? Were going to chart out all the main l two schemes that weve analyzed, and what soft forks are useful are to make these l two schemes successful. As discussed above, OpCAT and by extension script revival which includes OpCAT, can emulate all of the other soft forks in this list, with the exception of op expire and fee sponsorship. So where a projects needs are most efficiently met by some other soft fork directly, we wont include Opcad were also going to leave off all the proposed Merkle tree manipulation opcodes. Theyre all too niche too use case specific to have a significant chance of getting adopted at this time. To the extent that these opcodes are useful, implementing their effects via OpCaT and or script revival is a much more likely path to adoption. Lightning op expire useful sigh any prev out useful CTV useful and redundant for Opcat and script revival because of their emulation properties. Channel factories Op expire useful sigh any prev out irrelevant CTV useful and again same with Opcat and script revival ln symmetry op expire useful sigh any prev out required CTV irrelevant again leaving off opcat and script revival. Arc op expire useful sigh any prev out irrelevant CTV required and again applying the same to Opcat and script revival advanced arc op expire useful sigh any prev out irrelevant CTV useful Opcat irrelevant script revival required validity roll ups Opticspire irrelevant sigh any prevalt irrelevant CTV irrelevant Opcat required script revival useful CTV is the clear winner here, followed by sigh any prev out opexpire is useful to many things by being a replacement cycling fix, but not essential. CTV wins because so many things fit into the design pattern of make sure the spending transaction matches this template. Even Opcat constructions can efficiently make use of CTV. Unlike OpcAT, CTV doesnt appear to raise much risk of unintended consequences beyond encouraging out of band fee payments in certain cases. This isn't ideal, but no one has come up with a widely supported alternative. My personal recommendation do a consensus cleanup soft fork followed by CTV get a cold card, back up your seed phrase and send your bitcoin to it. It is that simple. Do you have a cold card? Check on your backup seed phrase, make sure you have it. Make sure it's safe. Have you not gotten your cold card yet? Well, use my discount code bitcoinaudible all one word with the link in the details right in the show notes. If you have a cold card and you have backed up your seed phrase, well, then connect it to your wallet and send your bitcoin to it. Withdraw it from the exchange. If you haven't done those things, do them now. Get a cold card, back up your seed phrase and send your bitcoin to it. If you have done those things, congratulations. You actually own bitcoin. For those of you who would like to own their first bitcoin, the links and details are right in the show notes. All right, that wraps up this article. A layer two salt fork and covenant proposal review by Peter Todd and again, funded by Folger Ventures with no strings. [00:45:06] Speaker B: Attached, just to get someone to do. [00:45:09] Speaker A: The review and the breakdown of these different ideas. [00:45:11] Speaker B: And a much, much appreciated shout out to Folger ventures. You know, just getting, just funding this. I don't think people respect and recognize how important this, this type of work. [00:45:27] Speaker A: Is and just reveal, like, how critical. [00:45:30] Speaker B: They'Re like, there's no, there's no profit to this, right? [00:45:33] Speaker A: Like, Fulger ventures isn't going to make a return. This is just important work that needs to be done. Somebody needs to sit down and do. [00:45:40] Speaker B: The analysis of these things, break it. [00:45:43] Speaker A: Down, collect all of the proposals and review them. [00:45:46] Speaker B: We have to review everything. And it's a lot of work. [00:45:50] Speaker A: It's not easy. [00:45:52] Speaker B: There's not even that many people who. [00:45:53] Speaker A: Can read all of this crap and. [00:45:54] Speaker B: Know what the hell's going on. I don't understand a ton of it. I, you know, have vague ideas of how a lot of these pieces put. [00:46:03] Speaker A: Together, are put together, and I try. [00:46:05] Speaker B: To lego piece them back in some sort of an explanation so that I. [00:46:08] Speaker A: I can translate it to people who have even vaguer ideas of how all of this shit works and the process of pulling all of this information together and making an analysis of it that is actually informed and knows how to. [00:46:21] Speaker B: Judge what the good, the bad, the cost, the trade offs, the difficulties. Like, I still have a very hard. [00:46:28] Speaker A: Time wrapping my head around exactly how. [00:46:31] Speaker B: You unroll a merkle tree. [00:46:33] Speaker A: Like, how you can construct a merkle. [00:46:35] Speaker B: Tree of transactions and sub transactions. Because my head thinks an account with, like, I don't specifically think in how. [00:46:44] Speaker A: The script relates to each other. [00:46:46] Speaker B: Like the. I know the, like, I've read it and gone through it in mastering bitcoin. [00:46:53] Speaker A: And stuff, but holy crap, it's been. [00:46:55] Speaker B: A long time and I. It's been a long, long time since. [00:46:59] Speaker A: I've gone through it with a fine tooth comb. [00:47:01] Speaker B: And I kind of, like, did the. [00:47:03] Speaker A: Fat end of the fine tooth comb, the. The non fine tooth side of the. [00:47:08] Speaker B: Combined when I first did it, because some of it's just difficult to picture and it's easier to skim that part. [00:47:16] Speaker A: And as the guy who's read more. [00:47:18] Speaker B: About bitcoin than anybody else, you know, that makes it incredibly difficult to find. [00:47:24] Speaker A: The people who know all of this stuff. [00:47:26] Speaker B: And so just a long way of. [00:47:30] Speaker A: Saying, shout out to Folger ventures for. [00:47:33] Speaker B: For funding this work because it's not easy to do. It's not easy to do. It takes a lot of time, takes a lot of experience and knowledge to. [00:47:42] Speaker A: Put all this together. And, of course, shout out to Peter. [00:47:43] Speaker B: Todd for bringing this together and, you know, giving his take on all of. [00:47:48] Speaker A: This since he's been in the. [00:47:50] Speaker B: In the space for so long and. [00:47:51] Speaker A: Been debating and working with every proposal. [00:47:54] Speaker B: Under the sun for. [00:47:58] Speaker A: Who knows, long time. [00:48:00] Speaker B: So if you know where both of them are on, I wonder if vulgar ventures is actually on Noster. [00:48:08] Speaker A: And. And I think Peter Todd is. [00:48:11] Speaker B: But I'll try. [00:48:12] Speaker A: I'll try to find their in pubs. [00:48:13] Speaker B: So please zap them. [00:48:15] Speaker A: Zap them both. [00:48:17] Speaker B: If you. If you listen to this far. Listen, this far ends, you know, went. [00:48:22] Speaker A: Through this whole piece and you appreciate. [00:48:25] Speaker B: This analysis, please, please zap them. I will try to find their in pubs so that they're right in the description. And I will zap them, too, so. [00:48:36] Speaker A: That you can probably just find them in my feed. Now, getting into specifics and trying to. [00:48:42] Speaker B: Re explain a lot of what he gets into with this article. So, first comes op expire. And so op expire just allows you to have the reverse of something like a check lock time. Verify where you have a time in which this before which this coin or these coins specifically are not spendable, whereas op expire gives you an after which this is no longer spendable. And kind of at a naive interpretation or naive thinking, it seems to make sense that you would kind of want, or that it could be beneficial to have both, that, you know, you have one side of the coin, you have the other, then, you know, it's like. It's like hot and cold. [00:49:32] Speaker A: It's like yin and yang. [00:49:33] Speaker B: You kind of want both sides of that operation in order to find that. [00:49:40] Speaker A: Sweet spot of the middle. [00:49:41] Speaker B: Except that the passing of time in bitcoin isn't deterministic, it's probabilistic. And the fact of the network, like. [00:49:53] Speaker A: The network needs to survive the crazy situations. Right. [00:49:57] Speaker B: The deep reorgs. And I didn't really know much about op expire, so I'm just kind of basically going off of everything that Peter. [00:50:06] Speaker A: Todd here explained with it. [00:50:09] Speaker B: But I completely agree that the idea. [00:50:11] Speaker A: Of just kind of dismissing a large. [00:50:13] Speaker B: Reorganization, and for anybody who doesn't recognize the term reorg or reorganization, means that we go 100 blocks deep or a thousand blocks deep in bitcoin, which would. [00:50:27] Speaker A: Be a really bad problem. [00:50:29] Speaker B: But the thing is, is we still want to be able to achieve consensus with the network. And it'd be more likely, obviously, that. [00:50:35] Speaker A: You go ten blocks deep or 20. [00:50:37] Speaker B: Blocks deep, and a completely separate, quote unquote fork or separate history of bitcoin becomes valid, and you've got 18 confirmations on your transaction, and you're certain it's done, and then, boom, 20 blocks come out of nowhere, and those 18 get dropped for the 20, because that one has a longer proof of work or a more cumulative proof of work. The idea is that you just trust. [00:51:06] Speaker A: The longest proof of work so the incentives stay aligned. [00:51:09] Speaker B: And if you have that 18 block reorganization, you don't have any critical problem. [00:51:16] Speaker A: You just. [00:51:17] Speaker B: You have just changed the history, or you have realized that the valid history wasn't fully known. And, you know, obviously, this could be malicious in the sense that we could have malicious hackers or, excuse me, hashers, we could have miners, or a mining pool gets compromised and they 51% attack the network. But more likely and more naturally, we could actually just have a split in the communication of the network itself. Like the Great Wall of China could just go on lockdown, trying to do everything they can to cut off the communication of the bitcoin network. And then finding consensus through the great firewall of China just becomes very, very difficult. You know, this persists for a couple of hours, and a bunch of blocks come in, and then finally, you know, through the satellite network or by ham radio, who knows? The. The information leaks out, and there were 18 blocks, or there were 20 blocks. [00:52:19] Speaker A: Generated inside of China and only 18 outside, or vice versa. Either the information gets in or the. [00:52:25] Speaker B: Information leaks out, and you have a big reorganization because there needs to be. [00:52:29] Speaker A: A single consensus around globe. [00:52:31] Speaker B: I mean, this is specifically why node. [00:52:34] Speaker A: Cost and node bandwidth needs to be as low as possible to prevent this from happening, so that you can always achieve consensus. But that possibility remains. It always exists. [00:52:45] Speaker B: So if you have an op expire, an expiry of 4 hours, and then we have a deep reorg because of something, some situation like this, or a 51% attack, well, then the problem isn't merely, oh, well, we just need to. [00:53:00] Speaker A: Put these transactions all back in the mempool. [00:53:02] Speaker B: So going back to the example is, whichever 18 blocks and the transactions are in those 18 blocks, whatever transactions are in them, they all either have a relative time lock or a relative block. [00:53:15] Speaker A: Height in which they are valid. [00:53:17] Speaker B: And if they all get reorged by these 20 other blocks that don't have those transactions in them, well, those transactions. [00:53:24] Speaker A: Just go back in the mempool. [00:53:25] Speaker B: They just go back and they get reconfirmed again. And if it's, you know, a relative time lock or something, it just starts over. And if it was a hard time lock, like with a block height, you're just closer to the timeout, but the funds are valid. Like, everything still works. And even if you're past that timeout, your. [00:53:43] Speaker A: Your funds are still valid. [00:53:45] Speaker B: It's just that some other path might have already or also have been valid, but yours are still going to go. [00:53:50] Speaker A: Right back in the mempool and get confirmed. I. [00:53:52] Speaker B: Again. So it's not like it won't be messy, but everything that was valid is still valid. Basically, the system accounts for brief interruptions and, you know, short term, short term, and hopefully, even semi midterm forks that get reorged and combine the network back together. Even in the case of disaster, even in the case of something very serious and, like, a very deep disconnect between the network nodes. [00:54:25] Speaker A: However, if we add op expire to. [00:54:27] Speaker B: That mix, suddenly those assumptions no longer work. Suddenly, even if you were active and even if you did get confirmations, those expirations could, like, let's say they were for a. For opening a lightning channel and. Or closing it and splicing it into a new thing. And obviously, you hit everything within the correct timeframe, and you've got ten confirmations. You've got 15 confirmations, and then there's a 17 block reorg. [00:54:59] Speaker A: And let's say you were past the expiry on that. [00:55:01] Speaker B: Well, if you weren't using. If op expire wasn't part of the equation, well, then it would just go back to unconfirmed. But you could still just kind of use the channel as it was. You could still use the next set of funds as if they're about to confirm. [00:55:19] Speaker A: And importantly, all of your sub transactions are still valid. You've just been using an unconfirmed channel. So, let's say you were updating it with ten transactions or 20 transactions inside of it. Well, you could broadcast the closing of. [00:55:32] Speaker B: That channel and have it be a child pays for parent thing, pay a really high fee, and get everything confirmed immediately into the next block. [00:55:38] Speaker A: But in the op expire alternative, you could be using what were valid coins. [00:55:44] Speaker B: And then you have a deep reorgan. Suddenly, they can't confirm. Again, you can't just put them back in the mem pool because they're already expired. It's like you accidentally executed a transaction with an expiry that was before the current block height, and then they're gone. Or maybe the only person who can redeem them is the person who wasn't even supposed to have those coins. Now, of course, all of this is based on the different construction of these things. And whether or how they'd be using htlcs and the, you know, justice transaction, all this stuff. And I don't even know exactly where it would. This. This might not even be some sort of a problem that would be often used, but it does change the assumptions. [00:56:27] Speaker A: The security assumptions of having been sent. [00:56:30] Speaker B: A bitcoin transaction confirmation or no, that. [00:56:34] Speaker A: You have the data necessary to rebroadcast and get those coins. And even in the situation of a. [00:56:39] Speaker B: Time lock, because that time lock is moving forward, even if there is a reorganization, everything can still just continue forward from the new place. But with an expiration date or an expiration block height, that changes. And while that might not seem like. [00:56:57] Speaker A: A huge concern, and maybe there's not. [00:56:59] Speaker B: Even a lot of situations for it, it also doesn't seem like op expire. [00:57:03] Speaker A: Is really necessary for anything. [00:57:05] Speaker B: Like it's just kind of nice to have for one very, for a couple of specific constructions. But you can solve that problem in other ways, other ways that don't even need soft forks. And there's a potential trade off and. [00:57:22] Speaker A: We have to do a soft fork. [00:57:24] Speaker B: To get it for something that is just kind of, okay, cool. It would be nice, but it's not necessary for anything. It's also kind of to fix an attack which hasn't been exploited, isn't. [00:57:40] Speaker A: It's not like it's a completely inexpensive attack. [00:57:43] Speaker B: Like there's, there's reasons why it's not just gleefully executed every single day. It's not the easiest thing in the world to pull off. And there are other solutions to it. I don't know, that just, that seems like a lot. You know, you need a lot for a soft fork to be viable. Like, it's got to be useful. It's got to be very fundamentally useful because the soft work itself is a remarkable pain in the ass. So I kind of, I kind of agree that opexpire, at least from my understanding of what, what he breaks down here, which is obviously not super in depth, this was mostly just kind of a summary rundown of it, but it does just kind of seem least useful among all of the various things being proposed here. So then we have sigh hash, any. [00:58:35] Speaker A: Prev out, any previous out. [00:58:38] Speaker B: So what this allows is basically of signing, of committing to a specific script and public key, but not any particular input. But then there's also sigh, any prev out, any script which allows you to basically have a signature that is valid with any number of potential past scripts and inputs or outputs. So what the hell does all of that mean, well, just in the context of lightning. So we put funds into an address and then we pay them out to another pre signed transaction. Like that's our quote unquote covenant. And I give you the transaction with. [00:59:22] Speaker A: My signed half and you give me. [00:59:24] Speaker B: The transaction with your signed half. And these are our abilities to exit from this agreement. And so each of these transactions spend that same input, that same channel out. [00:59:39] Speaker A: To two different addresses. And we have to sign these. [00:59:43] Speaker B: And every single time we do, we update, all the signature changes, all the stuff changes, and we have to exchange all this information again every single time we do an update. And the handshake goes both ways. So there's like, there's a bunch of back and forth in making sure that everything's signed and everybody has the half that they need in order to punish. [01:00:02] Speaker A: The other one, so that we can. [01:00:03] Speaker B: Know everybody's being honest and move forward. What if we could take that input. [01:00:10] Speaker A: And just sign that? [01:00:12] Speaker B: I was going to get some coins and it was going to be with this script, but I didn't really care where the coins came from. And every single time we updated the. [01:00:23] Speaker A: Address, the signature was still valid. [01:00:25] Speaker B: As I understand it, that's kind of the idea, is that you commit to and pre sign all of those explicit details without caring which output it was going to, because we can just keep updating that and then that signature remains valid, that signature remains consistent over any. [01:00:46] Speaker A: Of the states of this transaction or. [01:00:48] Speaker B: Of this, of this channel. And then I can't remember exactly what the, well, the specifics of it are, except that because you can commit to all of this stuff without having to have a pre signed transaction specifically, you can do it from any of the outputs, is that you can actually trustlessly just give it to the other party and it's the same. Like you can kind of combine the two halves of our make sure you trust me transactions, the pre signed transaction where I have the ability to exit. [01:01:23] Speaker A: And punish you, and then you have. [01:01:24] Speaker B: The ability to exit and punish me. And that's how we keep lightning channel honest. Well, we can actually just pre sign both of our pieces of it and then both have it. [01:01:33] Speaker A: And this gives us the ln symmetry. [01:01:35] Speaker B: So your valid state of lightning is the exact same thing as my valid state of lightning. So if I lost mine, you can still just send it to me and. [01:01:44] Speaker A: We could both update it. [01:01:45] Speaker B: But the problem there, and the reason Peter Todd, I don't quite, I don't completely agree with this thinking personally, but the reason Peter Todd is saying whether or not that's even necessary or even a good thing to have. L in symmetry is that in an. [01:02:03] Speaker A: Adversarial situation. [01:02:06] Speaker B: You want the punishment. So if somebody, if it costs somebody everything that they have in the channel, like if we have a one bitcoin channel and I have a half and you have a half, and I try to cheat you out of your half, but it specifically costs me my half. [01:02:22] Speaker A: To even try cheating. [01:02:24] Speaker B: If I fail, well, then I have no incentive whatsoever to try it. However, if I have half a bitcoin and you have half a bitcoin and I can try to steal your half, and when you quote unquote, enforce it, all it means is I just only get my half, well, then I have, like, why wouldn't I just try? Why wouldn't I just do it a bunch? There's not really any great disincentive for me to spam my cheating of the channel, because either I succeed and get your coins or I don't succeed and I still just get my coins and, you know, maybe, maybe that is the correct way to think about it. And I think probably just htlcs are kind of. The question is, what happens when something is locked up and somebody is trying to do this along a route? Like how does it affect everybody along the route? But lightning channels are also like a long term, like, arrangement between peers on the network. And it's kind of already trusted just. [01:03:30] Speaker A: Because locking up your funds with somebody. [01:03:32] Speaker B: Else, it has a time cost and. [01:03:36] Speaker A: Then exiting in any sense, also has a fee cost. [01:03:39] Speaker B: So it's not an arbitrary thing to open up channels with somebody. And so most of the lightning network is like the adversarial situation. We just kind of want the honest party to exit. And if any channel party partner is trying to spam a cheated part of. [01:04:00] Speaker A: The transaction or cheated part of the. [01:04:02] Speaker B: Channel, well, then the channel just will just leave and they'll never open with that channel party again. So the natural, like, you have to agree to go into a channel with somebody. So the natural incentives align to just basically not participate with anybody who is doing this. So I don't see it really becoming. [01:04:24] Speaker A: Like a huge problem. [01:04:26] Speaker B: But then the other question is, is ln symmetry really that important? Because that is its main use case. Its other though is the fee thing is that if you're, if you can commit to just the script and, you know, ensure that, you know, any of these inputs could pay out your, what you are owed from this channel, well, then it also means that other inputs could be added to essentially have a dynamic fee, whereas in the other situation where you want to, because you're pre signing these transactions, right, which means the fee is stuck. So if I have a pre signed transaction with you that pays me out 0.1 bitcoin and the fee is 100 sats, and then when I need to execute that, the fee is 1000 sats per transaction or per input, and it stays that way for six months because of some crazy shift in the weather on the bitcoin blockchain. Well then I'm shit out of luck if I didn't pre sign a 1000 sat fee transaction also. [01:05:38] Speaker A: So we have to pre sign all of these things. [01:05:42] Speaker B: And this is what he's talking about on a combinatorial explosion of fee rate variance is, okay, how many things, how. [01:05:49] Speaker A: Many of these should we pre sign and how many do we need to. [01:05:52] Speaker B: Pre sign and at what variance? Like how many, you know, along the, the height of all of the potential fees that we could see. Well, now we're having to do this for so many different, like now we're really exploding the amount of pre signed transactions and things that we need to send back and forth. Whereas if we had any prev out, that becomes a much simpler issue because we don't have to commit to the fee. We can just have the fee be. [01:06:22] Speaker A: Paid out of whatever the input is. [01:06:24] Speaker B: And we can add more inputs to cover whatever the fee you need to pay is and then also still commit or still execute the requirement of all of the transaction details. So in the dumbest sense possible, you just want to make sure you get your bitcoin. You don't care which bitcoin or which output or which specific update in the transaction history of the channel you're referring to. You just want to get the coins and sigh. Any prevalence just means that you can sign to know you're going to get the coins. And whenever an HTLC, whenever a new payment update comes through, it's still valid and it can be used to pay out from any previous state that has used any commitment transaction that was put. [01:07:10] Speaker A: Into. [01:07:13] Speaker B: Secure the channel. Again, you don't really care which one, you just need the coins to pay out from that. And in fact, if you had to rely on one specifically, well then do you run into that? Problem is, did you properly decide what that fee was going to be? And is that still true with this. [01:07:32] Speaker A: Payment that has now been sitting here. [01:07:34] Speaker B: On the chain or sitting here, you know, stuck as an HTLC for an hour, this payment that went through your channel? Well, is the commitment transaction that this refers to as this is this now the right fee. Things can change very quickly. And if we have any prevalence, it doesn't matter. You can use any of them. So anyway, that's interesting. And it seems like there are a lot of potential use cases because of the whole separating this off chain or separating this into a separate network. Well, then you can kind of commit to making sure that you can get information out of it, but then not really have to be. You can be a little bit more ephemeral about what you're saving from it. [01:08:17] Speaker A: You. [01:08:17] Speaker B: You kind of save, there's less data necessary to build to rebuild something valid out of it because you can not have to have all of these crazy pre signed transactions and all of these details like saved for every single state and all the different possible paths. You can save less stuff, and then. [01:08:37] Speaker A: It'S valid for a bunch of different options. [01:08:39] Speaker B: So that's any prev out. Then we have op check template verify or CTV. [01:08:47] Speaker A: And this is the one that I. [01:08:48] Speaker B: Have basically come down fully in support of because everything that I thought I had originally disliked about it or distrusted about it, I just kind of dug deeply into all of them and also had a very long conversation with a couple of different people, one person in particular in my DM's, which is so far gone now in Twitter, that I wish I could thank whoever that was because I really appreciated your patience with me in the. And the amount of time that you sank into helping convince me or helping me understand how this actually works. Because almost all of the FUD around CTV was genuinely based on not understanding how it worked. So, like, two years ago, I think I did like, four or five episodes over a period of a month or two on CTV, and also had John Carvalho, I believe, on the show. And we talked because we were both against it at the time, and we were proposing and thinking about things that you could do to basically trap people, like, how could you use this maliciously? And then the thing that I came up with, I genuinely misunderstood the sequence of operations to actually get a correct CTV transaction or a valid how you would actually construct a valid one and the degree of interactivity that was needed. [01:10:18] Speaker A: And specifically how and who could pay. [01:10:21] Speaker B: To execute that transaction and what it. [01:10:23] Speaker A: Would cost them to do so. [01:10:25] Speaker B: Because there's this one proposal specifically called a congestion control transaction that allows someone to spend a transaction that basically has a thousand next in line outputs for all of these different people to withdraw their coins so that it can basically be withdrawn like an exchange can execute a withdrawal for 1000 people. And even though they don't get it into their individual utxos because the fees are too high, all of the information is there to withdraw it to it. There's a hash of each one of those transactions in the tree to spend out of that. So you could execute these congestion control transactions when fees are really, really high and everyone could still withdraw very cheaply and then they could pay out, they could redeem from that transaction when fees got low again. So it would basically be a proof that this is now yours. But when you want to remove it from this system, you can choose and pay whatever fee is worth it to you and wait however long you wish to wait. Simplest way to think about it is it's a way to divert the fee to the future. And then every user can just choose how, how long of that future they're willing to wait before they move their. [01:11:53] Speaker A: Coins or do anything. [01:11:55] Speaker B: But they can know that they own it now before having to pay to. [01:12:00] Speaker A: Pay the fee to own it. [01:12:02] Speaker B: And so all CTV does as a. [01:12:05] Speaker A: System or as a tool itself is. [01:12:08] Speaker B: Commit to the hash of the output. [01:12:11] Speaker A: And so if somebody tries to spend. [01:12:13] Speaker B: It without that output, well, it's going. [01:12:15] Speaker A: To check the hash before it even looks at the output details. [01:12:20] Speaker B: And if that doesn't match the output details, well, then it's, it's not valid. It just doesn't work. So the hash just locks that information to wherever it's going to be spent. And then, as he explains is this is not recursive. And just understand recursive covenants would be that, oh, you can, let's say I said in that output, you can't really do a negative, but let's just for the sake of it, just because this is the evil thing that we don't want to happen is you just say you can spend it to anything. Except I, these three addresses because these addresses are on the OFAC, you know, evil, bad person list. Well, if a recursive covenant could basically use itself as a template and that, without adding that template again, it wasn't valid, well, then if the government had, you know, 300,000 coins and it put this recursive covenant on those coins, well, forever after that, it would never be you unless you had a hash collision or whatever. You would have to those 300,000 coins. [01:13:38] Speaker A: No matter how they broke up and. [01:13:39] Speaker B: Where they went, it would always be impossible to spend those 300,000 coins, which would get more and more valuable as time went on to those three addresses that we permanently locked indefinitely, you would essentially create two class of coins. And then that could happen with the russian government, that could happen with the corporation by accident. And suddenly that openness, that, that clear and explicit, this exchanged ownership from me to you relationship no longer applies. And suddenly one bitcoin isn't one bitcoin. You could end up with all different kinds of bitcoins. Like recursiveness is, is the destruction of bitcoin as money. I think, in my opinion, fungibility. And essentially the, the death and reminting. [01:14:31] Speaker A: Of coins every single time they exchange. [01:14:33] Speaker B: Hands, I think is the cause. That's, that's the thing about Utxos is it's kind of like a check. It doesn't, there's not an account that, you know, moves increasingly through time with a balance, and then, you know, that balance is just updated and some of it's removed. Like you're spending all of the things. Like the way that Utxos work, the way that transactions work on bitcoin, is that you're simply referencing the previous transaction in order to do the next one. So if you think about it like a check, like a handwritten check, is that it doesn't matter what the amount is. Somebody can send you a check for $57.73 or $10,000. But if you were spending $10,000 and $10,023, then bitcoin would be as if. [01:15:21] Speaker A: You had to take both of those. [01:15:22] Speaker B: Other checks, the $10,000.01 and the $57.01 and put them together as the input. You would write their check numbers or whatever it is on the input of your other check to basically prove that. [01:15:34] Speaker A: You have those funds. [01:15:36] Speaker B: And there was never an account, there was never an account balance. There was never one account of 10,057, one balance of $10,057.73 or whatever it was that I am. [01:15:50] Speaker A: Then spending out of the next check. [01:15:52] Speaker B: Simply references the last check. So my wallet is literally just a. [01:15:57] Speaker A: Collection of all of these checks. [01:15:59] Speaker B: And then my wallet balance is just. [01:16:01] Speaker A: Telling me what they are all together. [01:16:03] Speaker B: And how much my fee costs on the bitcoin network is how many checks. [01:16:08] Speaker A: I have to reference. [01:16:10] Speaker B: So if 100 people sent me $1. [01:16:13] Speaker A: Checks and I have to reference 100 checks, my fee is going to be 100 times as big. [01:16:18] Speaker B: So if we want to use this analogy for this image of the checks, if you want to think about any prev out, any prev out is like normally what you have to do now is every single time you have one of those inputs, you have to sign every single check. Like like every single one of them. And signatures, there's a lot of signatures. And signature is also a big chunk of the data of a transaction. So you're signing, you have one. If you have a bunch of $1 checks, you're gonna have to, you're gonna. [01:16:43] Speaker A: Sign a bunch of crap. [01:16:44] Speaker B: And that makes all of those taking all of that to chain, because you have to take each check plus the. [01:16:50] Speaker A: Signature a hundred times. [01:16:53] Speaker B: So any prep out would be something where you could just make a signature. [01:16:57] Speaker A: And it applies to specifically all of. [01:17:00] Speaker B: Your checks that were created from your address or from your, your keys. And that also means that if you got a bunch of new checks between the time that you made the signatures and the time that you needed to publish the next check that references those, you could actually swap out which checks there were. So you could have signed it with the intention of using all of the. [01:17:21] Speaker A: $1 100 of the $1 checks. [01:17:24] Speaker B: And then the $10,000 check comes in and that signature will still work to reference the $10,000 check because again, you don't care where it comes from. And now you have one check to reference that's going to be a whole. [01:17:33] Speaker A: Lot cheaper than 100. [01:17:35] Speaker B: And so you just use the new one in order to pay out those funds to you or to wherever they are, the channel party, blah, blah, blah. Now if we want to think about this isn't even relevant, but just so you can, just for the fun of conceptualizing it, you still do have to put a signature on every single check. So if you did those 100 $1 checks and you wouldn't have to have a new signature for every single one of them or your any prev out, but you still would need to put that signature on every single input. So there's also something that's being worked. [01:18:09] Speaker A: On, or that is in the future. [01:18:10] Speaker B: Plans of bitcoin called cross input signature aggregation, which is a trick of schnor signatures specifically that came in with taproot, and that makes, makes it so that you can actually combine, you can take. [01:18:24] Speaker A: All of the signatures of all of. [01:18:25] Speaker B: The $1 checks and you can actually. [01:18:29] Speaker A: Make one signature that was literally just. [01:18:32] Speaker B: All of those like essentially added up. You just kind of like, you do a signature for every single one of them and you mush them all together into one signature. So it's still basically the exact same size, but one of those. Now you literally saved 99 signatures worth of space. Now that wasn't in any of these proposals. That doesn't have anything to do with covenants, but that's just an interesting trick of schnorr signatures and how you want to think about it from the check analogy. Now, CTV in this analogy is like putting in the description of what the check is saying. $100 of this has to go to Bob. You're basically committing to the next thing that has to happen with that check. And so because of that, let's say you have 100 people to pay out to, and fees are super high. Using the congestion control transaction idea, the. [01:19:27] Speaker A: Fees are super high. And this just isn't the time to have to sign 100 different checks because. [01:19:33] Speaker B: That signature is going to cost way. [01:19:35] Speaker A: More today than it did yesterday and probably than it will tomorrow. [01:19:39] Speaker B: And we could just wait until tomorrow. However, we need to make this deal happen right now. So what I'm going to do is I'm going to pay everybody at once with one check, and then I'm going to write out the entire list of. [01:19:51] Speaker A: What I owe to every single person. [01:19:53] Speaker B: And all of this is going to. [01:19:54] Speaker A: Be in the input. [01:19:55] Speaker B: So I'm going to take my 10,000 input and I'm going to pay, I'm going to write out all of the outputs to all the checks that are going to go to the 100 people that I'm paying. I'm going to hash it, and I'm going to lock the signature. I'm going to lock this check of 10,000 to that hash, which means that. [01:20:16] Speaker A: The only checks that can validly reference. [01:20:19] Speaker B: This have to have those transaction details in them. Only certain checks are valid to pay from this check. Just in the same way that if I said this check isn't valid for two weeks, well, then any check dated before two weeks from now is not valid. Same as if I said any check. [01:20:40] Speaker A: That doesn't have your signature on it because I'm sending you the funds is not valid. I'm just restraining the next thing that. [01:20:47] Speaker B: Happens, what the ownership of these coins are. And with CTV, I'm, I'm simply also adding where and how much must go. [01:20:56] Speaker A: To one place or a certain place. But the simplicity of how that works. [01:21:01] Speaker B: Is why we know it is not recursive. And when I realized that the incentives or the congestion control transaction were not what I thought they were and that you cannot actually do recursive transactions with CTV, or at least not in the malicious way, not in the, the receiver can't control it and there's nothing they can do about it, those were basically. [01:21:23] Speaker A: The last two straws of like, okay. [01:21:25] Speaker B: I don't really have a good argument against CTV anymore. [01:21:29] Speaker A: And Peter Todd's quote in this one. [01:21:30] Speaker B: It says, why aren't recursive covenants possible in CTV? [01:21:34] Speaker A: Because hash functions. The CTV checks the spending transaction against a template hash. And there's no way of creating a. [01:21:42] Speaker B: Template containing a CTV with a hash of itself. And that's just because as soon as you add it, the hash is different. So you can't then put that new hash in like it's forever a chicken and egg problem. Essentially, if you have the hash and then you try to put it inside of the thing, well, then the hash, you basically have to have a hash collision of a piece of a hash that's inside of a thing that gets hashed, still happens to have the exact same hash, which is just never going to happen. Now he says the very next paragraph, and I want to clarify this, just because he seems to contradict himself, says that said, this isn't necessarily a real limitation. You can easily, easily hash a chain of CTV template hashes to a depth. [01:22:29] Speaker A: Of tens of millions of transactions in. [01:22:32] Speaker B: Just a few seconds on a modern. [01:22:34] Speaker A: Computer with relative in sequence time locks and the limited block size, actually reaching the end of such a chain could easily be made to take thousands of years. [01:22:46] Speaker B: Yes, you can predetermine a path that is infinitely long inside a CTV hash, or not infinitely long, but just tens of millions of transactions. That's, that's actually, you can't have something infinitely long because you, you would have to pre hash or pre create an infinite long. The only way you can make it infinite is recursive, but you could make it so long to the point that it doesn't matter from a practical standpoint. But I see those as completely different for two reasons. One, you have to pre plan where all of the transactions go to. I can't, I can't then do that and then maliciously send it to you without you knowing. You still have to create the transaction details and the output. Like it would be you who put in the, the next line of recursiveness. [01:23:39] Speaker A: If it was your wallet and your keys. [01:23:41] Speaker B: So you would be transaction two, and then you would be necessary in order to actually produce transaction 999,999,998 on. So basically, this potential problem is just, it's fundamentally the same primitive of screwing up a transaction, sending it to the wrong address, sending it to a burn address, losing your keys, accidentally typing in two extra zeros, or missing the nomination for the time lock because you thought it was seconds instead of years or something. All of that just falls under the category of you screwed up how to lock the coins, and therefore you lost the coins. So those being stuck in some crazy chain forever for a thousand years is really just kind of the same thing. [01:24:36] Speaker A: As Satoshi's keys being lost and those. [01:24:38] Speaker B: Coins being stuck there forever. Whereas the concept of an introspective recursive covenant, one that can be required to look and include something from itself in. [01:24:51] Speaker A: Order for the next one to be. [01:24:53] Speaker B: Valid forever, you could literally have an. [01:24:57] Speaker A: Infinite covenant and you could enforce it on these coins without anyone else's permission and send it to their wallets. [01:25:05] Speaker B: So the government could send those 300,000, you know, infinitely recursive coins that have an OFAC blacklist that they can't be sent to, to you. So hundreds, maybe even thousands of people, they could, they could open up a. [01:25:22] Speaker A: Bitcoin service and just start selling bitcoin, like a government run exchange. [01:25:26] Speaker B: And every single one of them that goes through, everybody who buys and sells those coins on that exchange, they go into the government ownership and the government owns, adds, you know, this permanent recursive. [01:25:40] Speaker A: Limitation on these coins and then spends. [01:25:43] Speaker B: Them back out into the network. And slowly, it could very well be that a majority of the coins on the network can't be sent to these addresses. Now, again, just to clarify, I don't think there is a negative covenant that just says you can't send it to these places like an XOR, where it's anything except this transaction. So it wouldn't be exactly like my. [01:26:09] Speaker A: Analogy, but that's the potential risk. [01:26:11] Speaker B: That's the type of attack, that's the type of problem that truly recursive covenants could be. So that's specifically why I really like CTV, is because I don't like the idea of even thinking about how recursive covenants could be done, especially in using. [01:26:30] Speaker A: A broader tool to then create covenants. [01:26:34] Speaker B: But I like CTV being very explicitly and simply used for the primitive of adding that now that we've got the who can spend it? And when it can be spent, adding the where can it be spent too? As a third primitive fundamental to just how the transactions can be locked up and that we know it's specific to the check that we write it on and it cannot encumber future checks, or at least not in the sense of. [01:27:05] Speaker A: Any random person who wasn't even participating. [01:27:08] Speaker B: And who never sent an address and never made a signature and was, was never involved, that it can't end up in their wallet or behind their keys with those restrictions still on it because that threatens the very notion of not your keys, not your coins. Like, suddenly the entire set of assumptions. [01:27:25] Speaker A: About security and ownership in bitcoin have. [01:27:28] Speaker B: Changed because you need to know what. [01:27:30] Speaker A: The template is of the coins that you're getting. So CTV doesn't change that. [01:27:36] Speaker B: It does not fundamentally alter those risks. [01:27:39] Speaker A: Those security assumptions and what your keys mean. Like, you still just need your twelve words. [01:27:44] Speaker B: You just need your 24 words. And any coins that ended up in your wallet or behind your address are yours. Now, as he says, from a practical. [01:27:54] Speaker A: Point of view, this means, quote, unquote, that in many circumstances, the only available mechanism for fee payment will be CPFP. [01:28:02] Speaker B: Or child pays for parent. So this means that going back to the idea of any prevalence and like, okay, well, don't we have to pre sign a bunch of different fees? [01:28:11] Speaker A: Yes. [01:28:12] Speaker B: So going back to the congestion control transaction idea is that you have to pre sign for what fees you're going to pay in order to exit from this group. So let's say the fees are $50 a transaction. When you execute the transaction, control the congestion control transaction, and the exchange does it and adds in a withdrawal to 1000 different people behind one Utxo. So it costs them only $50 to get it, and everybody's safe and they're not trusting the exchange anymore and everybody's just leaving it and they're just going to wait for fees to go low. Well, you have to already know what fee you're willing to pay before that congestion control transaction makes it to chain. Or you have to have a series of pre signed fee variants where, okay, I'm willing to pay 100 sats, but I'd also like to have one for 200 sats, and I'd also like to have one for 501,010 thousand. And then if this never goes anywhere and I'm stuck for two weeks, I would like to also just be able to pay 100,000 sats and pay a $50 transaction fee. So now all of that has to be pre signed and stuck into the CTV template as options. So going back to what Peter Todd said, that means that the only available way to change the fee, let's say you, everybody commits to just 100 sats per input or whatever, and the fees just never get low enough. Well, you can exit from that and publish the one to the mempool that. [01:29:47] Speaker A: Isn'T going to confirm, but it'll sit. [01:29:48] Speaker B: In the mempool and then you can. [01:29:50] Speaker A: Spend from that address again and pay a really high fee and just spend. [01:29:55] Speaker B: It back to yourself. [01:29:56] Speaker A: And now you're having to confirm two. [01:29:58] Speaker B: Different transactions but the second one's only valid if the first one goes in and the second one, the second one is paying from that output. That's what child pays for. Parent is the miners will look at. [01:30:09] Speaker A: The total fees they will receive. [01:30:12] Speaker B: They'll see the latest transaction and say, oh, that's got a big fee, but it's not valid. [01:30:15] Speaker A: Why isn't it valid? [01:30:16] Speaker B: Oh, well, this other one in the. [01:30:17] Speaker A: Midpool needs to be confirmed, too. And so then they will say, all. [01:30:20] Speaker B: Right, well, this fee is 100 sats. That's not enough. This fee is 10,000 sats. That's more than enough combined. Their fee rate is, you know, 9000 sats per input. So it is worth it to combine both. Put both of these transactions in my block because they're paying way over the current fee rate. That is, child pays for parent. You can create as many transactions between. [01:30:43] Speaker A: Blocks, unconfirmed, as you want. [01:30:46] Speaker B: So if you wrote me a check for 10,000, going back to the physical check idea is that if you wrote me a check for $10,000 and then. [01:30:54] Speaker A: I wrote another one for $1,000 to. [01:30:56] Speaker B: Me, and I put a very, very little fee on it, but then I just went ahead and wrote another thousand dollar check, I wrote another 900, I wrote another 200, another 100. Like, I just, like, just kept writing. [01:31:05] Speaker A: These in sequence with each other. [01:31:08] Speaker B: Well, the last one, even though the $10,000 check is the only one that's confirmed in a block, the last one is valid as long as all of the other ones get included. And if I pay a ton of fees on the very last transaction in that line, well, they can all go into the next block. And specifically, let's say I do 100 of these. Specifically the first one. I mean, excuse me, the last one. [01:31:32] Speaker A: Is not valid unless the first 99 are confirmed. So they all get stuck in one block if they're chasing the fee at. [01:31:39] Speaker B: The end of the line. The problem is that this does mean out of band fee payments become kind of a market, because, again, you're trapping people into what fees they have to pay. And thus you might have a mempool space. Like, that's not good to have out of band markets now. There will always be out of band markets, probably. And in a general sense, bitcoin doesn't do anything like you can't control out of band stuff. The idea is, how do we make it so that the bitcoin network itself runs as the most efficient or as the. The most profitable path? Because there are no explicit miners who have enough of the hash power to get centralization. [01:32:26] Speaker A: So the centralization of the hash power. [01:32:28] Speaker B: And the ability to confirm transactions privately in a reliable sense, because you're a huge miner or you're part of a huge pool, is a problem because it breaks the economies of scale of the probability like it's supposed to be a lottery. Now, it's fine if a whole bunch of people want to go in to a lottery and split a ticket, or specifically split the winning ticket, and then. [01:32:52] Speaker A: They have more chances of winning the. [01:32:54] Speaker B: Lottery, but they're going to just get a smaller reward. It still doesn't mess with the overall probability. You're still just getting the same lottery ticket. But if like 10% of the money that would go into the lottery ticket. [01:33:11] Speaker A: Now just talks directly with that group. [01:33:14] Speaker B: In a private way, well, now the little players who win the lottery or are playing the lottery, even if they win, they can't make as much money. [01:33:26] Speaker A: As the big guys. [01:33:28] Speaker B: Probability is no longer, basically, you're able to leverage the higher probability of your pool in order to make an out. [01:33:37] Speaker A: Of band market, and specifically making the. [01:33:40] Speaker B: Lottery unfair, when the point itself of. [01:33:44] Speaker A: The lottery is fairness. However, there's no real incentive for users. [01:33:49] Speaker B: To do this, because if you just. [01:33:53] Speaker A: Publish to the bitcoin chain, you have. [01:33:55] Speaker B: Much more, much more mining power to confirm your transaction than if you just used a pool. Like you're just using everyone, you're literally using every single pool. So as long as you can always. [01:34:08] Speaker A: Update your fee, it's always going to be economically most beneficial to just use. [01:34:14] Speaker B: Every miner at once, because any single. [01:34:17] Speaker A: Pool is obviously going to do less. [01:34:19] Speaker B: Than the whole network. Being trapped in a particular fee amount is going to naturally encourage external fee markets, because it's creating rigidity in a explicitly dynamic market. [01:34:34] Speaker A: A dynamic open auction on the bitcoin network. [01:34:38] Speaker B: If suddenly people can't change the amount that they're offering in the auction, and. [01:34:43] Speaker A: Tons of data is flowing through this. [01:34:45] Speaker B: Now, that's completely stuck in what it's able to offer in that global auction, well, then a secondary market is going. [01:34:54] Speaker A: To explode very, very quickly over solving. [01:34:58] Speaker B: That rigidity, of smoothing out that difference in price. That's literally what markets do. But that's a potentially negative outcome that could even purely for the sake of solving a problem, could cause a more. [01:35:14] Speaker A: Important, more fundamental problem. [01:35:16] Speaker B: And this is kind of the MEV idea, though. MEV more specifically is about kind of front running markets. Well, depending on the MEV specifically, because it comes in a bunch of different forms. And in fact, I've been really thinking that it's probably time to do like a full rundown of MeV on the show, because I feel like it's a very, very vague concept with a lot of people who don't have any specifics, myself included. Like, I don't. I can't tell you exactly all of the things. Like, I think this is worth maybe. [01:35:47] Speaker A: Even a shitcoin Insider episode, I don't. [01:35:48] Speaker B: Know, to dive into Ethereum and the MEV situation and like how this is causing problems in uniswap, because a lot of this is like front running in the markets, which I think is really just a big problem of having public trades and stuff in a decentralized system. But there are a lot bigger problems than that. And it's essentially miners or validators in all of these shitcoins and stuff having. [01:36:18] Speaker A: Because of their position in the mining. [01:36:20] Speaker B: Or in the validating set of these networks or in bitcoin, is they're able to capitalize a different market because the bitcoin market isn't good enough at actually settling those, the differences, that there's some sort of a variance in it. [01:36:39] Speaker A: There's a variance in what can actually. [01:36:41] Speaker B: Be done with that group of, based on the size of your validator or your miners. And so it's basically an arbitrage. It's an arbitrage between what's happening at the consensus layer of the network and what's being confirmed versus what access and capital movement is able to happen in. [01:37:02] Speaker A: The data that's then being solidified, that's being confirmed and stuck in the chain. [01:37:07] Speaker B: But if you followed that at all, you would realize that it's very, it's. [01:37:10] Speaker A: A very vague idea. [01:37:11] Speaker B: And just conceptually, it almost kind of feels like any external market could potentially. [01:37:18] Speaker A: Cause some sort of a problem. [01:37:19] Speaker B: But obviously, we can't just. There's no controlling of markets. So anyway, I just think there's clearly something to unpack there and a lot. [01:37:28] Speaker A: Of research to be done. [01:37:30] Speaker B: And I feel like it's probably something that's worth a show to really understand. Having a vague idea of a problem is just going to be able to make it use useful as a stupid boogeyman. People are just going to be running and say mev and then everybody's going to hate this thing. And, you know, people aren't saying anything concrete. And if something is going to cause mev problems, I want to know exactly how and in what way. So I don't know. This just a long roundabout way of saying we're going to have to cover me. And in fact, if anybody knows any. [01:38:06] Speaker A: Great articles or deep dives or have. [01:38:07] Speaker B: Any, has any really good, really good resources on it, or the problems specifically. [01:38:12] Speaker A: That have gone on in shitcoins and. [01:38:14] Speaker B: Why I would love those resources, send them to me. [01:38:19] Speaker A: I want it. [01:38:20] Speaker B: Give it to me. Seriously. [01:38:22] Speaker A: I actually live by suggestions. [01:38:24] Speaker B: So please, if you think of anything. [01:38:27] Speaker A: If you think of a good episode you want to hear, send it to me. [01:38:30] Speaker B: Because I that, that is one of. [01:38:31] Speaker A: My most used resources now. [01:38:34] Speaker B: It used to be just scouring Twitter and now I'm not on Twitter anymore. And I've leaned even more so on suggestions. Granted, Noster has a bunch of great ones too. Like I found this. I got this on Noster. Like it just came across my feed. But I've also had a ton of people just literally just send me suggestions. Oh, you should read this. This is cool. I am. Wait, I really want to read this. But holy crap, I'm not going to do that. I'm lazy. Please read it for me. I welcome all of those things. And in this particular case, I'm going. [01:39:01] Speaker A: To need some information on Mev. [01:39:02] Speaker B: The more the merrier. All right, I need to move a little bit faster through this. So Ellen Hans, I'm actually very disappointed because one of the things I immediately went into this article wanting to hear about was Ellen Hands because I don't know anything about it. And then his breakdown of it is we don't really know anything about this. They really need to do a better job of arguing for their proposal, so we won't discuss it further. And I really wanted to know about Ellen Hans, so maybe I will add that to the obligations of please send me if you have a great resource on ln Hance. I did kind of click on the links that he has and tried to dig down a little bit, but I'm not really finding a whole lot. So resources would be very useful on L enhance. Then there is op TX hash, which this one was interesting because it apparently so it says similar to CTV, this. [01:39:55] Speaker A: Proposal achieves a non recursive covenant functionality by hashing data from the spending transactions. Unlike CTV, the TX hash proposal provides. [01:40:02] Speaker B: A field selector mechanism allowing flexibility in. [01:40:05] Speaker A: Exactly how the spinning transaction is constrained. It achieves two main goals, one, enabling the addition of fees to a transaction. [01:40:12] Speaker B: Without breaking a multi TX protocol, and two multi user protocols where users only constrain their own inputs and outputs. Now number two is really, really cool. Multi user protocols where users only constrain their own inputs and outputs. This is kind of what I talked about from a conceptual standpoint of the kind of holy grail is if you could have interactivity where people could literally just only change what that what is. [01:40:44] Speaker A: Relevant to them in the transaction can. [01:40:46] Speaker B: Only sign for it and can only constrain it, but could do so without needing to update and demand signatures and sending it around to everybody else. Now, I don't think this is exactly what TX OptX hash enables. I'm just meaning conceptually, that's kind of like the dream, right? [01:41:04] Speaker A: Is that even though it's in this. [01:41:05] Speaker B: One UtxO, you don't really have to directly coordinate with everyone all the time in order to validly change updates. You're simply able to change what your. [01:41:17] Speaker A: Piece of it is. [01:41:18] Speaker B: But he says the main problem with. [01:41:20] Speaker A: It is that the field selector mechanism adds quite a lot of complexity, making review and testing challenging compared to the much simpler CTV proposal. [01:41:29] Speaker B: So essentially it enables a ton of. [01:41:33] Speaker A: Different paths for how this can be. [01:41:35] Speaker B: Constructed and what specific piece of information is being referred to such that trying to test it and know, oh, these are all of the things that you. [01:41:44] Speaker A: Can do with it and these are. [01:41:45] Speaker B: All the different ways that it can relate back to the original transaction. And we're selecting the combination of all of these different things. You just increasingly get bigger and bigger and bigger. The number of options you have, the number of different combinations you can have. Whereas CTV, you just hashed the output, you just lock it to whatever's behind the hash. So OpTX hash would allow the dynamic fee situation, but it is potentially far riskier than something like OPC TV because it's just really hard to know what all different combinations of stuff you can do with it. [01:42:20] Speaker A: Now, Op Cat, and I'm probably going. [01:42:24] Speaker B: To have to do episode and stuff. [01:42:27] Speaker A: On this one as well. [01:42:30] Speaker B: You know what, I'll go ahead and just make the call again, anybody who has any great OpCAt resources, I need to spend a couple of days and really just kind of go down the rabbit hole of this one because I've been avoiding it because it sounds like such a bad idea to me. It seems crazy dangerous. Like I said, just the idea of recursive, like infinitely recursive covenants, I just don't. And as I understand it, you can do that with Opcat. Now, I've been wrong about all of these things before I could understand it incorrectly. I didn't know they had put in or that it was being reproposed with a, essentially a DDoS, a limit on. [01:43:09] Speaker A: How much can be concatenated. [01:43:11] Speaker B: So that you never have to worry about, like the memory problem or using it, crash a node or make a infinitely computable something that's extremely difficult to compute because of the amount of recursive concatenation that you have to do every single time just to validate a simple script like that was a problem. But it appears that those things have been solved for OpCAT has been live on the liquid network for a pretty long time. I mean, that doesn't mean that there's not an attack, there's not a vulnerability or a way to abuse this. [01:43:46] Speaker A: It just means that so far, at least, nobody has. [01:43:50] Speaker B: But also not that many people use liquid. The use of liquid has only kind of really started to move with the implementation of bolts. [01:44:00] Speaker A: With the integration in the SDK with. [01:44:04] Speaker B: Aqua wallet, a lot of these new tools have finally started leveraging liquid. Liquid has barely been used, so it's hard to say that, oh, it's Opcat has been, you know, safe for five years because of liquid, when I don't think anybody have really been doing a lot of advanced programming. There hasn't been enough liquidity on liquid. Ironic for actually testing or caring about. [01:44:33] Speaker A: Building something user facing that might have. [01:44:36] Speaker B: That problem on it. So if anybody is seeking to prove that Opcat is a terrible idea, you have a platform with money that is. [01:44:44] Speaker A: Also growing in usage. In order to test it out, I. [01:44:48] Speaker B: Would love for you to break it or cause a problem on liquid first, go to town. [01:44:52] Speaker A: Also, send me any recommendations on things. [01:44:56] Speaker B: To read about Opcat and send it to me on Noster or telegram, by the way. And you can know you can send it to me on Twitter too. [01:45:04] Speaker A: I still check my DM's. [01:45:05] Speaker B: I'm just, I'm sluggish about it. I really don't like going back over there anymore, but it's still a decent way to get up with me. So after that, there's the script revival and then simplicity. And I actually did not understand simplicity. Like, I didn't realize about this jets thing. [01:45:24] Speaker A: Simplicity seemed interesting to me because of. [01:45:28] Speaker B: How it's designed, how low level, and. [01:45:30] Speaker A: Where the restrictions for how simplicity works. [01:45:33] Speaker B: Are built into it. But I had a very, very basic, again, going back to kind of like the idea related to Mev and some of these things. It's just a very vague idea of what these things are. And the idea that you would build simplicity, you would have simplicity as a programming language in bitcoin scripting system, but. [01:46:00] Speaker A: Then you would still have to soft. [01:46:01] Speaker B: Fork in substitutions like these jets that. [01:46:07] Speaker A: Are built with simplicity. [01:46:09] Speaker B: That just seems like a lot to deal with. Like, soft forks are not, like, they've been a mess. You know, they've been a real hassle. [01:46:21] Speaker A: To actually try to get any sort. [01:46:23] Speaker B: Of consensus around what to do. I think creating a new system for creating more softworks or creating sub soft forks inside of a new soft fork. I really don't think, like, I see that just being a way to never get anything done. Like. [01:46:43] Speaker A: Like, we're constantly. We're going two layers deep on the. [01:46:46] Speaker B: Problems with something that is a very big and convoluted and frustrating problem. And then the script revival probably needs an episode of his own. I'd like to even have rusty on the. To give his spiel. And there's been a couple episodes that. [01:47:00] Speaker A: I've been needing to listen to on. [01:47:02] Speaker B: That one to really kind of get a good foundation. So I have good questions to ask him because I am typically, I'm just kind of more of a. I'm still on the fence about a cat. And the idea of introducing OpCat with a whole bunch of other stuff at the exact same time, that just doesn't. [01:47:19] Speaker A: Even seem realistically on the table for me. [01:47:22] Speaker B: Like, I can't even make a decision about Opcat. Like, I would just outright reject that. I don't even see how, like, that's. [01:47:28] Speaker A: Just too much at once. [01:47:29] Speaker B: The amount of risk that you're throwing in by just putting a huge group of stuff together. I don't know, that just seems. That seems way out of, like, this is nuclear. Like, we're not even thinking about this as nuclear grade software and, you know, let chips fall where they may. I don't know, that just seems bonkers, like, reckless to me. But I am happy to hear the argument. And like I said, it's another thing I've been eager to dive down or to dig deeper into. And then, I'll be perfectly honest on the whole AwP, fancy tree manipulation stuff, I'm. I'm mostly lost there right now. I don't really have a stronghold on any of that stuff. Certainly not well enough to explain it. [01:48:15] Speaker A: In a meaningful manner without making just. [01:48:17] Speaker B: A ton of errors or really bad analogies. But I. One thing that Peter Todd argues for, his kind of conclusion here in this whole piece, and what he proposes as the path forward, is, I really like the consensus cleanup stage is just fixing the little things that we've been having. [01:48:38] Speaker A: To work around that can be fixed. [01:48:40] Speaker B: With soft forks and using that as. [01:48:44] Speaker A: A template, as figuring out how to. [01:48:46] Speaker B: Do a non controversial soft fork, because that's still one of the things that we have a big problem with is trying to figure out how to solve fork. Like, we just, it's been a mess every single time, and it's been different every single time. And I think we're in a new environment with new pressures, a lot of new people and a lot of people who don't, who haven't been through this before. [01:49:11] Speaker A: The last saw fork was in 2021. [01:49:15] Speaker B: And it started quite a bit before that. So I really like the idea of just trying to get the easiest thing soft forked and then moving towards CTV. So we'll see. We'll see. We'll be digging a lot more into all of these topics and a lot of the technologies. Again, don't forget to send me anything you have on MeV on OpCAT, or if you find something really good on l enhance. [01:49:46] Speaker A: I do want to dig deeper into those. [01:49:48] Speaker B: And that would be something great to kind of COVID for anybody who's looking for more of the technical stuff and just more concrete information on what they are and how they work. And actually, another great thing would be to just recommend people that I can. [01:50:01] Speaker A: Come on the show and ask questions, too. So hit me up. [01:50:05] Speaker B: You know where to find me. My in pub, Twitter profile, telegram, all that stuff is right there in the show notes. And you can always shoot me a message on fountain, send me a boost, ten sats, whatever. You can leave a message. Or of course, you could just shoot me a tag me in noster. I'll probably see it there, too. And of course, don't forget, if you want to support the show, obviously you can boost on fountain the value for value and streaming sats right now, one of my episodes, actually. [01:50:30] Speaker A: You can earn sats by listening to it. [01:50:33] Speaker B: And all you guys who stream sats and who boost, thank you. Thank you so much for supporting the show. And of course, if you have not gotten your cold card and you're looking to get one, use my discount code, bitcoin, audible, that also supports the show and let them know that I sent you. And a shout out to those guys for sponsoring and for just making a. [01:50:52] Speaker A: Freaking awesome hardware wallet. [01:50:54] Speaker B: Alright, guys, I am out shout out to Peter Todd Folger Ventures last time for their amazing work. And I will catch you on the. [01:51:04] Speaker A: Next episode of biggest audible. I am Guy Swan. [01:51:08] Speaker B: And until next time, everybody take it easy. Guys. [01:51:27] Speaker A: We are what we pretend to be, so we must be careful about what we pretend to be. Kurt Vonnegut, mother knighthood.