• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Idelto

Cryptocurrency news website

  • About
  • Monthly analysis
    • August 2019
    • July 2019
    • June 2019
  • Bitcoin/Ethereum
  • How to invest in cryptocurrencies
  • News

Bitcoin Core

How Bitcoin Should Be Upgraded In The Future

16/05/2022 by Idelto Editor

The history of Bitcoin upgrade activation mechanisms informs an opinion on how to make protocol changes in the future.

One of the most contentious questions in Bitcoin over the last five years has been how to activate soft forks. There have been many different mechanisms used in the history of Bitcoin to activate new features on the network, the iteration of which has generally evolved with the goal of making feature deployment as safe and non-disruptive as was possible. Until 2017, there was general consensus and not much disagreement as activation mechanisms changed, but during the deployment of Segregated Witness (SegWit), this changed.

SegWit became the issue that drove disagreement and contention over how features should be activated on Bitcoin for the first time. After the initial BIP9 deployment, dependent on miner signaling to lock in enforcement rules, a large majority of miners and mining pools refused to signal for activation with their blocks. At the time, many users became furious that miners were delaying the activation of a new feature and holding it hostage with demands for a hard fork to increase the block size (when, I might add, SegWit accomplished a block size increase through a soft fork), and the entire ecosystem was filled with completely inaccurate information about SegWit in an attempt to drive opposition to the feature itself based on outright lies.

BIP148 and the user-activated soft fork (UASF) wound up pushing miners to activate SegWit, and one of the big block pushes was called off, leaving the other to fork and eventually crash into irrelevance. But since then, Bitcoiners have generally avoided having the conversation about how new features should be deployed and activated. The topic has become contentious to the point of almost being a taboo.

I think it’s worth going through a high-level tour of some of the past activation mechanisms proposed and used before getting into how I personally think upgrades should be handled going forward. Note that these mechanisms can be used for both hard forks or soft forks, the only difference is that a chain split is guaranteed with a hard fork, and only possible in a soft fork if things go wrong.

Flag Day Activation

“It can be phased in, like: if (blocknumber > 115000) maxblocksize = largerlimit It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don’t have it are already obsolete.”

–BitcoinTalk, October 4, 2010

This is the infamous quote by Satoshi Nakamoto after they implemented the original block size limit, speaking to how it could eventually be increased in the future if users deemed it necessary. (It’s worth noting as well that when people called for it early on, Nakamoto was against the idea, and specifically responded with the above quote as to why it shouldn’t be done until needed. The last comment Nakamoto ever made on the issue of block size, found here, also explicitly acknowledged it was ultimately the choice of the users whether or not to do so.) 

This is a “flag day activation,” where a block height or timestamp is selected, and upgraded nodes simply start enforcing new rules at that point. There is no public signaling or visible coordination, people simply download the new client and everyone who has upgraded starts enforcing at the chosen time, and those who have not upgraded do not.

This is how pay to script hash (P2SH) was activated. Flag day activations are, technically speaking, a form of user-activated soft fork, given that it is the nodes on the network committing to activation of a new feature and enforcing its rules. The problem with flag days is that they provide no public signal indicating what percentage of miners claim to be enforcing new rules, so that everyone can gauge the potential risk and likelihood that a chain split will occur. Flag days have not been used in some time.

BIP9

BIP9 was developed in order to further decrease the risk of chainsplits in the deployment of soft forks. The idea behind it was having miners include a signal in the blocks they mine, with new node software only triggering the activation of new features if a threshold (95%) of miners in a difficulty period are signaling to activate the feature. This would give a public indication of how many miners were enforcing the new feature before nodes began enforcing the new rule. Obviously, miners could lie and signal falsely, but the idea was that there is no economically-rational reason to do so. CheckLockTimeVerify and CheckSequenceVerify were both deployed using BIP9, and the original Segregated Witness implementation was deployed with it as well.

The big downside of a BIP9 deployment, as evidenced by SegWit, is that a minority of miners can stall the activation of a feature by refusing to signal. Without deploying something a second time using a different activation mechanism, BIP9 gives miners a de facto veto where they can prevent a new feature from activating on the network. This activation mechanism therefore gives miners a disproportionate control over what is added to Bitcoin; miners are service providers to users and HODLers, and therefore should not have such oversized influence in feature activation.

BIP148 And UASF

BIP148 set a huge precedent as well as implemented a novel activation mechanism never seen before; it was not designed simply to activate a feature in its own deployment, but also guarantee the activation occurred for the prior BIP9 deployment of SegWit. This was the reason for the August 1 deadline. Beginning August 1, the last two-week difficulty adjustment period for miner signaling before the SegWit activation window ended, BIP 148 clients enforced by consensus the requirement that all blocks in that last window signaled for SegWit activation.

This mechanism was a novel activation design not previously needed or used, and was situationally done to correct what was viewed as a major shortcoming of BIP9: the ability of miners to stall the activation of features that otherwise had consensus.

BIP91

BIP91 is another unique activation scheme deployed in 2017 in relation to SegWit. Miners at the time were unwilling to cede to the ultimatum of BIP148, but at the same time were worried about the consequences to Bitcoin if BIP148 activated without miners signaling and causing Bitcoin to split into two parallel blockchains. BIP91 was created in order to find a compromise that would keep everyone in sync on the same blockchain.

It established an 80% threshold, where if that many miners signaled in a difficulty period to activate SegWit, it would start orphaning all blocks that were not signaling (similar to BIP148). The goal was to guarantee that if BIP91 activated, it would stay in sync and compatible with BIP148, which would then trigger the original BIP9 deployment of SegWit, keeping everyone on the same chain. The entire purpose was to give miners an excuse to “be the ones to trigger activation.”

BIP8

BIP8 was the proposed mechanism to replace BIP9 due to the situation that occurred during SegWit activation. The design goal was to have a deployment mechanism where miners reaching a threshold of signaling (90%) could activate the proposal at any given point in the activation window, but to create a mechanism where it was possible to guarantee that a fork is activated if enough miners refuse to signal.

That is the “lockinontimeout” variable. If it is set to true, then in the last signaling period consensus rules will enforce that all blocks in that period must signal for activation, just like BIP148, to guarantee that the new feature activates.

Speedy Trial

Speedy Trial was how Taproot wound up being successfully activated. It was a highly contentious choice of activation mechanisms to say the least. At the end of the day, Speedy Trial functions like a BIP9 activation deployment, except that the activation window is much shorter and the signaling threshold is the same as with BIP8 (90%). Part of the rationale for using Speedy Trial was that if something with consensus failed to activate, a BIP8 LOT=True deployment could be released afterwards.

Many people, myself included, viewed Speedy Trial as a step backwards in terms of refining feature activation mechanisms.

What Now?

The SegWit activation fiasco in 2017 demonstrated the ability of a small minority of miners to interfere with network consensus and feature deployment, which had to be corrected through an incredibly convoluted deployment of multiple different activation mechanisms simultaneously that had complicated incentive interactions between all of them. This was an incredibly risky situation that thankfully worked out in the end, but it very well could have gone disastrously.

In my opinion, the entire point of moving past BIP9 was to avoid recreating the potential for such a situation again. Some would argue that Speedy Trial does so because of a much shorter timeframe before an activation window closes, but I would argue it does not. It still presents the risk of an activation failing due to the maliciousness or lack of response from a minority of miners, and importantly, presents the impression on a social level that miners are capable of “vetoing” consensus among other network actors.

That is what I think activation mechanisms boil down to in the long term. As Bitcoin continues growing, more and more uneducated users are going to be entering the ecosystem. In that learning process, they will be observing everything going on, and most importantly, they will be looking at activation mechanisms through the lens of, “What is going on here, who is deciding whether something activates or not?” Developers? Miners? Businesses? This is the question, and these are the answers, that I think most new users will have running through their heads when we go to deploy new features and upgrades on the network.

The answers people will arrive at ultimately will become a self-fulfilling prophecy in this regard, if users wind up seeing miners as the decision makers, then most users will look to miners. If users wind up seeing developers as the decision makers, they will look to developers. How Bitcoiners approach this question now will set precedent for how future users handle things. There are lots of different opinions on how activation should be handled, but in the interest of not putting words in other peoples’ mouths, I’m going to stick with just describing mine.

I do not think Bitcoin Core or miners should be involved in the activation process in the role of either deploying new activation releases, or in a position where they are capable of vetoing or stalling something from activation. Going forward, I think all new features deployed through a UASF using BIP 8 LOT=True. I think it is important that the precedent we set going into the future is one of grassroots organization that does not consistently come from an identifiable group being seen as the arbiters of what features are or are not activated in the Bitcoin protocol.

If, going forward, we set the precedent of people outside of Core being the ones to propose activation, we set the precedent of a higher level of skepticism toward change in general. We avoid creating the social perception for newer users that developers decide what does or does not happen. This would set a very high bar for enacting new changes, and ensure that bar remains high instead of devolving into a dynamic of users deferring to experts to decide what happens. Activations can occur through outside clients, with the next Core release activating new features if they have successfully been activated through patched clients.

This can allow each “activation client” to be used temporarily during a feature deployment, with everyone switching back to Core after a successful activation, preventing the need to maintain long lived clients outside of Core while still removing the process of activation from Core developers.

Some might argue this creates a risk of chain splits during soft forks, but the reality is that chain splits are always possible during a soft fork. With LOT=True, the point at which a fork will occur will be known ahead of time if one were to occur. If the chain is going to split, it will occur during the final signaling period of the activation when the first block not signaling for activation is mined. This defines a consistent and predictable time period in which it will occur if it does, as opposed to any arbitrary point after activation when some miner not enforcing the new rules mines a block violating that rule.

If there truly is consensus for a new feature, then the majority of the economy will be running a client to activate it, and such a chainsplit will be a minor disruption and inconvenience. If there is no consensus for a new feature, then again such a chainsplit should be no more than a minor disruption and inconvenience as a tiny minority forks themselves off the network. They will be left with the decision to continue using a minority fork chain or relent and return to the Bitcoin network.

Bitcoin is ultimately a market-driven system, where consensus is arrived at voluntarily. I believe attempts to prevent that process from becoming messy are both misguided, missing the fundamental nature of the system, and will inevitably lead to more centralized social control and perception of top-down decision making if people constantly try to remove the mess from arriving at consensus. We should embrace that process, and stop trying to control it.

At the end of the day, this is simply my personal opinion on how things should be done, and there are many more diverse opinions out there. People shouldn’t be hesitant to voice their opinions on this matter. It’s time for us to start having this conversation instead of constantly putting it off, and letting the inertia of social dynamics slowly make the decision for us.

This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

Filed Under: Bitcoin Core, Bitcoin Magazine, English, Forks, Opinion, protocol, SegWit, Speedy Trial, technical, Upgrade

A Conversation About The Controversy Surrounding BIP119

05/05/2022 by Idelto Editor

There are many differing opinions about BIP119. This Twitter Spaces conversation aims to clear up some of the confusion and offer explanations.

This is a recording of a recent Twitter Spaces conversation about BIP119 (OP_CTV). If you would like to submit an opinion about BIP119, please email Bitcoin Magazine.

Listen To The Conversation Here:

  • Apple
  • Spotify
  • Google
  • Libsyn
  • Overcast

Transcript

[0:06] Casey Rodarmor: –BIP repository and they’ll request that a BIP number be assigned. If the proposal is sort of coherent and relevant to Bitcoin, the BIP editor will assign a BIP number and also might make requests for editing or make the document more clear, and then the document will be assigned a BIP number and the pull request will be merged into the repo.

I think the most important thing for people to keep in mind when they are thinking about what is the BIP is to just keep in mind that this is not a formal process for what is accepted and implemented in Bitcoin. If you come up with just an absolutely knuckle-draggingly moronic idea for Bitcoin, and it’s reasonably well-formed, you can apply for a BIP number. And if it’s relevant to Bitcoin and it’s well-formed, the editor will assign it a BIP number and add it to the repository. It doesn’t mean that anybody is going to implement it. It doesn’t mean that it’s a good idea. It’s just a formal process that ideas for changes to Bitcoin go through before they actually are implemented by anybody.

The main purpose is so that when people go to implement a change, they’re going to add it to Bitcoin core, maybe wallets are going to support it, then everybody knows, sort of, what the change is and what it contains. Does it make sense?

[1:44] Mark Goodwin: Yeah, I think that was a very good explanation. It’s a lot of sense to me.

[1:47] Casey: Fun Fact: if you go back to BIP 1, the first BIP, which describes the BIP process, it was proposed by Amir Taaki, who is everybody’s favorite revolutionary anarchist. I think he took up arms and went to fight in Rojava and Syria, so that’s a little deep cut from Bitcoins history.

There’s something else that people need to know about BIPs, which is that they don’t get assigned an order. It doesn’t go BIP-1, 2, 3, 4, they get assigned according to a topic area. And I don’t remember what all the areas are but, for example, I know that the drive chain proposal, I think those were like BIP-100, BIP-101, BIP-102, and I couldn’t tell you what the other topic areas are, but just keep in mind that BIPs are not assigned sequentially. So, it’s incredibly confusing trying to figure out which BIP was proposed, and in what order.

