Re: [Bitcoin-development] User vote in blocksize through fees
The size limit is an economic policy lever that needs to be transitioned -away- from software and software developers, to the free market. Exactly right. Bitcoin does not have a free market for fee though, and literally all the discussion so far has neglected some fundamental aspect of this, as you described. It's not at all a technical or engineering decision. It's the question of how to potentially re-design a fundamental part of Bitcoin, and the proposals so far don't address this. What is the price of the scarce resource of the blockchain and the mechanism to decide on price, once the subsidy runs out? On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson m...@henricson.se wrote: Jeff, with all due respect, but I've seen you saying this a few times now, that this decision is oh so difficult and important. But this is not helpful. We all know that. Even I. Make a suggestion, or stay out of the debate! Mats On 06/14/2015 07:36 AM, Jeff Garzik wrote: The choice is very real and on-point. What should the block size limit be? Why? There is a large consensus that it needs increasing. To what? By what factor? The size limit literally defines the fee market, the whole damn thing. If software high priests choose a size limit of 300k, space is scarce, fees are bid high. If software high priests choose a size limit of 32mb, space is plentiful, fees are near zero. Market actors take their signals accordingly. Some business models boom, some business models fail, as a direct result of changing this unintentionally-added speedbump. Different users value adoption, decentralization etc. differently. The size limit is an economic policy lever that needs to be transitioned -away- from software and software developers, to the free market. A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance problems associated with actors lobbying developers, even if a cloistered and vetted Technical Advisory Board as has been proposed. On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo elombr...@gmail.com wrote: I definitely think we need some voting system for metaconsensus…but if we’re going to seriously consider this we should look at the problem much more generally. Using false choices doesn’t really help, though ;) - Eric Lombrozo On Jun 13, 2015, at 10:13 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com wrote: 2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility. What is the alternative? Have a Chief Scientist or Technical Advisory Board choose what is a proper fee, what is a proper level of decentralization, a proper growth factor? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
Jeff, with all due respect, but I've seen you saying this a few times now, that this decision is oh so difficult and important. But this is not helpful. We all know that. Even I. Make a suggestion, or stay out of the debate! Mats On 06/14/2015 07:36 AM, Jeff Garzik wrote: The choice is very real and on-point. What should the block size limit be? Why? There is a large consensus that it needs increasing. To what? By what factor? The size limit literally defines the fee market, the whole damn thing. If software high priests choose a size limit of 300k, space is scarce, fees are bid high. If software high priests choose a size limit of 32mb, space is plentiful, fees are near zero. Market actors take their signals accordingly. Some business models boom, some business models fail, as a direct result of changing this unintentionally-added speedbump. Different users value adoption, decentralization etc. differently. The size limit is an economic policy lever that needs to be transitioned -away- from software and software developers, to the free market. A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance problems associated with actors lobbying developers, even if a cloistered and vetted Technical Advisory Board as has been proposed. On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo elombr...@gmail.com wrote: I definitely think we need some voting system for metaconsensus…but if we’re going to seriously consider this we should look at the problem much more generally. Using false choices doesn’t really help, though ;) - Eric Lombrozo On Jun 13, 2015, at 10:13 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com wrote: 2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility. What is the alternative? Have a Chief Scientist or Technical Advisory Board choose what is a proper fee, what is a proper level of decentralization, a proper growth factor? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
Exactly -- both block size proponents and block size change conservatives seem to be glossing over this aspect - much to my dismay. Choosing the size limit is choosing the size of a scarce resource. By fiat. It is wrong to think that a technical consensus can choose what is best here. The block size limit defines the scope of a resource for which all fee market actors bid. That, in turn, defines who is in the fee market and how they behave, what market choices are made. It doesn't matter how or why the limit was originally enacted, what Satoshi meant to do. What matters, economically, is what is. What the software and our $3B economy market knows and sees today. (I think some block size change proponents miss this!) The solution lies in transitioning this size limit to the free market. In the end, the users must choose their desired level of growth, decentralization, etc. We cannot rely on some dev's idea of the proper level of fee, proper level of growth, proper level of decentralization. And IMO, a floating limit with training wheels is better and stronger for bitcoin's health from a governance, user choice and free market perspective than simply hard fork to 2MB, come back again in 6 months. On Sun, Jun 14, 2015 at 6:34 AM, Benjamin benjamin.l.cor...@gmail.com wrote: The size limit is an economic policy lever that needs to be transitioned -away- from software and software developers, to the free market. Exactly right. Bitcoin does not have a free market for fee though, and literally all the discussion so far has neglected some fundamental aspect of this, as you described. It's not at all a technical or engineering decision. It's the question of how to potentially re-design a fundamental part of Bitcoin, and the proposals so far don't address this. What is the price of the scarce resource of the blockchain and the mechanism to decide on price, once the subsidy runs out? On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson m...@henricson.se wrote: Jeff, with all due respect, but I've seen you saying this a few times now, that this decision is oh so difficult and important. But this is not helpful. We all know that. Even I. Make a suggestion, or stay out of the debate! Mats On 06/14/2015 07:36 AM, Jeff Garzik wrote: The choice is very real and on-point. What should the block size limit be? Why? There is a large consensus that it needs increasing. To what? By what factor? The size limit literally defines the fee market, the whole damn thing. If software high priests choose a size limit of 300k, space is scarce, fees are bid high. If software high priests choose a size limit of 32mb, space is plentiful, fees are near zero. Market actors take their signals accordingly. Some business models boom, some business models fail, as a direct result of changing this unintentionally-added speedbump. Different users value adoption, decentralization etc. differently. The size limit is an economic policy lever that needs to be transitioned -away- from software and software developers, to the free market. A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance problems associated with actors lobbying developers, even if a cloistered and vetted Technical Advisory Board as has been proposed. On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo elombr...@gmail.com wrote: I definitely think we need some voting system for metaconsensus…but if we’re going to seriously consider this we should look at the problem much more generally. Using false choices doesn’t really help, though ;) - Eric Lombrozo On Jun 13, 2015, at 10:13 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com wrote: 2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility. What is the alternative? Have a Chief Scientist or Technical Advisory Board choose what is a proper fee, what is a proper level of decentralization, a proper growth factor? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] User vote in blocksize through fees
On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com wrote: 2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility. What is the alternative? Have a Chief Scientist or Technical Advisory Board choose what is a proper fee, what is a proper level of decentralization, a proper growth factor? -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
On Sun, Jun 14, 2015 at 12:55 AM, Chun Wang 1240...@gmail.com wrote: To tell you the truth. It is only because most miners are not located in the West. If Slush, Eligius and BTC Guild still on top 3, the core developers, including brain-dead Mike Hearn, would be very happy to do BIP100 just like they did BIP34 and BIP66. Shame on you! BIP 100 requires a hard fork to engage. Users proactively opt-in. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
The choice is very real and on-point. What should the block size limit be? Why? There is a large consensus that it needs increasing. To what? By what factor? The size limit literally defines the fee market, the whole damn thing. If software high priests choose a size limit of 300k, space is scarce, fees are bid high. If software high priests choose a size limit of 32mb, space is plentiful, fees are near zero. Market actors take their signals accordingly. Some business models boom, some business models fail, as a direct result of changing this unintentionally-added speedbump. Different users value adoption, decentralization etc. differently. The size limit is an economic policy lever that needs to be transitioned -away- from software and software developers, to the free market. A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance problems associated with actors lobbying developers, even if a cloistered and vetted Technical Advisory Board as has been proposed. On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo elombr...@gmail.com wrote: I definitely think we need some voting system for metaconsensus…but if we’re going to seriously consider this we should look at the problem much more generally. Using false choices doesn’t really help, though ;) - Eric Lombrozo On Jun 13, 2015, at 10:13 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com wrote: 2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility. What is the alternative? Have a Chief Scientist or Technical Advisory Board choose what is a proper fee, what is a proper level of decentralization, a proper growth factor? -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
I definitely think we need some voting system for metaconsensus…but if we’re going to seriously consider this we should look at the problem much more generally. Using false choices doesn’t really help, though ;) - Eric Lombrozo On Jun 13, 2015, at 10:13 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com mailto:elombr...@gmail.com wrote: 2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility. What is the alternative? Have a Chief Scientist or Technical Advisory Board choose what is a proper fee, what is a proper level of decentralization, a proper growth factor? signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
Yes, it does bother (some) people to see the consensus based system because of the difficulties that can be associated with implementing it. But that's the way it is. If you don't like consensus based systems (or decentralized, distributed systems) this is probably the wrong space for you. If consensus must be reached to make any changes, that just means that changes of anything more than trivial consequence simply can't be made. Extreme bias toward the status-quo will only work if external factors affecting the network also remain static. Aaron Voisine co-founder and CEO breadwallet.com -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
Chun, With all due respect, there are a couple major differences between BIP34 and BIP66 on the one hand and BIP100 on the other. 1) BIP34 and BIP66 are soft forks. Miners choosing to switch to them will not seriously impact validation rules for non-mining users that do not make the switch. With BIP66, the worst that can happen to them is noncompliant transactions will no longer be accepted by the network…but even nodes that do not switch over will continue to remain synched with the network. 2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility. - Eric Lombrozo On Jun 13, 2015, at 9:55 PM, Chun Wang 1240...@gmail.com wrote: To tell you the truth. It is only because most miners are not located in the West. If Slush, Eligius and BTC Guild still on top 3, the core developers, including brain-dead Mike Hearn, would be very happy to do BIP100 just like they did BIP34 and BIP66. Shame on you! On Sun, Jun 14, 2015 at 6:20 AM, Danny Thorpe danny.tho...@gmail.com wrote: Please forgive my ignorance, but why should Bitcoin users have a say in block size limits? It's the miners and Bitcoin node operators that bear the burden of managing large blocks, no? Users voting on network parameters sounds like neighbors voting on how deep my swimming pool should be. Thanks, -Danny On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd p...@petertodd.org wrote: Jeff Garzik recently proposed that the upper blocksize limit be removed entirely, with a soft limit being enforced via miner vote, recorded by hashing power. This mechanism within the protocol for users to have any influence over the miner vote. We can add that back by providing a way for transactions themselves to set a flag determining whether or not they can be included in a block casting a specific vote. We can simplify Garzik's vote to say that one of the nVersion bits either votes for the blocksize to be increased, or decreased, by some fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a nVersion bit in transactions themselves, also voting for an increase or decrease. Transactions may only be included in blocks with an indentical vote, thus providing miners with a monetary incentive via fees to vote according to user wishes. Of course, to cast a don't care vote we can either define an additional bit, or sign the transaction with both versions. Equally we can even have different versions with different fees, broadcast via a mechanism such as replace-by-fee. See also John Dillon's proposal for proof-of-stake blocksize voting: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
Miner voting, while imperfect, is the least-worst of various solutions which inject market input into the system. It is is known quantity, field tested, and must be sustained, in public, over a time span of months. As this thread shows, stakeholder and direct user voting is nigh impossible to get right. Choosing block size is fundamentally a central bank directive shaping the fee market. Whatever actor or algorithm or natural equilibrium picks the block size, that choice will dictate the level of competition for fees, the level of scarcity of an economically scarce resource. Picking the block size advantages some businesses over others, some business models over others. Software (and software devs) should not be the ones picking that limit. Checks-and-balances are also important. BIP 100 notably includes two steps at which user input is visibly and actively injected: 1) hard fork to enable, and 2) a second hard fork if the system is to scale beyond 32MB. The network users (not miners) twice approve the system. Further, one must remember all the basic miner incentives that do align with users, notably that of maintaining the value of bitcoin tokens as their primary income stream. On Sun, Jun 14, 2015 at 12:16 AM, Stephen stephencalebmo...@gmail.com wrote: While this idea is theoretically interesting because it involves many stakeholders, rather than just miners, I think in practice this would not work very well. Users don't want to worry about this kind of technicality, they just want to be able to make a transaction and have it be processed. In addition, while this gives stakeholders some weight with the fees they supply, these fees are marginal compared to the block size subsidy. If this proposal were actually implemented, I think miners would vote for whatever they think is best, and users would not contradict them with their votes to ensure a fast confirmation time. Users are incentivized to be in agreement with miners because the miners provide them with the confirmations they need, but fees do not provide a great incentive for miners to be in agreement with users, and likely won't for some time. Best, Stephen On Jun 12, 2015, at 2:11 PM, Peter Todd p...@petertodd.org wrote: Jeff Garzik recently proposed that the upper blocksize limit be removed entirely, with a soft limit being enforced via miner vote, recorded by hashing power. This mechanism within the protocol for users to have any influence over the miner vote. We can add that back by providing a way for transactions themselves to set a flag determining whether or not they can be included in a block casting a specific vote. We can simplify Garzik's vote to say that one of the nVersion bits either votes for the blocksize to be increased, or decreased, by some fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a nVersion bit in transactions themselves, also voting for an increase or decrease. Transactions may only be included in blocks with an indentical vote, thus providing miners with a monetary incentive via fees to vote according to user wishes. Of course, to cast a don't care vote we can either define an additional bit, or sign the transaction with both versions. Equally we can even have different versions with different fees, broadcast via a mechanism such as replace-by-fee. See also John Dillon's proposal for proof-of-stake blocksize voting: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
Please forgive my ignorance, but why should Bitcoin users have a say in block size limits? It's the miners and Bitcoin node operators that bear the burden of managing large blocks, no? Users voting on network parameters sounds like neighbors voting on how deep my swimming pool should be. Thanks, -Danny On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd p...@petertodd.org wrote: Jeff Garzik recently proposed that the upper blocksize limit be removed entirely, with a soft limit being enforced via miner vote, recorded by hashing power. This mechanism within the protocol for users to have any influence over the miner vote. We can add that back by providing a way for transactions themselves to set a flag determining whether or not they can be included in a block casting a specific vote. We can simplify Garzik's vote to say that one of the nVersion bits either votes for the blocksize to be increased, or decreased, by some fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a nVersion bit in transactions themselves, also voting for an increase or decrease. Transactions may only be included in blocks with an indentical vote, thus providing miners with a monetary incentive via fees to vote according to user wishes. Of course, to cast a don't care vote we can either define an additional bit, or sign the transaction with both versions. Equally we can even have different versions with different fees, broadcast via a mechanism such as replace-by-fee. See also John Dillon's proposal for proof-of-stake blocksize voting: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
That’s exactly the problem with Bitcoin - it was supposed to be the case that users ARE the miners and node operators…but…alas… On Jun 13, 2015, at 3:20 PM, Danny Thorpe danny.tho...@gmail.com wrote: Please forgive my ignorance, but why should Bitcoin users have a say in block size limits? It's the miners and Bitcoin node operators that bear the burden of managing large blocks, no? Users voting on network parameters sounds like neighbors voting on how deep my swimming pool should be. Thanks, -Danny On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd p...@petertodd.org mailto:p...@petertodd.org wrote: Jeff Garzik recently proposed that the upper blocksize limit be removed entirely, with a soft limit being enforced via miner vote, recorded by hashing power. This mechanism within the protocol for users to have any influence over the miner vote. We can add that back by providing a way for transactions themselves to set a flag determining whether or not they can be included in a block casting a specific vote. We can simplify Garzik's vote to say that one of the nVersion bits either votes for the blocksize to be increased, or decreased, by some fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a nVersion bit in transactions themselves, also voting for an increase or decrease. Transactions may only be included in blocks with an indentical vote, thus providing miners with a monetary incentive via fees to vote according to user wishes. Of course, to cast a don't care vote we can either define an additional bit, or sign the transaction with both versions. Equally we can even have different versions with different fees, broadcast via a mechanism such as replace-by-fee. See also John Dillon's proposal for proof-of-stake blocksize voting: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html -- 'peter'[:-1]@petertodd.org http://petertodd.org/ 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
(Sorry for spam, forgot to cc the mailing list) RE: miner economics Miners who have an agenda can forego fees to achieve it and create their own txns if it is completely txn/user driven. It is better to just count miners votes and let the user votes be their backing. Although miners need to include txns that have the same vote as them, or you expect them be able to vote themselves with their own txns, with backing eventually there will be a large pool of unconfirmed txns that vote against them. Which means a juicy choice of fees for an honest or small miner to vote the other way (if there are any). If the votes are required to be near unanimous (almost 100%) rather than majority rule, there will be a small miner out there who will vote honestly and reset the vote on behalf of those users, because there is a fee incentive to do so (a pure honest miner doesn't care about fees. But they're a dying breed). If it is a majority rule type of vote, bigger miners will set the vote direction and small miners have no say no matter how they vote. From a decentralisation perspective, it is better to want the big guns to have a small voice, otherwise it will tend towards centralisation. Troll users (voting against when the direction is very clear) can still be ignored by excluding their txns unless they're paying attractive fees. (So it isn't exactly 100%, but it'll be close). Miners have some power but ultimately they will represent the users if the users votes are clearly divided. If you think 100% is hard, 95-90% could be a compromise but that requires an assumption that at least 5-10% will have their voices unheard. And that might be OK. Personally, 100% is consensus, anything less is just a democracy. RE: vote bits I think letting a vote go up and down in the same vote is a strange one. Personally I think binary votes simplify the process. Would it be better to 'announce' a vote that will contain a certain change. For example, hash of a config file that said change MAX_BLOCK_SIZE - 8mb. More things can use the same mechanism by including changes in a config (or whatever script/markup) file as needed in the future, for whichever constants you want to expose to votes. Votes can just be 0 and 1 for no/yes and omitted for neutral. My preference is 1 for yes, 0 for no neutral/ignored and omitted for no, so that it is backwards compatible and doesn't skew votes to the agreeing direction, and forces node owners and wallet developers to upgrade and participate. On Jun 13, 2015 6:04 AM, Eric Lombrozo elombr...@gmail.com wrote: Miners currently only collect an almost negligible portion of their revenue from fees. While I certainly welcome any proposals that move us in the direction of defining a smooth metaconsensus process, I think with the curent economics, miners (and especially those with significant hashing power) have more of an incentive to block txs/spam their votes than to adapt to tx sender preferences...unless people increase their tx fees significantly. But without wallets that can make decent suggestions in this regard, this feature will be almost inaccessible to most regular users. And the economics still aren't entirely clear. - Eric Lombrozo On Jun 12, 2015 12:30 PM, Jannes Faber j.fa...@elevate.nl wrote: I'm imagining in Peter's proposal it's not the transaction votes that are counted but only the votes in the blocks? So miners get to vote but they risk losing money by having to exclude counter voting transactions. But garbage transactions are no problem at all. Note that users that want to cast a vote pay for that by increased confirmation time (on average, hopefully slightly depending on the trend). On Fri, Jun 12, 2015, 20:27 Matt Whitlock b...@mattwhitlock.name wrote: On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote: Peter it's not clear to me that your described protocol is free of miner influence over the vote, by artificially generating transactions which they claim in their own blocks Miners could fill their blocks with garbage transactions that agree with their vote, but this wouldn't bring them any real income, as they'd be paying their own money as fees to themselves. To get real income, miners would have to vote in accordance with real users. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
On Friday, 12 June 2015, at 7:44 pm, Peter Todd wrote: On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote: On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote: On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote: Why should miners only be able to vote for double the limit or halve the limit? If you're going to use bits, I think you need to use two bits: 0 0 = no preference (wildcard vote) 0 1 = vote for the limit to remain the same 1 0 = vote for the limit to be halved 1 1 = vote for the limit to be doubled User transactions would follow the same usage. In particular, a user vote of 0 0 (no preference) could be included in a block casting any vote, but a block voting 0 0 (no preference) could only contain transactions voting 0 0 as well. Sounds like a good encoding to me. Taking the median of the three options, and throwing away don't care votes entirely, makes sense. I hope you mean the *plurality* of the three options after throwing away the don't cares, not the *median*. Median ensures that voting no change is meaningful. If double + no change = 66%-1, you'd expect the result to be no change, not halve With a plurality vote you'd end up with a halving that was supported by a minority. Never mind. I think I've figured out what you're getting at, and you're right. We wouldn't want halve to win on a plurality just because the remaining majority of the vote was split between double and remain-the-same. Good catch. :) -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
For the purposes of finding the median, halve same double. It will only change if a majority of non-apathetic votes are for halve or a majority of non-apathetic votes are for double. On Fri, Jun 12, 2015 at 11:54 AM, Matt Whitlock b...@mattwhitlock.name wrote: On Friday, 12 June 2015, at 7:44 pm, Peter Todd wrote: On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote: On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote: On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote: Why should miners only be able to vote for double the limit or halve the limit? If you're going to use bits, I think you need to use two bits: 0 0 = no preference (wildcard vote) 0 1 = vote for the limit to remain the same 1 0 = vote for the limit to be halved 1 1 = vote for the limit to be doubled User transactions would follow the same usage. In particular, a user vote of 0 0 (no preference) could be included in a block casting any vote, but a block voting 0 0 (no preference) could only contain transactions voting 0 0 as well. Sounds like a good encoding to me. Taking the median of the three options, and throwing away don't care votes entirely, makes sense. I hope you mean the *plurality* of the three options after throwing away the don't cares, not the *median*. Median ensures that voting no change is meaningful. If double + no change = 66%-1, you'd expect the result to be no change, not halve With a plurality vote you'd end up with a halving that was supported by a minority. Never mind. I think I've figured out what you're getting at, and you're right. We wouldn't want halve to win on a plurality just because the remaining majority of the vote was split between double and remain-the-same. Good catch. :) -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- J. Aaron Gustafson Cornell University '16 | Computer Science, Engineering | Mathematics, Arts Sciences Vice President, Kappa Delta Rho jag...@cornell.edu | Ithaca, New York -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
On Fri, Jun 12, 2015 at 1:04 PM, Eric Lombrozo elombr...@gmail.com wrote: Miners currently only collect an almost negligible portion of their revenue from fees. Then they shouldn't care about the block size limit, since an increase in block size (and thus in the number of txs they get fees from) will only increase their revenue negligibly. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote: Why should miners only be able to vote for double the limit or halve the limit? If you're going to use bits, I think you need to use two bits: 0 0 = no preference (wildcard vote) 0 1 = vote for the limit to remain the same 1 0 = vote for the limit to be halved 1 1 = vote for the limit to be doubled User transactions would follow the same usage. In particular, a user vote of 0 0 (no preference) could be included in a block casting any vote, but a block voting 0 0 (no preference) could only contain transactions voting 0 0 as well. Sounds like a good encoding to me. Taking the median of the three options, and throwing away don't care votes entirely, makes sense. Incidentally, I love this idea, as it addresses a concern I immediately had with Jeff's proposal, which is that it hands control exclusively to the miners. And your proposal here fixes that shortcoming in a economically powerful way: miners lose out on fees if they don't represent the wishes of the users. Thanks! I personally expect disaster to ensue with this kind of proposal, but I'm less concerned if the disaster is something users explicitly allowed to happen in a consensual way. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
On Fri, Jun 12, 2015 at 02:26:20PM -0400, Matt Whitlock wrote: On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote: Peter it's not clear to me that your described protocol is free of miner influence over the vote, by artificially generating transactions which they claim in their own blocks Miners could fill their blocks with garbage transactions that agree with their vote, but this wouldn't bring them any real income, as they'd be paying their own money as fees to themselves. To get real income, miners would have to vote in accordance with real users. Exactly. I very explicitly am proposing that we consider giving users a mechanism to pay for votes to give them a way to directly influence the outcome. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
This is a misguided idea, to say the least. If such a mechanism of of user input would be possible, one would use it for transaction verification in the first place. In proof-of-stake outcomes are determined by vote by stake (that vote has very different characteristics than vote by compute power). There is no such thing as making it possible to determine what users want. That's what the proof-of-work mechanism does in the first place, only that it is now unfortunately skewed/corrupted/(whatever you want to call it). Before centralization the concept of miners didn't exist in Bitcoin and miners were roughly identical to users. Peer-to-Peer implies only one class of users. A big problem with such a vote (in PoW and PoS): miners get paid for their work and have incentives to raise fees. Those who pay fees would have no say in whether those fees are fair or not. Transaction verification has to be roughly profitable, but there is no fixed formula for determining profitability. On Fri, Jun 12, 2015 at 8:26 PM, Matt Whitlock b...@mattwhitlock.name wrote: On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote: Peter it's not clear to me that your described protocol is free of miner influence over the vote, by artificially generating transactions which they claim in their own blocks Miners could fill their blocks with garbage transactions that agree with their vote, but this wouldn't bring them any real income, as they'd be paying their own money as fees to themselves. To get real income, miners would have to vote in accordance with real users. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development On Fri, Jun 12, 2015 at 8:34 PM, Peter Todd p...@petertodd.org wrote: On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote: Why should miners only be able to vote for double the limit or halve the limit? If you're going to use bits, I think you need to use two bits: 0 0 = no preference (wildcard vote) 0 1 = vote for the limit to remain the same 1 0 = vote for the limit to be halved 1 1 = vote for the limit to be doubled User transactions would follow the same usage. In particular, a user vote of 0 0 (no preference) could be included in a block casting any vote, but a block voting 0 0 (no preference) could only contain transactions voting 0 0 as well. Sounds like a good encoding to me. Taking the median of the three options, and throwing away don't care votes entirely, makes sense. Incidentally, I love this idea, as it addresses a concern I immediately had with Jeff's proposal, which is that it hands control exclusively to the miners. And your proposal here fixes that shortcoming in a economically powerful way: miners lose out on fees if they don't represent the wishes of the users. Thanks! I personally expect disaster to ensue with this kind of proposal, but I'm less concerned if the disaster is something users explicitly allowed to happen in a consensual way. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development On Fri, Jun 12, 2015 at 8:36 PM, Peter Todd p...@petertodd.org wrote: On Fri, Jun 12, 2015 at 02:26:20PM -0400, Matt Whitlock wrote: On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote: Peter it's not clear to me that your described protocol is free of miner influence over the vote, by artificially generating transactions which they claim in their own blocks Miners could fill their blocks with garbage transactions that agree with their vote, but this wouldn't bring them any real income, as they'd be paying their own money as fees to themselves. To get real income, miners would have to vote in accordance with real users. Exactly. I very explicitly am proposing that we consider giving users a mechanism to pay for votes to give them a way to directly influence the outcome. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development On Fri, Jun 12, 2015 at 8:36 PM, Matt Whitlock b...@mattwhitlock.name wrote: On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote: On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote: Why should miners only be able to
Re: [Bitcoin-development] User vote in blocksize through fees
Peter it's not clear to me that your described protocol is free of miner influence over the vote, by artificially generating transactions which they claim in their own blocks, or conforming incentives among voters by opting to be with the (slight) majority in order to minimize fees. Wouldn't it in fact be simpler to use the dynamic block size adjustment algorithm presented to the list a few weeks back, where the miner opts for a larger block by sacrificing fees? In that way the users vote for larger blocks by including sufficient fees to offset subsidy, but as it is an economic incentives miners gain nothing by inflating the fees in their own blocks. On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd p...@petertodd.org wrote: Jeff Garzik recently proposed that the upper blocksize limit be removed entirely, with a soft limit being enforced via miner vote, recorded by hashing power. This mechanism within the protocol for users to have any influence over the miner vote. We can add that back by providing a way for transactions themselves to set a flag determining whether or not they can be included in a block casting a specific vote. We can simplify Garzik's vote to say that one of the nVersion bits either votes for the blocksize to be increased, or decreased, by some fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a nVersion bit in transactions themselves, also voting for an increase or decrease. Transactions may only be included in blocks with an indentical vote, thus providing miners with a monetary incentive via fees to vote according to user wishes. Of course, to cast a don't care vote we can either define an additional bit, or sign the transaction with both versions. Equally we can even have different versions with different fees, broadcast via a mechanism such as replace-by-fee. See also John Dillon's proposal for proof-of-stake blocksize voting: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote: Peter it's not clear to me that your described protocol is free of miner influence over the vote, by artificially generating transactions which they claim in their own blocks Miners could fill their blocks with garbage transactions that agree with their vote, but this wouldn't bring them any real income, as they'd be paying their own money as fees to themselves. To get real income, miners would have to vote in accordance with real users. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
