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.
1 reply 0 retweets 9 likesShow this thread -
6/ An example of a development goal: scale the network 2X without degrading network security or Bitcoin’s essential attributes.
1 reply 0 retweets 5 likesShow 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.
1 reply 3 retweets 11 likesShow 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.
1 reply 2 retweets 8 likesShow this thread -
9/ TL;DR: In-protocol incentives only work if the goal can be mathematically defined & computationally verifiable.
1 reply 6 retweets 23 likesShow 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 …
1 reply 1 retweet 10 likesShow 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%.
1 reply 0 retweets 5 likesShow this thread -
Hugo Nguyen Retweeted Tuur Demeester
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 …
Hugo Nguyen added,
Tuur Demeester @TuurDemeester“Proof-of-Stake, Private Keys Attacks and Unforgeable Costliness the Unsung Hero” —@hugohanoi https://medium.com/@hugonguyen/proof-of-stake-private-keys-attacks-and-unforgeable-costliness-the-unsung-hero-5caca70b01cb#---0-560 … pic.twitter.com/yHn0WbtVOCShow this thread1 reply 1 retweet 6 likesShow 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.
6 replies 3 retweets 16 likesShow this thread
but onchain governance isn't democracy, it's the rule of the rich
-
-
Replying to @MustStopMurad
Good point, only a democracy if everyone owns equal stake - unlikely. So yeah plutocracy is more like it. Rule by the mob or rule by the rich, pick your poison
1 reply 0 retweets 1 like - 1 more reply
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.