jl2012 at xbt.hk [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-04 📝 Original message:> Bitcoin's consensus ...
📅 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
📝 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