Decentralizing Development through Coin-holder Consensus
To increase the blocksize or not increase the blocksize, that is the question. As core developers quarrel and mining pools take sides, the world of Bitcoin-holders wait.
The genius of the Bitcoin Blockchain is in its ability to leverage asymmetrical cryptography to empower the individual through decentralization. Time, however, has taught us that Bitcoin’s real risks come not from within, but from its interactions with the old centralized-world from which it was born.
For instance:
1 – Centralized exchanges promote centralized theft.
2 – Centralization from mining pools concentrates the hashing power used to approve transactions and change the code, while simultaneously increasing the probability of a successful 51% attack.
3 – Centralized development gives us centralized decision-making and is leading to dilutive hard-forks.
Our focus here is on issue number three: centralized development.
With the controversy between Bitcoin-Core, Bitcoin-XT, BIP100, BIP101, et al., growing by the day, we now have centralized developers wooing the ever-centralizing mining pools to get the consensus they need to decide the fate of increased blocksizes.
And where exactly are the Bitcoin-holders in this decision-making process? Well, they aren’t.
You see, Bitcoin-holders are stuck waiting on the sidelines to have these centralized decision-makers shove “consensus” down their decentralized throats because, you know, Bitcoin is a decentralized currency and all.
Newsflash: Bitcoin-holders are the actual owners of Bitcoin and, consequently, have a bigger stake in Bitcoin’s outcome than either the mining pools or developers. Yet, the only decentralized stakeholders left in this “consensus” equation, the Bitcoin-Holders themselves, are completely removed from it.
But with blockchain technology, there is a better way: decentralized blockchain consensus.
Decentralized Shareholder-style Blockchain Voting
We propose a simple and clean decentralized shareholder-style blockchain voting system that allows Bitcoin-holders to cast votes on development issues in proportion to their ownership stake in Bitcoin itself; all without ever giving up control of their coins, or without needing trusted-third-parties to hold, cast or audit votes.
Decentralized shareholder-style blockchain voting provides the mandate developers need to push out controversial updates and will finally give a voice to Bitcoin-holders in a non-binding public forum that requires zero changes to the existing codebase.
In addition to creating an objectively fair method for resolving development conflicts, decentralized blockchain voting would also incentivize information-sharing between developers and the Bitcoin community. Furthermore, one day decentralized blockchain voting could give rise to competing developer factions who propose features for Bitcoin-holders to decide, and miners to subsequently adopt, rather than having a handful of centralized developers decide issues top-down.
Accordingly, in response to the shortcomings of centralized development, we now bring you CryptoVoter.
CryptoVoter
In a nutshell, decentralized shareholder-style blockchain voting, aka CryptoVoter, works by using vanity Bitcoin addresses to create a personalized vanity voting address in the user’s wallet file to allow users to send coins to themselves to publicly register votes.
More specifically, to vote the user picks an answer choice and simply sends coins from one address in their wallet to another vanity voting address in their wallet before the published voting blockheight deadline. This vanity voting address is personalized with a pre-designated voting pre-fix that represents a voting question and answer pair reflecting the user’s vote choice.
To count votes, at the designated voting blockheight deadline anyone can search voting results by doing a simple wildcard search (*) on any blockchain explorer. To eliminate double-voting, coins not confirmed in a voting address at the block-height deadline do not count. Additionally, requiring +n confirmations to the voting blockheight deadline could further secure the voting.
The CryptoVoter client would perform this functionality automatically and would provide: (i) a user-friendly interface to automatically complete the voting steps; (ii) options to manually complete the voting steps (if desired); and, most importantly, (iii) will have its source-code published on Github with deterministic Gitian build instructions and file checksum hashes provided, so anyone can verify the safety and authenticity of the CryptoVoter client.
Ultimately, with decentralized blockchain voting any user could propose, vote and audit votes themselves using the blockchain without the necessity of trusted-third parties. And best of all, it works on all blockchain-based cryptocoins that use asymmetrical public-key encryption.
After over a year of development (and setbacks), we filed a patent application and completed alpha-testing this summer (USPTO Non-Prov Patent App # 14745370).
Thus, we are pleased to announce that CryptoVoter is ready for official launch September 14, 2015.
CryptoVoter Release Date: September 14, 2015
For the initial launch the first cryptocoin to decentralize development through CryptoVoter’s shareholder-style blockchain voting service will be the Bitcoin-sCrypt alt-coin (BTCS), with plans to expand to Bitcoin-Core and other alt-coins shortly thereafter…if the community supports our efforts.
So join us in our attempt to shift power away from centralized developers and mining pools to Bitcoin-holders themselves, and help further the democratization of finance through Bitcoin blockchain technology.
The future is decentralization.
For more information check out our CryptoVoter infographic below.
info [[at]] cryptovoter.com
www.cryptovoter.com Follow us on Twitter:
@cryptovoter
Support our efforts: 1M5Uiye4tGUver2LHUzWPkZvH9cuuoomuj
Original Article posted at:
http://theotherbitcoin.com/decentralizing-development-through-coin-holder-consensus
Show Posts
