My proposal is to make updates to the Dash software automatically propagate through the Dash blockchain. Updates can be voted by Master Nodes, each miner, master node or client must then include the change or become incompatible. The client software should manage the update automatically as part of its normal operation.
With a system like this in place, there is zero chance of a situation similar to the politics currently surrounding Bitcoin’s block size changes.
Some implementation details
To make this work technically, there needs to be a core of the Dash client that is automatically updatable. This could be either by an interpreter (e.g. JavaScript) some kind of bytecode-based runtime (JVM, WASM), source code that is compiled locally by a compiler that is part of the core, or a self modifying executable. The latter being least preferable because of cross-platform concerns. The core client is wrapped in a shell, which can be provided by any third party. The shell application should support one additional integration command, which is to update and replace the entire core. This may be desirable years in the future, when the current technology is too outdated. The core is self-updating for most functional changes, and any part of the protocol can be modified, without restriction.
Changes are patches that are applied to a particular base version and are identified by a secure hash. You should be able to update all patches in sequence if your client is very far behind. Patches may be stored anywhere on the internet, with URLs for mirrors stored in the blockchain. Votes are cast against a hash of the signed update, which is verified upon installation.
My proposal would be that a new change to the core would require 51% of master nodes to agree and the 51% must stand for at least 60 consecutive days. Having a time period attached to a vote makes sure that voters have time to change their mind and to give a window to notice problems with changes after testing on testnet.
For very urgent fixes, which should be tagged as such (for example a security exploit or crashing bug), 95% of master nodes may agree for a period of 1 hour or 85% for 12 hours. There should be a mechanism to reverse an urgent patch if it turned out to be ineffective or in some way harmful.
It might make sense for there to be multiple layers with different rules. The underlying layer, the “Constitution”, requires a very high number of votes, over a long period of time in order to change it. This would include parameters related to voting thresholds etc. The next layer would be economic and include mining, block reward and difficulty parameters. Layers on top of that might relate to masternode services like darksend etc.
Consequences
There is no Foundation required. Money is allocated to developers by masternode vote, as already implemented. When patches are ready they are voted automatically into every connected client.
All aspects of the protocol may be easily modified: Block Reward, master node reward, block size constraints, confirmation time, voting thresholds, “suggested” miner fee, even the mining algorithm.
There is only one Dash core. Competing wallet clients can focus on usability features and not worry about compatibility.
Miners may still produce compatible alternatives that are more efficient, but have to play catch-up if the mining hashing algorithms change. Dash can keep ahead of ASICs by frequently adding new algorithms, and removing old ones. The fact that this *could* happen should disincentivise ASICs from even being designed.
Emergency changes can be made very quickly and distributed to the entire network seamlessly. Think of all the issues that Bitcoin has had in the last few years and how hard they were to fix without creating forks.
Changes to the protocol are immediate, and transparent to the user. (New features may not be available to GUI applications until the developers and UI for it, and removed features may no longer work, but this should be manageable.
It’s quite a frightening thought, but all aspects of the currency would come under the control of an autonomous democratic entity. It’s possible to imagine this growing into something analogous to a national government, but across international borders. The Dash "government" could end up having permanent human employees, carrying out any practical tasks, while no Dash owners even need to know who they are.
It should still be possible for dissenting full-node owners to cause a hard fork if they disagree with Masternode votes. A kind of revolution.
This is an experiment in pure capitalism, but without the possibility of corruption.
With a system like this in place, there is zero chance of a situation similar to the politics currently surrounding Bitcoin’s block size changes.
Some implementation details
To make this work technically, there needs to be a core of the Dash client that is automatically updatable. This could be either by an interpreter (e.g. JavaScript) some kind of bytecode-based runtime (JVM, WASM), source code that is compiled locally by a compiler that is part of the core, or a self modifying executable. The latter being least preferable because of cross-platform concerns. The core client is wrapped in a shell, which can be provided by any third party. The shell application should support one additional integration command, which is to update and replace the entire core. This may be desirable years in the future, when the current technology is too outdated. The core is self-updating for most functional changes, and any part of the protocol can be modified, without restriction.
Changes are patches that are applied to a particular base version and are identified by a secure hash. You should be able to update all patches in sequence if your client is very far behind. Patches may be stored anywhere on the internet, with URLs for mirrors stored in the blockchain. Votes are cast against a hash of the signed update, which is verified upon installation.
My proposal would be that a new change to the core would require 51% of master nodes to agree and the 51% must stand for at least 60 consecutive days. Having a time period attached to a vote makes sure that voters have time to change their mind and to give a window to notice problems with changes after testing on testnet.
For very urgent fixes, which should be tagged as such (for example a security exploit or crashing bug), 95% of master nodes may agree for a period of 1 hour or 85% for 12 hours. There should be a mechanism to reverse an urgent patch if it turned out to be ineffective or in some way harmful.
It might make sense for there to be multiple layers with different rules. The underlying layer, the “Constitution”, requires a very high number of votes, over a long period of time in order to change it. This would include parameters related to voting thresholds etc. The next layer would be economic and include mining, block reward and difficulty parameters. Layers on top of that might relate to masternode services like darksend etc.
Consequences
There is no Foundation required. Money is allocated to developers by masternode vote, as already implemented. When patches are ready they are voted automatically into every connected client.
All aspects of the protocol may be easily modified: Block Reward, master node reward, block size constraints, confirmation time, voting thresholds, “suggested” miner fee, even the mining algorithm.
There is only one Dash core. Competing wallet clients can focus on usability features and not worry about compatibility.
Miners may still produce compatible alternatives that are more efficient, but have to play catch-up if the mining hashing algorithms change. Dash can keep ahead of ASICs by frequently adding new algorithms, and removing old ones. The fact that this *could* happen should disincentivise ASICs from even being designed.
Emergency changes can be made very quickly and distributed to the entire network seamlessly. Think of all the issues that Bitcoin has had in the last few years and how hard they were to fix without creating forks.
Changes to the protocol are immediate, and transparent to the user. (New features may not be available to GUI applications until the developers and UI for it, and removed features may no longer work, but this should be manageable.
It’s quite a frightening thought, but all aspects of the currency would come under the control of an autonomous democratic entity. It’s possible to imagine this growing into something analogous to a national government, but across international borders. The Dash "government" could end up having permanent human employees, carrying out any practical tasks, while no Dash owners even need to know who they are.
It should still be possible for dissenting full-node owners to cause a hard fork if they disagree with Masternode votes. A kind of revolution.
This is an experiment in pure capitalism, but without the possibility of corruption.