TL;DR: Bitcoin needs a formal built-in "meta-level" - so that we can vote for rule changes directly on the blockchain.
---
To resolve Bitcoin's apparently intractable governance impasse, I propose:
- We should use the well-known approach of doing a "spinoff" - which, by definition, will preserve everyone's existing balances on the existing Bitcoin ledger.
- This spinoff should also include a crucial new feature called
"meta-upgrades" - ie, it should include support for
voting directly on the blockchain to make any changes to the protocol rules, the consensus rules and the governance rules.
This approach would constitute a kind of "meta Schelling point" - because it not only guarantees that all investors can preserve their current wealth, but it also guarantees that they will
always retain full control over the rules of the system itself, now and forever in the future.
Basically the concept of "meta upgrades" would put certain existing governance proposals (fork futures from /u/ForkiusMaximus aka
@Zangelbert Bingledack, or off-chain proof-of-stake governance voting from
@awemany)
directly on the blockchain, where they belong.
It is time for us to stop wasting our lives arguing about governance on forums infested by sockpuppets and trolls. It is time for us to implement Bitcoin governance itself directly on the blockchain.
Satoshi already created a decent formal on-chain consensus mechanism for choosing the next block to append to the chain. It should be straightforward for us to now extend that - to a decent formal on-chain consensus mechanism for choosing the ruleset used to define the validity of the blocks themselves.
Some existing approaches in this direction include:
- Bitcoin Unlimited - where nodes are able to signal their preferences regarding "max blocksize"
- BitPay's Adaptive Blocksize - where this decision-making process is partially based on examining the median of previous blocksizes
In order to avoid eternal bikeshedding in the future about any additional changes (as well as to get everyone "on board" now with a kind of "meta Schelling point" where everyone feels comfortable that the new system will be able to adequately handle any possible unforeseen rule changes down the road), it is important for us to do a bit of this kind of "meta" thinking right now - focusing on building a system which not only allows changing the rules, but also allows
changing the rules for changing the rules - on the blockchain itself.
If people are going to put all kinds of crap onto the blockchain such as colored coins or land deeds or marriage proposals, then it's time for us to harness the blockchain for what we most urgently need to do:
on-chain Bitcoin governance.
Feasibility:
Of course, this might sound ambitious - because anything "meta" can be a bit intimidating.
But this approach has a long track record of success in mathematics and computer science, eg:
- the
CLOS-MOP: Common LISP Object System Meta-Object Protocol;
- philosopher Peter Suber’s
Nomic, a game built around a fully introspective set of rules;
- programming systems such as
Spoofax or
Maude which include strategy meta-languages, etc.
More importantly: there is also a cryptocurrency in the works which aims to provide "meta updates" (on-chain voting about the rules), called
Tezos - see below.
So basically the idea is: let's borrow the "meta updates" feature from Tezos, while using a spinoff to maintain the existing ledger.
A "functional" language like Ocaml is better than a "procedural/imperative" language like C/C++
Voting for "upgrades to rules/algorithms" directly on the blockchain should be quite feasible, given an expressive enough language for encoding the rules/algorithms themselves.
Indeed any decent "functional" programming language can do this.
Recall that one of the main features of a "functional" programming language is that it is able to treat functions as data - eg, it is able to pass a function as an
argument into a call to another function, and it also able to return a function as the
result of a call to a function.
This is the precisely kind of feature which is needed if we want to be able to "vote on the rules".
In a "functional" language, it is straightforward define rules/algorithms by encoding them as functions, and then pass those functions around as data: using them as input and output for the "main" functions of the cryptocurrency system itself.
In addition, certain mature "functional" language ecosystems (such as the functional language Ocaml + the theorem-prover Coq) also support an even more advanced and more secure approach: we could write a
specification (theorem) in Coq, and then we could derive a
implementation (proof) for it in Ocaml. The extra benefit here is that a
specification is more compact, more human-readable, and thus easier to reason about than an
implementation.
Mathematical aside: This formal approach, already used with success for decades, is based on the well-known Curry-Howard Isomorphism, which states that deriving a proof for a theorem (in math) is equivalent to deriving an implementation from a specification (in programming).
We can illustrate the importance of providing a
theorem (and not just its
proof) by recalling high school geometry: Consider a
proof of something like the Pythagorean theorem. There are actually many such proofs - and they are all rather long and involved and confusing and hard to understand. On the other hand, recall the statement of the Pythagorean
theorem itself: a^2 + b^2 = c^2 - ie, for a right triangle, the sum of the squares of the shorter sides (the "legs") is equal to the square of the longer side (the "hypotenuse").
This comparison is highly relevant today - the day when Ethereum's "The DAO" got hacked. The problem with The DAO was that its description (
specification), while being human-readable, was also informal - and totally disconnected from its
implementation, which was long and not very human-readable, and which tragically, contained a flaw which a hacker was able to exploit.
[continued below]
