đź“… Original date posted:2015-08-04
đź“ť Original message:I would like to withdraw my proposal from your self-appointed vote.
If you want to let a majority decide about economic policy of a currency, I
suggest fiat currencies. They have been using this approach for quite a
while, I hear.
Bitcoin's consensus rules are a consensus system, not a democracy. Find a
solution that everyone agrees on, or don't.
On Aug 4, 2015 9:51 AM, "jl2012 via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150804/db57dc3a/attachment-0001.html>;
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 15:45:09
in reply to nevent1q…jh7y
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rSeen on
wss://relay.noswhere.comPublished at
2023-06-07 15:45:09Event JSON
{
"id": "49da6586f9762d8c640f56d6fbe56b7b5076bbea48d104c62b7a17304c1b9331",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686152709,
"kind": 1,
"tags": [
[
"e",
"37db21c1d9def528e9399e6fbbd8279c30b90088530ac52221b26e4bfa4cc2df",
"",
"root"
],
[
"e",
"da0a0e312597c77fe2db8b817682d6c36fbd2425d256fbd7401304ecff4827c1",
"",
"reply"
],
[
"p",
"b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa"
]
],
"content": "📅 Original date posted:2015-08-04\n📝 Original message:I would like to withdraw my proposal from your self-appointed vote.\n\nIf you want to let a majority decide about economic policy of a currency, I\nsuggest fiat currencies. They have been using this approach for quite a\nwhile, I hear.\n\nBitcoin's consensus rules are a consensus system, not a democracy. Find a\nsolution that everyone agrees on, or don't.\nOn Aug 4, 2015 9:51 AM, \"jl2012 via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e As now we have some concrete proposals (\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html),\n\u003e I think we should wrap up the endless debate with voting by different\n\u003e stakeholder groups.\n\u003e\n\u003e ---------------------------------\n\u003e Candidate proposals\n\u003e\n\u003e Candidate proposals must be complete BIPs with reference implementation\n\u003e which are ready to merge immediately. They must first go through the usual\n\u003e peer review process and get approved by the developers in a technical\n\u003e standpoint, without political or philosophical considerations. Any fine\n\u003e tune of a candidate proposal may not become an independent candidate,\n\u003e unless it introduces some “real” difference. “No change” is also one of the\n\u003e voting options.\n\u003e ---------------------------------\n\u003e Voter groups\n\u003e\n\u003e There will be several voter groups and their votes will be counted\n\u003e independently. (The time frames mentioned below are just for example.)\n\u003e\n\u003e Miners: miners of blocks with timestamp between 1 to 30 Sept 2015 are\n\u003e eligible to vote. One block one vote. Miners will cast their votes by\n\u003e signing with the bitcoin address in coinbase. If there are multiple\n\u003e coinbase outputs, the vote is discounted by output value / total coinbase\n\u003e output value.\n\u003e Many well-known pools are reusing addresses and they may not need to\n\u003e digitally sign their votes. In case there is any dispute, the digitally\n\u003e signed vote will be counted.\n\u003e\n\u003e Bitcoin holders: People with bitcoin in the UTXO at block 372500 (around\n\u003e early September) are eligible to vote. The total “balance” of each\n\u003e scriptPubKey is calculated and this is the weight of the vote. People will\n\u003e cast their votes by digital signature.\n\u003e Special output types:\n\u003e Multi-sig: vote must be signed according to the setting of the multi-sig.\n\u003e P2SH: the serialized script must be provided\n\u003e Publicly known private key: not eligible to vote\n\u003e Non-standard script according to latest Bitcoin Core rules: not eligible\n\u003e to vote in general. May be judged case-by-case\n\u003e\n\u003e Developers: People with certain amount of contribution in the past year in\n\u003e Bitcoin Core or other open sources wallet / alternative implementations.\n\u003e One person one vote.\n\u003e\n\u003e Exchanges: Centralized exchanges listed on Coindesk Bitcoin Index,\n\u003e Winkdex, or NYSE Bitcoin index, with 30 days volume \u003e100,000BTC are\n\u003e invited. This includes Bitfinex, BTC China, BitStamp, BTC-E, itBit, OKCoin,\n\u003e Huobi, Coinbase. Exchanges operated for at least 1 year with 100,000BTC\n\u003e 30-day volume may also apply to be a voter in this category. One exchange\n\u003e one vote.\n\u003e\n\u003e Merchants and service providers: This category includes all bitcoin\n\u003e accepting business that is not centralized fiat-currency exchange, e.g.\n\u003e virtual or physical stores, gambling sites, online wallet service, payment\n\u003e processors like Bitpay, decentralized exchange like Localbitcoin, ETF\n\u003e operators like Secondmarket Bitcoin Investment Trust. They must directly\n\u003e process bitcoin without relying on third party. They should process at\n\u003e least 100BTC in the last 30-days. One merchant one vote.\n\u003e\n\u003e Full nodes operators: People operating full nodes for at least 168 hours\n\u003e (1 week) in July 2015 are eligible to vote, determined by the log of\n\u003e Bitnodes. Time is set in the past to avoid manipulation. One IP address one\n\u003e vote. Vote must be sent from the node’s IP address.\n\u003e\n\u003e --------------------\n\u003e Voting system\n\u003e\n\u003e Single transferable vote is applied. (\n\u003e https://en.wikipedia.org/wiki/Single_transferable_vote). Voters are\n\u003e required to rank their preference with “1”, “2”, “3”, etc, or use “N” to\n\u003e indicate rejection of a candidate.\n\u003e Vote counting starts with every voter’s first choice. The candidate with\n\u003e fewest votes is eliminated and those votes are transferred according to\n\u003e their second choice. This process repeats until only one candidate is left,\n\u003e which is the most popular candidate. The result is presented as the\n\u003e approval rate: final votes for the most popular candidate / all valid votes\n\u003e\n\u003e After the most popular candidate is determined, the whole counting process\n\u003e is repeated by eliminating this candidate, which will find the approval\n\u003e rate for the second most popular candidate. The process repeats until all\n\u003e proposals are ranked with the approval rate calculated.\n\u003e\n\u003e --------------------\n\u003e Interpretation of results:\n\u003e\n\u003e It is possible that a candidate with lower ranking to have higher approval\n\u003e rate. However, ranking is more important than the approval rate, unless the\n\u003e difference in approval rate is really huge. 90% support would be excellent;\n\u003e 70% is good; 50% is marginal; \u003c50% is failed.\n\u003e\n\u003e --------------------\n\u003e Technical issues:\n\u003e\n\u003e Voting by the miners, developers, exchanges, and merchants are probably\n\u003e the easiest. We need a trusted person to verify the voters’ identity by\n\u003e email, website, or digital signature. The trusted person will collect votes\n\u003e and publish the named votes so anyone could verify the results.\n\u003e\n\u003e For full nodes, we need a trusted person to setup a website as an\n\u003e interface to vote. The votes with IP address will be published.\n\u003e\n\u003e For bitcoin holders, the workload could be very high and we may need some\n\u003e automatic system to collect and count the votes. If people are worrying\n\u003e about reduced security due to exposed raw public key, they should move\n\u003e their bitcoin to a new address before voting.\n\u003e\n\u003e Double voting: people are generally not allowed to change their mind after\n\u003e voting, especially for anonymous voters like bitcoin holders and solo\n\u003e miners. A double voting attempt from these classes will invalidate all\n\u003e related votes.\n\u003e\n\u003e Multiple identity: People may have multiple roles in the Bitcoin ecology.\n\u003e I believe they should be allowed to vote in all applicable categories since\n\u003e they are contributing more than other people.\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150804/db57dc3a/attachment-0001.html\u003e",
"sig": "e5c389ff7a81470df1c286b36a83580b88b15d0176b4f659010cea9b3061655615b15e3a5d525715bbcf6a90c9519cce52a5ce9194b04d89d6c8afac8540241c"
}