[Bitcoin-development] User vote in blocksize through fees

[Bitcoin-development] User vote in blocksize through fees

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3348 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Matt Whitlock]

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 Friday, 12 June 2015, at 2:11 pm, Peter Todd 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

Re: [Bitcoin-development] User vote in blocksize through fees

[Matt Whitlock]

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.

Re: [Bitcoin-development] User vote in blocksize through fees

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Matt Whitlock]

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

Re: [Bitcoin-development] User vote in blocksize through fees

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Benjamin]

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

On Fri, Jun 12, 2015 at 8:34 PM, Peter Todd <pete@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
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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 <pete@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
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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 <bip@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 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

Re: [Bitcoin-development] User vote in blocksize through fees

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

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.

-- 
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

On Fri, Jun 12, 2015 at 08:39:21PM +0200, Benjamin wrote:
> 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.

Read John Dillon's proposal then, which via proof-of-stake explicitly
approportions control of increases via % of Bitcoin owned.


Anyway, representing everyone is never going to be easy, but at least
this nVersion thing is very easy to implement.

-- 
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Matt Whitlock]

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.

I'm very confused.

Let's say, out of the 12,000 blocks in a voting period:
• 1000 blocks express no preference,
• 2000 blocks vote to halve the limit,
• 3500 blocks vote to double the limit, and
• 5500 blocks vote to keep the limit the same.

 The plurality vote is to keep the limit the same. The median vote is… well, I'm not sure, since there are four choices, and an average of the two "middle" choices doesn't seem to make sense.

Re: [Bitcoin-development] User vote in blocksize through fees

[Matt Whitlock]

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

Re: [Bitcoin-development] User vote in blocksize through fees

[Aaron Gustafson]