[2:44] Mark: Got you. So there’s no ordinal system to BIPs.

[2:48] Casey: That’s right. Yeah.

[2:49] Mark: Roger that. All right. Well, then let’s get into this particular one. So what is BIP-119 or otherwise known as OP_CTV.

[3:02] Casey: Yep. So, when you have money in Bitcoin, you don’t have some balance which is like a number that goes up and down. You have a set of some number of outputs that you control and an output has some value in satoshis and it also has spending conditions, the conditions under which that output can be spent. The spending conditions are encoded in something called Bitcoin Script, which is a very simple programming language. If anybody’s familiar, it’s very similar to either fourth or PostScript. It’s a very simple, stack-based programming language and you can use a script to encode the conditions under which an output can be spent.

So, one of the simplest forms of a condition is the transaction that spends this output must be signed by this public key. And so if you have a normal sort of vanilla wallet, your wallet is going to hold a bunch of outputs that are encumbered by a spending condition expressed in Script, which says that they can only be spent if a signature that matches your public key is provided so nobody can spend them but you.

Bitcoin has a bunch of unused opcodes, so these are things that currently do nothing, and they’re reserved for future extensions to the protocol. So, finally getting to BIP-119, what BIP-119 does is it redefines one of these opcodes that does nothing, and it basically says, take the transaction that is like under consideration and hash certain parts of it. Things like the order and value of the inputs, which inputs are used, the lock time, the outputs, who the outputs are being spent to, or like what the locking conditions of the outputs are etcetera. So, it takes the current transaction and it takes all these bits of it and hashes it, and then it requires that that hash match some pre-existing, some hash that’s been encoded in the spending script.

So, this is a very complicated way of saying it, but basically, it says that the transaction that spends this output must have a certain form, for example, which coins it spends– sorry, coins and outputs, in this case, are synonymous. Which outputs it spends, which outputs it creates, and how it allocates satoshis between those different outputs. The name OP_CTV stands for OP, which is operation or opcode and CTV is Check Template Verify. I forget whether check or verify. Basically, it’s called Check-Verify because it checks the condition and fails the script if that condition is not met and it’s called Template because this sort of combination of properties of the transaction that it commits to is essentially a template for a transaction saying this pending transaction must be made according to this template, otherwise, you can’t spend this coin. Does that make sense?

[6:38] Mark: Yeah, absolutely. So, perhaps one of these templates you might call a covenant perhaps?

[6:45] Casey: That’s right. Yeah, that’s right. Yeah.

[6:48] Mark: So, let’s get into that a little bit and I know Jeremy just joined, which is awesome. Hello, Jeremy. Thank you for joining us. We’re going over the very basics so feel free to jump in and correct us at any point. But, yeah, let’s get into what our covenants are, Casey, and how it relates to that sort of template restriction model you’re sort of talking about.

[7:06] Casey: Yep. So, I mean, I’m using the word Template but you could also say that it’s a covenant. I kind of like the word Template because it’s a little bit more friendly and, to me, at least, it’s a little bit more evocative of what the opcode is actually doing. But I think we should restrict ourselves to talking about covenants, so, yeah, a covenant is some restriction that is placed on some coins. So, a very simple covenant is the sort of spending condition that I described before. Where, for example, you can only spend if you provide a signature, with some public key. That’s like a very simple covenant, right? It restricts how this coin may be spent. And OP_CTV creates these transaction template covenants where it restricts other properties of the transaction.

Just to give a concrete example of why you would want this, I think the classic covenant example that is used for OP_CTV is that of a vault, so you have a bunch of coins, you don’t want somebody to steal those coins, but you do want to be able to spend them. So, you send them into a vault and you use OP_CTV in the spending condition for the vault outputs that you create and the spending condition is that these coins, once you broadcast something like a spending transaction, you can send those coins or let me say this better – you can either send those coins to a hot wallet after some time out, like two weeks, or there’s an alternative transaction that sends those coins to a cold wallet.

And so the idea is that the coins are in the vault and you can move them to your spending wallet, but it’s going to take some time and at any time while they’re moving to your spending wallet, you can, sort of, claw them back into cold storage. And the idea is you’re walking around with your spending wallet, you do a withdrawal from the vault to your spending wallet, but then it gets stolen by an attacker or malware, whatever. And so, you have time to broadcast this alternate transaction that moves the coins back to your cold storage, which is like somewhere that you think is going to be safe. So, this gives you the convenience that you can get your funds out, and as long as your hot wallet is not compromised or you have a week or two to broadcast this other transaction, your funds are going to be safe.

[9:49] Guest 1: Hey, Casey, do you want to quickly define how that differs from Child-Pays-For-Parent or Replaced-By-Fee?

[9:58] Casey: Oh, sure. Yeah. So, Child-Pays-For-Parent and Replaced-By-Fee are both ways to replace transactions in the mempool before they’ve been mined by miners. So, there are ways to incentivize the miners to include one transaction over another. In some cases, they can be used to sort of prevent something that you don’t want to be mined from being mined but it’s a suggestion to the miners. It doesn’t restrict them in terms of what they could do. So, in this case, yeah, you could use either one to sort of try to redirect funds, IE, like you create a bad transaction, maybe you create another transaction that uses RBF to do what you want but it’s not enforceable. And then, if this bad transaction that you would like not to get mined is creating an output that an attacker controls, then they can also use RBF and Child-Pays-For-Parent to try to get the money to themselves. So, you and the attacker will sort of both be bidding to try to get the minor to mine the transaction that you wanted. It’s kind of similar but it doesn’t really provide hard guarantees.

[11:21] Shinobi: Hey, Casey, real quick and correct me if I misheard this, I’m kind of eating right now. But I think I heard you refer to like a normal, like script pov or like a public key script, like just a traditional output encumbrance as a covenant. I really would not consider any type of Bitcoin script a covenant, unless those encumbrance conditions are applied to future transactions. Because just dealing with the output that exists now that allows it to be freely spent, I would not definitionally call that a covenant. The whole notion of a covenant is that it’s restricting the future spending conditions when you go to spend the existing output. And in a normal public key script, you have to meet the condition of providing a signature that matches that pov key and verifies but you can freely spend it everywhere.

The whole notion of a covenant is that when you meet any other spending condition, there are still restrictions limiting where you can spend it.

[12:35] Casey: That seems totally reasonable to me. I don’t think I’ve thought about what the precise definition of a covenant is, but I can definitely see where you’re coming from. Right? It’s like a normal Bitcoin Script determines how it can be unlocked and then a covenant says what you can do with it from there.

[13:02] Shinobi: Exactly. Yeah.

[13:05] Casey: Yep. That’s a totally fine definition that I’m perfectly comfortable with.

[13:08] Mark: Speaking in that field right there, one of the often-discussed features of OP_CTV is the time-locked release of funds with an example, sort of being like at the beginning of the month for rent, you can get a set amount of satoshis sent to an accessible wallet, which gives you the ability to still access when you need it knowingly but then also– [crosstalk]

[13:36] Casey: Jeremy, I think your connection is kind of bad.

[13:39] Shinobi: I’m sorry. Robot Jeremy, can you put regular Jeremy on the phone with us?

[13:45] Mark: Bummer. Well, just to kind of finish what I was saying. The question there – how does this work, and why would a user pay the fee to construct a transaction in this way to sort of limit the amount of touch to their cold storage wallet? Why is this advantageous? Why would this be a feature used?

[14:10] Casey: So, one nice thing about this OP_CTV vault construction is that they don’t need to get their cold wallet online. In the normal course of things, a cold wallet stays offline, doesn’t need to sign any transactions, and only in the emergency case do they need to bring their cold wallet online and sign transactions. So, that’s great. Your cold wallet can be super inconvenient. It can be spread under rocks in six different national parks or whatever and super secure and you can, yeah, just use your Bitcoin more comfortably in a more secure way.

[14:48] Mark: One of the other notable discuss features is sort of lovingly referred to as like, congestion control, sort of, fee market throttle mechanism that allows for distributing evenly in block space fees. How exactly does OP_CTV allow this to happen and make it available? And why would this be a good thing? Why would we want this even fee market?

[15:18] Casey: Right. The classic example is you have an exchange and you have a whole bunch of users who have coins on the exchange and they want to make a withdrawal and they don’t actually really care or they have various levels of sensitivity in terms of when they want these coins to be spendable by them. But what they all want is they want to make sure that the coins will be spendable by them eventually. Like, before the withdrawal takes place, they’re trusting the exchange to process the withdrawal. So, instead of waiting but let’s say, additionally, space is limited and fees on the blockchain are very high.

So, how OP_CTV can help is the exchange can make a single very small transaction, that uses an OP_CTV spending condition, and that transaction is broadcast and mined immediately with a relatively high fee rate, and that transaction using OP_CTV sort of commits to expand into one or more transactions that actually pay out all of the customers. So, imagine, there are a thousand customers, they all want one Bitcoin off of the exchange, the exchange makes this one transaction that pays a thousand Bitcoin to each of these thousand users, but it doesn’t actually create those outputs yet. It just commits to creating them in the future and the advantage of doing this is that this initial transaction that commits to paying all the users is very small.

And so, the exchange can pay a relatively high fee rate to get that transaction mined immediately, and once that transaction is mined, there’s still another transaction that needs to be broadcast for the users to actually get those funds spendable in their own wallet, but those transactions no longer are relying on the exchange. You no longer have to trust the exchange that those transactions will happen. The initial transaction that was mined commits to all of those transactions. So, those transactions can happen later as users want them and wait for a lower fee rate period to get those transactions mined.

[17:41] Guest 2: So, just to clarify real quick, whereas now we have basically two types or classes of transactions, like in the memory pool, and then confirmed, this would add a whole new class to the mempool which would be those committed [inaudible] is that right?

[18:03] Casey: Yeah, sort of. It doesn’t really add them. You wouldn’t say that it adds this class of committed transactions to the mempool because transactions are committed, they’re mined, and they’re not in the mempool anymore. But, yeah, definitely adds this third class transaction state, which is this transaction is committed to be mined and it can be mined whenever anybody broadcasts on an appropriate template transaction that satisfies this.

[18:37] Jeremy Rubin: Well, I mean, Casey, I’d go a step further. It’s just guaranteed to happen. Unless that original transaction is reorg out of the blockchain, it is literally impossible for the descending transactions to not eventually get mined because that originally committed output is only spendable through those predefined transactions. So, as soon as that first one is confirmed and has a good amount of work on top of it, all of the ones descending from it are absolutely guaranteed to eventually confirm because by consensus, literally, no other transaction could ever spend that confirmed output.

[19:21] Casey: So, guaranteed just seems like such a strong word. For example, somebody does still need to be holding onto the spending transaction, right? So, if the transaction that satisfies the template was lost and nobody was storing it, then those transactions would never happen. So, I see what you’re saying, but like, guaranteed, man, guaranteed is a really strong word.

[19:48] Jeremy: As close to guaranteed as it could be. It’s more guaranteed than a lightning channel state in that you can still try to double-spend a lightning channel with different states. But when you’re using CTV, there is no other valid way to spend.

[20:05] Mark: Hey, when you have a UTXO, in general, how do you know that you can spend it?

[20:10] Casey: Is this a rhetorical, philosophical question? Do you know that you can satisfy the conditions of the spending script?

[20:17] Mark: Yeah, but until you’ve actually spent it, you don’t know that you could spend it.

[20:20] Casey: Because maybe there’s been some soft work that you missed that change the consensus rules?

[20:28] Mark: Sure. I mean, yeah, there are lots of things that can happen or maybe you lose the key in the future, and then you can’t do it anymore. Maybe you’re asleep for a long time and then UTXO becomes really popular and you don’t remember where your coin was or maybe your wallet gets corrupted and then you go get it from a backup and you don’t have the latest new descriptors that were derived before your life is backed up and now the money’s gone. So, there are lots of things that can lead to issues in this. And I think it’s one new class of something in a space of like, a lot of things that can happen like that but it’s as guaranteed as anything if you have the information available to you at the time that you’re able to estimate that you can receive that fund in the future.

[21:09] Casey: Yep. Yep. I mean or if it got insanely high, like, fees just skyrocket and you’re never willing to pay the fees to get it mined.

[21:16] Mark: Yeah. And then how would you spend Bitcoin in the future as well if you’re not willing to spend the fees for it?

[21:21] Casey: Right.

[21:22] [ads]

[23:20] Mark: Speaking of the fee market dynamics here, I honestly can, maybe be a devil’s advocate here, see why people have apprehension about any mechanism that appears to affect the fee market dynamics of Bitcoin. Do you see any way in which this sort of throttling mechanism could negatively impact this natural market for block space? Is supply and demand curve smoothing a good thing for the open fee market of Bitcoin?

[23:48] Casey: I don’t think I have a super nuanced take on this. It seems good to me. It seems like being able to smooth that demand and avoiding spiky fees is good. A more reliable, less volatile fee rate seems good so that people can plan ahead better, but I haven’t thought about it enough to think that I have a deep take on this.

