You may have noticed a new trend on bitcoin Twitter lately: people swapping their profile photos for some sort of Reuben sandwich. I'm going to explain what this means, why you should care, and why you should consider becoming a Reuben sandwich too. First I need to address something important: 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 resemblance between Rubin and Reuben. Which you may have already discovered. So by having a Reuben sandwich as your profile photo or showing the emoji, you are indicating your support for CTV or, more recently, the LNHANCE update proposals. LNHANCE, 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 and allows for additional things like LN/eltoo symmetry.
in a bitcoin-has-a-scaling-issue”>Previous article I explained that bitcoin has a scaling problem and that covenants, including CTV, can be a solution to help with this. However, I didn't talk about the process involved in how we actually activate these new OP codes. By design, it is not a quick or easy process to soft fork bitcoin to change the consensus rules. But what is consensus? This is a difficult question with many nuances and the answer will depend on who you ask. In the past there was the concept of approximate consensus, where once the change has been well discussed and there are no longer reasonable concerns to allay regarding a proposal, a rough consensus has been reached. Some people believe that a consensus is reached when companies, such as wallet providers, exchanges, and miners, agree to a change. Or even just the miners alone, like if you did a soft fork without a majority of mining hash support you would be rejecting blocks from the heavier chain, then it will be up to the market to decide which is the real bitcoin. This can be very confusing and complicated, so it's much easier if you can bring miners into the update. The reality is that the economic majority of bitcoin users get to determine the consensus, of which regular users, developers, miners, exchanges, wallets and other bitcoin holders play a role. Measuring this is incredibly difficult, if not impossible. However, you should try to judge the consensus level of a proposal before attempting to activate it.
In April 2022, Jeremy Rubin proposed a rapid test activation of CTV, but this did not go well and made the fork very controversial. The quick test is where the final decision on whether to activate a soft fork proposal or not is given to the miners. Just 5 months earlier the taproot was activated using the same rapid test method. However, many people felt that it did not go well and did not feel comfortable giving miners the opportunity to say no to a change that could have a majority consensus among users. A couple of weeks after Jeremy announced the rapid test client, he decided to cancel 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 (User Resisted Softfork) activation attempt with the activation client. Now, 2 years later, the community is considering another activation attempt, but this time there will be no quick testing method.
So what are the alternative ways to trigger a soft fork? There are 2 BIPs (bitcoin Improvement Proposals) used for activation, BIP8 and BIP9, I recommend reading them. Taproot used BIP9 for the rapid test, which relies on timestamps for signaling periods. If the signaling period ends without reaching 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 fail after a signal period without sufficient miner signaling, just like BIP9. Or it can be set to activate after the signaling period, even without reaching the threshold. This parameter is called “lockinontimeout” or batch for short; when set to true, the soft fork will trigger no matter what. This forced activation is called UASF (User Activated Soft Fork) and can only be successful in the long term if the majority of the economic value in the bitcoin ecosystem agrees with the change and upgrades its nodes. Otherwise you won't end up on the heaviest chain as the miners will follow the economic majority and not upgrade, but if you have the economic majority supporting the change the miners will have to follow them due to the economic incentives of the miners wanting Get as many rates as possible. Ideally, miners will signal sufficient support before the signaling period ends, and the drama of a UASF can be avoided. It was the UASF threat that made miners in 2017 accept the Segwit upgrade and not increase the block size as Bcashers wanted. (Yes, technically the block size still increased a bit.)
Now we need to briefly discuss the activation parameters, these are the details of the activation and include the following: the name; the version bit number; the height of the initial block; the height of the signal period timeout block; the minimum height of the activation block; the block signaling threshold; and finally if lockinontimeout is true or false. Typically the name should be just the BIP number, in the case of CTVs, BIP119. The version bit can be any that is not already in use. The start is still to be determined, I hope it could be sometime in 2024, however this is ultimately a community decision. The signal period timeout should be at least 1 year after startup, some feel 2 or more years would be even better, again this is a community decision and the client developer should try to judge what they are up to. agree most, I would be happy with 1 to 2 years signaling period. The minimum trigger height is the earliest possible time that the soft fork could trigger, this could be before the end of the signal period, at the same time as the timeout, or after the timeout. I think it should be at least 6 months after the initial height. The threshold is how many blocks in a 2-week difficulty period, 2016 blocks, are required to activate via signaling. Generally, this is 90 or 95% of the blocks, 1815-1915 blocks in 2016. This means that 90/95% of the network's hash power should indicate 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 can we get to a point where we feel confident that we have found a consensus? Interact with the community, have conversations with bitcoin companies and service providers, and signal support online in various ways. Rubin's Reubens is an example of this signage and is a fun and social way to do it. Don't be afraid to ask questions about anything you don't understand or agree with, remember, we verify here, we don't just trust. Interact with your favorite bitcoin companies, ask them their opinion on CTV and be sure to let them know yours; after all, you are the customer. If you're a developer, you can review the code or create a proof of concept for CTV. There is currently over 5 btc at stake if you can create a positive proof of concept or a damaging negative proof of concept, plus any bugs found using OP_CTV. This bounty has been around for over a year and no one has found any problems. You can find this reward here: https://bipbounty.org/bounties/1e101655-bad8-5147-82f7-f03145d567af/.
Of course, in a decentralized system like bitcoin, we can never know for sure whether the economic majority wants a change, we can only make a rough guess and hope for the best. Although we won't know until we try. I think we are very close or have already found a consensus for CTV. Be sure to head to utxos.org/signals and add your name or business to the list, you can indicate yes or no. You will also find much more information about the agreements on this website.
This is a guest post by George 203. The opinions expressed are entirely his own and do not necessarily reflect those of btc Inc or bitcoin Magazine.
