A Modest Bitcoin Improvement Proposal, Proposal

This is an opinion piece about BIP119 (OP_CTV). If you would like to submit a counter argument, please email Bitcoin Magazine.

We’ve Got A Problem

Decentralized consensus isn’t easy. There’s a reason most companies have CEOs, and “non-hierarchical” organizations tend not to function well for long. Bitcoin’s decentralized governance is harder still: On top of decentralization, we layer a relative lack of official processes, standards and norms for group decision-making — we even lack clarity around when to make a decision at all.

Jeremy Rubin’s recent proposal of a Speedy Trial consideration for Bitcoin improvement proposal (BIP)119 (OP_CTV) has brought these issues to the fore, illustrating just how difficult and amorphous the Bitcoin decision-making process is.

This problem is largely inevitable. Bitcoin would not be Bitcoin with central governance. But as the community scales and becomes more ideologically diverse, this problem gets worse and effective communication and decision-making become increasingly difficult.

This article argues for two changes to the “meta” process of BIP consideration, which I believe could significantly improve the quality of our debates:

1. Raise a set of high standards for BIP documentation.
2. Adopt these open standards as a de facto minimum quality bar for a BIP to be considered for wider discussion.

I believe these standards could radically improve the quality of our decentralized decision-making about Bitcoin. But first, I’d like to illustrate the problem in more detail.

Information And objectivity

Let’s pick on an anonymous, highly indicative tweet:

“CTV isn’t necessary and is very much in its infancy as a project. No one knows enough about it, no one has bothered to review it thoroughly. I’m not a developer or technically trained but this feels rushed and that is a 🚩 for me.”

The claims made in this tweet exemplify two broad problems I see with the discussion about CTV: poor informational standards and unmoored subjectivity.

Poor Informational Standards

Our anon argues that CTV is “very much in its infancy as a project,” but by reasonable or comparative standards, this is not true. CTV was under development in 2019. Its BIP number was assigned over two years ago and consistent work has been done on top of the essentially static BIP since. Its potential applications have been explored in the programming language and graphical user interface that its author built to create, visualize and test covenants — including other BIPs.

“[N]o one has bothered to review it thoroughly,” the anon adds, but a large number of Bitcoiners and developers have done so. The social “signals” of their support or objection are listed on Rubin’s CTV website, where he also links to implementations of numerous downstream uses of CTV by himself and others.

The author of said tweet has a reasonable model for decision-making — to oppose new or poorly reviewed proposals — but is applying that model incorrectly because he lacks essential context.

The above two criticisms are not the only popular expressions of this problem. For example, concerns have been voiced about CTV’s riskiness, but they are voiced in the absence of essential context — clarity around what constitutes a risk and comparison to previously accepted BIPs.

By way of context, Taproot, a far riskier proposal in almost every way — with complex cryptography potentially subject to future quantum attack and a significantly greater footprint of code to debug and maintain — seemed to sail through with comparatively little testing and scrutiny, causing bugs, losing funds and involving incompletely demonstrated applications.

(My argument is not, “Because Taproot, therefore CTV.” I am merely pointing to the inconsistency resulting from a poorly informed mental model.)

Most of us work for a living and keeping up with these things is hard. Epistemic constraint is a fundamental fact of human existence. But to amend a quote by Thomas Jefferson, “An educated citizenry is a vital requisite for Bitcoin’s survival as the global monetary standard.”

The discussion about BIP119 could benefit from a much higher floor of understanding and context.

Unmoored Subjectivity

Our Twitter anon makes two further points: “CTV isn’t necessary” and “[T]his feels rushed and that is a 🚩 for me.” Once again, the arguments are fair enough. As Rubin himself said, pointing to alternate covenant solutions, “I don’t give a single fuck if BIP-119 CTV specifically is activated or not.”

