Bitcoin⚡️Channel

On February 28th, 2025, I will endorse a covenant upgrade plan. If you don't care what I have to say, that's fine. But a variety of folks have been asking me to weigh in, and I do not want to be in the position of gatekeeping the formation of consensus. I don't personally plan to do any implementation, but I will provide mentorship and guidance for those who wish to make that effort and will throw my full throated support behind a sufficiently organized effort. My current favoured approach is CTV+CSFS followed by CAT+ECMath+Arith ops. Between now and February 28th, I'll consider potential roadmaps. For me to consider an option, please make a PR to github.com/JeremyRubin/utxos… describing your proposal, I invite everyone to participate in discussing and evaluating these proposals on the github. At the end of this period, I'll merge any proposal that is still open (and meets basic sanity requirements), and then publicly endorse my preferred path. I will not be endorsing any proposal that does not have a clear deployment plan and team of capable advocates. I am perfectly happy with the outcome of endorsing nothing at all. I see no reason why a coherent plan of action, started today, could not have an upgrade live on Bitcoin before the end of the year. The main blocker seems to be the developers who care failing to find a Schelling point to rally around. Short of that, perhaps this effort can serve to coordinate the community around a common goal. Below, I'll discuss two potential paths I would love to see submitted, that I could see myself endorsing. CTV+CSFS followed by CAT+EcMath+Arith After thinking long-and-hard about the current state of Bitcoin, I believe that the superior approach is to start with an attempt to activate a soft fork containing CTV and CSFS. These are two opcodes that are well studied, well reviewed, and well understood. They pose a minimal risk to Bitcoin, but both help enable key improvements to Bitcoin projects like Lightning, Ark, BitVM, Vaults, Mining Pools, DLCs, and more. They do not enable -- to the best of anyone's knowledge -- arbitrary computation smart contracts. Adding these two opcodes seems uncontroversial, with broad technical consensus. This upgrade can proceed over the next year, although I don't pretend to know exactly what an activation would look like. While that soft fork is being built and deployed, I believe a second proposal for deployment should be developed, centered around OP_CAT. This upgrade would contain OP_CAT, as well as a few additional opcodes for the most common uses of OP_CAT. This would include elliptic curve operations (such as ECADD, TWEAKADD, ECMUL) appropriately costed, as well as 64 bit math operations, and perhaps some tools to ensure encodings for bitcoin data types can be structured/destructured without needing to go through hoops in script. This is not a full "GSR" effort, but rather ensuring that smart contracts don't take on excessive technical debt with OP_CAT to emulate functionality that should have been delivered as a specific opcode. There are great implementation targets to evaluate these extensions against, such as implementation complexity for STARK verifiers. This also buys time for the community to fully consider and study the impacts of MEV, while using the tools from CTV+CSFS to drive more decentralization. I'd also love to see a team of developers formalize a proposal for the above plan, and submit to the utxos.org repo. If you're interested in working on this, you can find an issue to discuss the proposal here github.com/JeremyRubin/utxos… CTV+CSFS+CAT I also see a strong potential for a soft fork that is just CTV+CSFS+CAT, advanced immediately. I would also love to see that proposal submitted and backed by a team of advocates to advance this packaged proposal. If you're interested in working on it, you can find an issue to discuss here: github.com/JeremyRubin/utxos… I personally do not think this approach is as likely to acheive consensus, but I think it may be more likely to find a qualified team willing to do the work.