1/ This is an interesting idea. Leaving aside the issue of whether this would actually stop the rise of altcoins, I doubt that in-protocol incentives for future development would be feasible.
2/ The reason Bitcoin’s incentive scheme works is that it’s actually pretty simple.
*Note: this does not imply that the Game Theory aspect of Bitcoin is simple. Complex dynamics could develop from very simple rules (e.g.: think of Go/Chess).
*Note: this does not imply that the Game Theory aspect of Bitcoin is simple. Complex dynamics could develop from very simple rules (e.g.: think of Go/Chess).
3/ Concretely, in Bitcoin, the goal of mining can be:
(a) mathematically defined - miners get paid for finding a hash that is <= current difficulty target
(b) computationally verifiable - miners’ work is verifiable by *anyone*, cheaply
(a) mathematically defined - miners get paid for finding a hash that is <= current difficulty target
(b) computationally verifiable - miners’ work is verifiable by *anyone*, cheaply
4/ The fact that the goal can be mathematically defined & computationally verifiable means that the incentive scheme can be automated: a reward will be paid out whenever said goal is met. This simple logic thus can be embedded directly into Bitcoin’s consensus code.
5/ In contrast, it’s often impossible to convert “development goals” into something that satisfy the above 2 conditions.
6/ An example of a development goal: scale the network 2X without degrading network security or Bitcoin’s essential attributes.
7/ How would you translate this scaling requirement into concrete, mathematical terms? As we have seen, “network security” or “Bitcoin’s essential attributes” can mean very different things to different people. It is also hard to verify and verify cheaply.
8/ In effect, this means that development goals/roadmap will ultimately require *subjective human inputs*. Who’s to create development goals? Who’s to define judging criteria? This is all fuzzy stuff that cannot be automated away / embedded into the protocol.
9/ TL;DR: In-protocol incentives only work if the goal can be mathematically defined & computationally verifiable.
10/ One more food for thought: there is another aspect to incentives & that is whether designed incentives can truly bring the intended effects. There’s a long history of human-made incentives that ended up producing undesirable outcomes. en.wikipedia.org/wiki/Perverse_…
11/ In Bitcoin’s case, it’s clear how block rewards (and later transaction fees) help secure the network. The effort spent chasing the rewards is directly linked to network security. 100%.
12/ But it’s not always so simple. An example of a perverse incentive is Ethereum Casper’s concept of “inactivity leak”. In trying to incentivize nodes to stay online, you might inadvertently *disincentivize* them instead.
13/ A similar argument can be made for any protocol that fancies the idea of embedding governance into the protocol & have stake holders vote on protocol changes. Democracy will never produce a good engineering system. It’s akin to asking the mob on how to design a space shuttle.
14/ The more complex the rules, the harder it is to ensure that the arising dynamics match exactly what you want, or not have unintended effects.