But these two statements point squarely at another problem with the debate: Our unavoidably subjective standards have nothing tangible to latch onto — no objective measures and no clear comparisons. In the absence of clear and comparative evidence, how are we to assess what is “necessary” or has been “rushed” without resorting to emotion, group-think and shifting, illogical argumentation?

“Eternal toxicity” may be “the price of consensus,” and subjectivity is fundamental and unavoidable. Permanent subjectivity detached from relevant facts, however, destroys the capacity for collective decision-making.

What To Do About It?

I propose the adoption of a set of public documentation standards for what constitutes the bare minimum a BIP must provide to be worthy of large-scale public debate. I am not advocating for a clear path to BIP acceptance or even to BIP discussion. I am advocating for a higher normative standard of public documentation without which we can agree to consider a BIP “rushed,” “too early” and “very much in its infancy as a project.”

In a phrase, “The community will consider your BIP premature until it answers all the relevant questions clearly in one place.”

I see two significant benefits to this higher bar: It anchors the inevitably subjective debate to consistent objective measures and it raises a standard for documentation likely to lead to better-informed discussion.

Absent the clarity to meaningfully align on the comparative standards for a given BIP, our decentralized debates descend into a purgatory of “trivial” bikeshedding — a hippie co-op from hell.

The implications of this are deadly serious. As our community grows in scale, distribution and intellectual diversity, we very seriously risk becoming a modern Tower of Babel, an ambitious project that falls into disarray because of a fundamental inability to productively communicate and make intelligent collective decisions.

This is as chill as it’ll get. We’re gonna need a better process. There are reasons to be wary of more processes, however, and I think it’s important to address them first.

Objections

On Ossification

My argument assumes the desirability of change at all. Many in the community argue against any change and for “ossification” of Bitcoin’s code, but even if we want to protect Bitcoin as it is, I believe this to be a mistake.

Bitcoin’s value lies in certain fundamental properties. Some of those properties require effective code stasis. The mining rewards enforcing the supply cap set in place by Satoshi — peace be upon him — provide the canonical example.

Other core properties of Bitcoin, however, are dynamic functions of the broader environment, as well as of Bitcoin’s usage over time. These can change even if Bitcoin Core’s code doesn’t.

Consider privacy. Bitcoin’s ledger is dismayingly open to chain analysis. Privacy advocates worry that bitcoin’s fundamental lack of default privacy opens it up to attacks that could eliminate fungibility and make the currency practically unusable for anything other than condoned, tracked and taxed purposes — a central bank digital currency (CBDC) by proxy.

Privacy is not the only irreducible monad of bitcoin’s value proposition. Rubin’s advent calendar series of articles on covenants outlines a reasonable starting set of four such “pillars” beyond its constrained supply:

1. Scalability: The capacity for bitcoin to be used by a wide set of people, not merely serve as the monetary layer for bank and corporate final settlement.
2. Self-custody: The capacity for individuals in a variety of locations and conditions to easily secure their own funds, rather than rely on third parties (who can seize their funds or mint “paper bitcoin”).
3. Decentralization – The dispersal of power across a wide range of actors, itself a proxy for fundamental censorship-resistance and user control.
4. Privacy – The ease with which bitcoin users can transact without their funds being tracked, seized, marked or blocked.

Perhaps you don’t really care about one or two of these “pillars.” Perhaps you want to add another of your own. But consider the following list and note how:

• For most Bitcoiners, some characteristics other than auditability and fixed issuance are highly valuable.
• Each of these fundamental values is a spectrum, all with significant room for improvement.
• Functionality which is prohibitively difficult to use — or which relies on a trusted custodial service acting off-chain — is a far cry from functionality which can be trustlessly executed with Bitcoin script.
• Bitcoin’s “rating” along these axes shifts naturally over time, as when China bans miners, chain analysis becomes more Orwellian, fees shoot up or down or UTXO space becomes too scarce for global use.
• The “rating” for each pillar improves as more Bitcoiners improve their individual standing, as when more widespread private use increases the fungibility of bitcoin as a whole, or widespread self-custody limits exchanges’ capacity to fractionally reserve it and manipulate the price.

