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).
-
-
Show this thread
-
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
Show this thread -
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.
Show this thread -
5/ In contrast, it’s often impossible to convert “development goals” into something that satisfy the above 2 conditions.
Show this thread -
6/ An example of a development goal: scale the network 2X without degrading network security or Bitcoin’s essential attributes.
Show this thread -
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.
Show this thread -
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.
Show this thread -
9/ TL;DR: In-protocol incentives only work if the goal can be mathematically defined & computationally verifiable.
Show this thread -
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. https://en.wikipedia.org/wiki/Perverse_incentive …
Show this thread -
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%.
Show this thread -
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.https://twitter.com/TuurDemeester/status/981720971223629825 …
Show this thread -
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.
Show this thread -
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.
Show this thread
End of conversation
New conversation -
-
-
Agreed. I can’t come up with a decentralized, on-chain solution for incenting developers either:https://twitter.com/naval/status/985020476744400896?s=21 …
-
What I don’t buy is the argument that good developers don’t need to be paid (not saying you’re making it, others are). It’s an AND not an OR. Anyone designing an incentive system should acknowledge Free Rider and Tragedy of the Commons.
-
What we have right now is suboptimal incentive allocation - all the rewards are going to founders, early investors and miners. None to late developers. Which leads to more independent blockchains that would exist otherwise.
-
But there seems to be no decentralized, on-chain solution to the problem. But the market will test BTC and ETH by creating “innovation incentives.” BTC has a weak implicit one (own some BTC). ETH has a slightly stronger one (ERC 20).
-
But in this Cambrian Coin Explosion, we will see coins that use inflation funding and centralized grants to fund engineering for a while, and then switch to decentralized models.
-
For the non-private pure-SoV use case, there’s a good argument that Bitcoin is done, should stay simple and decentralized. For the “Global Computing Platform” use case, further innovation is likely needed. So ongoing incentives for development matter.
-
I mostly agree. Lack of top dev talents is def a big problem & like you said, Tragedy of the Commons. Maybe the next best solution is for the biggest companies in the space to step up & raise a common, neutral fund to attract protocol developers. Give them a stake in the coin.
-
I'm kinda skeptical on the decentralized computing idea for smart contracts- there’re quite a few knowledgable folks that believe that what’s important for smart contracts is less about "computing" than contract verifiability. Easier to scale too.
- 4 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
