You may have noticed a new trend on bitcoin twitter lately, people changing their profile pictures to some form of a Reuben sandwich. I am going to explain what this means, why you should care and why you should consider also becoming a Reuben sandwich. First I must address something important, the Rubin’s Reubens images are not NFTs, they are not inscriptions, they are simply AI generated art that anyone can choose to use for free.
The name comes from Jeremy Rubin (@JeremyRubin), the creator of OP_CTV and BIP119, and the likeness between Rubin and Reuben. Which you may have already figured out. So by having a Reuben sandwich as your profile picture or by displaying the 🥪 emoji you are signaling your support for the CTV or more recently LNHANCE upgrade proposals. LNHANCE, which was written by Brandon Black (@reardencode) is a combination of OP_CTV, OP_CSFS and OP_INTERNALKEY. This combination provides a bit more flexibility and programmability than just OP_CTV alone, and enables extra things such as LN symmetry/eltoo.
In a previous article I explained that bitcoin has a scaling issue and that covenants, including CTV, can be a solution to help with this. However I didn’t discuss the process involved with how we actually activate these new OP codes. By design, it is not a quick or easy process to soft fork bitcoin in order to change the consensus rules. But what even is consensus? This is a tough question with a lot of nuance, and the answer will depend on who you ask. In the past there was a concept of rough consensus, where once the change is well discussed and there are no more reasonable concerns left to dispel regarding a proposal, you have reached rough consensus. Some people believe consensus is found when businesses, such as wallet providers, exchanges and miners agree on a change. Or even just the miners alone, as if you soft forked without a majority of miner hash support, you would be rejecting the blocks from the heavier chain, then it will be up to the market to decide which is the real bitcoin. This can be very messy and complicated, hence it’s much simpler if you can get the miners on board with the upgrade. The reality is that the economic majority of bitcoin users get to determine consensus, of which regular users, developers, miners, exchanges, wallets and other bitcoin holders all play a part. Measuring this is incredibly difficult, if not impossible. However you must try to judge the level of consensus for a proposal before attempting to activate it.
In April 2022 Jeremy Rubin proposed a speedy trial activation of CTV, this did not go well, and led to the fork being very contentious. Speedy trial is where the final decision whether to activate a soft fork proposal or not, is given to the miners. Just 5 months earlier taproot was activated using the same speedy trial method. However many people felt it did not go well, and they weren’t comfortable giving the miners the ability to say no to a change that may have majority consensus amongst the users. A couple weeks after Jeremy announced the speedy trial client he decided to call off the activation attempt. There was no consensus on CTV as a change in 2022. It is worth noting that Jeremy also released a tool for users to resist a CTV activation attempt (User Resisted Softfork) with the activation client. So now 2 years later the community is looking at another activation attempt, but this time there won’t be any speedy trial method.
So what are the alternative ways to activate a soft fork? There are 2 BIPs (Bitcoin Improvement Proposals) that are used for activation, BIP8 and BIP9, I recommend reading these. Taproot used BIP9 for the speedy trial, which relies on timestamps to know the signaling periods. If the signaling period ends without achieving the activation threshold, then the attempt fails and there is no soft fork. BIP8 uses block height to judge time periods and can be configured to either fail after a signal period without enough miner signaling, just like BIP9. Or it can be configured to activate after the signaling period, even without reaching the threshold. This parameter is called “lockinontimeout” or lot for short, when set to true the soft fork will activate no matter what. This forced activation is called a UASF (User Activated Soft Fork), and can only succeed long term if the majority of economic value in the bitcoin ecosystem agrees with the change and upgrades their nodes. Otherwise you won’t end up on the heaviest chain, as miners will follow the economic majority and not upgrade, but if you do have the economic majority supporting the change, miners will have to follow them due to economic incentives from the miners wishing to get the most fees possible. Ideally the miners will signal enough support before the end of the signaling period, and the drama of a UASF can be avoided. It was the threat of UASF that caused the miners in 2017 to agree to the Segwit upgrade and not increase the blocksize like the Bcashers wanted. (Yes, technically the blocksize did still increase a bit.)
We now need to briefly discuss activation parameters, these are the specifics of the activation, and includes the following: the name; the version bit number; the start block height; the signal period timeout block height; the minimum activation block height; the threshold of blocks signaling; and finally whether lockinontimeout is true or false. The name should generally just be the BIP number, in CTVs case, BIP119. The version bit can be any that isn’t being used already. The start is yet to be determined, I would hope it can be sometime in 2024, however this is a community decision ultimately. The signal period timeout should be at least 1 year after the start, some feel 2 or more years would be even better, again this is a community decision and the client developer must try and judge what the majority agree with, I would be happy with 1 to 2 years of signaling period. The minimum activation height is the earliest potential time that the soft fork could activate, this could be before the end of the signal period, at the same time as the timeout or after the timeout. I believe it should be at least 6 months after the start height. The threshold is how many blocks in a 2 week difficulty period, 2016 blocks, are required to activate through signaling. Generally this is 90 or 95% of the blocks, 1815-1915 blocks out of 2016. This means 90/95% of the network’s hash power must be signaling support for the upgrade in a 2 week period. Finally, as we already discussed, lockinontimeout should probably be set to true if you want the community to support the activation attempt.
So how do we get to a point of feeling confident we have found consensus? Engaging with the community, having conversations with bitcoin businesses and service providers, and signaling support online in various ways. Rubin’s Reubens is one example of this signaling, and it’s a fun and social way to do so. Don’t be afraid to ask questions about anything you don’t understand or agree with, remember, we verify around here not just trust. Engage with your favourite bitcoin businesses, ask them their opinion of CTV and be sure to let them know yours, after all, you are the customer. If you are a developer, you could review the code, or create a proof of concept for CTV. There is currently over 5 BTC up for grabs if you can create a positive proof of concept, or a negative that is harmful, plus any bugs found when using OP_CTV. This bounty has been around for more than a year already, with nobody finding any issues. You can find this bounty here: https://bipbounty.org/bounties/1e101655-bad8-5147-82f7-f03145d567af/.
Of course, in a decentralized system like bitcoin, we can never know for sure that the economic majority desire a change, we can only take a rough guess and hope for the best. We won’t find out until we try though. I believe we are either extremely close or have already found consensus for CTV. Make sure you head to utxos.org/signals and add your name or business to the list, you can signal yes or no. You will also find lots more information about covenants on this website.
This is a guest post by George 203. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
