User vote in blocksize through fees

> 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
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> 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
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778

> 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

> 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.

> 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.

> 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.

> 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.

> 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 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
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> 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
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> 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*.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

> 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*.

> 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 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.

> 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.

> 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
>

> 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 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
>

> 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.faber@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 <bip@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 mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> 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.

> Miners currently only collect an almost negligible portion of their
> revenue from fees.

> 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
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> On Jun 13, 2015, at 3:20 PM, Danny Thorpe <danny.thorpe@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 <pete@petertodd•org <mailto:pete@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/>
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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

> On Jun 12, 2015, at 2:11 PM, Peter Todd <pete@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
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

> Adding back the list. Did not intend to remove it. Apologies.
>
> On 13 Jun 2015 4:52 pm, Raystonn <raystonn@hotmail•com> wrote:
>
> Based on my observations, what the majority of Bitcoin users want
> is a system that can carry more transactions per second than any
> existing payment system while retaining most of the security
> offered today. The technicalities on how this is achieved are not
> as important as the end result. If the only user input is to
> technicalities, they will use that to voice their opinions.
>
> On 13 Jun 2015 4:25 pm, Danny Thorpe <danny.thorpe@gmail•com>
> wrote:
>
> I don't recall Facebook or MySpace asking end users to alter the
> parameters of their respective back-end network infrastructure.
>
> How are Bitcoin end users qualified to make an informed decision
> regarding block size limits? And why should they care?
>
> Sure, I want Bitcoin to grow its user base. But to do that,
> Bitcoin has to be accessible to the nontechnical population.
> Asking nontechnical people to make technical decisions leads
> directly to stress and confusion, which most folks find
> off-putting.
>
> And please don't call me Shirley.  ;>
>
> On Sat, Jun 13, 2015 at 3:42 PM, Raystonn <raystonn@hotmail•com
> <mailto:raystonn@hotmail.com>> wrote:
>
> Surely you would prefer to actually have users? Bitcoin does not
> exist in a vacuum. Network effect alone is not enough to ensure
> success in the face of competition from alternatives with a much
> better user experience. See Facebook vs MySpace, IE vs Netscape,
> etc.
>
> On 13 Jun 2015 3:20 pm, Danny Thorpe <danny.thorpe@gmail•com
> <mailto:danny.thorpe@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 <pete@petertodd•org
> <mailto:pete@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

>
>
>

> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
> ----------------------------------------------------------------------

>
>
>

> On Jun 13, 2015, at 9:16 PM, Stephen <stephencalebmorse@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 <pete@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
>> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> 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

> 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 <pete@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
>> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>

> 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 <pete@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
> > 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > 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
>

> 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 Jun 13, 2015, at 9:55 PM, Chun Wang <1240902@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.thorpe@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 <pete@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
>>> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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

> 2) BIP100 has direct economic consequences…and particularly for miners. It
> lends itself to much greater corruptibility.
>
>

> On Jun 13, 2015, at 10:13 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
>
> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo@gmail•com <mailto:elombrozo@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?

> 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 <jgarzik@bitpay•com> wrote:
>
> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo@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?
>
>
>

>
> 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.
>

> 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
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> 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 <elombrozo@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 <jgarzik@bitpay•com> wrote:
>>
>> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo@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
>

> 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 <elombrozo@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 <jgarzik@bitpay•com> wrote:
>>>
>>> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo@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

> 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 <elombrozo@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 <jgarzik@bitpay•com> wrote:
> >>
> >> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo@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
>

> "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 <mats@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 <elombrozo@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 <jgarzik@bitpay•com> wrote:
> >>>
> >>> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo@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
>

> On Jun 14, 2015, at 3:34 AM, Benjamin <benjamin.l.cordes@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 <mats@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 <elombrozo@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 <jgarzik@bitpay•com> wrote:
>>>>
>>>> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo@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

> 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
> <http://breadwallet.com/>

> 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.cordes@gmail•com <mailto:benjamin.l.cordes@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 <mats@henricson•se
> <mailto:mats@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
> <elombrozo@gmail•com <mailto:elombrozo@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
>>>> <jgarzik@bitpay•com
> <mailto:jgarzik@bitpay.com>> wrote:
>>>>
>>>> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo
> <elombrozo@gmail•com <mailto:elombrozo@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
> <mailto:Bitcoin-development@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>>>
>>>
>>
>>
>>
> ----------------------------------------------------------------------

>
>
>

> Since you missed it, here is the suggestion again:
> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
>

> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo@gmail•com <mailto:elombrozo@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?

> On Jun 13, 2015, at 10:36 PM, Jeff Garzik <jgarzik@bitpay•com> 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?