Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
Proposal 1 does not deal with Tx fee. Proposal 2 does. According to proposal 2, miners wont be able to increase or decrease Max Block Size only by manipulating Tx fee. They have to manipulate... i. Tx fee of ~4000 blocks. ii. Block size of ~4000 blocks. I never proposed *next block collects Tx fee from previous block*. Not sure what you mean here! On Tue, Aug 25, 2015 at 2:49 PM, Chun Wang 1240...@gmail.com wrote: 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
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
On 26 August 2015 at 01:29, Peter Todd via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: For instance, a very simple toy example that would work is just XORing your vote with SHA256(the entire blockchain) Uh, that would totally not work. I think my proposal of using CLTV to lock coins (votes) is better. Failing a soft-fork to implement that in time, counting votes from the UTXO set is also ok - the difference between that and CLTV is that it is not as strong an evidence of commitment. ___ 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]
Can we please keep this mail chain discussion specific to the proposed draft - https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki ? I understand, voting process is an important subject of discussion. But, that may be discussed in a separate mail chain. On Wed, Aug 26, 2015 at 11:58 AM, Hector Chu via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On 26 August 2015 at 01:29, Peter Todd via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: For instance, a very simple toy example that would work is just XORing your vote with SHA256(the entire blockchain) Uh, that would totally not work. I think my proposal of using CLTV to lock coins (votes) is better. Failing a soft-fork to implement that in time, counting votes from the UTXO set is also ok - the difference between that and CLTV is that it is not as strong an evidence of commitment. ___ 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] 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
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
