Monthly News Letter • May 2022
Life comes at you fast, especially in an industry like Bitcoin where there is no central authority to make decisions for the rest of the network. Only 14 days after announcing plans for rolling out a new Bitcoin soft fork, BIP119 author Jeremy Rubin announced he will not be advancing the activation attempt.
First, let me be clear: I am not advancing a Speedy Trial(ST) activation of Bitcoin Improvement Proposal-119 (BIP-119) CheckTemplateVerify (CTV) at this time.
Jeremy Rubin, on the bitcoin-dev mailing list
This month’s news letter gives a high-level overview of what BIP119 would have done for Bitcoin, what a Speedy Trial is, and what went wrong with activating CTV. Jeremy Rubin is the founder of Judica, a Bitcoin development organization focused on Smart Contracts. Jeremy is also the author of BIP119, a proposal that would have added some smart contract features to the Bitcoin consensus layer. On April 17, 2022, Jeremy published a blog post announcing his plans for moving forward with activating BIP119. This announcement stirred up controversy throughout the Bitcoin community, comments on the bitcoin-dev mailing list from Bitcoin developers can be found here.
BIP-119
The full text for BIP119 can be read on GitHub using this link. BIP119 proposed introducing a covenant that would allow users to program rules on how their bitcoin could be spent such as, only allowing it to be spent to certain pre-defined addresses or only allowing it to be spent after a certain period of time. Covenants are restrictions on how bitcoin may be spent beyond key ownership. BIP119 calls this feature a “template” and it uses a new opcode called OP_CHECKTEMPLATEVERIFY, or “CTV” for short. Some use cases for CTV included:
Wallet Vaults – The ability to set restrictions on the amount of bitcoin which may be spent from cold storage, which addresses this bitcoin may be spent to, and restrictions on how much time must pass between transactions.
Congestion Controlled Transactions – The ability to create large batch transactions from a single output. The idea here is that during times of high transaction volume on the Bitcoin network, exchanges could save on transaction fees by using CTV to create a transaction with a small data size that has only a single output. After so many blocks, that single output could be expanded thus revealing several payments from a batch spend.
Payment Channels – Users could open several Lightning channels using a single CTV address. For example, a user could generate a CTV address and once that address is funded, all resulting spends from that address could be Lightning channel openings. This could even be unbeknownst to the spender who originally sent funds to the CTV address.
Although these features may sound interesting, BIP119 comes with certain risks and tradeoffs such as the possibility of rendering bitcoin permanently un-spendable.
Unknown Preimage – One could use a template preimage that is unknown or un-satisfiable. Theoretically, it would be possible to create a template that stipulates requirements that are impossible to fulfill. Thus any bitcoin spent to a CTV address like this would mean that the bitcoin could never be spent again. To avoid this, the sender would need a signature from the leafs of the template tree verifying that bitcoin could be spent from there.
Address Reuse – If a CTV address is reused, then the amount sent to it would need to be exactly the same every time. Otherwise, if the amount is less than used previously, that output is frozen permanently. If the output is more than used previously then the overage becomes an extra large miners fee.
Argument Length – It could be possible to construct a transaction that passes consensus rules but doesn’t follow the template “standardness” rules if the argument length is not exactly 32 bytes. This could result in loss of funds.
BIP119 would have introduced features that some Bitcoiners find interesting, giving them the ability to program more control into their money. Opponents of BIP119 raised concerns that if this gives regulators an inch, they will take a mile. Potentially, an exchange could require customers to present the template programmed in their receiving address before allowing a withdrawal. The exchange could put certain requirements in place such as mandating that the template explicitly enforce that their bitcoin could never be spent to OFAC blacklisted addresses. Others pointed out that these kinds of smart contract features are better suited for a Layer2 solution. Some Bitcoiners supported BIP119 but disagreed on the activation method.
Speedy Trial
Speedy Trial is a Bitcoin soft fork activation method that uses a combination of time and percentage of miners to lock-in a new feature. For example, if 90% of miners signal support for the activation within any 2-week period (2,016 block difficulty adjustment epoch) during a 3-month trial period then the feature locks in. Miners would change the nVersions bit in their blockheaders from 0 to 1 to signal support. If 90% of miners signal support during the trial then the activation takes place some months later.
The proposed dates were:
- Signal Start MTP: 1651708800 (May 5th, 2022, 00:00 UTC)
- Signal Timeout MTP: 1660262400 (August 12th, 2022, 00:00 UTC)
- Activation Height: 762048 (Approximately Nov 9th)
- The way Jeremy approached this was that he created a fork of Bitcoin Core with CTV activation code in it. Jeremy was requesting that miners run his code so that when they mined blocks, the blocks would have a support indicator flag in them. If 2-weeks went by and the 90% threshold was not met, then the 2-week clock starts again. That would have gone on until the 90% threshold was met or 3-months, which ever occurred first. If 90% had not been met by the end of the 3-month trial then the effort would be considered failed.
This is the same way Taproot was activated, a Miner Activated Soft Fork Speedy Trial. The difference is that Taproot underwent 3-years of development, testing, validation, and open discussions; then it gained user support, exchange support, and dev support; then it was merged into Bitcoin Core and finally the miners were asked if they wanted to signal support for it or not.
What went wrong?
By releasing forked software and seeking a Miner Activated Soft Fork by Speedy Trial, Jeremy surprised many in the community who thought that this approach was being rushed without first gaining wide support from the broader community. This also caused others to react with suspicion that there may be ulterior motives at play.
Michael Folkson posted to the bitcoin-dev mailing list announcing that he would be releasing a forked version of Bitcoin Core that would reject any blocks signaling support for CTV. This User Resisted Soft Fork is one way that users running nodes can cause economic hardship on miners who try to lock-in features that they do not agree with. Jeremy had already coded forked software that would maintain the non-activating chain in anticipation that some users would want to reject such blocks. But it never hurts to have a back up.
If Jeremy would have gone forward with this proposal, users would have had to react whether they wanted the CTV upgrade or not. CTV would not have broken consensus rules so it wouldn’t be rejected by the standard Bitcoin Core software, nor would it have been activated since no merge has been made. This means if a user did not support CTV then they would have to upgrade to a forked version of Bitcoin Core that rejected those blocks. If a user supported CTV then they would need to upgrade to a forked version of Bitcoin Core with the support coded in until the pull request gets merged.
Even though Jeremy has been working on CTV for roughly two years at this point, the interest from users, the demand from exchanges, and the support from developers just wasn’t there. Many users had never even heard of BIP119 until a couple weeks ago. So when Jeremy announced that he was initiating a Miner Activated Soft Fork, many people reacted negatively to the news.
In Jeremy’s own words, the last two weeks have been full of confusion, fear, and misunderstanding:
“I believe that the disinformation spread around my post (“7 Theses on a next step for BIP-119″[0]) created three main negative outcomes within the Bitcoin community:
- Confusion about how Bitcoin’s “technical consensus” works and how changes are “approved”.
- Fear about the safety of CTV and covenants more broadly.
- Misunderstandings around the properties of Speedy Trial, User Activated Soft Fork (UASF), User Resisted Soft Fork (URSF), Soft Forks, Hard Forks, and more.“
He may be right about some of that, but perhaps that is exactly how it should be, no central authority should be approving changes nor should a group of authorities be able to decide among themselves. People are right to greet changes with skepticism and concern about the implications. Standardizing the process would lead to anyone who can follow instructions submitting requests for features no one is asking for. People would be committing low effort attempts that are aimed at checking a box off a list rather than garnering broad support from a relevant community for features that are needed.