Rubin’s push for Rubens and CTV

You may have recently noticed a new trend on Bitcoin Twitter where people are changing their profile pictures to look like Reuben sandwiches. We’ll explain what this means, why you should care, and why you should consider becoming a Reuben Sandwich. First, I should mention an important point. The Rubin’s Reubens image is neither an NFT nor an inscription, it is just an AI-generated artwork that anyone can use for free.

The name was given because it resembles Jeremy Rubin (@JeremyRubin), the creator of OP_CTV and BIP119, and Rubin and Reuben. You may have already figured it out. So, if you use a Reuben sandwich as your profile picture or show the 🥪 emoji, you are showing your support for CTV or the recent LNHANCE upgrade proposal. Written by Brandon Black (@reardencode) LNHANCE is a combination of OP_CTV, OP_CSFS, and OP_INTERNALKEY. This combination allows for slightly more flexibility and programmability than OP_CTV alone, and also allows for additional features such as LN symmetry/eltoo.

In a previous article, I explained that Bitcoin has a scaling problem and that covenants including CTV can help solve this problem. However, I haven’t discussed the process involved in how to actually enable these new OP codes. By design, soft forking Bitcoin to change its consensus rules is not a quick or easy process. But what is agreement? This is a difficult question with many nuances, and the answer depends on who you ask. There used to be this concept rough consensus, Once the changes have been well discussed and there are no more reasonable concerns remaining to be addressed regarding the proposal, a rough agreement has been reached. Some people believe that consensus is achieved when companies such as wallet providers, exchanges, and miners agree to changes. Alternatively, if miners go it alone, like most soft forks without miner hash support, they will reject blocks from heavier chains and it will be up to the market to decide which is the real Bitcoin. This can be very messy and complicated, so it’s much simpler if you can get miners on board with an upgrade. The reality is that consensus decisions are made by the economic majority of Bitcoin users, and regular users, developers, miners, exchanges, wallets, and other Bitcoin holders all participate. Measuring this is incredibly difficult, if not impossible. However, before activating a proposal, you need to determine the level of consensus on the proposal.

In April 2022, Jeremy Rubin proposed a rapid trial activation of CTV, but this did not go over well and the fork became very controversial. A speedy trial is where the final decision on whether or not to activate a soft fork proposal is given to miners. Just five months ago, taproot was activated using the same rapid testing method. However, many felt that it was not going well and were uncomfortable with giving miners the ability to reject changes that might have majority consensus among users. A few weeks after announcing the quick trial client, Jeremy decided to stop trying to activate it. The 2022 changes leave no agreement on CTV. It’s worth noting that Jeremy has also released a tool (User Resisted Softfork) that allows users to resist CTV activation attempts via the activation client. So now, two years later, the community is considering another activation attempt, but this time there will be no quick way to try it.

So what are the different ways to enable a soft fork? There are two Bitcoin Improvement Proposals (BIPs) used for activation, BIP8 and BIP9. I recommend reading this. Taproot used BIP9 for fast testing that relies on timestamps to know the signal period. If the signal period ends without achieving the activation threshold, the attempt fails and no soft fork occurs. BIP8 uses block height to determine the period and, like BIP9, can be configured to fail after a signal period without sufficient miner signals. Alternatively, it can be configured to activate after the signal period even if the threshold has not been reached. This parameter is called “lockinontimeout”, or lot for short. If set to true, the soft fork will be active no matter what. This forced activation is called User Activated Soft Fork (UASF), and can only be successful in the long term if most of the economic value of the Bitcoin ecosystem agrees to the changes and upgrades their nodes. Otherwise, you will never reach the heaviest chain because miners will not upgrade and follow the economic majority. However, if there is an economic majority that supports the change, the miners will have to follow suit due to the miners’ economic incentives to want it. Earn as much commission as possible. Ideally, miners can signal sufficient support before the signal period ends and avoid the drama of UASF. It was the threat from UASF in 2017 that caused miners to agree to the Segwit upgrade and not increase the block size as Bcashers wanted. (Yes, technically the block size still increased slightly.)

We should now briefly discuss activation parameters. These are the details of the activation and include: name; version bit number; starting block height; signal period timeout block height; Minimum active block height; Threshold of block signal; Finally, whether lockinontimeout is true or false. The name should typically be the BIP number, which for CTV is BIP119. The version bit may already be an obsolete bit. The start has not yet been determined. Hopefully around 2024, but this is ultimately a community decision. The signal duration limit should be at least one year from start, although some people think two years or more would be better. Again, this is a community decision and client developers will have to try and determine what the majority agrees on. I will be satisfied. The signal period is 1-2 years. The minimum activation height is the earliest potential time at which a soft fork can become active, which may be before the end of the signal period, simultaneously with the timeout, or after the timeout. I believe it should be at least 6 months from starting height. The threshold is the number of blocks (2016 blocks) required to be activated via cue during a two-week difficulty period. Typically this is 90 or 95% of blocks 1815 to 1915 of the 2016 blocks. This means that 90/95% of the network hash power must signal support for the upgrade within two weeks. Finally, as already discussed, you must set lockinontimeout to true if you want the community to support activation attempts.

So how do we get to a point where we can be confident we’ve found consensus? Participate in communities, talk to Bitcoin companies and service providers, and signal your support online in a variety of ways. Rubin’s Reubens is an example of this signaling and a fun and social way to do it. Don’t be afraid to ask questions about things you don’t understand or agree with. Remember, we’re not just trusting, we’re verifying here. Join your favorite Bitcoin business, ask CTV what they think, and let us know what you think. After all, you are the customer. If you’re a developer, you can review code or create a proof of concept for CTV. If you can create a positive proof of concept or a harmful negative proof and a bug discovered when using OP_CTV, you can currently win over 5 BTC. This bounty has been running for over a year now and no one has found a problem. This bounty can be found at https://bipbounty.org/bounties/1e101655-bad8-5147-82f7-f03145d567af/.

Of course, in a decentralized system like Bitcoin, it is impossible to know for sure whether the majority of the economy wants change, so we can only make wild guesses and hope for the best. But you won’t know until you try. I believe we are very close or have already found agreement on CTV. Go to utxos.org/signals and make sure you’ve added your name or company to the list. You can signal yes or no. You can also find more information about covenants on this website.

This is a guest post by George 203. The opinions expressed are solely my own and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.