[24:22] Shinobi: I mean, in the simplistic case, Mark, when you use something like CTV and congestion control treaties, you’re kind of locking yourself into a fee rate because you’re committing to the exact hash of an exact transaction. And so that fee rate has to be specified. So, for all the transactions in a congestion control tree unfurling, that fee is locked in. The only way that you could alter that would be with like Child-Pays-For-Parent if one of the outputs of one of them was freely unencumbered to be spent anywhere. But to go down a little bit of a rabbit hole, if you compose CTV with Taproot, in theory, you could have different tap tree spending paths that commit to different versions of a CTV congestion tree at different fee rates.

So, ultimately, you would either just have this blob of transactions that all have fee rates locked in that regardless of where the highest fee was, they would be in the same fee rate area of the mempool or if you want to go down a crazy complexity rabbit hole, there would be the potential to have different tap trees with different CTV paths and scripts so that you could kind of submit whichever ones you want based on the fee you’re willing to pay and what the mempool is looking like at the time.

[25:57] Casey: I think you could also include like a small, anyone can spend output that somebody can use to attach a Child-Pays-For-Parent like at every stage in the unfurling, leave a little dangling output that can be used to bump the effect of a fee rate.

[26:15] Shinobi: Actually, I had not thought about that before right now. Yeah, that would be a lot simpler. It’s no punch of different tap tree paths.

[26:23] Jeremy: And I think one thing that’s important, too, is you can play with the parameters on anything like that where you could do, like, let’s say there are 10 branching factors per node, so then the overhead of having one-off true output is pretty low. If it’s 1 over 10.

[26:40] Mark: Sort of interesting it seems to me that covenants are sort of restrictive by design and yet, I think there’s a lot of fear about expanding conditions with the new opcode bringing up these sort of unforeseen attack vectors. Do you guys see any validity to this that could come from such implementation?

[27:02] Jeremy: No, not with OP_CTV. With other covenant designs, there are potential worries of things you could do like get coins forever stuck in some extra spending condition they could never get out of. But with CTV, because you have to exactly define an exact transaction ahead of time, it’s kind of impossible to make this general covenant that you can never get out of but people can still spend money around because it’s not like you can have a CTV coin and then choose where to spend it. It’s already decided ahead of time where it’s going to be spent. So, there’s no way to do weird things like the covenant where the government has to sign off on every transaction you make and can’t deny it. That’s just not possible to do with CTV.

That’s personally one of the things that I really like about the proposal is it’s so narrowly defined and specific that there’s no risk of that type of thing being done with it.

[28:12] Casey: I think it’s also just worth underlining how simple OP_CTV is. It’s a very, very simple opcode. It looks at the transaction that’s being processed, it hashes some bits of that transaction, and then it asserts that that hash is equal to the hash that it got is equal to some pre-existing hash. It’s not like a sort of weird, arbitrary, smart contracting mechanism. It’s a very extremely simple construct and I feel pretty confident that not only is it probably useful and probably can be used for the things that people want to do with it, that’s like one part, but also, let’s say that there was something wrong with it, then everybody could just ignore it. Everybody could just go back to not using OP_CTV and your coins would not be effective and nobody can somehow force you to accept an OP_CTV covenant that you didn’t sign up for.

If you send somebody an address, there’s no way they can send funds to that address and also encumber them with OP_CTV somehow at the same time. So, it’s totally opt-in and if it’s bad, you can just ignore it.

[29:33] Mark: Do you think kind of going off that, this would be a good time to define what a recursive covenant is versus not recursive covenant?

[29:44] Casey: Sure. So, a recursive covenant is just a covenant that is recursive – not helpful at all. Recursive meaning that you can say, okay, I have this Covenant X and then when you can satisfy the covenant, you can do something, but then some or all of the coins need to then go back to Covenant X. So, the sort of classic scary example of an evil recursive covenant was, like, the government publishes an address and says, every coin now has to be a multisig that includes this address and additionally whenever you spend from such a multisig output, it’s enforced in the covenant that the funds also have to have this malevolent government address as a cosigner to the output. So, the covenant can sort of last indefinitely into the future.

OP_CTV does not enable this just by its very nature. An OP_CTV covenant can specify many steps into the future but it can’t specify an infinite number of steps in the future. After some sequence of transactions being mined, the OP_CTV covenant terminates. It can’t control what happens further down the line.

[31:09] Mark: Very cool. I guess just to let you know, we’ll wrap up the first half hour and then I think we should open it up and kind of talk about the BIP process.

[31:17] Casey: Just go ham, you know.

[31:19] Mark: Yeah. I hope everyone’s sharpened their canines and their knives. No, just kidding. All love here. But for me, I think one of the interesting parts of this debate is sort of the ossification versus the necessity of invention and where we have to go if we want to serve, say, five billion people on the Bitcoin Network. So, how could this BIP allow larger numbers of users to open batch channels for Layer Two solutions in a small amount of block space? How is this something that can help us scale?

[31:57] Shinobi: Well, I was just getting my knife sharp, Mark.

[32:01] Mark: Good. Good, Shinobi. Get ready.

[32:04] Shinobi: One of the biggest shortcomings with lightning is the limitation on opening and closing channels and there is just no way around that. If that bottleneck gets too large, then lightning just hits a scaling ceiling. So, CTV cannot– I mean, Jeremy can probably spitball and get into and help with closing channels. But as far as what he’s got written up and designed right now, they could absolutely help open channels and it’s literally just everything about how a congestion control tree works, it’s just using that, except at the end of that tree unfurling and everybody finally having unilateral control over their coins, they’re just Lightning channels, instead of all the coins winding up in a single sig address. And it can be a lot more beneficial than just a normal withdrawal tree because once that initial output is confirmed, you can effectively treat those lightning channels as open and you can use them because, eventually, that tree of transactions is going to unfurl, unchain, and all get confirmed. And then those individual UTXOs that are lightning channels will actually be confirmed on-chain.

And so, like, there are still potentially, issues, really annoying shit, like if your channel counterparty stops responding to you while you can’t go close the channel until the tree starts or finishes unfurling. But as long as your channel counterparty is cooperative, the minute that first output in the beginning of that congestion control tree is confirmed to the depth that you require for a normal lightning channel, you can treat all of the channels that that single output is committing to as open and you can start using them. So, it massively increases the scalability of onboarding people onto the lightning network. And that, I think, personally, is one of the biggest benefits of CTV. That is the most effective, impactful use case that I think personally comes out of that.

[34:37] Mark: Do you think right now, Shinobi, that Bitcoin could service the entire world without an additional opcode? Or I guess just additional development beyond just current operational upkeep?

[34:49] Shinobi: No. If Bitcoin froze where it is right now then the reality is 95% of people on this planet are going to be using custodians, they’re not going to be able to solve custody of their own coins, and that’s just the harsh reality. I think that Bitcoin eventually does have to ossify to be secure neutral money, but if that happens right now, kiss the entire idea of an entire planet of people self custodying their own coins and dealing with things in a self-sovereign way goodbye.

[35:27] Mark: Yep. I mean, if people get priced out of main chain transactions that will certainly happen, unfortunately. Well, not certainly happen, but certainly possible happening. All right. Well, I say, let’s open things up.

[35:42] Casey: Can I ramble for a minute about Bitcoin governance?

[35:45] Mark: Please.

[35:46] Shinobi: Can anyone stop you?

[35:48] Casey: No, nobody can stop me. Actually, they can. I’m not a co-host. So, I think it’s just really interesting to talk about what is Bitcoin’s governance process and it’s very chaotic and very messy, and I think that that is very much a good thing. Bitcoin just has all of these different stakeholders, it has users, it has developers, it has miners, it has exchanges, it has services, it has custody providers, it has all sorts of people doing all sorts of crazy things. The BIP process is kind of the only formal bit of governance that Bitcoin has and it’s a very weak form of governance. It’s not really there to tell anybody to do things. It’s just there to sort of tell everybody the things that they might want to do. And I think that this is actually kind of good.

If you think about any sort of formal process that you might imagine for Bitcoin, some sort of vote or some sort of board, or some sort of miner voting or proof of stake, horrible, whatever. Any one of those processes is going to enshrine the ability to ramrod through a not great or a sort of contentious proposal if enough people agree to it. The current Bitcoin process which Jeremy is currently up to his knees in is this very messy thing where you sort of have to explain your idea and explain why you think it’s a good idea, find people who want to use it, explain to them how it can benefit them, implement the code, write the spec, etcetera, etcetera, etcetera. But at the end of the day, there’s no one party that can ram it through or no official entity that you can appeal to, to make your change happen.

And so that means that like, yeah, you sort of have to get this broad nebulous consensus of enough people and enough stakeholders, and if any one stakeholder, and by stakeholder, I don’t mean individuals. But if anyone major sort of group of Bitcoin interests, really hates it, they can stop it from going through to some extent. And I think this is really good. But one problem with it is we do see the situation right now where, not to editorialize, but I think BIT-119 is great. I like it. I think it’s simple. And there isn’t a clear path for it to get into Bitcoin, but that’s kind of because there’s no clear path for anything to get into Bitcoin. That’s okay but, yeah, also got to deal with some of the inconveniences that that poses. So, yeah, ramble over.

[38:40] Shinobi: Well, to respond to that with another ramble. Maybe the last six or seven years, this is how I’ve thought about how Bitcoin “governance” works. Bitcoin is just a mob. It’s literally a mob of people currently engaged in a mindless thing in one direction and in order to change Bitcoin, you have to get up there and convince the mob to do something else without getting skewered alive, yeah, and that’s just how that works. It’s total anarchy. Sometimes maybe beating your head on the wall for a long time convince the mob to do something, maybe sometimes you can get a small fraction of the mob to break off and go form another one, and sometimes you get skewered alive.

[39:40] Guest 3: If I may interject there. I maybe interested to get my thoughts because it seems like a lot of the objections currently, I know we haven’t really talked about controversy in this talk about controversy, but it’s about technical consensus in the idea that CTV doesn’t have technical consensus.

[39:57] Casey: Yeah. I mean, the developers are also in the mob, right? So, that’s what technical convinces is. It’s like talking to the mob of developers and trying to convince them what to do.

[40:09] Guest 3: Well, it seems like the inference with the technical consensus is something that happens before user consensus, right? Like, I mean, it seems from like my reading between the lines with the various threads and telegram channels, I don’t know if you guys would agree with that, but there seems to be this overwhelming kind of voice from the kind of older group of developers that there needs to be some sort of technical consensus, and then there’s user consensus and then there’s that order of operation and it’s that order of operations that’s particularly in violation here.

[40:39] Jeremy: Hang on. I am very certain that I had a technical consensus. I am very uncertain what technical consensus is but I’m very certain that I have it for CTV and I think that’s something that’s like a weird position to be in but there’s not really a rigorous definition of it. And there’s also not really a rigorous definition of what threshold to these things you’re supposed to be seeking and there are other parties that matter other than just like developers decided and now it’s something that’s ready to go. One concept that I really like to bring up is, in Judaism, if you are doing a rabbinic tribunal to decide if somebody should be put to death, just a little bit like a soft work, right? If we’re deciding that we’re going to put the existing version of Bitcoin to death permanently and we’re gonna have a new version of Bitcoin.

If one of the people in that tribunal doesn’t say that this person should not be put to death, they get to go free because every life has some redeeming property that should happen. In the same way, every software has some reason why it really shouldn’t happen. If nobody can come up with a reason that’s compelling that it shouldn’t happen, then probably there’s too much groupthink, and we’ve not done an actual job of thoroughly evaluating this thing because we all agree on how it should be. Actually, sometimes descent means that people have put thorough thought into actually considering the reasons why somebody might not like something, and when you see too much consent, consent is not consensus. It means, maybe there’s groupthink going on.

And when I evaluated CTV under this regard, what I saw was across the board. The experts who you might want to speak to about this who have actually spent the time thinking about this issue, all basically had around the same line, which is, well, CTV seems okay, but it’s kind of a subset of the things that I’m interested in and I’m not positive that the applications built on it will be sufficiently interesting for what I would like to build, right? So, under that lens, none of the experts had an actual issue with CTV as an implementation. Any issue like, oh, this is going to break this, or I think this will have an issue with some aspect of something else. It was just, “Oh, well, maybe I’d want something else in a couple of years,” and that’s not rival with CTV.

That’s just like, okay, well, now, it’s really a question now that this form of technical consensus, which is a form of acceptability has been reached, now, it’s a question of, well, is this something if you’re saying nobody wants to build on this, now, is this something other people want to build on? And if people do want to build meaningful things on it, then cowabunga, let’s go. That’s technical consensus, let’s see what the market wants. And what happened, in this case, I believe, is a bunch of middle manager technical experts popped up saying, “This does not have technical consensus. This does not have technical consensus,” without even really defining exactly what that means. And that’s sort of where people then got this idea that there wasn’t a technical consensus rather than actually making an honest effort at evaluating what other people had actually evaluated and why I was reading technical consensus from the statement of other people who are involved in the technical discussion so far.

