-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It is not scientific or sensible to go from proposal stage straight to
voting and then implementation stage.
The proposals you have diligently gathered, summarized and presented
in your document must go through testing, and scenario simulation with
published results, in order for objective evaluation to be made
possible.
For that matter, even "running up against a capacity limit" has not
been simulated or tested. Additionally, (and looking the other way)
there is a lack of provision for scaling DOWN in the current proposals
- - hard to envision, yes - but what goes up will eventually come down.
A global credit contraction is not unlikely, nor is natural disaster,
and these scenarios have implications for usage, scale, degree of
decentralization and security.
CS is science, there is no reason for this generation not to apply
rigorous Computer Science to Bitcoin.
Venzen
On 08/04/2015 02:50 PM, jl2012 via bitcoin-dev wrote:
As now we have some concrete proposals
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html),
I think we should wrap up the endless debate with voting by different
stakeholder groups.
--------------------------------- Candidate proposals
Candidate proposals must be complete BIPs with reference
implementation which are ready to merge immediately. They must
first go through the usual peer review process and get approved by
the developers in a technical standpoint, without political or
philosophical considerations. Any fine tune of a candidate proposal
may not become an independent candidate, unless it introduces some
“real” difference. “No change” is also one of the voting options.
--------------------------------- Voter groups
There will be several voter groups and their votes will be counted
independently. (The time frames mentioned below are just for
example.)
Miners: miners of blocks with timestamp between 1 to 30 Sept 2015
are eligible to vote. One block one vote. Miners will cast their
votes by signing with the bitcoin address in coinbase. If there are
multiple coinbase outputs, the vote is discounted by output value /
total coinbase output value. Many well-known pools are reusing
addresses and they may not need to digitally sign their votes. In
case there is any dispute, the digitally signed vote will be
counted.
Bitcoin holders: People with bitcoin in the UTXO at block 372500
(around early September) are eligible to vote. The total “balance”
of each scriptPubKey is calculated and this is the weight of the
vote. People will cast their votes by digital signature. Special
output types: Multi-sig: vote must be signed according to the
setting of the multi-sig. P2SH: the serialized script must be
provided Publicly known private key: not eligible to vote
Non-standard script according to latest Bitcoin Core rules: not
eligible to vote in general. May be judged case-by-case
Developers: People with certain amount of contribution in the past
year in Bitcoin Core or other open sources wallet / alternative
implementations. One person one vote.
Exchanges: Centralized exchanges listed on Coindesk Bitcoin Index,
Winkdex, or NYSE Bitcoin index, with 30 days volume >100,000BTC
are invited. This includes Bitfinex, BTC China, BitStamp, BTC-E,
itBit, OKCoin, Huobi, Coinbase. Exchanges operated for at least 1
year with 100,000BTC 30-day volume may also apply to be a voter in
this category. One exchange one vote.
Merchants and service providers: This category includes all
bitcoin accepting business that is not centralized fiat-currency
exchange, e.g. virtual or physical stores, gambling sites, online
wallet service, payment processors like Bitpay, decentralized
exchange like Localbitcoin, ETF operators like Secondmarket Bitcoin
Investment Trust. They must directly process bitcoin without
relying on third party. They should process at least 100BTC in the
last 30-days. One merchant one vote.
Full nodes operators: People operating full nodes for at least 168
hours (1 week) in July 2015 are eligible to vote, determined by the
log of Bitnodes. Time is set in the past to avoid manipulation. One
IP address one vote. Vote must be sent from the node’s IP address.
-------------------- Voting system
Single transferable vote is applied.
(https://en.wikipedia.org/wiki/Single_transferable_vote). Voters
are required to rank their preference with “1”, “2”, “3”, etc, or
use “N” to indicate rejection of a candidate. Vote counting starts
with every voter’s first choice. The candidate with fewest votes is
eliminated and those votes are transferred according to their
second choice. This process repeats until only one candidate is
left, which is the most popular candidate. The result is presented
as the approval rate: final votes for the most popular candidate /
all valid votes
After the most popular candidate is determined, the whole counting
process is repeated by eliminating this candidate, which will find
the approval rate for the second most popular candidate. The
process repeats until all proposals are ranked with the approval
rate calculated.
-------------------- Interpretation of results:
It is possible that a candidate with lower ranking to have higher
approval rate. However, ranking is more important than the
approval rate, unless the difference in approval rate is really
huge. 90% support would be excellent; 70% is good; 50% is marginal;
<50% is failed.
-------------------- Technical issues:
Voting by the miners, developers, exchanges, and merchants are
probably the easiest. We need a trusted person to verify the
voters’ identity by email, website, or digital signature. The
trusted person will collect votes and publish the named votes so
anyone could verify the results.
For full nodes, we need a trusted person to setup a website as an
interface to vote. The votes with IP address will be published.
For bitcoin holders, the workload could be very high and we may
need some automatic system to collect and count the votes. If
people are worrying about reduced security due to exposed raw
public key, they should move their bitcoin to a new address before
voting.
Double voting: people are generally not allowed to change their
mind after voting, especially for anonymous voters like bitcoin
holders and solo miners. A double voting attempt from these classes
will invalidate all related votes.
Multiple identity: People may have multiple roles in the Bitcoin
ecology. I believe they should be allowed to vote in all
applicable categories since they are contributing more than other
people.
_______________________________________________ bitcoin-dev mailing
list bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVwISfAAoJEGwAhlQc8H1mygAH/jxe3C5RjPlsSKfIg+CikEwi
kSttrZKr45s6EzayUqyBjBensgsgQCYKo3RLUq8lSpeJdZSmfu4qis09iZVJmKNX
klA/CTuiHTE8jGgwjAHNeeAI/ZQSFOYictzk4OVTSQWoMuB8Wq6S+QXCiUbulOGH
E/vHQz25ZNPX0+Z1Ypx26kSglBNzWJT1cdtyAvd3SDOTMuRVcH9y4aECSB+399Jt
BT2pBOYCJjrXfuU0lh26yph08UyIKSoToCJ4jxEtBzf4COYppsO0dzHeboYkwLMo
+ZuBhz5Bv9Fy5d6AcQtCUjBJE0dZvyAjf7Zc3U9X5ZXe5sAx/zC36O307YtneHI=
=f/pR
-----END PGP SIGNATURE-----