A 21-million hard-capped currency which cannot be accepted by any vendors — which is onerous to self-custody and remains predominantly in un-auditable company-held “paper bitcoin” accounts, or which cannot scale to be used by most people in the world (Lightning Network is not a singular answer here) — will likely fail in its core mission of global emancipation from the horrors of a centrally controlled, inflationary currency.

In other words, code ossification can mean the erosion of Bitcoin’s core strengths.

Bitcoin’s adversaries are constantly improving, and as Lightning Labs CTO Olaoluwa Osuntokun put it in a recent TFTC interview, we need to constantly level Bitcoin up for its “next big boss,” since there are no “respawns” in Bitcoin.

We cannot just sit back, complacent in our citadels, and watch Bitcoin nail the moon landing. Not code ossification, but ossification around a set of principles, along with strict standards for the changes necessary to keep us on track, should be our goal.

Even if you disagree, you likely agree that change will, perhaps unfortunately, continue to occur. In a way, the question is whether that change meets high, public and well-communicated standards, including standards of stasis in essential ways, or if that change is pushed in relative private without assurances of quality. Again, this problem becomes increasingly difficult with time.

On Murkiness

There are many in the community who feel the lack of clarity in the BIP process is positive. Their argument is very much worth considering.

In a recent newsletter, Marty Bent refers to this characteristic as “murkiness,” and he argues that “murky rough consensus driving protocol changes” is better than “a well defined process that could potentially be socially attacked.” Defending core developers’ reluctance to clarify a process for BIP proposals, Marty argues that “those who have the keys to the machine that allows you to change the most commonly used client should be as impartial as humanly possible.”

This argument makes sense. Consider it by analogy: Knowledge of the precise machinery or protocols used in elections allows hackers or social engineers to more easily game them, but as security experts have turned into a refrain, “security by obscurity” is limited in its efficacy, and has significant drawbacks. More importantly, the argument for general murkiness implies that all forms of clarity are similarly likely to provide angles of attack and similarly unlikely to add value.

A different analogy, of an engineering job application, makes clear that there are many different forms of “clarity” and “murkiness,” and they enact different trade-offs:

• An employer might publish the questions they plan to ask in an interview. This would allow applicants to prepare “for the test” and undermine the value of testing. Lower quality employees would result.
• An employer might have questions but not publish them. This encourages insiders like recruiters to share the questions with their clients, thereby creating a secret advantage and legitimately gaming the process. Lower quality employees with “political” connections would result.
• An employer might raise clear public standards for applicants. For example, each applicant must demonstrate four years of relevant experience in a resume that reflects effort and organization. Higher quality employees would generally result, without skewing outcomes politically.

If the standards are reasonably chosen, this last option does little but improve the quality of the interaction, saving employer and applicant time and improving average quality. Furthermore, the fully murky process often advocated for Bitcoin is more akin to a job application where the questions can’t be gamed because there are none (because there is no consistent standard), and each applicant is judged arbitrarily based on the mood and individuals of the day.

This points to two additional issues:

• An arbitrary process invites inconsistency and even corruption. Ivy League schools can leverage unspecified and arbitrary standards to accept “well-rounded” children of Hollywood stars or cash-cow legacies because “unspecified” is not “unknowable” or “incorruptible.” As Rubin noted on the bitcoin-devs mailing list, “the amount of work a BIP needs to do … to fully describe all applications and use cases” is unclear. In this present circumstance, centralized, arbitrary gatekeeping seems to define the line of “enough” for broader discussion.
• Social trust is a short-term solution. We may trust the Core developers of today to make selfless and wise arbitrations. But Bitcoin should remain robust for ages, and trusted third parties are security holes. Moreover, as the last two years have made clear, leaning on centralized “experts” leads to technocracy, and the corrosion and capture of the expert class itself.