[43:43] Shinobi: I mean, to build off that, Jeremy, what comes to my mind is the whole idea of rough consensus from the IETF and the whole basis of that has absolutely nothing to do with voting or a number of people who approve or disapprove. It is entirely about substantial material criticism and whether that criticism has been able to be addressed or not. And the entire notion is that – no matter how many or how few people raised criticism of something, if that criticism has been actually addressed and shown to not be a valid criticism, then something is considered to have a rough consensus. And I have not seen any valid criticism against CTV except we can do better. And if that’s the whole argument, well, then that brings up the whole question of – well, how long do we sit around and wait? How many times can people just pop up at the last second, go, here’s something that could be better and just keep doing that ad infinitum before we go, “This is enough.”

[44:59] Jeremy: Hold on. Let’s just say most regular Bitcoiners were against and who cares about whoever’s the most influential people are, and even whatever technical consensus means. If most regular Bitcoiners, people that had gone on spaces, go to Bitcoin meetups that you meet at a conference. You know what? We don’t like the idea of, kind of, maybe it’s cool, maybe it’s not. [crosstalk]

[45:32] Shinobi: Do you think that’s not a negative? Do you think that’s just like who cares or is that considered a negative to you in the process of consensus?

[45:39] Jeremy: I mean, basically, at that point, then they can make their choice of what to run or not to run, and that is the users say who is not a technical person who is not going to get involved in critiquing these things. Like, I’m sorry, dude. I used to be very sympathetic to that argument after Taproot, just no. With all the hoo-ha about Taproot and then after it was activated, most of the people I see in this space have no fucking clue how it works, anything about it. They were just repeating marketing sales pitches like nonsense without any actual understanding of what it can do, what it can’t do, how it actually works.

The reality is most users have no fucking clue how any of this shit work or the technical reality of it. They have their choice, which is what to run or not to run.

[46:37] Pete Rizzo: So, is technical consensus, in your opinion, there’s no issue, like, there’s nothing wrong with it or it’s technical consensus that this is 100% good because it seems like that’s all this mean, right? Some people think consensus thinks, this is great, everybody loves it, and some people think rough consensus is, there’s no problems. It sounds like that’s what you’re asserting, your guys’s definition.

[47:01] Jeremy: Well, I think at least in as far as I can see it, I view the market in the general set of folks who exist in this space is determining some sort of roadmap of what types of way Bitcoin should be moving and I do not believe that is a thing that is in the hands of developers who do technical consensus. I think developers read what the market should be wanting and it asked for people, like how many times have you had a developer approached you and be like, “Hey, how can Bitcoin solve problems for you? Like what’s not happening in Bitcoin right now? And what are the issues that you face that you feel are not things you can solve it the application layer?” And in that sort of a thing that you read from the ecosystem and then developers produce solutions for that and determine if those solutions are sufficient for what the market needs.

I don’t think that it’s a bunch of people who jerk around all day and come up with fancy toys and then put them on the market and see if they do well. To me, you may all agree on what the thing is to put out but really a lot of the process is in finding what the product consensus is, what people need, and what’s going to actually solve problems and then determining if you can ship a solution. It’s not about getting everybody on board with the thing they’re most excited about.

[48:20] Guest 4: Yeah. So, Jeremy, I’m curious. I’m curious for you to agree with me on this. And Pete, this ties into your question as well. So, I think, in your definition of technical consensus versus product consensus, the line to me seems to be technical consensus is – can we agree that this new change does no harm, right? There’s no downside that this is like a fine solution to a problem and that it definitely doesn’t harm and users of the protocol. Have you guys like kind of like checkbox one and then and I do think actually CTV generally is there and then it’s kind of like checkbox two which is, is this the best where best is very relative dependent on what your priorities are, is this is the best way to accomplish this in Bitcoin? Would you agree that that’s kind of like the distinction that we’re in right now?

[49:12] Jeremy: Yeah. I think so and I think a lot of where that gets tricky is there’s like limited attention and limited time and if they’re not rival at a protocol level, their rival in terms of what people spend time working on.

[49:27] Guest 4: Yeah, and so along those lines, one thing that has become pretty clear throughout the last couple of months of discussion is on a kind of what applications do we think are most valuable for covenants to enable? It seems like there’s like general consensus being an overloaded word, but general agreement at least that the two types of applications are vaults and then payment pools. CTV does those both fine, there’s working code for both of them in CPO, but I do think we’ve released– that has successfully been shifted to where it’s like covenants are good. It’s okay to want covenants. And CTV is a non-harmful way to do covenants. Right? And now we have, I think this new third thing, which is the covenant that we introduced should produce really good vaults and really good payment pools, right? I think that’s kind of like the current state, which is to be fair, worlds farther. We don’t have any of that agreement a year ago, right? So, the conversation has been moved quite a bit, which I think is great.

[50:40] [ads]

[51:29] Mark: I wanted to ask a question. Just when we’re talking about like point one of – we’re agreeing that CTV does not cause any harm. I think this has been answered and in my rudimentary understanding of it right now, this is one of the things that I’ve particularly not kept up with at all. Covenants and CTV lately is just kind of been this big blank space for me. The one thing that I feel like a lot of the conversations on Twitter about covenants have been, is this idea of encumbering other people’s addresses? Like there was a tweet today or something, somebody was saying, oh, there’s a new law and the government says that, you were only going to be able to reset Bitcoin–

[52:16] Jeremy: That’s not possible. That’s just not possible with CTV. You could with other covenants, but not CTV.

[52:25] Mark: Yeah, I mean, I think it’s a terminology issue.

[52:32] Jeremy: Specifically though the distinguishing between the example, because other people were saying, oh, you can just require that you have like a government multisig or whatever. It’s like, well, no shit. You got a law that said any stupid thing, right? And it seems like this is obviously should be the case but if I give them my address that I generated from my keys and my wallet with whatever script I wanted and give it to them, it cannot be encumbered with any other CTV restriction. It’s just my address and my control, correct? If they agreed to withdraw to it.

[53:14] Casey: Yeah, when you give somebody an address–

[53:16] Jeremy: That’s already encumbered with everything, right?

[53:17] Casey: Yeah. Exactly. That address encodes or commits to the Bitcoin script that will spend those coins. So they cannot pay you to that address without using your script, which means that you specify, which means they cannot stick OP_CTV in there without making it essentially paying to a different address which is not the address you gave them. In that case, be sending you the coins.

[53:46] Mark: It didn’t seem like that could possibly be the case, just on my understanding of that, but because I didn’t quite know, I didn’t really understand how a covenant would work any way that you could encumber things later down the road. I was admittedly like a little bit, like, “But how?”

[54:03] Jeremy: Also, I think, this is what a lot of the plebs, maybe, don’t get, is that they think that they have formed a strong anti-consensus set with the technical consensus committee bureau or whatever, like, oh, CTV is not the thing but I think what’s not really being realized or at least like clearly explained is that the reasons why general pleb kind are like, “Let’s not rush this thing in. Let’s think about it more,” is precisely because there’s a worry about introducing some of these really sophisticated complicated things that have a massive social risk for what Bitcoin will look like. And then almost universally, there is technical consensus among the technical wizards that we should have full-blown, pie-in-the-sky covenants. It’s just a matter of time until we find the one that we like enough to advocate.

And I think that people don’t necessarily see the storm brewing around that question that it is not something as far as I can tell talking to a lot, a lot of Bitcoin users is desired. People want Bitcoin to be the sound money, strongest store of value possible. They do not care about having every possible fucking application. What they do care about is having sound money and having a scale to the largest number of people possible without violating the soundness of the system. And that’s really where something like CTV and there are other possibilities for things that can fill in gaps like that. It is a waypoint of not introducing almost anything more than is already possible today with the worst trust assumptions, but still doing something pretty useful that’s like a covenant.

Anything more, you do start getting into the territory that you’re talking about. And it’s a difficult trade-off space, but I don’t think people know why they agree to disagree over CTV. I don’t think they realize that the way that the core development process or whatever technical consensus process is leading is into something that’s much, much, much more complicated and has some of these negative trade-offs for like the what is Bitcoin question. Bitcoin is still going to look like Bitcoin with CTV but these other things will be a very different type of system.

[56:19] Shinobi: To translate that to pleb real quick, anybody worried about weird shit like the government forcing coins into some magic script where the government has to sign off on everything, and those coins can never escape that, it is absolutely impossible for CTV to do that. All the developers arguing against CTV are not arguing against CTV to avoid things like that. They are arguing against CTV because they want more complicated covenants that move closer and closer to things like that being possible. Now, that does not mean that every other covenant proposal out there enables things like that, but that’s the direction that technical developers want to go is closer to things like that being possible.

[57:18] Jeremy: And the way that we typically dealt with this kind of controversy in the past with Bitcoin is by being patient. If enough people want to look at other stuff and see how it compares or whatever, like the thing that solves that is time, and one of the biggest things I’m hearing, and one of the biggest reasons there’s controversy isn’t because I’m hearing anybody say, like, “You know what, screw CTV, we want this instead.” I’m not really hearing that. What I’m hearing is really, “We need time so that people can consider other things and CTV itself as well.”

I mean, sure, CTV is solid, and pretty much everybody agrees CTV is solid but the thing that I hear people are saying a lot is they feel like we need more time in general, even at general plebs. We just got Taproot. It’s so short and you think, well, who cares? Like logically if you’re just being logical, who cares? It’s good. People like it. It’s not risky technically. Let’s just do it. Who cares that ?it’s not been a long time. I think people do care. And I think it matters.

[58:14] Casey: The complexity of other solutions and the simplicity of OP_CTV. None of the other things that have been proposed or are sort of considered as alternative covenants have the incredible bang-for-buck ratio of OP_CTV. OP_CTV is just so simple. It’s like caveman technology and I mean that like in the best possible way. It has limitations, but everything that’s sort of more flexible, winds up, being way, way, way, way, way more complicated. I think even if somebody came up with a more featureful covenant proposal, I think there’s a good chance that I would still prefer to also have OP_CTV so that I could opt for that incredible simplicity when I didn’t need those more featureful things of whatever, some arbitrary future coming that scheme can give.

And that, I think is an argument against why it’s not like the sort of just wait and see argument, isn’t super compelling for me. It’s that, yeah, maybe somebody will come up with something, somebody else after a lot of development. But that thing will definitely be way more complicated than OP_CTV.

[59:28] Shinobi: Let me, really quick, to respond to what Casey was saying. Bitcoin changing is threading a needle. Yes, change should be approached cautiously, things should be analyzed thoroughly, and things should not just be done whimsically, but just look at pay to script hash, CLTV, and how quickly and easily those changes went through versus things like SUG would, like Taproot. Bitcoin is growing. It’s getting bigger. And the bigger it grows, the more difficult, the more time-consuming, the more friction there will be to changes. And it’s just a simple reality right now. Bitcoin as it is will not be a self-sovereign money for people in the world. It does not scale. It cannot accomplish that goal as Bitcoin is right now that is a pipe dream and we will see how the prognosis from 2010 play out if it froze right here, right now.

Everybody’s going to be using banks. No one’s going to be self-custodying their own money, nobody is going to have the freedom that that ability affords. So it’s threading the needle, it’s finding the balance between those two things. We have to approach change cautiously and actually think it through, but we can’t just sit here on our asses and pretend like we can just wait forever. Because that day if Bitcoin is going to work will come where it’s just not changeable anymore. And if it isn’t scalable enough, by the time that day comes, then we are not going to have self-sovereign money for people. That’s not going to happen.

[61:21] Casey: I really don’t care about like the last five percent of people, I’m gonna still be able to use Bitcoin exactly the way it is forever.

[61:30] Shinobi: No, you won’t, Casey. That’s a fucking delusional pipe dream.

[61:33] Marshall: So, as a guy who tried to, I guess you could call it core score in my previous life would make it quite a classic. I’ll tell you my optics are these – people gave the same, oh, we need to wait. It’s like impossibly more complicated and it got in because Peter Wool was a homey of everybody else. Jeremy has pissed on a lot of people. He’s pissed a lot of people off because that’s just how the development community works. If you have committee access and you’re not in the Homeboy Network, it’s just a lot harder for you to get shit through. CLTV by Greg and Peter, they’re in the Homeboy Network, it’s easier to get shit through. That is just the nature of Open Source Development, Bitcoin, Linux, whatever. The fact is, this is more kind of developers bitching and pissing on each other than anything else regardless of the facade of, oh, it’s too complex or, oh, we need more time. That’s the reality as I see it.

I think the code is great. It’s been fully audited. Jeremy has put the money where his mouth is, nobody’s claim the bounty. Nobody really has shit to say. The excuse of, oh, we just got Taproot. You got Taproot because the miners were fucking paying attention. Most of the time, we’re asleep at the wheel. I mean, let’s be honest. That being said, like, that’s not a good reason to not do something, and Jeremy and I talked a lot about this and it’s up to him to self-market. And that’s a big part of what this room’s about.

And so in my opinion, as my history in Bitcoin, it’s more about who likes you and the commit list and who doesn’t like you. That’s just kind of the politics as I see it.

[63:18] Mark: Yeah, I think that’s a good spot. I’m not going to close it out. I want another 25 minutes for questions from the audience. So if the speakers on stage don’t mind, I’m going to start pulling people up. Try and make it brief, ask your question, keep it on topic about CTV, and then we’ll have the people on stage speak about it.

[63:35] Guy Swann: Can I say one thing real quick?

[63:37] Mark: Yeah, go ahead, Guy.

[63:39] Guy: In the fact of its controversy, I really think the reason that’s drummed up so much controversy, not specifically in the developer community, but just because just in the pleb and Twitter in general, is that nobody knows what the hell it is. Like I still think like we just barely– I mean how many years really did we spend just explaining the basics of Taproot and CTV, there’s been lots of talks of covenants and stuff like the dev list and stuff like when I go through all that, but even I have just been kind of brushing over it because there’s just so much of the other shit to go over. And so, what was a very basic question was something that I really didn’t know. And the not very, very naive assumption of when someone says, oh, you can encumber further transactions in the future with what it can do, sounds like it could be a bad thing. So, I think a lot of it is just nobody knows what the hell’s going on.

Generally, everybody’s ignorant and nobody’s got any time to cover all this stuff except for the people who do this all damn day.

[64:47] Jeremy: So, I think one thing I just want to add is that when I designed CTV, I literally designed it with that concern in mind, so I wasn’t putting something out to then evaluate against, oh, do we do good enough for this? That was literally what I had in mind. People don’t want covenants for this reason let me make something. And that’s why it’s sort of, in a little bit of a weird spot. And then in terms of timeline, like CTV specification was finished nine months before Taproot’s spec was finished and the code has been done since then as well. And a lot of why it was not more in the public eye for the last while was people, kind of, I’m not going to say the word ‘threatened’ but kind of put a lot of pressure on me that if I talked about CTV too much before Taproot got done that I was going to destabilize the process that would lead to Taproot. It was going to be on my back that Taproot failed to get through.

So, I sit down, shut up, I didn’t make complaints that I wanted to make about Taproot and I helped get Taproot activated, so that then, I would say, okay, now I can work on CTV. Now, people turn around and say, “Thanks for all the help, Motherfucker, get out of here, get away with your thing.” And it’s like, “Dude, I literally just help you get your things through so that I could like help get this thing through like, okay.” And they’re like, oh, but now the bar should be even higher. I’m like, all right, chill, I’ll show you more work. I’ll show you more work products. I’ll make it better. I’m okay with all that, but I think people just don’t really recognize what the actual process has been from my perspective, which is pretty freaking dysfunctional.

[66:22] Mark: For sure. Hudson had his hand up a long time ago at the beginning of this. So I just wanted to make sure you got a chance to speak there, brother.

[66:30] Hudson: Thanks so much. Yeah, so, I’m Hudson. I’ll do a quick question. And basically, my background is I did some politics stuff in dark coin was kind of early Bitcoin but not super involved in the dev at the time because I was in college and then did Ethereum EIP, which is like BIP but for Ethereum, I was the lead editor.

[66:48] Guest 5: Hudson, can you talk just about Bitcoin, no other coins, please. Thank you.

[66:52] Mark: No, hang on, let him speak. This is a very respected person who’s sharing wisdom and I want to learn anything that he has to share.

[66:59] Hudson: Yes. I’m not about to compare though. This is more just I actually learned from the BIP process and stuff. So, that’s why I was here. But, yeah, I understand. I totally get it. So, yeah, basically from looking at Leekens’ latest thread where they kind of discussed, hey, what’s going on with CTV? A lot of what I saw were people who were semi-prominent within the Bitcoin Development Community kind of shitting on Jeremy and I looked into that a little bit more, and what really bothered me about that was that, was just like Marshall said. What Marshall said earlier is basically the summary of what I’m about to say, which is like it’s like an Insider’s Club. Like if they’re going to tell Jeremy that they’re not doing the right process or they broke some unspoken rule, why can’t Luke Dash Jr. make an alternative Taproot implementation they push out widely and then expect that to go okay and still have all these very high-level accesses to get hub repos they’ve had for years.

It’s like they like shush the crazy person, and just let him do his thing because they don’t want to be political or cause conflict. But as long as people like Luke and others who are problematic within Bitcoin or allowed to have that level of leadership, that’s kind of a symptom of a bigger root problem of a lack of accountability, a lack of process for how to get these things done. So, that’s just kind of what I was thinking on that. But who else has a comment especially it’s more into Bitcoin because why is this happening?

[68:22] Ryan Gentry: I mean, Hudson, I wouldn’t say exactly from my point of view that it’s like the Old Boys’ Club and you’re just in the club or not. I would just say it’s more of a product of things getting bigger, the stakes getting bigger, and people being more paranoid, more skeptical, and just more analytical of people getting involved. Like, I do not see this as like an Old Boys Club that you’re either a member of or not. I just see this as having gotten to the point where the degree of trust and respect amongst different groups or different individuals in this group who even, with that respect and that trust there, still are very animus between each other at times and really get into it. It just takes time to build that kind of trust. And I think the bigger Bitcoin gets, the more time that’s going to take because people are going to be more skeptical, more paranoid because the stakes keep getting bigger.

[69:34] Guest 5: Ryan, that’s not true. Jeremy has been a core dev for longer than damn near anybody else. That’s not true. That’s just not true.

[69:41] Hudson: Well, I guess the other thing is like, even, you can look at the analytics of it. Like, yeah, Jeremy’s had commenced for a while, has had good code, never done anything malicious, but also like from the Bitcoin devs that I hear about like they’ll be in groups of people from different cryptos and talk to them and be like, “Yeah, I have this opinion, so and so,” it might be either anti-Bitcoin, it might be pro another crypto, nd then they’ll say like, “But don’t mention that I said this,” and it’s kind of like in a vein of like, well, wait, why? And it’s like, “Well, I can’t say that on Twitter because then I’ll be outed. I’ll be outcast.”

[70:14] Ryan: Yeah, I don’t know. It’s big for the first guest to bring up but, in general, I think Luke has done a ton of great work for Bitcoin. He’s widely regarded as one of the devs that understands the system the best and really interestingly, it seems a lot of the rebuttals or a lot of the source of the current controversy is actually, people disagreeing the speedy trial as a method that we should push through upgrades, which was Luke’s position to begin with, which I think is pretty interesting. So, Bitcoin is definitely very different than Ethereum. We have our ways of doing so. Can they be improved? Like, of course, is our logic behind the way, things are, yes.

[70:57] Hudson: That’s a great answer. Because, yeah, I basically obviously, I’m gonna get like, the worst parts of the drama with that so that’s a very good answer. I appreciate the perspective there and unless there’s anything else for me, I’ll jump off and give my speakers lot to someone else with good questions as well.

[71:11] Mark: Thank you, Hudson. Yep. I appreciate the question. I’m gonna reorganize some of the speakers. So, if I knock you down, sorry about that, but I’m bringing up other people for questions.

[71:22] Casey: I mean, just in regards to, kind of, jumping off that last part, do we think there’s been any dangerous precedent set in the way BIP-119 has been proposed with speedy trial? Does anyone take that position?

[71:41] Mark: I am of the exact same opinion as Luke. That speedy trial is a mistake. Jeremy, I said, UASF, I didn’t say speedy trial. I said when UASF. I do not like the idea of Bitcoin core or miners or any more tangibly definable group being in control of the activation mechanism for proposals. I think that begins to get political, I think that begins to move in the direction where a more and more identifiable group is perceived as being in control of that, and I think that core specifically and miners should not have any direct role in it, I think things should be done with UASF. I don’t think core should be doing anything but writing the validation logic for things. I think activation deployments should come from elsewhere. I do not think that miners should have a veto or an ability to cause something to activate or not. I think that users should be running activation logic and there is either enough of them to strong-arm everyone else along to the point that miners activate because they do not want to see their bottom line hurt to the point that core flips things on in the next release because something else activated it after their initial release with the validation logic.

I do not think that these definable identifiable groups should have anything to do with that. I think that would set the road of capturable processes that can be used maliciously.

[73:29] Jeremy: I don’t disagree with that. I mean, I think if you see and read the post that I put out, I literally say, people ask me for AUSF and I’ve already committed myself that I’m not going to lead any AUSF process because I also don’t think that a dev should lead AUSF either. And what I say is, look, I’m putting out a client that can do this. It’s really up to the community to decide if this is the client that is the right one for them. And I guess when the question gets asked of like, is there an issue with the process by which I rolled this out? The question really is – what did I roll out? I rolled out a blog post with links to software people could build. I didn’t go and say, “You have to run this.” I didn’t misrepresent what the action-reaction consequence or anything would be, it’s like, “Look, here’s software. If this is the software that you want that you think people should run, do it.”

I even say you should get real loud and tell people why they shouldn’t run this. And I think where it’s been surprising to me is people haven’t really read that I was inviting them to shoot it down. And then they’re getting very personally aggressive towards me, rather than just like politely saying, we shouldn’t do the proposal that you put out which I was clearly very open for that feedback. And now I think in terms of AUSF, it is more clear that that’s the thing that should happen if there’s something for CTV, I’m a man of my word, so I’m not going to lead the charge there, but I’m not also not going to be like sitting on anybody who’s trying to do that.

[74:52] Ryan: Great brief word of clarification, Mark. I would say, like Jeremy just said, BIP-119 in this current controversy is just following the process that works for the last software. So, if there was any troubling precedent sent, it was set with Taproot not with what’s happening right now.

[75:09] Mark: Just to be super clear, Ryan and Jeremy, I totally agree with you. I’m just sort of playing I guess a little bit of devil’s advocate and sort of just answering the questions I’m getting from the crowd. I actually had someone just messaged me about what are the cons of this scenario? So, there’s definitely a lot of people talking about a lot of this stuff and that’s the only reason why I brought it up that way. I’m not trying to frame this speedy trial or anything going on here as anyway dangerous or malicious, more just bringing it up for the sake of discussion.

[75:44] Guest 6: Real quick comment, it’s good that, Mark, you brought this up that we have to be careful. I mean, it’s a bit of a hedging language there. The biggest takeaway for me out of this whole saga, personally, was that one has to be extremely careful about the language that they use and this whole battle about the process and whatever, right? It’s very important. Like a lot of people in their minds, they have utterly confused the proposal itself with the proposal on how to activate it. It does very two different things, nothing to do with each other at all. But this goes deeper, right? I mean, we have to be extremely mindful of the language that we use but even that comes down to single words like one Shinobi was talking and just want to let Jeremy make his comment. We became, in some sense, very much different. The sense of the world to the core. And even the word itself, it evokes a certain feel that there’s some kind of a center of the universe there or something, right?

The sacred GitHub repo that it’s somehow, I don’t know, it defines everyone’s life. Now, it’s a trillion dollar thing and it’s like I don’t know, we should like a build a pedestal and a monument there and, of course, everybody’s respected and it’s hard-working people and all and they deserve the credit. But I think it was extremely unfortunate that it was renamed. It used to be just called Bitcoin client, and at some point, it was renamed to Core and I think that actually, that was a very bad move. On this basis, I’m going to make a proposal that we should rename it to Bitcoin Dash Center of Universe, I always refer to it as such so that everybody knows the center of the universe is there and that nothing else can possibly come from anywhere else.

This sort of language in the supposedly centralized system, I think can be profoundly damaging and when people don’t know much about anything they hear Core, they think, oh, well, that’s what it has to come from. Of course, that’s the Core, right? And seems like very logical but that’s just the word, that doesn’t really mean anything. Just the core of the software and the initial motivation was because we’re going to separate the network part from the wallet part, which never really happened. But we stuck with the name and I think we amplified a lot of drama, I think, in many people’s minds.

[78:08] Mark: Yeah. I think the next question went to Tao and then The Last Airbender unless, Tao, you don’t have anything then The Last Airbender.

[78:15] Tao: No, actually, I do have something. Thanks for bringing me up. Just speaking from a pleb’s perspective, I’m just a regular pleb, got into Bitcoin a while back but I do want to give my opinions and what I’m seeing. So, what we want really, is this sound money, some of the core principles that everybody knows, self-sovereignty. No one can fuck with the money. And then also, one of the things that I notice is this – I don’t think it’s good to start implementing new features. The reason why I say that is not that it’s not something that can be done in the future but definitely not at the current state. The reason why is because most people, most plebs are still just catching up to learn everything that Bitcoin has currently as it stands. This, on top of the many people in the world who don’t even know about Bitcoin. So it is not necessary to add new features at the moment.

What we should do or what, I think, the energy should be put into is what Shinobi mentioned earlier and that is the scalability of the system, right? The scalability is told that one day because we know that will come, meaning, we know there will be more and more adoption and as that come, we’re going to need to satisfy and be able to support that sort of scalability and adoption. So, the energy really should be focused on that and not necessarily adding this feature, or that feature, or whatever feature because people don’t even know about all the current features right now. I’m just speaking from a pleb’s perspective, so, thank you very much.

[80:04] The Last Airbender: I think Tao had a great point in terms of making sure that the scalability is improved and continues to be improved for everybody who are users of Bitcoin and I like that idea. I also like the idea that change like any change in the system needs to be incorporated in a manner that impacts and it takes assessment of all the users of the product, like in this case, the Bitcoin. But in this discussion, on this topic, what I have been seeing, at least I’ve been reading on Twitter about the speedy trial only activating is the miner’s want and miners, of course, one of the main parties, the whole thing. Like I think I saw a video from Antonopoulos. I’m forgetting his name, the right pronunciation.

[80:55] Mark: Andreas.

[80:56] The Last Airbender: Yeah, Andreas. So, he has a comment about potentially this idea that is not incorporating all the users, the wallet makers, the note makers, and in here like a beautiful chart that he created in a presentation on which I think, [inaudible] picked up and another person also picked up. The questions were that the speedy trials applied to the previous case of this Taproot. It may not be the right idea because it doesn’t involve all the stakeholders and that’s a question I have for us because I’m literally new to the idea of developing for Bitcoin. I’ve been hoarding Bitcoin for quite some time but not actively looking at GitHub repo and things of that nature because I was doing other things. But now I’m going to focus more my attention on this idea of actually developing the product and making my contributions going forward.

The context that I would like to ask all of us, all of you who are listening, is this idea of having a speedy trial only the miners get to decide is something that I think I questioned that concept because it doesn’t represent me because I’m not a miner. So, how do I get involved?

[82:14] Jeremy: I think, if I can just answer really quickly, one miner do generally follow what’s happening in the world and what people are saying in public sentiment. And at least ten percent of them do or 11% and if at least eleven percent of them are doing that, there’s no way that something can activate under a speedy trial as long as you’re not assuming somebody’s going to like reorg the chain, in which case, it’s like, 51% of that. The other side to that, too, that’s important to keep in mind is you actually do have ways based on the signalling mechanism to not be on that chain if it happens and you have a big threat of users to do user-resisted soft work. And I also wrote the code for that, in case that’s something that people want that conceptually does work.

And then, I think, sort of as the last bit of like just where there’s a lot to learn about a lot of things and what’s going on with these things, have they been studied or whatever. Generally, it’s really hard to know about everything going on and if you want to say, well, what’s the wide set of people who have been involved? I put together the site, utxo.org/signals and I suspect that that capture is a wider breadth of the industry and of people in the industry, and when I say industry, I just mean people who like Bitcoin then was available as indexing of sentiment then we had for anything like Taproot where it’s not really clear what the measurable criteria was when we said Taproot has consensus like nobody’s been able to point me to like a specific thing. That’s like, oh, yes, it’s clear. The only thing somebody has been able to point me to for Taproot was an index of miners who said they would support it and I’ve not been able to see a list of businesses that said they want to support it, for example.

[84:04] The Last Airbender: Thank you, Jeremy. I would like to have one follow-up question, which is – in the future if there is a change that is need to be proposed and needs to be merged into the master branch on our GitHub repository, what would that branch be that I want to build myself and run it like a note to make sure that I represent my vote? How would I select that branch? Is there a process like that, say, I choose to say this change is going to be suggested to go forward, let me get that branch tag, build my own node, run that node to indicate my vote, whether I support or whether I do not support, how is the process for that? What is that process? Or what should that process be if there is any, and if not, please educate me.

[84:49] Jeremy: What you want to run and what happens happens. It’s the mob. Like, that’s just how that works. There is no process there. You make your choice. Everybody makes their individual choice and then what happens, happens.

[85:06] The Last Airbender: So, is there a process that can be incorporated to help people make a decision? Yes, or no? ABC? What are the choices available to make different branches or decided they can choose? Is there a use for slightly technical users for them to be able to build on their own and then indicate their preference by running that version of node?

[85:27] Jeremy: You learn or you choose people to trust, those are your choices.

[85:32] The Last Airbender: I think that’s fair enough. So, basically you’re suggesting I create my own, do it myself.

[85:40] Jeremy: Well, I actually did that during Taproot activation. I’ve worked my own custom client and started enforcing Taproot from the Genesis block, and some giant asshole, [inaudible] attacked the Bitcoin Network and stalled my node for the rest of eternity.

[86:01] Mark: I was just about to bring that up when you got forked up. Well, I wanted to thank everybody. We’re hitting our 7:00 here and that’s just about our cutoff time here. I wanted to thank Casey so much for joining from the get-go and kind of going through the basics. I think we can all agree there’s just a lot more to talk about and sort of understand about the process and specifically Jeremy’s proposal. And obviously, of course, I want to thank Jeremy for all of your energy and being so accessible and willing to talk about all this stuff. Thanks everyone else for hanging out as always. Bitcoin Magazine, check us out. Thanks, Chris, for hosting. Chris, have we got any other shows coming up you want to talk about?

[86:41] Chris Alaimo: No, not right at this minute. Thanks for all the speakers. Thanks, Jeremy. Thanks, Shinobi. We’ll have to do this again sometime. I apologize we didn’t get to all the questions but thanks, guys, for coming out. And, Mark, you got anything else or Q?

[86:57] Jeremy: Can I make a quick closing comment?

[86:58] Mark: Yes. I was going to say, yep.

[87:02] Jeremy: Yeah, I mean, all that I want to say to everybody is that this is the work, one of my main mantras, and what that means is like people get really stressed out and they’re like, “Oh, no.” But it’s like, hey, we’re in a common project that we’re trying to make better money for humankind and whatever we’re doing, this is a part of the work, part of that process, answering these questions, figuring it out. This is the work and it’s all going to be good. We’re doing our best, everybody, and try to not like harbor too much grudge or hate. People are just advocating for what they believe in and just make better arguments. That’s sort of what it comes down to is, well, that’s how it will evolve to be the best ecosystem and the best money system is like people making vociferous debate and moving on and like accepting losses, taking wins, that’s what it’s all about.

[87:54] Mark: Beautiful. And on that, thanks so much, Jeremy, everybody, have a beautiful start to the week and we’ll see you next time.

[88:00] Shinobi: Peace.

[end]

Filed Under: BIP119, Bitcoin Core, Bitcoin Magazine, Consensus, English, Jeremy Rubin, OP_CTV, Podcast, technical, Twitter, Twitter Spaces

Exploring BIP119 And The Way Changes Are Made In Bitcoin

04/05/2022 by Idelto Editor

In Bitcoin, it is nearly impossible to find out how much support there is for a proposal without trying it. CTV is a non-invasive change and should be accepted.

This is an opinion piece about BIP119 (OP_CTV). If you would like to submit a counter argument, please email Bitcoin Magazine.

In the past few weeks, there has been an effort to push a Bitcoin Improvement Proposal (BIP) forward by the name of CTV or BIP119. In this article I will attempt to do two things. First I’d like to describe the important properties of CTV, and secondly, I’d like to disentangle the two debates that are happening concurrently within the Bitcoin community right now.

In Bitcoin, we should take the “Don’t Trust, Verify” imperative seriously. As such, anything I say in this article should be cross-validated against the original BIP119 text as well as the pull request implementing it.

Further, while what I say should be able to stand on its own, irrespective of any credentialing, I will note that I have been working on Bitcoin technologies and Bitcoin directly for almost five years as of the publishing of this article. This does not make me immune to errors, but it should at least help convince you that this article is coming from an informed view and that reading it is worth your time.

Disclosure: I am publicly on the record as supporting the activation of BIP119 on Bitcoin mainnet. It is impossible for me to give you an “unbiased” take. However, I will do my best to make it clear what is a fact and what is an opinion.

Finally, this article assumes a basic familiarity with how Bitcoin works, the structure of transactions and the scripting system in Bitcoin.

So what is CTV? CTV, short for CheckTemplateVerify, is a proposed consensus change to Bitcoin. The proposal would effectively add an operation to Bitcoin’s script system that would prevent a coin from being spendable unless it was being spent in a transaction that had a particular “template.”

This is a fundamentally new capability for the Bitcoin script system and this is partly why the proposal has stirred up a bit of controversy. As of the publishing of this article, all of the spending requirements you can place on Bitcoin are either time-based (CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY) or they are requirements placed on the “witness” (the evidence you present to the Bitcoin network that proves you are allowed to spend the coins).

None of the opcodes you can use in Bitcoin script today allow you to specify any requirements on the transaction that spends those coins. The category of designs and opcodes that do place restrictions on the transactions themselves is often referred to as “covenants.” There are many other proposals that fall in this category that are being discussed by the Bitcoin development community, but what are covenants and why would I want them?

The most important thing to understand about covenants is that they allow you to place restrictions on the outputs of the transactions that spend the coins that are bound by them. Recall that Bitcoin transactions are a collection of inputs (coins you are trying to spend), a collection of outputs (where you are trying to spend the coins) and a witness (proof that you are allowed to spend those coins).

Being able to specify the possible ways you wish to spend your coins in the future can allow you to create more secure cold storage solutions. For example, let’s say that you never want to withdraw more than 10% of your cold storage coins per month. With covenants you could structure your spend conditions such that one month after deposit, you could only spend your coins in one of two predetermined ways: either 10% goes to a predefined hot wallet address and the remaining 90% goes to a new cold storage setup that is similarly structured, or all 100% goes to a new cold storage setup that is similarly structured. The value of this type of arrangement is that you can be sure that even if your system was compromised you would only be risking 10% of your funds before you had a chance to react. This use case is very often referred to as a “vault.”

This is not the only use case for covenants, though. You need covenants to do a number of contracts that “carry state.” I do not have the ability to go into a long list of use-cases here, and there are better materials on the web for that.

Back to CTV, specifically. How does CTV actually work? CTV takes the top item on the Bitcoin Virtual Machine’s stack and verifies that the “template hash” of the current transaction matches that value. This necessarily means that if you wish to spend the coins protected by CTV, you must have known the template hash of the spending transaction before depositing funds into the CTV protected address.

Why is this? Since the template hash of the spending transaction is embedded in the script you are sending your coins to, and because hash functions are one-way, you had to know this value up front: Solving for it after the fact would be equivalent to breaking Bitcoin’s mining algorithm.

As a result of this design, CTV has a property that makes it much simpler than some of the competing proposals. First, all “exit paths” of a CTV contract are known up front. This makes analysis of the safety of CTV contracts significantly easier and therefore less likely to lock your funds up forever.

Before we wrap up the discussion of how CTV works, let’s talk about what goes into the “template hash,” as this is ultimately what you are having to commit to before generating the CTV contract. The template hash covers the transaction’s version, locktime, number of inputs, sequence numbers, number or outputs, the hash of the outputs and values. This is every part of the transaction except the exact input IDs and the witnesses. Essentially, this means you have to know the exact transaction you want to use to spend these coins. This gives the design very little wiggle room in which there could be bugs in the design that allow for vulnerabilities. This is another reason why CTV has a much smaller surface to analyze than other proposals.

So where does the technical community stand on the subject right now? There seems to be broad agreement within the technical community that some mechanism for covenants is desirable. Where the disagreement remains is whether or not CTV, specifically, is the best next course of action or whether other proposals would afford a better set of trade-offs.

Many people are advocating for doing a bunch more research into alternative schemes for adding covenants to Bitcoin. This is noble in principle. However, I first learned of CTV at Bitcoin2019 which is just about three years ago now. So while it is a new idea for a lot of folks, there is a set of people who have been discussing this for years and are justifiably trying to figure out what the appropriate next steps are. Nevertheless, it is important for Bitcoiners to maintain a culture of skepticism when it comes to proposed consensus changes. That is what makes Bitcoin strong.

If you have read this far and still don’t find the story for CTV compelling, that’s fine. Usage of any opcode in Bitcoin is opt-in. The existence of the multisig opcode does not force you to use it, and CTV is no different in this respect. CTV also has no means of changing the way your current coins can be spent. You must take action to move your coins to a CTV address if and when it is activated in order for it to impact your ability to transact on the Bitcoin network.

I usually call these kinds of changes “non-invasive” because they only affect you if you want them to. Further, I’d like to make the case for wanting to be amenable to these kinds of changes, even if you don’t yourself wish to use them: You may be the one who wants a non-invasive change sometime in the future and building a culture of cooperation will help more people get what they want. If a change does harm you or change some property of Bitcoin that is important to you, you should absolutely resist, but not every change is like that and in my professional opinion CTV isn’t either.

So where’s the controversy in all of this? For the remainder of this article I want to refocus away from CTV itself and talk about the activation procedure. This is really where the meat of the debate is. The first part of the controversy stems from the fact that many believe that an attempt to activate CTV this summer is too soon. If you’re just hearing about CTV now, this is probably how you feel. As I mentioned earlier, for some people, this has been a proposal in-the-making for around three years. This is where the fundamental tension lies.

In Bitcoin, it is nearly impossible to figure out how much support there is for a proposal without just trying it. Everyone’s individual view into the social consensus is colored by their connections in the network. Everyone’s view into social consensus is unique and valid, but ultimately incomplete. There is some research for how to improve our collective understanding with where people are, but the same things that make Bitcoin uniquely special also make this particular problem devilishly hard to solve in a way that people would agree is fair. Despite this, we have activated consensus changes as recently as last year. Even though Taproot has been activated for months, there are still people who don’t really understand what it enables, much less how it works.

