{"id":9610,"date":"2022-05-03T22:00:00","date_gmt":"2022-05-03T22:00:00","guid":{"rendered":"http:\/\/ci02a0423fd0002718"},"modified":"2022-05-03T22:00:00","modified_gmt":"2022-05-03T22:00:00","slug":"a-modest-bitcoin-improvement-proposal-proposal","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/culture\/a-modest-bitcoin-improvement-proposal-proposal","title":{"rendered":"A Modest Bitcoin Improvement Proposal, Proposal"},"content":{"rendered":"
<\/div>

This is an opinion piece about BIP119 (OP_CTV). If you would like to submit a counter argument, please email<\/a> Bitcoin Magazine.<\/em><\/strong><\/p>\n

We\u2019ve Got A Problem<\/h2>\n

Decentralized consensus isn\u2019t easy. There\u2019s a reason most companies have CEOs, and \u201cnon-hierarchical\u201d organizations tend not to function well for long. Bitcoin\u2019s decentralized governance is harder still: On top of decentralization, we layer a relative lack of official processes, standards and norms for group decision-making \u2014 we even lack clarity around when to make a decision at all.<\/p>\n

Jeremy Rubin\u2019s recent proposal of a Speedy Trial consideration<\/a> 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.<\/p>\n

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.<\/p>\n

This article argues for two changes to the \u201cmeta\u201d process of BIP consideration, which I believe could significantly improve the quality of our debates:<\/p>\n

    \n
  1. Raise a set of high standards for BIP documentation.<\/li>\n
  2. Adopt these open standards as a de facto minimum<\/em> quality bar for a BIP to be considered for wider discussion.<\/li>\n<\/ol>\n

    I believe these standards could radically improve the quality of our decentralized decision-making about Bitcoin. But first, I\u2019d like to illustrate the problem in more detail.<\/p>\n

    Information And objectivity<\/h2>\n

    Let\u2019s pick on an anonymous, highly indicative tweet:<\/p>\n

    \n

    \u201cCTV isn\u2019t 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\u2019m not a developer or technically trained but this feels rushed and that is a for me.\u201d<\/p>\n<\/blockquote>\n

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

    Poor Informational Standards<\/h3>\n

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

    \u201c[N]o one has bothered to review it thoroughly<\/em>,\u201d <\/em>the anon adds, but <\/em>a large number of Bitcoiners and developers have done so. The social \u201csignals\u201d<\/a> of their support or objection are listed on Rubin\u2019s CTV website, where he also links to implementations of numerous downstream uses<\/a> of CTV by himself and others<\/a>.<\/p>\n

    The author of said tweet has a reasonable model for decision-making \u2014 to oppose new or poorly reviewed proposals \u2014 but is applying that model incorrectly because he lacks essential context.<\/p>\n

    The above two criticisms are not the only popular expressions of this problem. For example, concerns have been voiced about CTV\u2019s riskiness, but they are voiced in the absence of essential context \u2014 clarity around what constitutes a risk and comparison to previously accepted BIPs.<\/p>\n

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

    (My argument is not, \u201cBecause Taproot, therefore CTV.\u201d I am merely pointing to the inconsistency resulting from a poorly informed mental model.)<\/p>\n

    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, \u201cAn educated citizenry is a vital requisite for Bitcoin\u2019s survival as the global monetary standard.<\/a>\u201d<\/p>\n

    The discussion about BIP119 could benefit from a much higher floor of understanding and context.<\/p>\n

    Unmoored Subjectivity<\/h3>\n

    Our Twitter anon makes two further points: \u201cCTV isn\u2019t necessary\u201d and \u201c[T]his feels rushed and that is a for me.\u201d Once again, the arguments are fair enough. As Rubin himself said, pointing to alternate covenant solutions, \u201cI don’t give a single fuck if BIP-119 CTV specifically is activated or not.<\/a>\u201d<\/p>\n

    But these two statements point squarely at another problem with the debate: Our unavoidably subjective standards have nothing tangible to latch onto \u2014 no objective measures and no clear comparisons. In the absence of clear and comparative evidence, how are we to assess what is \u201cnecessary\u201d or has been \u201crushed\u201d without resorting to emotion, group-think and shifting, illogical argumentation<\/a>?<\/p>\n

    \u201cEternal toxicity\u201d may be \u201cthe price of consensus,\u201d<\/a> and subjectivity is fundamental and unavoidable. Permanent <\/em>subjectivity detached from relevant facts, however, destroys the capacity for collective decision-making.<\/p>\n

    What To Do About It?<\/h2>\n

    I propose the adoption of a set of public documentation <\/em>standards for what constitutes the bare minimum<\/em> a BIP must provide to be worthy of large-scale public debate. I am not<\/em> 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 \u201crushed,\u201d \u201ctoo early\u201d and \u201cvery much in its infancy as a project.\u201d<\/p>\n

    In a phrase, \u201cThe community will consider your BIP premature until it answers all the relevant questions clearly in one place.\u201d<\/p>\n

    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.<\/p>\n

    Absent the clarity to meaningfully align on the comparative standards for a given BIP, our decentralized debates descend into a purgatory of \u201ctrivial\u201d bikeshedding<\/a> \u2014 a hippie co-op from hell.<\/p>\n

    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.<\/p>\n

    This is as chill as it\u2019ll get. We\u2019re gonna need a better process. There are reasons to be wary of more processes, however, and I think it\u2019s important to address them first.<\/p>\n

    Objections<\/h2>\n

    On Ossification<\/h3>\n

    My argument assumes the desirability of change at all. Many in the community argue against any change and for \u201cossification\u201d of Bitcoin\u2019s code, but even if we want to protect Bitcoin as it is, I believe this to be a mistake.<\/p>\n

    Bitcoin\u2019s 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 \u2014 peace be upon him \u2014 provide the canonical example.<\/p>\n

    Other core properties of Bitcoin, however, are dynamic functions of the broader environment, as well as of Bitcoin\u2019s usage over time. These can change even if Bitcoin Core\u2019s code doesn\u2019t.<\/p>\n

    Consider privacy. Bitcoin\u2019s ledger is dismayingly open to chain analysis<\/a>. Privacy advocates worry<\/a> that bitcoin\u2019s 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 \u2014 a central bank digital currency (CBDC) by proxy.<\/p>\n

    Privacy is not the only irreducible monad of bitcoin\u2019s value proposition. Rubin\u2019s advent calendar series of articles<\/a> on covenants outlines a reasonable starting set of four such \u201cpillars\u201d beyond its constrained supply:<\/p>\n

      \n
    1. Scalability<\/a>: 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.<\/li>\n
    2. Self-custody<\/a>: 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 \u201cpaper bitcoin\u201d).<\/li>\n
    3. Decentralization<\/a> – The dispersal of power across a wide range of actors, itself a proxy for fundamental censorship-resistance and user control.<\/li>\n
    4. Privacy<\/a> – The ease with which bitcoin users can transact without their funds being tracked, seized, marked or blocked.<\/li>\n<\/ol>\n

      Perhaps you don\u2019t really care about one or two of these \u201cpillars.\u201d Perhaps you want to add another of your own. But consider the following list and note how:<\/p>\n