I am arguing for the equivalent of a resume standard to raise the bar for an entrant to discussion without setting any clear or gameable path for acceptance. It seems clear to me that this is not a security risk, but it is a contribution to the quality of applications and discussion.

It is for a similar reason that a BIP process exists at all. Only the most thoroughly tested and explicated BIPs should be considered for activation and the community should be maximally equipped to productively discuss them.

The Proposal

A guide (BIP2) exists for the proposal and creation of a narrow BIP “technical specification” document, but beyond that, there seems to be no standard for determining what is a “good” or “complete” BIP.

It is critical for the long-term health of Bitcoin that its community coalesce around a more robust set of public standards to which we can hold future BIPs. These standards should be maximally quantitative and address the full range of questions and concerns Bitcoiners might have about a proposal in as digestible and objective a manner as possible.

As a linked supplement to the BIP document, each BIP should be accompanied by a living artifact which addresses all of the requirements below, creating a single navigable repository of ongoing, version-controlled information about the proposal.

Let’s call it a “proposal tracker” — a first step for anyone looking to understand and participate meaningfully in debate. Each proposal tracker should have sections on: history, description, resources, costs and risks, benefits, alternatives, activation and a post-mortem.

History

To apply quantitative heft to concerns that a given BIP “feels rushed,” the proposal tracker should include a full timeline of relevant events:

• Date first proposed: Date idea was first brought up on the Bitcoin mailing list.
• Date of BIP: When it was given an official BIP number.
• Changelog
• Discussion log: Dated links to references in Bitcoin mailing lists or other public fora.
• Review log: For each reviewer, their date of review and the substance of their review.

Some of this information is already available for those who want to spelunk in BIP commit history, but a future which requires every Bitcoiner to use GitHub to be informed is not a future in which good decisions are made.

Description

For The Nerds

A link to the BIP we see today: The condensed, technical proposal with real implementation details and references to concrete opcodes, fields and code.

For The Five-Year-Old Plebs

Not everyone who is invested in Bitcoin’s future has the time or capacity to parse through the technical details of a proposed change.

Each proposal tracker should include a high-level explanation that anyone who has read The “Bitcoin Standard” (ok, maybe “Inventing Bitcoin”) can grok. What does this BIP aim to do and how does it do it, broadly speaking? What, at a high level, are its costs and benefits? Maybe Lily can explain.

To engage in informed debate, the community needs to be … informed. Although a distributed community of journalists, podcasters and enthusiasts goes a long way, a collaboratively edited description for the layperson would significantly add to public understanding of the BIP.

Resources

An ongoing, version-controlled list of relevant links to news articles, podcasts and other external references to the proposal.

Costs And Risks

The Bitcoin community seems quite alive to the risks of change, but often in a vague way that shows little conception of the specific risks posed by a specific change. The risks of a given proposal to Bitcoin Core (and they are numerous) should be listed explicitly. They include:

• Protocol security risk: For example, does new cryptography add a risk of compromise by future quantum computing?
• Maintenance cost: How complicated will this code be to maintain, year after year, for the length of Bitcoin’s existence? Perhaps lines of code could be one measure of this cost along with discussion of scarcity of relevant expertise and inherent complexity.
• Other complexity costs: Will this be hard for non-Bitcoin Core software to implement? Is this difficult to test?
• Footgun risk: Does this change increase the chances of a Bitcoiner doing something stupid with their money? Is it hard to use correctly?
• Political risk: Does this change add any surface for government attack? For example, some concern has been expressed that covenants might be used by governments to constrain bitcoin uses. Are there sensible responses to such concerns?
• Computing cost: Does computation of the new opcode add significant time to node transaction processing or blockchain parsing?
• Space cost: Does this increase the size of blocks or transactions, increasing node hardware requirements and minimizing decentralization?
• Non-pareto changes: Does this addition undermine the strength of any of the “core pillars” of Bitcoin?
• Deployment risk: Do existing nodes and wallets encounter blocks, transactions or addresses that they do not understand? If miners do not upgrade but claim to have upgraded, how is security reduced?
• Developer confusion: If this change rolls out, will a similar change that has some better qualities get rejected as insufficiently useful?