Even though there seems to be this lack of education surrounding what Taproot’s properties are, there doesn’t seem to be anyone upset about its activation. I suspect the reason for this is that there was near unanimous consensus in the technical community that Taproot was a good idea and the consensus and activation code was formally released in a Bitcoin Core release, which I believe contributed to people being more amenable to it.

This is in contrast to the current situation which I’ll get into in a moment. But before I do, there’s one thing I want to make clear about the story of Taproot: Even though there was overwhelming support for the activation of Taproot, the method of activation was (and still is) hotly contested.

This reveals something about the CTV debate as well. Namely, that there are actually two debates happening. First, there is the debate that aims to answer the question, “Do we want CTV to be activated at all?” Second, there is the debate that aims to answer the question, “Assuming we want CTV, what is the appropriate way to activate it?” Jeremy Rubin, the author of the CTV proposal (BIP119), wrote an article on his blog explaining his rationale for his next steps, which included plans for releasing a Bitcoin client, based on the newest version of Bitcoin Core, that contained code that would activate CTV as early as 2022.

While the code that is responsible for the activation is taken straight from the Taproot episode, an important difference here is that CTV hasn’t been merged in Bitcoin Core, nor has its activation code. These plans have since been abandoned in response to the controversy which indicates pretty strongly that there is a lack of consensus. That said, in my view, the process of trying stuff, incorporating feedback and then trying again is how consensus gets built. After all, had no one advocated for Taproot, it still wouldn’t be live on the Bitcoin network today.

So where does this leave us? Current activation attempts for CTV have been abandoned in an attempt to let public discussion build consensus. The merits and flaws of CTV should be and will be discussed for the next several months. In parallel, there are numerous discussions on how softforks should be treated going forward such that Bitcoin can still reasonably improve while minimizing the chances of letting the process be hijacked by actors who wish to materially alter Bitcoin’s purpose.

This is a guest post by Keags. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine.

Filed Under: BIP119, Bitcoin Core, Bitcoin Magazine, Consensus, English, Jeremy Rubin, OP_CTV, Opinion, technical

A Modest Bitcoin Improvement Proposal, Proposal

03/05/2022 by Idelto Editor

Decentralized consensus is required to make changes to the Bitcoin code. Clear processes, standards and norms can ease decision-making in the future.

This is an opinion piece about BIP119 (OP_CTV). If you would like to submit a counter argument, please email Bitcoin Magazine.

We’ve Got A Problem

Decentralized consensus isn’t easy. There’s a reason most companies have CEOs, and “non-hierarchical” organizations tend not to function well for long. Bitcoin’s decentralized governance is harder still: On top of decentralization, we layer a relative lack of official processes, standards and norms for group decision-making — we even lack clarity around when to make a decision at all.

Jeremy Rubin’s recent proposal of a Speedy Trial consideration for Bitcoin improvement proposal (BIP)119 (OP_CTV) has brought these issues to the fore, illustrating just how difficult and amorphous the Bitcoin decision-making process is.

This problem is largely inevitable. Bitcoin would not be Bitcoin with central governance. But as the community scales and becomes more ideologically diverse, this problem gets worse and effective communication and decision-making become increasingly difficult.

This article argues for two changes to the “meta” process of BIP consideration, which I believe could significantly improve the quality of our debates:

  1. Raise a set of high standards for BIP documentation.
  2. Adopt these open standards as a de facto minimum quality bar for a BIP to be considered for wider discussion.

I believe these standards could radically improve the quality of our decentralized decision-making about Bitcoin. But first, I’d like to illustrate the problem in more detail.

Information And objectivity

Let’s pick on an anonymous, highly indicative tweet:

“CTV isn’t necessary and is very much in its infancy as a project. No one knows enough about it, no one has bothered to review it thoroughly. I’m not a developer or technically trained but this feels rushed and that is a 🚩 for me.”

The claims made in this tweet exemplify two broad problems I see with the discussion about CTV: poor informational standards and unmoored subjectivity.

Poor Informational Standards

Our anon argues that CTV is “very much in its infancy as a project,” but by reasonable or comparative standards, this is not true. CTV was under development in 2019. Its BIP number was assigned over two years ago and consistent work has been done on top of the essentially static BIP since. Its potential applications have been explored in the programming language and graphical user interface that its author built to create, visualize and test covenants — including other BIPs.

“[N]o one has bothered to review it thoroughly,” the anon adds, but a large number of Bitcoiners and developers have done so. The social “signals” of their support or objection are listed on Rubin’s CTV website, where he also links to implementations of numerous downstream uses of CTV by himself and others.

The author of said tweet has a reasonable model for decision-making — to oppose new or poorly reviewed proposals — but is applying that model incorrectly because he lacks essential context.

The above two criticisms are not the only popular expressions of this problem. For example, concerns have been voiced about CTV’s riskiness, but they are voiced in the absence of essential context — clarity around what constitutes a risk and comparison to previously accepted BIPs.

By way of context, Taproot, a far riskier proposal in almost every way — with complex cryptography potentially subject to future quantum attack and a significantly greater footprint of code to debug and maintain — seemed to sail through with comparatively little testing and scrutiny, causing bugs, losing funds and involving incompletely demonstrated applications.

(My argument is not, “Because Taproot, therefore CTV.” I am merely pointing to the inconsistency resulting from a poorly informed mental model.)

Most of us work for a living and keeping up with these things is hard. Epistemic constraint is a fundamental fact of human existence. But to amend a quote by Thomas Jefferson, “An educated citizenry is a vital requisite for Bitcoin’s survival as the global monetary standard.”

The discussion about BIP119 could benefit from a much higher floor of understanding and context.

Unmoored Subjectivity

Our Twitter anon makes two further points: “CTV isn’t necessary” and “[T]his feels rushed and that is a 🚩 for me.” Once again, the arguments are fair enough. As Rubin himself said, pointing to alternate covenant solutions, “I don’t give a single fuck if BIP-119 CTV specifically is activated or not.”

But these two statements point squarely at another problem with the debate: Our unavoidably subjective standards have nothing tangible to latch onto — no objective measures and no clear comparisons. In the absence of clear and comparative evidence, how are we to assess what is “necessary” or has been “rushed” without resorting to emotion, group-think and shifting, illogical argumentation?

“Eternal toxicity” may be “the price of consensus,” and subjectivity is fundamental and unavoidable. Permanent subjectivity detached from relevant facts, however, destroys the capacity for collective decision-making.

What To Do About It?

I propose the adoption of a set of public documentation standards for what constitutes the bare minimum a BIP must provide to be worthy of large-scale public debate. I am not advocating for a clear path to BIP acceptance or even to BIP discussion. I am advocating for a higher normative standard of public documentation without which we can agree to consider a BIP “rushed,” “too early” and “very much in its infancy as a project.”

In a phrase, “The community will consider your BIP premature until it answers all the relevant questions clearly in one place.”

I see two significant benefits to this higher bar: It anchors the inevitably subjective debate to consistent objective measures and it raises a standard for documentation likely to lead to better-informed discussion.

Absent the clarity to meaningfully align on the comparative standards for a given BIP, our decentralized debates descend into a purgatory of “trivial” bikeshedding — a hippie co-op from hell.

The implications of this are deadly serious. As our community grows in scale, distribution and intellectual diversity, we very seriously risk becoming a modern Tower of Babel, an ambitious project that falls into disarray because of a fundamental inability to productively communicate and make intelligent collective decisions.

This is as chill as it’ll get. We’re gonna need a better process. There are reasons to be wary of more processes, however, and I think it’s important to address them first.

Objections

On Ossification

My argument assumes the desirability of change at all. Many in the community argue against any change and for “ossification” of Bitcoin’s code, but even if we want to protect Bitcoin as it is, I believe this to be a mistake.

Bitcoin’s value lies in certain fundamental properties. Some of those properties require effective code stasis. The mining rewards enforcing the supply cap set in place by Satoshi — peace be upon him — provide the canonical example.

Other core properties of Bitcoin, however, are dynamic functions of the broader environment, as well as of Bitcoin’s usage over time. These can change even if Bitcoin Core’s code doesn’t.

Consider privacy. Bitcoin’s ledger is dismayingly open to chain analysis. Privacy advocates worry that bitcoin’s fundamental lack of default privacy opens it up to attacks that could eliminate fungibility and make the currency practically unusable for anything other than condoned, tracked and taxed purposes — a central bank digital currency (CBDC) by proxy.

Privacy is not the only irreducible monad of bitcoin’s value proposition. Rubin’s advent calendar series of articles on covenants outlines a reasonable starting set of four such “pillars” beyond its constrained supply:

  1. Scalability: The capacity for bitcoin to be used by a wide set of people, not merely serve as the monetary layer for bank and corporate final settlement.
  2. Self-custody: The capacity for individuals in a variety of locations and conditions to easily secure their own funds, rather than rely on third parties (who can seize their funds or mint “paper bitcoin”).
  3. Decentralization – The dispersal of power across a wide range of actors, itself a proxy for fundamental censorship-resistance and user control.
  4. Privacy – The ease with which bitcoin users can transact without their funds being tracked, seized, marked or blocked.

Perhaps you don’t really care about one or two of these “pillars.” Perhaps you want to add another of your own. But consider the following list and note how:

  • For most Bitcoiners, some characteristics other than auditability and fixed issuance are highly valuable.
  • Each of these fundamental values is a spectrum, all with significant room for improvement.
  • Functionality which is prohibitively difficult to use — or which relies on a trusted custodial service acting off-chain — is a far cry from functionality which can be trustlessly executed with Bitcoin script.
  • Bitcoin’s “rating” along these axes shifts naturally over time, as when China bans miners, chain analysis becomes more Orwellian, fees shoot up or down or UTXO space becomes too scarce for global use.
  • The “rating” for each pillar improves as more Bitcoiners improve their individual standing, as when more widespread private use increases the fungibility of bitcoin as a whole, or widespread self-custody limits exchanges’ capacity to fractionally reserve it and manipulate the price.

A 21-million hard-capped currency which cannot be accepted by any vendors — which is onerous to self-custody and remains predominantly in un-auditable company-held “paper bitcoin” accounts, or which cannot scale to be used by most people in the world (Lightning Network is not a singular answer here) — will likely fail in its core mission of global emancipation from the horrors of a centrally controlled, inflationary currency.

In other words, code ossification can mean the erosion of Bitcoin’s core strengths.

Bitcoin’s adversaries are constantly improving, and as Lightning Labs CTO Olaoluwa Osuntokun put it in a recent TFTC interview, we need to constantly level Bitcoin up for its “next big boss,” since there are no “respawns” in Bitcoin.

We cannot just sit back, complacent in our citadels, and watch Bitcoin nail the moon landing. Not code ossification, but ossification around a set of principles, along with strict standards for the changes necessary to keep us on track, should be our goal.

Even if you disagree, you likely agree that change will, perhaps unfortunately, continue to occur. In a way, the question is whether that change meets high, public and well-communicated standards, including standards of stasis in essential ways, or if that change is pushed in relative private without assurances of quality. Again, this problem becomes increasingly difficult with time.

On Murkiness

There are many in the community who feel the lack of clarity in the BIP process is positive. Their argument is very much worth considering.

In a recent newsletter, Marty Bent refers to this characteristic as “murkiness,” and he argues that “murky rough consensus driving protocol changes” is better than “a well defined process that could potentially be socially attacked.” Defending core developers’ reluctance to clarify a process for BIP proposals, Marty argues that “those who have the keys to the machine that allows you to change the most commonly used client should be as impartial as humanly possible.”

This argument makes sense. Consider it by analogy: Knowledge of the precise machinery or protocols used in elections allows hackers or social engineers to more easily game them, but as security experts have turned into a refrain, “security by obscurity” is limited in its efficacy, and has significant drawbacks. More importantly, the argument for general murkiness implies that all forms of clarity are similarly likely to provide angles of attack and similarly unlikely to add value.

A different analogy, of an engineering job application, makes clear that there are many different forms of “clarity” and “murkiness,” and they enact different trade-offs:

  • An employer might publish the questions they plan to ask in an interview. This would allow applicants to prepare “for the test” and undermine the value of testing. Lower quality employees would result.
  • An employer might have questions but not publish them. This encourages insiders like recruiters to share the questions with their clients, thereby creating a secret advantage and legitimately gaming the process. Lower quality employees with “political” connections would result.
  • An employer might raise clear public standards for applicants. For example, each applicant must demonstrate four years of relevant experience in a resume that reflects effort and organization. Higher quality employees would generally result, without skewing outcomes politically.

If the standards are reasonably chosen, this last option does little but improve the quality of the interaction, saving employer and applicant time and improving average quality. Furthermore, the fully murky process often advocated for Bitcoin is more akin to a job application where the questions can’t be gamed because there are none (because there is no consistent standard), and each applicant is judged arbitrarily based on the mood and individuals of the day.