[-- Attachment #1: Type: text/plain, Size: 2435 bytes --]

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 <bip@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
jag426@cornell.edu | Ithaca, New York

[-- Attachment #2: Type: text/html, Size: 3925 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Jannes Faber]

[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 1833 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Eric Lombrozo]

[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3314 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Vincent Truong]

[-- Attachment #1: Type: text/plain, Size: 5209 bytes --]

(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" <elombrozo@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.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
>
>

[-- Attachment #2: Type: text/html, Size: 6785 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Luke Dashjr]

On Friday, June 12, 2015 11:01:02 PM Vincent Truong wrote:
> 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.

Just simplify this? Allow a miner to have their block counted as <max possible 
votes> votes for X provided not a single transaction they include votes 
against it. Then miners can explicitly forego the fees of opposing 
transactions without having to bloat blocks.

Luke

Re: [Bitcoin-development] User vote in blocksize through fees

[Aaron Gustafson]

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

On Fri, Jun 12, 2015 at 1:04 PM, Eric Lombrozo <elombrozo@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".

[-- Attachment #2: Type: text/html, Size: 655 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Danny Thorpe]

[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3020 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Eric Lombrozo]

[-- Attachment #1.1: Type: text/plain, Size: 2907 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 4566 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Stephen]

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

Re: [Bitcoin-development] User vote in blocksize through fees

[Eric Lombrozo]

[-- Attachment #1: Type: text/plain, Size: 3722 bytes --]

What Stephen said is very much along the same lines of my earlier critique. This voting mechanism would be all but unusable to most endusers without some pretty elaborate tools…and unless users are willing to pay substantially higher fees than they’re currently paying, their votes will not really count all that much. And it’s not all that clear that most users would really be able to make very rational economic decisions even having elaborate tools. More likely, a small group would figure out ways to exploit this for their own benefit - at everyone else’s expense.

- Eric Lombrozo


> 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


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Chun Wang]

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
>

Re: [Bitcoin-development] User vote in blocksize through fees

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 4447 bytes --]

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



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

[-- Attachment #2: Type: text/html, Size: 6176 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

On Sun, Jun 14, 2015 at 12:55 AM, 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!
>

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/

[-- Attachment #2: Type: text/html, Size: 954 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Eric Lombrozo]

[-- Attachment #1: Type: text/plain, Size: 3942 bytes --]

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


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

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?


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

[-- Attachment #2: Type: text/html, Size: 927 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Eric Lombrozo]

[-- Attachment #1.1: Type: text/plain, Size: 739 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 3473 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]

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


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

[-- Attachment #2: Type: text/html, Size: 4504 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Ashley Holman]

[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]

Economic policy sounds like a dirty word in the context of Bitcoin, but as
Jeff Garzik said, choosing a block size cap is unfortunately an economic
policy that has to be chosen somehow.  Enabling users to incentivise the
voting process is an interesting tool to have in the toolbox, but I think
it would be sensible to first observe how the miner-only voting system
behaves on its own.

If, for example, the hashing majority tended to favour a move towards
centralization (big blocks), user preferences could potentially hasten this
move by further punishing marginal miners through reduced fees.  On the
other hand, if user preferences tended to oppose the preferences of miners,
then such a system might function well in keeping a balance between
usability and security (although it's not clear how this balance might
change over time as the block subsidy drops).

In short, I think it's wise to keep it simple and implement one mechanism
at a time.

On Sat, Jun 13, 2015 at 4: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
>
>

[-- Attachment #2: Type: text/html, Size: 3656 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Mats Henricson]

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
> 

Re: [Bitcoin-development] User vote in blocksize through fees

[Benjamin]

"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

Re: [Bitcoin-development] User vote in blocksize through fees

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 3303 bytes --]

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


On Sun, Jun 14, 2015 at 6:06 AM, 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
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

[-- Attachment #2: Type: text/html, Size: 4874 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 5595 bytes --]

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



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

[-- Attachment #2: Type: text/html, Size: 7784 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Eric Lombrozo]

[-- Attachment #1: Type: text/plain, Size: 4614 bytes --]


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

In addition, fees are complicated by the fact that they are used as an anti-spam measure for relay nodes…who don’t see ANY direct compensation whatsoever for providing that service. So we really have two different fees being tacked on…but the miners get to keep all of it…and the relay fee is being hard coded into the software.

Fee calculation heuristics for wallets are already far from trivial - this is another issue that needs to be addressed.

- Eric Lombrozo

> 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


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Notionally, I agree with what I see written here by Jeff, and I
appreciate the thoughtfulness that went into this short post to list.

On 06/14/2015 08:07 AM, Jeff Garzik wrote:
> 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
>
>>>
>>> 
>> 
>> 
>> 
> ----------------------------------------------------------------------
- --------
>
>
> 
_______________________________________________
>> Bitcoin-development mailing list 
>> Bitcoin-development@lists.sourceforge.net
> <mailto:Bitcoin-development@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> ----------------------------------------------------------------------
- --------
>
>
> 
_______________________________________________
> Bitcoin-development mailing list 
> Bitcoin-development@lists.sourceforge.net 
> <mailto: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
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVfflFAAoJEGxwq/inSG8CrWoIAJOsZHTWqdILE0IYmmE50E/S
BcbPJJtjodw1liPVJEybyNUKSgq4Ucw9tuQpMVv3hF8bvug6/6HtxAQCptuIKRSw
WigZyvgm79u474YsPULG+2SltMrOFqmA05jTF9vWo0LBSY4xiMXjT4VwVt9xEcFc
qHW5OUa1QoFZkaOf/jtY+H3a9w8cHZFlroTkf4MaJkaMo81oSRfWz3Mj8wOz6f8z
MSEpvQERzETEcV0SqTBnzsoX8toO1s24a9HejMMfbeD7JAy8EvayFb3G1LNzBNVC
1x/yeLBGnE3Z0P80J0oUR5taLbGJl9+7Hb16rEzxivtZF5FWBdDmvwKBOKJ1Alo=
=ubcH
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] User vote in blocksize through fees

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 307 bytes --]

On Sun, Jun 14, 2015 at 4:42 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:

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

Reposting as Jeff's mail got eaten by the anti-phishing filters, due to
SourceForge's obsolete mailman setup.

[-- Attachment #2: Type: text/html, Size: 736 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[Eric Lombrozo]

[-- Attachment #1.1: Type: text/plain, Size: 1468 bytes --]

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

To be clear, Jeff, I am 100% in agreement with you that a mechanism like what you’re proposing is a million times better than having high priests that ram hard forks without proper consensus. And perhaps given the present circumstances it seems like the only alternative. However, in my mind this block size limit controversy is actually a fairly superficial aspect - a mere symptom, a manifestation of the real problem...

What I find somewhat irksome is that we’ve had six years to figure out a mechanism to enable hard forks (which we knew from the start would be inevitable) - and more to the point, we’ve known about this block size issue from the start as well…and only suddenly it becomes an issue of major urgency that we must bump up this parameter 20x…

- Eric Lombrozo

[-- Attachment #1.2: Type: text/html, Size: 3644 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I agree that changes of anything more than trivial are difficult, but
I would disagree that they can't be made.  It seems that the issue is
one of roadblocks and muddling through when a major issue (e.g. the
proposal of a hardfork / XT) is confronting the community and the
question of how to address this issue in a timely manner. That does
not mean that there isn't a process for the community to weigh in or
for the decisions of the participants in the network to be measured
because, of course, there is, but I submit that the larger issues are
having to do with concerns over the problems inherent in the totally
unnecessary XT proposal itself.

My own thoughts on that proposal are written up at
http://www.twitlonger.com/show/n_1smkanp

And have been supported somewhat by various others in the community,
such as GreenAddress (which is opposed at this time to increasing the
blocksize limit as per Gavin's proposal) and Adam Back:
https://twitter.com/adam3us/status/608920099609817088

I think Jeff Garzik had some good thoughts specifically regarding this
subject of user vote in blocksize through fees.  Although I do agree
with you, Aaron, that the "changes more than trivial" are a tough nut
to crack, I won't say that they can't be made in such processes and I
am curious to see how this discussion progresses.

- -O





On 06/13/2015 10:46 PM, Aaron Voisine wrote:
> 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/>

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVffRMAAoJEGxwq/inSG8CGfIH/RkMNeJpcXdG+pC6Cg1XMELQ
wa/fkdKnnkhhxNm4keHeO0YQFw0BL4rQSQ2PfGEXU3keJrWlmxchEQteAGDzL55Y
1dSkQbfxsaEco2m6P0/1+WGuNOn2Sp653+/G/WoeaqMvp+b2ORbVZoqURv7Iz240
sI6GqWxWxuGpJyaW/PwVYfvGAImeQRKgKiB3w001Q3Lc36wDr/EGs4lVWJTSk+g+
60zj4+7jmqpr/Q/+sjQDE0KZSBU/EmrPYEuEdBkOmG4JnFgBqM7civtHis/zu7Uc
1sr/LcqeGm0VB/yt0CfvtsAC5KZyMFQABF0/Q2qX0GtuLbjyKWf7B/KEAPdC+m0=
=3cf3
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] User vote in blocksize through fees

[Aaron Voisine]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1100 bytes --]

Re: [Bitcoin-development] User vote in blocksize through fees

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A decentralized, distributed application should offer its users
decentralized, distributed method of weighing in on the direction of
how it evolves as well as having an open development model.  The
reference to Facebook and Myspace is completely inapplicable here
because the tyranny of such spaces isn't what we have with bitcoin
(fortunately), nor would we want to try to replicate it, ever, in any
way, shape, or form.

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.

On 06/13/2015 04:57 PM, Raystonn wrote:
> 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
/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
> 
> 
> 
> 
> 
> ----------------------------------------------------------------------
- --------
>
>
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVfQL0AAoJEGxwq/inSG8CRqMH/0l9tHGA8figVGnIBoMgdpVi
uwMGTQTjLUf12/NFS27vT+OLMWqZRvVXvlxDF25N7la+QImhh67LqmQy8fkwGg5T
kJ6MkkFLgy05aqE/X3ywJUifOKmS3Y/RDDUJhrFjjHrsMGoF4ATtVwTpUBLik+kX
G3XRNlInmyB55UEcpyfBg9kfLz8xiy6sBPeaeGnFLCNWTs5TgJ6DTFqhBAAmE8Hw
k0tN6mW3wYS610FFkS2E3+W8O8KGs4oqAYLX/ZQOhX9oKjBvWWI4ppRpSDyBNcxd
A6VAKyU8HCuDHAEwba6gdlUa+yf4qxuZV1KCNENbvtN1CTsJ6oh0OxnEO6dtogo=
=KZmG
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] User vote in blocksize through fees

[Raystonn]

[-- Attachment #1: Type: text/html, Size: 5396 bytes --]