Re: [bitcoin-dev] RE : Visualizations of Votes
Yes, the two dimensions are orthogonal: BIP 100 support and actual size voting. However there seem to be a few pools which simply vote to support BIP100, without specifying a desired block size [1], hence I started tracking both on the same chart, maybe I'll split them into different charts to clarify. Regards, Chris [1] https://blockchain.info/tx/ba1e5d21a340772d637ee5dc0bde8072ad1a7b499ba241d5bfaae9618749531e On Mon, Aug 24, 2015 at 4:46 PM Jeff Garzik jgar...@gmail.com wrote: There is a duplicated column. BIP 100 voting is /BV\d+/ On Fri, Aug 21, 2015 at 9:24 AM, Christian Decker via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I hacked together a simple tracking page for the 'block votes', it currently includes the 8MB vote and XT, as well as the /BV\d+/ vote for generic size: http://bitcoinstats.com/network/votes/ On Fri, Aug 21, 2015 at 7:25 AM odinn via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Nicolas, On 08/20/2015 08:49 PM, Nicolas Dorier via bitcoin-dev wrote: A visualization I would like to see would include: pie graph(s) of what % are voting for (BIP 100, BIP 101, 8MB, BIP sipa etc) based on what's published in blocks. If such a vote existed, I would gladly show the pie on BIPxDevs. However there is no standard way for miners to vote informally BIP they support. What about formal votes? Is there a way to visually have them appear in a pie chart as the votes become apparent in blocks? I appreciate good visualizations and am trying to get a (visual) comparison of the votes on these competing proposals. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev - -- http://abis.io ~ a protocol concept to enable decentralization and expansion of a giving economy, and a new social good https://keybase.io/odinn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJV1rZSAAoJEGxwq/inSG8CuNgIAIOIpHavzz6EJ5AOGBg2T859 MV7rsPfk1HBV4K1Yf4HfrlD/1SY0L57SANpRodi1NME3pl27QQCDnuwNLAqOLKtA P/sHXnk9LuSG8Czk0PHOslZ+f1fDbmNm9gtR3QWXGOx0jP2b+WQ8RhkPhqQ++S/i oXmjyrk+8TTu1hxMbuCcG5bqeS0lBm0SyrSbRTPWH+4U1jGYbxQNKkHnuZGByX4B HBWuKvIylQzHCfy0ToUW+Z29Y+78wQNQUOA10eq7qpZCZvfRZUov1KBVXLx8GAKy Y5WGSJYIAt+Rwn9eMxhpD91ZR1vwtqtRZn7M+NtrStPBJt+n4ET9VmPpsMAc/Zc= =AHv3 -END PGP SIGNATURE- ___ 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
Github: https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki pre BIP: 1xx Title: Dynamically Controlled Bitcoin Block Size Max Cap Author: Upal Chakraborty bitc...@upalc.com Status: Draft Type: Standards Track Created: 2015-08-24 /pre ==Abstract== This BIP proposes replacing the fixed one megabyte maximum block size with a dynamically controlled maximum block size that may increase or decrease with difficulty change depending on various network factors. I have two proposals regarding this... i. Depending only on previous block size calculation. ii. Depending on previous block size calculation and previous Tx fee collected by miners. ==Motivation== With increased adoption, transaction volume on bitcoin network is bound to grow. If the one megabyte max cap is not changed to a flexible one which changes itself with changing network demand, then adoption will hamper and bitcoin's growth may choke up. Following graph shows the change in average block size since inception... https://blockchain.info/charts/avg-block-size?timespan=allshowDataPoints=falsedaysAverageString=1show_header=truescale=0address= ==Specification== ===Proposal 1 : Depending only on previous block size calculation=== If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize Double MaxBlockSize Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize Half MaxBlockSize Else Keep the same MaxBlockSize ===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners=== TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008 blocks in last 2 difficulty period TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty) TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks in last 2 difficulty period TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty) If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty TotalBlockSizeInLastButOneDifficulty) ) MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty TotalBlockSizeInLastButOneDifficulty) ) MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty Else Keep the same MaxBlockSize ==Rationale== These two proposals have been derived after discussion on [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html bitcoin-dev mailing list]. The original idea and its evolution in the light of various arguements can be found [http://upalc.com/maxblocksize.php here]. ===Proposal 1 : Depending only on previous block size calculation=== This solution is derived directly from the indication of the problem. If transaction volume increases, then we will naturally see bigger blocks. On the contrary, if there are not enough transaction volume, but maximum block size is high, then only few blocks may sweep the mempool. Hence, if block size is itself taken into consideration, then maximum block size can most rationally be derived. Moreover, this solution not only increases, but also decreases the maximum block size, just like difficulty. ===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners=== This solution takes care of stable mining subsidy. It will not increase maximum block size, if Tx fee collection is not increasing and thereby creating a Tx fee pressure on the market. On the other hand, though the block size max cap is dynamically controlled, it is very difficult to game by any party because the increase or decrease of block size max cap will take place in the same ratio of average block size increase or decrease. ==Compatibility== This is a hard-forking change to the Bitcoin protocol; anybody running code that fully validates blocks must upgrade before the activation time or they will risk rejecting a chain containing larger-than-one-megabyte blocks. ==Other solutions considered== [http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Making Decentralized Economic Policy] - by Jeff Garzik [https://bitcointalk.org/index.php?topic=1078521.0 Elastic block cap with rollover penalties] - by Meni Rosenfeld
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
Proposal 1 looks good, but tx fee collected can be manipulated by miners. I like the idea next block collect the tx fee from previous block. On Tue, Aug 25, 2015 at 5:07 PM, Upal Chakraborty via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Github: https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki pre BIP: 1xx Title: Dynamically Controlled Bitcoin Block Size Max Cap Author: Upal Chakraborty bitc...@upalc.com Status: Draft Type: Standards Track Created: 2015-08-24 /pre ==Abstract== This BIP proposes replacing the fixed one megabyte maximum block size with a dynamically controlled maximum block size that may increase or decrease with difficulty change depending on various network factors. I have two proposals regarding this... i. Depending only on previous block size calculation. ii. Depending on previous block size calculation and previous Tx fee collected by miners. ==Motivation== With increased adoption, transaction volume on bitcoin network is bound to grow. If the one megabyte max cap is not changed to a flexible one which changes itself with changing network demand, then adoption will hamper and bitcoin's growth may choke up. Following graph shows the change in average block size since inception... https://blockchain.info/charts/avg-block-size?timespan=allshowDataPoints=falsedaysAverageString=1show_header=truescale=0address= ==Specification== ===Proposal 1 : Depending only on previous block size calculation=== If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize Double MaxBlockSize Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize Half MaxBlockSize Else Keep the same MaxBlockSize ===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners=== TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008 blocks in last 2 difficulty period TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty) TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks in last 2 difficulty period TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty) If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty TotalBlockSizeInLastButOneDifficulty) ) MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty TotalBlockSizeInLastButOneDifficulty) ) MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty Else Keep the same MaxBlockSize ==Rationale== These two proposals have been derived after discussion on [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html bitcoin-dev mailing list]. The original idea and its evolution in the light of various arguements can be found [http://upalc.com/maxblocksize.php here]. ===Proposal 1 : Depending only on previous block size calculation=== This solution is derived directly from the indication of the problem. If transaction volume increases, then we will naturally see bigger blocks. On the contrary, if there are not enough transaction volume, but maximum block size is high, then only few blocks may sweep the mempool. Hence, if block size is itself taken into consideration, then maximum block size can most rationally be derived. Moreover, this solution not only increases, but also decreases the maximum block size, just like difficulty. ===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners=== This solution takes care of stable mining subsidy. It will not increase maximum block size, if Tx fee collection is not increasing and thereby creating a Tx fee pressure on the market. On the other hand, though the block size max cap is dynamically controlled, it is very difficult to game by any party because the increase or decrease of block size max cap will take place in the same ratio of average block size increase or decrease. ==Compatibility== This is a hard-forking change to the Bitcoin protocol; anybody running code that fully validates blocks must upgrade before the activation time or they will risk
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
This BIP has been assigned BIP112 by the BIP repository maintainer. I have updated the pull request accordingly. Regarding the suggestion to cannibalise version, by your own disadvantage list, we would lose fine grained control over txins which neuters the usefulness considerably. Also using version is also ugly because there isn't a semantic association with what we are trying to do, whereas, sequence is associated with transaction finality and is thus the more appropriate and logical field to use. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
To follow up on this, let's say that you want to be able to have up to 1 year relative lock-times. This choice is somewhat arbitrary and what I would like some input on, but I'll come back to this point. * 1 bit is necessary to enable/disable relative lock-time. * 1 bit is necessary to indicate whether seconds vs blocks as the unit of measurement. * 1 year of time with 1-second granularity requires 25 bits. However since blocks occur at approximately 10 minute intervals on average, having a relative lock-time significantly less than this interval doesn't make much sense. A granularity of 256 seconds would be greater than the Nyquist frequency and requires only 17 bits. * 1 year of blocks with 1-block granularity requires 16 bits. So time-based relative lock time requires about 19 bits, and block-based relative lock-time requires about 18 bits. That leaves 13 or 14 bits for other uses. Assuming a maximum of 1-year relative lock-times. But what is an appropriate maximum to choose? The use cases I have considered have only had lock times on the order of a few days to a month or so. However I would feel uncomfortable going less than a year for a hard maximum, and am having trouble thinking of any use case that would require more than a year of lock-time. Can anyone else think of a use case that requires 1yr relative lock-time? TL;DR On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach m...@friedenbach.org wrote: A power of 2 would be far more efficient here. The key question is how long of a relative block time do you need? Figure out what the maximum should be ( I don't know what that would be, any ideas?) and then see how many bits you have left over. On Aug 23, 2015 7:23 PM, Jorge Timón bitcoin-dev@lists.linuxfoundation.org wrote: On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the discussion has any thought been given to represent one block with more than one increment? This would leave additional space for future signaling, or allow, for example, higher resolution numbers for a sharechain commitement. No, I don't think anybody thought about this. I just explained this to Pieter using for example, 10 instead of 1. He suggested 600 increments so that it is more similar to timestamps. ___ 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
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
On Tue, Aug 25, 2015 at 11:08 PM, Mark Friedenbach via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Assuming a maximum of 1-year relative lock-times. But what is an appropriate maximum to choose? The use cases I have considered have only had lock times on the order of a few days to a month or so. However I would feel uncomfortable going less than a year for a hard maximum, and am having trouble thinking of any use case that would require more than a year of lock-time. Can anyone else think of a use case that requires 1yr relative lock-time? The main advantage of relative locktime over absolute locktime is in situations when it is not possible to determine when the clock should start. This inherently means lower delays. As a workaround, you could chain transactions to extend the relative locktime. Transaction B has to be 360 days after transaction A and then transaction C has to be 360 days after transaction B and C must be an input into the final transaction. The chain could be built up with multi-sig, like the refund transaction system, so no one person can create an alternative chain. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
On Tue, Aug 25, 2015 at 04:26:23PM -0400, Matt Whitlock wrote: On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev wrote: What would you think of an approach like John Dillon's proposal to explicitly give the economic majority of coin holders a vote for the max blocksize? Miners could still vote BIP100 style for what max they were willing to use, limited in turn by the vote of the economic majority. What fraction of coin holders do you suppose will vote? And, of those, what fraction have the technical knowledge to make an informed vote? It would be like polling Toyota truck owners to see whether the 2017 Tacoma should increase its engine's cylinder displacement by 10%. Ordinary users just aren't going to be able to vote meaningfully, and most won't respond to the poll at all. Note that you can make the % of voters required adapt dyanmically to voter interest. Also, your example is rather misleading, as car buyers *do* make those kinds of decisions though various market mechanisms. Equally, you can make the same criticism of democracy in general. An interesting idea would be to design a voting mechanism such that only users with access to validating nodes be able to vote - a fundemental requirement for users to fully participate in Bitcoin's goverance. -- 'peter'[:-1]@petertodd.org 0ba8add4a8edc1b0467e9e377da016834d2abff3fc8ce1fb signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev wrote: What would you think of an approach like John Dillon's proposal to explicitly give the economic majority of coin holders a vote for the max blocksize? Miners could still vote BIP100 style for what max they were willing to use, limited in turn by the vote of the economic majority. What fraction of coin holders do you suppose will vote? And, of those, what fraction have the technical knowledge to make an informed vote? It would be like polling Toyota truck owners to see whether the 2017 Tacoma should increase its engine's cylinder displacement by 10%. Ordinary users just aren't going to be able to vote meaningfully, and most won't respond to the poll at all. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
On Wed, Aug 26, 2015 at 05:44:46AM +0800, Chun Wang wrote: On Wed, Aug 26, 2015 at 5:18 AM, Simon Liu via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I don't think this would work. If the rule is that one user can only have one vote, how do you prevent a user running multiple nodes? The vote is not counted by nodes, but bitcoin amount, or probably better, coin-days. It works like proof-of-stake. A mix of proof-of-work and proof-of-stake is good. Yup. To implement a vote where only users with access to a full node can vote, you'd force part of the vote to be determined by a non-miner-committed value calculatable by anyone with a full node. For instance, a very simple toy example that would work is just XORing your vote with SHA256(the entire blockchain) -- 'peter'[:-1]@petertodd.org 08d42f5514157c3257577e006985ea8335e4567e1bed16bd signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIP/Motivation and deployment of consensus rule changes ([soft/hard]forks)
As I understand Github is not to be used for the high-level discussion of a draft BIP so I will post my thoughts here (is this specified somewhere? Can we specify this in BIP-0001?). - I have some concerns about the structure and the wording of this proposal. I think both the structure and the internal wording can be slimmed down and simplified - I also believe the history lessons should be trimmed out, mentioned at best - There's separate BIP for at least one of the code forks - BIP-001 specifies that BIP proposals should not be given a BIP number until after they have been spelled checked and approved by an editor. Greg Maxwell: was this followed? - What kind of proposal is this? Informational, Process or Standards track? - I believe it should be Standards Track. Include the proposed upgrade path as a patch into core as a module that hard forks can use in the future. This will also give us some space to work through some of the complexities of forks in a definite way. - Alternatively maybe we can split up this BIP into a Standards track and a separate Informational BIP? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
On Tuesday, 25 August 2015, at 1:37 pm, Peter Todd wrote: On Tue, Aug 25, 2015 at 04:26:23PM -0400, Matt Whitlock wrote: On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev wrote: What would you think of an approach like John Dillon's proposal to explicitly give the economic majority of coin holders a vote for the max blocksize? Miners could still vote BIP100 style for what max they were willing to use, limited in turn by the vote of the economic majority. What fraction of coin holders do you suppose will vote? And, of those, what fraction have the technical knowledge to make an informed vote? It would be like polling Toyota truck owners to see whether the 2017 Tacoma should increase its engine's cylinder displacement by 10%. Ordinary users just aren't going to be able to vote meaningfully, and most won't respond to the poll at all. Note that you can make the % of voters required adapt dyanmically to voter interest. Also, your example is rather misleading, as car buyers *do* make those kinds of decisions though various market mechanisms. Yes, car buyers do make those kinds of decisions through market mechanisms. An equivalent process for Bitcoin would be that the max block-size limit (and other fundamental economic parameters) would be determined via a process of forking off altcoins (such as Bitcoin XT will do) and allowing the market to decide which coin is most valuable. This is the default mechanism for change (because it's what naturally happens when there is a lack of internal consensus), but it's not the least painful mechanism. My point still stands that — just as in democracy in general — the voters are really in no position to cast informed votes, nor should they be (cf. rational ignorance [1]). I do not oppose opening up the determination of the max block-size limit to a popular check via stakeholder vote — actually, I think this is an important check on miners' power — but I do argue that the vote is likely to have drastically little participation and very low-quality results. [1] Rational Ignorance: «Ignorance about an issue is said to be rational when the cost of educating oneself about the issue sufficiently to make an informed decision can outweigh any potential benefit one could reasonably expect to gain from that decision, and so it would be irrational to waste time doing so.» https://en.wikipedia.org/wiki/Rational_ignorance ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
just as in democracy in general One should be clear that Bitcoin is by no possible measure a democracy. The proposed vote is on what goes into a particular github repository. The outcome is ultimately controlled by those with control of that repository. Bitcoin is an anarchy by design. People will use whatever they want. e On 08/25/2015 02:14 PM, Matt Whitlock via bitcoin-dev wrote: On Tuesday, 25 August 2015, at 1:37 pm, Peter Todd wrote: On Tue, Aug 25, 2015 at 04:26:23PM -0400, Matt Whitlock wrote: On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev wrote: What would you think of an approach like John Dillon's proposal to explicitly give the economic majority of coin holders a vote for the max blocksize? Miners could still vote BIP100 style for what max they were willing to use, limited in turn by the vote of the economic majority. What fraction of coin holders do you suppose will vote? And, of those, what fraction have the technical knowledge to make an informed vote? It would be like polling Toyota truck owners to see whether the 2017 Tacoma should increase its engine's cylinder displacement by 10%. Ordinary users just aren't going to be able to vote meaningfully, and most won't respond to the poll at all. Note that you can make the % of voters required adapt dyanmically to voter interest. Also, your example is rather misleading, as car buyers *do* make those kinds of decisions though various market mechanisms. Yes, car buyers do make those kinds of decisions through market mechanisms. An equivalent process for Bitcoin would be that the max block-size limit (and other fundamental economic parameters) would be determined via a process of forking off altcoins (such as Bitcoin XT will do) and allowing the market to decide which coin is most valuable. This is the default mechanism for change (because it's what naturally happens when there is a lack of internal consensus), but it's not the least painful mechanism. My point still stands that — just as in democracy in general — the voters are really in no position to cast informed votes, nor should they be (cf. rational ignorance [1]). I do not oppose opening up the determination of the max block-size limit to a popular check via stakeholder vote — actually, I think this is an important check on miners' power — but I do argue that the vote is likely to have drastically little participation and very low-quality results. [1] Rational Ignorance: «Ignorance about an issue is said to be rational when the cost of educating oneself about the issue sufficiently to make an informed decision can outweigh any potential benefit one could reasonably expect to gain from that decision, and so it would be irrational to waste time doing so.» https://en.wikipedia.org/wiki/Rational_ignorance signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
On Wed, Aug 26, 2015 at 5:18 AM, Simon Liu via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I don't think this would work. If the rule is that one user can only have one vote, how do you prevent a user running multiple nodes? The vote is not counted by nodes, but bitcoin amount, or probably better, coin-days. It works like proof-of-stake. A mix of proof-of-work and proof-of-stake is good. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
I don't think this would work. If the rule is that one user can only have one vote, how do you prevent a user running multiple nodes? Also, how do you verify that a node is indeed a fully validating node with its own copy of the blockchain? On 08/25/2015 01:37 PM, Peter Todd via bitcoin-dev wrote: An interesting idea would be to design a voting mechanism such that only users with access to validating nodes be able to vote - a fundemental requirement for users to fully participate in Bitcoin's goverance. ___ 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