This points to two additional issues:

  • An arbitrary process invites inconsistency and even corruption. Ivy League schools can leverage unspecified and arbitrary standards to accept “well-rounded” children of Hollywood stars or cash-cow legacies because “unspecified” is not “unknowable” or “incorruptible.” As Rubin noted on the bitcoin-devs mailing list, “the amount of work a BIP needs to do … to fully describe all applications and use cases” is unclear. In this present circumstance, centralized, arbitrary gatekeeping seems to define the line of “enough” for broader discussion.
  • Social trust is a short-term solution. We may trust the Core developers of today to make selfless and wise arbitrations. But Bitcoin should remain robust for ages, and trusted third parties are security holes. Moreover, as the last two years have made clear, leaning on centralized “experts” leads to technocracy, and the corrosion and capture of the expert class itself.

I am arguing for the equivalent of a resume standard to raise the bar for an entrant to discussion without setting any clear or gameable path for acceptance. It seems clear to me that this is not a security risk, but it is a contribution to the quality of applications and discussion.

It is for a similar reason that a BIP process exists at all. Only the most thoroughly tested and explicated BIPs should be considered for activation and the community should be maximally equipped to productively discuss them.

The Proposal

A guide (BIP2) exists for the proposal and creation of a narrow BIP “technical specification” document, but beyond that, there seems to be no standard for determining what is a “good” or “complete” BIP.

It is critical for the long-term health of Bitcoin that its community coalesce around a more robust set of public standards to which we can hold future BIPs. These standards should be maximally quantitative and address the full range of questions and concerns Bitcoiners might have about a proposal in as digestible and objective a manner as possible.

As a linked supplement to the BIP document, each BIP should be accompanied by a living artifact which addresses all of the requirements below, creating a single navigable repository of ongoing, version-controlled information about the proposal.

Let’s call it a “proposal tracker” — a first step for anyone looking to understand and participate meaningfully in debate. Each proposal tracker should have sections on: history, description, resources, costs and risks, benefits, alternatives, activation and a post-mortem.

History

To apply quantitative heft to concerns that a given BIP “feels rushed,” the proposal tracker should include a full timeline of relevant events:

  • Date first proposed: Date idea was first brought up on the Bitcoin mailing list.
  • Date of BIP: When it was given an official BIP number.
  • Changelog
  • Discussion log: Dated links to references in Bitcoin mailing lists or other public fora.
  • Review log: For each reviewer, their date of review and the substance of their review.

Some of this information is already available for those who want to spelunk in BIP commit history, but a future which requires every Bitcoiner to use GitHub to be informed is not a future in which good decisions are made.

Description

For The Nerds

A link to the BIP we see today: The condensed, technical proposal with real implementation details and references to concrete opcodes, fields and code.

For The Five-Year-Old Plebs

Not everyone who is invested in Bitcoin’s future has the time or capacity to parse through the technical details of a proposed change.

Each proposal tracker should include a high-level explanation that anyone who has read The “Bitcoin Standard” (ok, maybe “Inventing Bitcoin”) can grok. What does this BIP aim to do and how does it do it, broadly speaking? What, at a high level, are its costs and benefits? Maybe Lily can explain.

To engage in informed debate, the community needs to be … informed. Although a distributed community of journalists, podcasters and enthusiasts goes a long way, a collaboratively edited description for the layperson would significantly add to public understanding of the BIP.

Resources

An ongoing, version-controlled list of relevant links to news articles, podcasts and other external references to the proposal.

Costs And Risks

The Bitcoin community seems quite alive to the risks of change, but often in a vague way that shows little conception of the specific risks posed by a specific change. The risks of a given proposal to Bitcoin Core (and they are numerous) should be listed explicitly. They include:

  • Protocol security risk: For example, does new cryptography add a risk of compromise by future quantum computing?
  • Maintenance cost: How complicated will this code be to maintain, year after year, for the length of Bitcoin’s existence? Perhaps lines of code could be one measure of this cost along with discussion of scarcity of relevant expertise and inherent complexity.
  • Other complexity costs: Will this be hard for non-Bitcoin Core software to implement? Is this difficult to test?
  • Footgun risk: Does this change increase the chances of a Bitcoiner doing something stupid with their money? Is it hard to use correctly?
  • Political risk: Does this change add any surface for government attack? For example, some concern has been expressed that covenants might be used by governments to constrain bitcoin uses. Are there sensible responses to such concerns?
  • Computing cost: Does computation of the new opcode add significant time to node transaction processing or blockchain parsing?
  • Space cost: Does this increase the size of blocks or transactions, increasing node hardware requirements and minimizing decentralization?
  • Non-pareto changes: Does this addition undermine the strength of any of the “core pillars” of Bitcoin?
  • Deployment risk: Do existing nodes and wallets encounter blocks, transactions or addresses that they do not understand? If miners do not upgrade but claim to have upgraded, how is security reduced?
  • Developer confusion: If this change rolls out, will a similar change that has some better qualities get rejected as insufficiently useful?

Beyond the above non-exhaustive list, each proposal should include a discussion of interactions with other proposals being considered. How does this particular BIP interact with other BIPs on offer? Rubin’s aforementioned “advent calendar” attempts to explore these interactions and future proposals should follow suit — ideally in a clear, well-formatted manner such as a simple table accompanied by an explanation.

A long-running bug bounty, such as that on offer for CTV, is strongly encouraged and could be community-sponsored in the future.

Benefits

Solo

What are the implications and applications of this proposed change on its own? What does it make possible? What does it make easier? Each described “application” should include:

  • A layperson explanation: How does this BIP make an application possible? For example, what is the basic logic by which BIP119, which tightly constrains how an output may be spent, makes “smart vaults” possible?
  • A technical explanation: On a level closer to pseudocode, what is going on with the code to make this application possible?
  • A technical implementation: Tested code, ideally illustrated in Sapio or some other explorable/vettable “playground.”
  • Discussion of degree of solution: Does the BIP make this application possible or just easier, clearer or more efficient?
  • Relevant pillar: Using Rubin’s above taxonomy or some other system of value, what fundamental goal of Bitcoin’s does this application address? Does it make it more scalable, easy to custody, censorship-resistant or private?
  • Urgency and stakeholders: What groups does this add value to and how much value? Does it address an extremely urgent issue?

Combined

Since BIPs are generally constructed as “small steps” rather than “big leaps,” they are often designed to become more powerful in conjunction with future proposals. What could be achieved in combination with future BIPs? (Note the discussion of combinatory risk above.)

All of the above requirements for “solo” applications should apply here as well, minus the technical implementation, which depends on the other BIP’s level of progress.

These requirements raise a high and expensive bar for any proposal — which is the idea. Ideally, a fully etched-out sense of both costs and benefits will permit more Bitcoiners to form accurate assessments of the risk-benefit ratio of a given change.

Alternatives

BIP119 is a covenant and has some overlap with other covenants. Each proposal tracker should try to tackle the question of “why this proposal” and not others like it. How does it fit into the ecosystem of other BIPs?

Activation

How do the authors propose activating this BIP and why? What is their ideal schedule and their fallback plan? Should activation precede merging into Bitcoin Core? Should it ever not? Ideally, over time, the Bitcoin community can arrive at some preemptive consensus around which activation methods are ideal based on governance features and a balance of powers.

Post-Mortem

If the BIP becomes part of Bitcoin Core, the author or authorial group should track its integration over the coming months and years. What worked and didn’t work? Was the process successful? Was the process incomplete?

If rejected, what lessons were learned?

Where To Go From Here?

Much rigor and measurement could be added to the above, but I hope it’s a useful start.

We will learn from this process. Perhaps we will find that CTV meets these minimal requirements, but isn’t urgent or powerful enough to include in Bitcoin Core. Perhaps we’ll discover, to our dismay, that Taproot faced a much easier standard and was even “rushed” in “its infancy.” Regardless, we should discover a reasonable baseline for review, explanation and testing. By applying a more consistent and documented process, we raise the quality of both proposals and debates.

The Bitcoin community’s focus on defending its fundamentals from change is essential, but this adversarial posture is mostly outward-facing and can miss subtle threats from within. If we are unable to handle debate without descending into aimless factionalism, we may fail to handle the wider usage and greater political pressure coming our way.

Decentralized consensus isn’t easy. We should take it very seriously.

If you are interested in helping move this idea forward, please reach out and share.

This is a guest post by Sasha Klein. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine.

Filed Under: BIP119, Bitcoin Core, Bitcoin Magazine, Checktemplateverify, Consensus, culture, English, Jeremy Rubin, Opinion, Proposals

Is Speedy Trial The Best Way To Change Bitcoin?

27/04/2022 by Idelto Editor

BIP119, which adds limited covenants to Bitcoin, is the current conversation and many people question if Speedy Trial for Taproot was a good precedent.

The below is a direct excerpt of Marty’s Bent Issue #1198: “OP_CTV and rough consensus” Sign up for the newsletter here.

(Source)
(Source)
(Source)

As I’m sure some of you are aware of by now, there is a heated debate happening amongst Bitcoin developers and users alike about OP_CTV, a subject we began covering here at the Bent in December 2019. OP_CTV, if enabled, would bring back to life an op code (OP_NOP4) with added restrictions. This would allow users to create complex covenants on Bitcoin that would enable more complex preconfigured transactions and could improve the user experience around security and batching a large number of transactions.

I think these are functionalities that would add utility to many bitcoin users, particularly larger economic actors who hold a lot of bitcoin that needs to have the highest degree of security as is humanly possible and those who send a lot of bitcoin to a large number of users on a daily basis.

With that being said, the attempt to get OP_CTV merged into Bitcoin Core has highlighted the murky nature of rough consensus within a distributed peer-to-peer system. The conversation around OP_CTV is forcing people to ask (myself included) questions like; is this completely necessary right now? Has there been enough discussion and review of the proposal? If so and it is deemed worthy, how should it be activated on the Bitcoin network?

After having spoken to a few developers who are familiar with both Bitcoin Core and the needs of some of the larger custodians it does seem that OP_CTV would be beneficial for many players in the space. The ability to leverage these types of covenants would expand the design space of the solutions they can offer customers because they have better security guarantees when moving large amounts of bitcoin. (I am using security in this context to mean “prevent human-error from leading to a loss of funds”.) I think OP_CTV would get used if it were activated.

Another variable that has been brought to light with the debate around OP_CTV activation (or refusal) is that the lead maintainers of Bitcoin Core, who have what’s known as “commit access” and are in charge of actually hitting the buttons that merges code into Bitcoin Core, do not seem to want any part in suggesting whether or not something should or should not be merged and how that should or should not happen. They seem to be adopting an increasingly neutral posture so that they don’t come off as partial and can be viewed as biased controllers of the codebase. This seems to be evident by their lack of willingness to provide Jeremy Rubin, the developer behind OP_CTV, with an answer to his question, “How do I go about getting this merged into Bitcoin Core?” I actually view this as a positive. It should be hard to change bitcoin and those who have the keys to the machine that allows you to change the most commonly used client should be as impartial as humanly possible.

Because of the refusal to deliver a straight answer to Jeremy in regards to an activation path, he has taken it upon himself to create his own client that has OP_CTV activated and provides users an avenue through which they can try to make OP_CTV official by participating in another User Activated Soft Fork (UASF) that leverages the Speedy Trial method of activation. While I understand Jeremy’s push to get OP_CTV activated, I’m not a big fan of pushing another soft fork via Speedy Trial. In retrospect, it seems that it was a bad precedent that was set when taproot was activated. I fear that normalizing a rapid succession of soft forks via Speedy Trial is a slippery slope that could lead to a lot of unnecessary changes in the future that could cause a degradation of the integrity of the bitcoin network.

While there are many people who would probably use OP_CTV if it were activated tomorrow, it doesn’t seem to be a pressing need at the moment. I am in favor of a more thorough conversation and debate about the merits of the feature and the precedents we set via its activation, if it comes to happen. I like the idea of OP_CTV but certainly do not think it’s a make or break feature at the moment.

I am in favor of murky rough consensus driving protocol changes over a well-defined process that could potentially be socially attacked. It will be interesting to see when and how this debate gets settled. One thing is for sure, I’m happy that OP_CTV is here to bring these tough but necessary conversations around consensus to the fore. These are very important discussions to be having.

Filed Under: BIP119, Bitcoin Core, Bitcoin Magazine, Covenants, English, Jeremy Rubin, Marty Bent, Marty's Bent, OP_CTV, Speedy Trial, technical

  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Interim pages omitted …
  • Go to page 83
  • Go to Next Page »

Primary Sidebar

Archives

Recents articles

  • Bill Gates: Crypto Has No Valuable Output — It’s Not Adding to Society Like Other Investments
  • Rich Dad Poor Dad’s Robert Kiyosaki Thinks Bitcoin Could Bottom Out at $9K — Reveals Why He Remains Bullish
  • Kevin O’Leary Expects US Crypto Regulations to Come Out After Midterm Elections
  • ETH Co-Founder Vitalik Buterin Says The Merge Could Happen in August, There’s Also ‘Risk of Delay’
  • Draft Law About NFTs Submitted to Russian Parliament
  • Dubai Creates Committee to Help Cement Its Position as ‘Key City in the Metaverse’
  • Crypto’s Barren Wasteland: A Look at What’s Left of Terra’s Defi and Token Ruins
  • Celebrating Bitcoin Pizza Day With Knoxville Bitcoin Network

© 2022 · Idelto · Site design ONVA ONLINE

Posting....