* Re: [bitcoin-dev] Wrapping up the block size debate with voting
2015-08-04 7:50 [bitcoin-dev] Wrapping up the block size debate with voting jl2012
@ 2015-08-04 9:03 ` Pieter Wuille
2015-08-04 9:22 ` jl2012
2015-08-04 9:29 ` Hector Chu
2015-08-04 9:23 ` Venzen Khaosan
` (2 subsequent siblings)
3 siblings, 2 replies; 10+ messages in thread
From: Pieter Wuille @ 2015-08-04 9:03 UTC (permalink / raw)
To: jl2012; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 6610 bytes --]
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@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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 7271 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [bitcoin-dev] Wrapping up the block size debate with voting
2015-08-04 9:03 ` Pieter Wuille
@ 2015-08-04 9:22 ` jl2012
2015-08-04 9:29 ` Hector Chu
1 sibling, 0 replies; 10+ messages in thread
From: jl2012 @ 2015-08-04 9:22 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Dev
> 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@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@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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Wrapping up the block size debate with voting
2015-08-04 9:03 ` Pieter Wuille
2015-08-04 9:22 ` jl2012
@ 2015-08-04 9:29 ` Hector Chu
1 sibling, 0 replies; 10+ messages in thread
From: Hector Chu @ 2015-08-04 9:29 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 7415 bytes --]
On 4 August 2015 at 10:03, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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.
>
Nearly all the fiat currencies I'm familiar with have their economic policy
dictated by the government or the relevant central bank committee. Ordinary
users of the banking system are not consulted.
> Bitcoin's consensus rules are a consensus system, not a democracy. Find a
> solution that everyone agrees on, or don't.
>
That's correct. The people who disagree will cease using the system, and
quite possibly move to a different one (i.e. Bitcoin XT). The people left
on the old system will indeed have a solution that they all can agree on.
> On Aug 4, 2015 9:51 AM, "jl2012 via bitcoin-dev" <
> bitcoin-dev@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@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 8749 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Wrapping up the block size debate with voting
2015-08-04 7:50 [bitcoin-dev] Wrapping up the block size debate with voting jl2012
2015-08-04 9:03 ` Pieter Wuille
@ 2015-08-04 9:23 ` Venzen Khaosan
2015-08-04 9:44 ` jl2012
2015-08-04 10:22 ` Tier Nolan
2015-08-06 23:26 ` Dave Scotese
3 siblings, 1 reply; 10+ messages in thread
From: Venzen Khaosan @ 2015-08-04 9:23 UTC (permalink / raw)
To: jl2012, Bitcoin Dev
-----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-----
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Wrapping up the block size debate with voting
2015-08-04 9:23 ` Venzen Khaosan
@ 2015-08-04 9:44 ` jl2012
0 siblings, 0 replies; 10+ messages in thread
From: jl2012 @ 2015-08-04 9:44 UTC (permalink / raw)
To: venzen; +Cc: Bitcoin Dev
As I mentioned, the candidate proposals must go through usual peer
review process, which includes proper testing, I assume.
Scaling down is always possible with softforks, or miners will simply
produce smaller blocks. BIP100 has a scaling down mechanism but it still
requires miners to vote so it doesn't really make much difference
But anyway, this is off-topic, as candidate proposals may include
mechanism for scaling down.
Venzen Khaosan 於 2015-08-04 05:23 寫到:
> -----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-----
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Wrapping up the block size debate with voting
2015-08-04 7:50 [bitcoin-dev] Wrapping up the block size debate with voting jl2012
2015-08-04 9:03 ` Pieter Wuille
2015-08-04 9:23 ` Venzen Khaosan
@ 2015-08-04 10:22 ` Tier Nolan
2015-08-06 23:26 ` Dave Scotese
3 siblings, 0 replies; 10+ messages in thread
From: Tier Nolan @ 2015-08-04 10:22 UTC (permalink / raw)
Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]
On Tue, Aug 4, 2015 at 8:50 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> --------------------
> 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.
>
Instant runoff voting is not a good system for finding a consensus of the
voters.
http://zesty.ca/voting/sim/
The main issue here is the "Squeezing out" of center opinions.
If the middle option is acceptable to almost everyone but is only the top
choice of 20%, then it will lose in round one and leave only extreme
options remaining.
Approval is a better system for a consensus.
Each voter can indicate which of the proposals is approved/accepted and the
option with the most support wins.
If one option has 80% support and another has 90% support, then both make a
good choice (though the 90% one has won).
Range voting allows more accuracy, if that is an issue. If voters are
honest, it allows a middle ground to be reached.
If everyone votes strategically, it becomes approval voting. With
consensus, there is an assumption that a significant fraction of the
community would be willing to be honest rather than strategic.
The outcome is possible a final decision but not a binding decision.
Voters need to recognise that failing to find a middle ground could mean
they get their way but they split the community.
Additionally, since the point is to determine parameters, you don't
necessarily need to select from discrete candidates.
- Initial new size
- Rate of increase
- Maximum size
They are just numbers. You could have votes indicate what they want, and
then use the median as the consensus option.
The exception is to have the miners choose what the size is (subject to
limits). That option is already entirely in the hands of the miners and
they could do it unilaterally.
[-- Attachment #2: Type: text/html, Size: 3445 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* [bitcoin-dev] Wrapping up the block size debate with voting
2015-08-04 7:50 [bitcoin-dev] Wrapping up the block size debate with voting jl2012
` (2 preceding siblings ...)
2015-08-04 10:22 ` Tier Nolan
@ 2015-08-06 23:26 ` Dave Scotese
2015-08-06 23:32 ` Pieter Wuille
3 siblings, 1 reply; 10+ messages in thread
From: Dave Scotese @ 2015-08-06 23:26 UTC (permalink / raw)
To: jl2012, bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 7390 bytes --]
"Miners can do this unilaterally" maybe, if they are a closed group, based
on the 51% rule. But aren't they using full nodes for propagation? In this
sense, anyone can vote by coding.
If and when we need to vote, a pair-wise runoff ("condorcet method") will
find an option that is championed by a majority over each other option.
There may not be any such option, in which case no change would make the
most sense.
The voting proposal has several appeals to authority (which no one has)
like "People with certain amount of contribution" and "Exchanges operated
for at least 1 year with 100,000BTC 30-day volume may also apply": who
decided what amount or whether or not the application is approved? It also
doesn't specify how many btc equates to one vote.
> On Aug 4, 2015, at 12:50 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org <javascript:;>> 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 <javascript:;>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
[-- Attachment #2: Type: text/html, Size: 8490 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [bitcoin-dev] Wrapping up the block size debate with voting
2015-08-06 23:26 ` Dave Scotese
@ 2015-08-06 23:32 ` Pieter Wuille
2015-08-07 0:37 ` Will
0 siblings, 1 reply; 10+ messages in thread
From: Pieter Wuille @ 2015-08-06 23:32 UTC (permalink / raw)
To: Dave Scotese; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 560 bytes --]
On Fri, Aug 7, 2015 at 1:26 AM, Dave Scotese via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
"Miners can do this unilaterally" maybe, if they are a closed group, based
> on the 51% rule. But aren't they using full nodes for propagation? In this
> sense, anyone can vote by coding.
>
They don't need to use full nodes for propagation. Miners don't care when
other full nodes hear about their blocks, only whether they (eventually)
accept them.
And yes, full nodes can change what blocks they accept. That's called a
hard fork :)
--
Pieter
[-- Attachment #2: Type: text/html, Size: 968 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Wrapping up the block size debate with voting
2015-08-06 23:32 ` Pieter Wuille
@ 2015-08-07 0:37 ` Will
0 siblings, 0 replies; 10+ messages in thread
From: Will @ 2015-08-07 0:37 UTC (permalink / raw)
To: Pieter Wuille via bitcoin-dev, Dave Scotese, Pieter Wuille; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4459 bytes --]
I think the key is comity and humility in terms of being honest about our inability to predict future trends in a meaningful way while passing through scrutiny coming from divergent perspectives. 8MB + 40% annually (at whatever increase frequency is preferred, at coinbase halvings seems most ideal) is the proposal to use.
What if 40% is too fast?
If 40% turns out to be excessive, miners have a built in incentive to cap their blocks at a lower amount that meets the supply / demand equilibrium vs. the price of bitcoin trading on the free market. The key here is to understand “price of bitcoin on the free market”. Most developers don’t understand free market economics beyond gambling, which is a good bit of the problem here.
Bottom line is, miners directly benefit from higher bitcoin prices when denominated in other currencies. This fact will naturally limit excessive growth of blk*.dat. size, because if the storage requirements for bitcoin grow out of reach of amateurs, it will lead to excessive centralization and capture by powerful interests, which would threaten to convert bitcoin to a form of sovereign currency and kill free demand for bitcoin (and tank the price). Miners don’t want that without some other body paying them to make econonically distorted decisions. They will limit the size themselves if they see this as an emerging threat. It’s in their best interests and will keep them in business longer.
Now, is there a risk that some excessively well funded entity could artificially inflate the price of bitcoin while this bribing miners to let blk*.dat size grow out of hand (distorting miner economics) in some sort of “subsidies for increased liquidity” corruption scheme? No there isn’t, because we are going to have a cap on the size that is reasonable enough that we know it won’t force out any amateurs for at least 5 years, and likely longer.
What if 40% is too slow?
That’s a problem anyone who actually owns bitcoin would like to have. We’ll gladly support an increase in the rate if demand supports it later with a subsequent change. We’ll have to do this eventually anyway when SHA256 and RIPEMD160 exhibit collisions, or some other non-self imposed existential threat rears its head.
Long game
Now, this entire scheme is predicated on the price going higher over the extended term. I would argue that if we are doing a good job, the price should go higher. Isn’t that the best barometer of performance? Demand for the scarce units inside the protocol denominated in other currencies?
8MB is 1MB + 40% a year from January 2009 to today. 40% a year is as good as we are going to get in terms of our extrapolated estimation of future ability to host full nodes. Anything else is overengineering something we can’t predict anyway. Any arguments against this setting and rate of growth that aren’t exclusively focused on the computer science side of the debate are misguided at best, and corrupted by competing incentives at worst. This is because it’s not possible to predict the future any better than using an extrapolation of the past, which is exactly what 8MB + 40% represents.
So TLDR? Go with 8MB + 40% annually and we will cross any (likely imaginary) bridges when we come to them down the road.
Will
From: Pieter Wuille via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Reply: Pieter Wuille <pieter.wuille@gmail•com>>
Date: August 6, 2015 at 5:32:20 PM
To: Dave Scotese <dscotese@litmocracy•com>>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>>
Subject: Re: [bitcoin-dev] Wrapping up the block size debate with voting
On Fri, Aug 7, 2015 at 1:26 AM, Dave Scotese via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
"Miners can do this unilaterally" maybe, if they are a closed group, based on the 51% rule. But aren't they using full nodes for propagation? In this sense, anyone can vote by coding.
They don't need to use full nodes for propagation. Miners don't care when other full nodes hear about their blocks, only whether they (eventually) accept them.
And yes, full nodes can change what blocks they accept. That's called a hard fork :)
--
Pieter
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 8667 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread