Name: A Modest Bitcoin Improvement Proposal, Proposal
Brand: bitcoinmagazine.com
SKU: bitcoinmagazine-com-10
Availability: OnlineOnly
Rating: 100 (1 reviews)

critic

A Modest Bitcoin Improvement Proposal, Proposal

preview

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 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:Raise a set of high standards for BIP documentation.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.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.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 . Its BIP number was assigned and consistent work has been done on top of the essentially static BIP since. Its potential applications have been explored in the and 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 of their support or objection are listed on Rubin’s CTV website, where he also links to of CTV by himself and .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 , , and involving .(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, “”The discussion about BIP119 could benefit from a much higher floor of understanding and context.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, “”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 ? and subjectivity is fundamental and unavoidable. Permanent subjectivity detached from relevant facts, however, destroys the capacity for collective decision-making.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 — 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.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 . 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 on covenants outlines a reasonable starting set of four such “pillars” beyond its constrained supply:: 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.: 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”). - The dispersal of power across a wide range of actors, itself a proxy for fundamental censorship-resistance and user control. - 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: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 put it in a , 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.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 , 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: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: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. 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.To apply quantitative heft to concerns that a given BIP “feels rushed,” the proposal tracker should include a full timeline of relevant events: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.A link to the BIP we see today: The condensed, technical proposal with real implementation details and references to concrete opcodes, fields and code.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 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.An ongoing, version-controlled list of relevant links to news articles, podcasts and other external references to the proposal.The Bitcoin community seems quite alive to the risks of change, but often in a vague way that shows . The risks of a given proposal to Bitcoin Core ( should be listed explicitly. They include: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 “” attempts to 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 , is strongly encouraged and could be community-sponsored in the future.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: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 .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?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 .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?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 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.Loading…See MoreCLOSECLOSECLOSECLOSE

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 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...

Well Sourced

public

Sasha Klein

The Most Trusted Voice In #Bitcoin • Daily News 📫 http://b.tc/subscribe • Learn & Earn⚡️http://b.tc/21days • Conference 🎟 http://b.tc/conference • Watch & Learn 🎥 http://b.tc/youtube

A Modest Bitcoin Improvement Proposal, Proposal

No article scores yet.

CRITIC REVIEWS

PUBLIC REVIEWS