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