Beyond the above non-exhaustive list, each proposal should include a discussion of interactions with other proposals being considered. How does this particular BIP interact with other BIPs on offer? Rubin’s aforementioned “advent calendar” attempts to explore these interactions and future proposals should follow suit — ideally in a clear, well-formatted manner such as a simple table accompanied by an explanation.

A long-running bug bounty, such as that on offer for CTV, is strongly encouraged and could be community-sponsored in the future.

Benefits

Solo

What are the implications and applications of this proposed change on its own? What does it make possible? What does it make easier? Each described “application” should include:

• A layperson explanation: How does this BIP make an application possible? For example, what is the basic logic by which BIP119, which tightly constrains how an output may be spent, makes “smart vaults” possible?
• A technical explanation: On a level closer to pseudocode, what is going on with the code to make this application possible?
• A technical implementation: Tested code, ideally illustrated in Sapio or some other explorable/vettable “playground.”
• Discussion of degree of solution: Does the BIP make this application possible or just easier, clearer or more efficient?
• Relevant pillar: Using Rubin’s above taxonomy or some other system of value, what fundamental goal of Bitcoin’s does this application address? Does it make it more scalable, easy to custody, censorship-resistant or private?
• Urgency and stakeholders: What groups does this add value to and how much value? Does it address an extremely urgent issue?

Combined

Since BIPs are generally constructed as “small steps” rather than “big leaps,” they are often designed to become more powerful in conjunction with future proposals. What could be achieved in combination with future BIPs? (Note the discussion of combinatory risk above.)

All of the above requirements for “solo” applications should apply here as well, minus the technical implementation, which depends on the other BIP’s level of progress.

These requirements raise a high and expensive bar for any proposal — which is the idea. Ideally, a fully etched-out sense of both costs and benefits will permit more Bitcoiners to form accurate assessments of the risk-benefit ratio of a given change.

Alternatives

BIP119 is a covenant and has some overlap with other covenants. Each proposal tracker should try to tackle the question of “why this proposal” and not others like it. How does it fit into the ecosystem of other BIPs?

Activation

How do the authors propose activating this BIP and why? What is their ideal schedule and their fallback plan? Should activation precede merging into Bitcoin Core? Should it ever not? Ideally, over time, the Bitcoin community can arrive at some preemptive consensus around which activation methods are ideal based on governance features and a balance of powers.

Post-Mortem

If the BIP becomes part of Bitcoin Core, the author or authorial group should track its integration over the coming months and years. What worked and didn’t work? Was the process successful? Was the process incomplete?

If rejected, what lessons were learned?

Where To Go From Here?

Much rigor and measurement could be added to the above, but I hope it’s a useful start.

We will learn from this process. Perhaps we will find that CTV meets these minimal requirements, but isn’t urgent or powerful enough to include in Bitcoin Core. Perhaps we’ll discover, to our dismay, that Taproot faced a much easier standard and was even “rushed” in “its infancy.” Regardless, we should discover a reasonable baseline for review, explanation and testing. By applying a more consistent and documented process, we raise the quality of both proposals and debates.

The Bitcoin community’s focus on defending its fundamentals from change is essential, but this adversarial posture is mostly outward-facing and can miss subtle threats from within. If we are unable to handle debate without descending into aimless factionalism, we may fail to handle the wider usage and greater political pressure coming our way.

Decentralized consensus isn’t easy. We should take it very seriously.

If you are interested in helping move this idea forward, please reach out and share.

This is a guest post by Sasha Klein. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine.