This post is syndicated from rubin.io.
I know, I know.
God forbid, a roadmap. People hate roadmaps. As I’ve noted before:
Bitcoin Eschews Roadmaps and Agendas. I provide this maxim to make clear that this document is by no means an official roadmap, narrative, or prioritization. However, it is my own assessment of what the current most pragmatic approach to upgrading Bitcoin is, based on my understanding of the state of outstanding proposals and their interactions.
My priorities in producing this are to open a discussion on potential new features, risk minimization, and pragmatic design for Bitcoin.
If you didn’t click, I definitely recommend reading the quoted post in conjunction with this one. As well as, if you’re a first time visitor to the Advent Calendar, the preceding 26 posts.
In contrast to my prior post, this roadmap is going to be less about full justifications and unbiased weightings and tallyings of sentiments and more just me spitting out a timeline we could introduce changes on. It’s not a final answer, and in no way authoritative, but it’s a launch point for a discussion that has to happen in some way at some point in order to advance a soft-fork.
Consider this as being posted for the sake of public review. If you disagree with this, let me know why! But please no attacks just for the act of discussing the topic of soft-fork activation1.
So buckle up here’s how we could make Bitcoin kick ass in 2022 and beyond:
CheckTemplateVerify is getting close to ready to go. There are numerous supporters (listed on utxos.org), few detractors, and a bumper crop of amazing use cases (did you read the calendar?) waiting for us on the other side of CTV activation. The major critiques are that we might want something that does ‘more’ than CTV itself, or to include it in a bundle of things.
My take: we’re not Gordon Gecko. Greed is Not Good. CTV represents a clean, well contained, unproblematic upgrade that’s going to deliver hella functionality in service of scaling, decentralization, self custody, and privacy. Let’s secure the bag for Bitcoin users everywhere and make it happen. We can always do more, later, informed by what extensions we need for rapidly maturing tools like Sapio. CTV is also technically specified and implemented sufficiently – a view I’ve confirmed with a couple other devs – that it is able to be considered for release.
On March 15th developers reach agreement on merging BIP-119’s implementation. On April 15th, agreement is reached on release parameters for signalling from ~ June 1st to ~September 1st. The activation height would be November 10th. A client is prepared, and tested, and released. No issues are found. The miners signal at some point in the 3 month window above the threshold. CTV locks-in. Developers can prep wallet software for deeper integration. CTV activates before Thanksgiving, avoiding the “dire straits” of thanksgiving-hanukkah-christmas-chinese-new-year-valentines-day season.
but that’s basically identical to Taproot’s timeline?
Exactly. If we act on this timeline starting in early January 2022, it is possible to meet an almost identical timeline for CTV as Taproot.
Part of why it works is that the next major release is scheduled for 2022-04-01. Soft forks are usually released as a minor patch on top of a few recent major releases. So CTV could be:
What could go wrong?
After the release of CTV Soft Fork Client, what goes next?
Yep, new opcodes. As soon as CTV is merged, there are some new features that could be tooled into BIPs without much controversy, given their simplicity:
These are “universally agreed on” bits of functionality that have very little wiggle room in how they might be specified. Therefore their implementation, testing, and release is mostly mechanical. This makes them good bets for a concrete timeline because they’re a rote-development task with few research dependencies and easily agreed on design.
With hard work, these could be reviewed and tested in time for Speedy Trial signalling in June 2023 (+1 year), with realllllly hard work 6 months earlier (but there are conflicting priorities for developer’s time – e.g., building stuff with/for CTV and Taproot – that make that super unlikely).
Anyprevout is 1000000% not ruled out here for advancing to the consensus stage in 2022. There are a couple things happening on Anyprevout that make me suspect it might be more primed towards early-mid 2024 best case.
All of these reasons point to it being highly unlikely APO could be finished on the timeline presented for CTV, but also that given a desire to see a working LN client (ensuring the protocol is sound end-to-end without modifications) leads to additional engineering complexity.
I’ve heard on the rumour vine some excellent engineers might start working on an Eltoo implementation, I believe that work to be of tremendous value to gain consensus on deploying anyprevout.
Given that a couple years seems like the best case for a set of upgrades around APO to deliver Eltoo, if we have the ability to deliver CTV now, it is a good asymmetric bet for delivering utility to Bitcoin’s users.
Suppose I’m wrong, and Anyprevout really could get done in 2022. Shouldn’t it be ’next’ and CTV can wait?
The notion that any soft-fork is “next” for consideration and blocks any other from being considered is somewhat contrary to the support for parallel soft-forks with distinct version bits used for signalling. The possibility of deploying soft forks on independent bits means things can be ultimately “proposed” whenever they’re mature enough to enter the “final stage” and the timing fits with Bitcoin’s general release schedule. The chief counterarguments to this are twofold: One, review resources are finite and we can’t even think about $$>1$$ thing at a time; Two, it’s bad if the protocol is simultaneously deploying $$N$$ upgrades and any of them might fail, leading to $$2^N$$ potential protocol states. It’s actually the other way around: if things can proceed in parallel we can get more review, because developers won’t feel that reviewing others work has the potential to slow down their own, and we’ll be more certain that the upgrades we release are strongly desired by the community (i.e., will end in a UASF if not activated due to miner apathy).
If I had to estimate, I’d say TLUV needs another year or so of people ‘stewing’ on the possibilities and design before it could move forward. It would then probably need at least a year of tinkering to get a well-accepted implementation, and then a year for release process. So let’s say best case it could be a 2024 thing, more likely 2025 given Anyprevout is seen as higher priority for the engineering work.
They didn’t make the cut in the earlier piece since they’re a bit more abstract, but I’d posit that IIDs could also approach a 2024 timeline were the developer of the idea to spend a heckin’ big amount of time on advocacy for the concept in 2022, and present a clean implementation of the concept (& demonstration of overheads) by 2023. This is complicated by the issue that he would have to also solve issues with requiring a new index, such as helping assist assumeutxo compatibility, write reindexing logic from genesis (or somehow exclude old coins?), and also work on utreexo compatibility. Those all seem tractable, but very hard to do for someone who is not a full-time long-time contributor to the project, but I’m a believer that the job could be done given the quality of the insights in the IIDs paper.
In parallel to the above, there are some things that I think are very cool that should remain under development, but don’t have a clear path to inclusion presently.
The first is Transaction Sponsorship, which could substantially simplify many protocols on top of Bitcoin, especially things like Eltoo and CTV stuff. We can’t predict that too well because it will depend on what developers end up running up against with current best practices around CPFP/RBF, but I suspect it might become popular if a small group of developers prioritizes such an approach as a unified front. Since it’s technically simple, it wouldn’t take much time to implement, but because there’s very little consensus for it right now it’s not fit for inclusion in a roadmap.
The next is Simplicity. Simplicity could completely change how Bitcoin scripting works and is super duper exciting. I guess it’s going out on Elements sometime soon? However, it’s stupidly complicated for most devs to fully understand (although it is called simplicity…), so it would take a fair amount of time (read: years) before the implementation could be sufficiently independently reviewed by the intersection of qualified Bitcoin and Programming Language theory reviewers. The interesting thing about Simplicity with respect to this roadmap is that because it’s so general, as soon as it seems like Simplicity would be on Bitcoin within ~1.5 years, it’s likely all other scripting soft fork developers would “stop” development2 and focus on deployment as Simplicity Jets.
Should this plan not seem feasible to the near unanimity of the community for us the deliver on (e.g., with +2-3 months of the suggested timeline), I don’t think there is another good opportunity to enact on an activation of CTV and the best course of action would be to delay +1 year. There could be a UASF for it, since there is strong user demand for CTV, but I wouldn’t personally lead the charge on that beyond ensuring that the BIP-119 code remains up-to-date and is implemented correctly.
Assuming someone doesn’t make a bold argument that gives me or the aggregate current supporters of CTV pause, I plan to begin holding a fortnightly CTV review session to iron out any details, additional testing, code review, and activation plans. I would also like to help a third party host a review club, although the focus of Review Club is more educational for the reviewers as opposed to for the purpose of formally reviewing the code for merge.
You’ve now reached the end of Rubin’s Bitcoin Advent Calendar, 2021! Congrats.
wc -w $(ls | grep advent) tells me that means you read 50,773 words total of
me rambling on about covenants. That’s PhD thesis length! I really hope you
found something to enjoy.
A special thanks to all who helped review this post in particular and provided feedback in ensuring I’ve done an OK job capturing the complexity of gaining consensus. To the extent that I haven’t succeeded in representing your perspectives here, I take sole responsibility for the inadequacy. Your constructive feedback on how to improve is welcomed. A further special thanks to Ryan Gentry who encouraged me to produce the series in the first place, and to Sarah Satoshi for her support as I battled my way through this task.
As for me, I’m off to sip some Eggnog and eat some holiday cookies! I’ll take a little bit of a break, and be back in the New Year following up on next steps and dropping fresh content for y’all as always.
Merry Christmas and Happy New Years,