Topic: A blockchain-based hard-fork voting system without thresholds (Read 735 times)
This will stop the discussions?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
A blockchain-based hard-fork voting system without thresholds
A managed hard-fork event requires synchronised cooperation between various participants (core developers, wallet developers, exchanges, miners). It requires human attention and humans are notoriously limited with their attention span. Too many possibilities (often similar) lead to distraction and endless discussions.
A given managed hard-fork also requires a specific threshold which triggers a hard-fork deployment (e.g. 75% of hashing power needs to signal an agreement with proposed hard-fork). This threshold is problematic because there has to be *someone* who sets it in stone. This threshold level has delicate effects on the outcome and that leads to politics.
Let me propose a blockchain-based hard-fork voting and scheduling system without hard-fork thresholds. First, I'm going to describe a gist of it in less-technical terms. Following sections will include possible technical implementation details and a short discussion.
- ---
Every 6 months Bitcoin network executes a managed hard fork. This divides timeline into equal 6-month periods where each period has two phases:
1. first 5 months is a voting phase
2. last 1 month is a signalling phase / a proposal phase
During the proposal phase, anyone can submit a specially crafted transaction which proposes a libconsensus changeset. Transaction will only contain identification of the changeset (a witness). Full details will be publicly published off-chain. Let's call this transaction a 'proposal'.
During the voting phase, anyone can submit a specially crafted transaction (e.g. by spending bitcoins to themselves or as part of their normal spending) mentioning a proposal. This will cast a weighted vote for the mentioned proposal (bitcoin days destroyed).
At the end of the voting period. The winning proposal (total bitcoin days destroyed) is promoted as the new candidate libconsensus. The last month is the time for miners to signal their intentions for fork-point. Miners express (Y) to signal support for switch to the candidate, (N) to signal support to stay on the current libconsensus. Or they do nothing (0) to signal a neutral opinion (or they simply don't care).
At the end of signalling period. A hard-fork happens either way. Please note that technically libconsesus is the same in N as the old libconsensus but their versions will be different. So from the point of the system N is a hard-fork of the current state.
Signalling period time is also used for gathering new proposals for following period. Participants should submit proposals (optionally anonymously without revealing off-chain content until the proposal gets mined or voting starts).
- ---
All voting/signalling information must be communicated via the blockchain. Anyone having a copy of the blockchain must be able to reconstruct and evaluate "the whole picture" (except for changesets which is not relevant for observing the system).
We have to define period/phase timing in terms of block counts:
1. voting phase: VP=5*30*24*6 blocks
2. signalling phase: SP=1*30*24*6 blocks
This will require an initial "bootstrapping" hard-fork to define starting block for the first period. This hard-fork also adds a new "super-consensus" rule: "must switch to a new version of libconsensus with each new period".
A proposal transaction could use OP_RETURN. E.g. to combine proposal-marker (38b), proposal-type (2b) and proposal-content witness (40b). Initially we could support git-based proposal-type where witness is defined as a SHA of the proposed libconsensus branch tip. The system would be open for future proposal-types by defining a new proposal-type.
A voting transaction could use OP_RETURN to mention transaction ID of a specific proposal transaction.
Signalling could use existing mechanism of version bits. It would require 2 bits to encode the three cases (Y,N,0).
At the point of hard-fork. Miners following the "super-consensus" rule will either switch to Y or N. There are not allowed to stay on the old libconsensus. Y is defined as the candidate libconsensus from winning proposal. N is constructed as the current libconsensus with bumped version number. In theoretical degenerated case when there were no proposals. Y is defined as N.
- ---
I believe this system would have beneficial community effect. Managed hard-forks cannot occur more often than every X months and they occur at well defined schedule. Mainstream discussion will likely revolve around a few top winning proposals backed with strong signal of their support. Voting is performed by economic community of people and machines who really use Bitcoin (they either transact or hold significant amounts). Voting can be anonymous, is fully revealed to public and provable via the blockchain. Voting power is a scarce resource as well as time (there is well defined closing-date for each voting period). This won't change the fundamental rule in Bitcoin that majority of hashing power sets the consensus. But a community-promoted candidate proposal will force miner community to clearly answer. The Y/N/0 voting clearly separates "definitely-yes", "definitely-no" and "indifferent" miner camps. At the point of hard-fork, 0-camp will probably jump on the side with stronger signalling (because according to super-consensus rule they must change libconsensus anyways), shortly after that losing side will join the stronger side. Of course, miners can ultimately behave differently than they signalled, but in that case they damage their public reputation. Also they could suddenly remove super-consensus rule and stay on the old libconsensus without hard-forking. This would effectively mean abandoning this voting system and undoing "bootstrapping" hard-fork. This is a game-theory question which I hope someone more capable will be able to model more formally. The main question to answer is if a small group of miners can still effectively inhibit any decision process under a system like this.
Also I think that mandatory forking (even to the same consensus rules just with bumped version number) would have beneficial effects (like performing a fire drill). All participants will learn how to deal with it in an orderly way. Also this system does not prevent ad-hoc (emergency) hard-forks if needed (today's model).
This system is also able to remove the need for setting an arbitrary threshold for hard-fork triggering. But it is introducing arbitrary timing constants (VP,SP). I believe those timing constants are less prone to politics because they should be modelled after natural human/community/developer attention capacity. Also they will be set once in the bootstrapping hard-fork and then should be changed only via the voting mechanism itself.
-----BEGIN PGP SIGNATURE-----
wsFcBAEBCAAQBQJW3H0QCRAyqJqp3djIfwAAGggQABVgB0YNWVBVlhgt3QQQklDb
d/l2kJ1kz0tSaGPPdvmL0XDEP1GuBTBep26Fj2123uyjCnOALgMWzLN+rBJ8NyRP
IshhVMNql67LmvQ8RqPWhJ4bolY4Zja9L932mpDhIaJSr+9DSS5YrM86B33g23HH
sPmcILyb3hEqTtmctgg1Gc5tE1CtyDyxkYEnYABLZ7BP2eFFEFVOsCFPCNROqvV5
Q+ATuMnLDLy8Zqzsqj01VBaJOPRSktfkP8VN4tGpiuS/NF7U/gUkvNDvjIlr3vWg
GqNagi86icyXHQRL1cVYfwrPZwPDDxQxVMCDyG2lpE6AJoYuQq0DAEHVoQEfMPkS
lCizMMnoBkXXG4uZdjy1kosjg2DEtML/DI9IHnCMLffcxK9IS8B+K08h1BVZqWnW
/qMoYJu1P0IXO3HktLiDuxPqH8fkh39wx+XrnjRzleYBLxoqCiJkEsCKcS9rQeJa
B5qdpWXYEFgE8aSSHlwkHwUhNI20cAuxPddNX6yeOiQe7xYreUq43FGopFiPePmc
0Hg0fmiNMRHV4u2u1PD1g+k5hD/MmHDukpH9aZUG45Fu6Pguxv+okXlhwt2cgURO
PLpxtBgt829AOfKF4Iuj5bcaePBRv4HEsqaIiN7JXHfi9Iq0ZZArf8F7jGAYc9rE
aXm96IPwihq0SSZb7M7J
=+w90
-----END PGP SIGNATURE-----
Hash: SHA256
A blockchain-based hard-fork voting system without thresholds
A managed hard-fork event requires synchronised cooperation between various participants (core developers, wallet developers, exchanges, miners). It requires human attention and humans are notoriously limited with their attention span. Too many possibilities (often similar) lead to distraction and endless discussions.
A given managed hard-fork also requires a specific threshold which triggers a hard-fork deployment (e.g. 75% of hashing power needs to signal an agreement with proposed hard-fork). This threshold is problematic because there has to be *someone* who sets it in stone. This threshold level has delicate effects on the outcome and that leads to politics.
Let me propose a blockchain-based hard-fork voting and scheduling system without hard-fork thresholds. First, I'm going to describe a gist of it in less-technical terms. Following sections will include possible technical implementation details and a short discussion.
- ---
Every 6 months Bitcoin network executes a managed hard fork. This divides timeline into equal 6-month periods where each period has two phases:
1. first 5 months is a voting phase
2. last 1 month is a signalling phase / a proposal phase
During the proposal phase, anyone can submit a specially crafted transaction which proposes a libconsensus changeset. Transaction will only contain identification of the changeset (a witness). Full details will be publicly published off-chain. Let's call this transaction a 'proposal'.
During the voting phase, anyone can submit a specially crafted transaction (e.g. by spending bitcoins to themselves or as part of their normal spending) mentioning a proposal. This will cast a weighted vote for the mentioned proposal (bitcoin days destroyed).
At the end of the voting period. The winning proposal (total bitcoin days destroyed) is promoted as the new candidate libconsensus. The last month is the time for miners to signal their intentions for fork-point. Miners express (Y) to signal support for switch to the candidate, (N) to signal support to stay on the current libconsensus. Or they do nothing (0) to signal a neutral opinion (or they simply don't care).
At the end of signalling period. A hard-fork happens either way. Please note that technically libconsesus is the same in N as the old libconsensus but their versions will be different. So from the point of the system N is a hard-fork of the current state.
Signalling period time is also used for gathering new proposals for following period. Participants should submit proposals (optionally anonymously without revealing off-chain content until the proposal gets mined or voting starts).
- ---
All voting/signalling information must be communicated via the blockchain. Anyone having a copy of the blockchain must be able to reconstruct and evaluate "the whole picture" (except for changesets which is not relevant for observing the system).
We have to define period/phase timing in terms of block counts:
1. voting phase: VP=5*30*24*6 blocks
2. signalling phase: SP=1*30*24*6 blocks
This will require an initial "bootstrapping" hard-fork to define starting block for the first period. This hard-fork also adds a new "super-consensus" rule: "must switch to a new version of libconsensus with each new period".
A proposal transaction could use OP_RETURN. E.g. to combine proposal-marker (38b), proposal-type (2b) and proposal-content witness (40b). Initially we could support git-based proposal-type where witness is defined as a SHA of the proposed libconsensus branch tip. The system would be open for future proposal-types by defining a new proposal-type.
A voting transaction could use OP_RETURN to mention transaction ID of a specific proposal transaction.
Signalling could use existing mechanism of version bits. It would require 2 bits to encode the three cases (Y,N,0).
At the point of hard-fork. Miners following the "super-consensus" rule will either switch to Y or N. There are not allowed to stay on the old libconsensus. Y is defined as the candidate libconsensus from winning proposal. N is constructed as the current libconsensus with bumped version number. In theoretical degenerated case when there were no proposals. Y is defined as N.
- ---
I believe this system would have beneficial community effect. Managed hard-forks cannot occur more often than every X months and they occur at well defined schedule. Mainstream discussion will likely revolve around a few top winning proposals backed with strong signal of their support. Voting is performed by economic community of people and machines who really use Bitcoin (they either transact or hold significant amounts). Voting can be anonymous, is fully revealed to public and provable via the blockchain. Voting power is a scarce resource as well as time (there is well defined closing-date for each voting period). This won't change the fundamental rule in Bitcoin that majority of hashing power sets the consensus. But a community-promoted candidate proposal will force miner community to clearly answer. The Y/N/0 voting clearly separates "definitely-yes", "definitely-no" and "indifferent" miner camps. At the point of hard-fork, 0-camp will probably jump on the side with stronger signalling (because according to super-consensus rule they must change libconsensus anyways), shortly after that losing side will join the stronger side. Of course, miners can ultimately behave differently than they signalled, but in that case they damage their public reputation. Also they could suddenly remove super-consensus rule and stay on the old libconsensus without hard-forking. This would effectively mean abandoning this voting system and undoing "bootstrapping" hard-fork. This is a game-theory question which I hope someone more capable will be able to model more formally. The main question to answer is if a small group of miners can still effectively inhibit any decision process under a system like this.
Also I think that mandatory forking (even to the same consensus rules just with bumped version number) would have beneficial effects (like performing a fire drill). All participants will learn how to deal with it in an orderly way. Also this system does not prevent ad-hoc (emergency) hard-forks if needed (today's model).
This system is also able to remove the need for setting an arbitrary threshold for hard-fork triggering. But it is introducing arbitrary timing constants (VP,SP). I believe those timing constants are less prone to politics because they should be modelled after natural human/community/developer attention capacity. Also they will be set once in the bootstrapping hard-fork and then should be changed only via the voting mechanism itself.
-----BEGIN PGP SIGNATURE-----
wsFcBAEBCAAQBQJW3H0QCRAyqJqp3djIfwAAGggQABVgB0YNWVBVlhgt3QQQklDb
d/l2kJ1kz0tSaGPPdvmL0XDEP1GuBTBep26Fj2123uyjCnOALgMWzLN+rBJ8NyRP
IshhVMNql67LmvQ8RqPWhJ4bolY4Zja9L932mpDhIaJSr+9DSS5YrM86B33g23HH
sPmcILyb3hEqTtmctgg1Gc5tE1CtyDyxkYEnYABLZ7BP2eFFEFVOsCFPCNROqvV5
Q+ATuMnLDLy8Zqzsqj01VBaJOPRSktfkP8VN4tGpiuS/NF7U/gUkvNDvjIlr3vWg
GqNagi86icyXHQRL1cVYfwrPZwPDDxQxVMCDyG2lpE6AJoYuQq0DAEHVoQEfMPkS
lCizMMnoBkXXG4uZdjy1kosjg2DEtML/DI9IHnCMLffcxK9IS8B+K08h1BVZqWnW
/qMoYJu1P0IXO3HktLiDuxPqH8fkh39wx+XrnjRzleYBLxoqCiJkEsCKcS9rQeJa
B5qdpWXYEFgE8aSSHlwkHwUhNI20cAuxPddNX6yeOiQe7xYreUq43FGopFiPePmc
0Hg0fmiNMRHV4u2u1PD1g+k5hD/MmHDukpH9aZUG45Fu6Pguxv+okXlhwt2cgURO
PLpxtBgt829AOfKF4Iuj5bcaePBRv4HEsqaIiN7JXHfi9Iq0ZZArf8F7jGAYc9rE
aXm96IPwihq0SSZb7M7J
=+w90
-----END PGP SIGNATURE-----
Jump to: