* [Bitcoin-development] Max Block Size: Simple Voting Procedure
@ 2015-05-31 19:04 Stephen Morse
2015-06-02 21:26 ` Matt Whitlock
[not found] ` <CAM7BtUod0hyteqx-yj8XMwATYp73Shi0pvdcTrW0buseLGc_ZQ@mail.gmail.com>
0 siblings, 2 replies; 7+ messages in thread
From: Stephen Morse @ 2015-05-31 19:04 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]
This is likely very similar to other proposals, but I want to bring voting
procedures back into the discussion. The goal here is to create a voting
procedure that is as simple as possible to increase the block size limit.
Votes are aggregated over each 2016 block period. Each coinbase transaction
may have an output at tx.vout[0] with OP_RETURN data in it of the format:
OP_RETURN {OP_1 or OP_2}
OP_2 means the miner votes to increase the block size limit. OP_1 means the
miner votes to not increase the block size limit. *Not including such a
vote is equivalent to voting to NOT increase the block size. *I first
thought that not voting should mean that you vote with your block size, but
then decided that it would be too gameable by others broadcasting
transactions to affect your block size.
If in a 2016 block round there were more than 1008 blocks that voted to
increase the block size limit, then the max block size increases by 500 kb.
The votes can start when there is a supermajority of miners signaling
support for the voting procedure.
A few important properties of this simple voting:
- It's not gameable via broadcasting transactions (assuming miners don't
set their votes to be automatic, based on the size of recent blocks).
- Miners don't have to bloat their blocks artificially just to place a
vote for larger block sizes, and, similarly, don't need to exclude
transactions even when they think the block size does not need to be raised.
- The chain up until the point that this goes into effect may be
interpreted as just lacking votes to increase the block size.
We can't trust all miners, but we have to trust that >50% of them are
honest for the system to work. This system makes it so that altering the
maximum block size requires >50% of miners (hash power) to vote to increase
the consensus-limit.
Thanks for your time. I think this is an important time in Bitcoin's
history. I'm not married to this proposal, but I think it would work. I
think a lot of the proposals mentioned on this mailing list would work. I
think it's time we just pick one and run with it.
Please let me know your thoughts. I will start working on a pull request if
this receives any support from miners/core devs/community members, unless
someone with more experience volunteers.
Best,
Stephen
[-- Attachment #2: Type: text/html, Size: 2873 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
2015-05-31 19:04 [Bitcoin-development] Max Block Size: Simple Voting Procedure Stephen Morse
@ 2015-06-02 21:26 ` Matt Whitlock
2015-06-03 0:30 ` Stephen Morse
[not found] ` <CAM7BtUod0hyteqx-yj8XMwATYp73Shi0pvdcTrW0buseLGc_ZQ@mail.gmail.com>
1 sibling, 1 reply; 7+ messages in thread
From: Matt Whitlock @ 2015-06-02 21:26 UTC (permalink / raw)
To: Stephen Morse; +Cc: bitcoin-development
Why do it as an OP_RETURN output? It could be a simple token in the coinbase input script, similar to how support for P2SH was signaled among miners. And why should there be an explicit token for voting for the status quo? Simply omitting any indication should be an implicit vote for the status quo. A miner would only need to insert an indicator into their block if they wished for a larger block.
That said, proposals of this type have been discussed before, and the objection is always that miners would want larger blocks than the rest of the network could bear. Unless you want Bitcoin to become centralized in the hands of a few large mining pools, you shouldn't hand control over the block size limits to the miners.
On Sunday, 31 May 2015, at 3:04 pm, Stephen Morse wrote:
> This is likely very similar to other proposals, but I want to bring voting
> procedures back into the discussion. The goal here is to create a voting
> procedure that is as simple as possible to increase the block size limit.
>
> Votes are aggregated over each 2016 block period. Each coinbase transaction
> may have an output at tx.vout[0] with OP_RETURN data in it of the format:
>
> OP_RETURN {OP_1 or OP_2}
>
> OP_2 means the miner votes to increase the block size limit. OP_1 means the
> miner votes to not increase the block size limit. *Not including such a
> vote is equivalent to voting to NOT increase the block size. *I first
> thought that not voting should mean that you vote with your block size, but
> then decided that it would be too gameable by others broadcasting
> transactions to affect your block size.
>
> If in a 2016 block round there were more than 1008 blocks that voted to
> increase the block size limit, then the max block size increases by 500 kb.
> The votes can start when there is a supermajority of miners signaling
> support for the voting procedure.
>
> A few important properties of this simple voting:
>
> - It's not gameable via broadcasting transactions (assuming miners don't
> set their votes to be automatic, based on the size of recent blocks).
> - Miners don't have to bloat their blocks artificially just to place a
> vote for larger block sizes, and, similarly, don't need to exclude
> transactions even when they think the block size does not need to be raised.
> - The chain up until the point that this goes into effect may be
> interpreted as just lacking votes to increase the block size.
>
> We can't trust all miners, but we have to trust that >50% of them are
> honest for the system to work. This system makes it so that altering the
> maximum block size requires >50% of miners (hash power) to vote to increase
> the consensus-limit.
>
> Thanks for your time. I think this is an important time in Bitcoin's
> history. I'm not married to this proposal, but I think it would work. I
> think a lot of the proposals mentioned on this mailing list would work. I
> think it's time we just pick one and run with it.
>
> Please let me know your thoughts. I will start working on a pull request if
> this receives any support from miners/core devs/community members, unless
> someone with more experience volunteers.
>
> Best,
> Stephen
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
2015-06-02 21:26 ` Matt Whitlock
@ 2015-06-03 0:30 ` Stephen Morse
0 siblings, 0 replies; 7+ messages in thread
From: Stephen Morse @ 2015-06-03 0:30 UTC (permalink / raw)
To: Matt Whitlock; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]
>
> Why do it as an OP_RETURN output? It could be a simple token in the
> coinbase input script, similar to how support for P2SH was signaled among
> miners. And why should there be an explicit token for voting for the status
> quo? Simply omitting any indication should be an implicit vote for the
> status quo. A miner would only need to insert an indicator into their block
> if they wished for a larger block.
>
I don't really care the exact location it's put in. I just thought there
wasn't an explicit need to put it in the header (via a bit of nVersion),
and the scriptSig is already used for many things (block height, merged
mining hash, "\"P2SH\"", miner identifier). And voting to keep the block
size the same by not voting is fine by me.
> That said, proposals of this type have been discussed before, and the
> objection is always that miners would want larger blocks than the rest of
> the network could bear. Unless you want Bitcoin to become centralized in
> the hands of a few large mining pools, you shouldn't hand control over the
> block size limits to the miners.
>
Yeah, that was the conclusion we came to chatting on #bitcoin-wizards the
other day. I now think that this could be useful to dynamically increase a
lower limit, but that there should still be a hard upper limit like 20 MB.
I think that just changing the upper limit might be simpler and better,
though.
- Stephen
[-- Attachment #2: Type: text/html, Size: 1942 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
[not found] ` <CAM7BtUrN9D__ha63Qfs2Fi4HSUFWb8BArHni9yFKRSdLSxCNnA@mail.gmail.com>
@ 2015-06-03 2:33 ` Stephen Morse
2015-06-03 3:08 ` Vincent Truong
2015-06-03 4:18 ` Pindar Wong
0 siblings, 2 replies; 7+ messages in thread
From: Stephen Morse @ 2015-06-03 2:33 UTC (permalink / raw)
To: Pindar Wong; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 987 bytes --]
Pindar,
yes and it's a good idea to separate the hard/soft fork upgrades. The point
> being here is that we're also establishing a process for the community to
> self-determine the way forward in a transparent and verifiable manner.
>
> What's not to like? :)
>
> I'll probably have some time on Sunday to help hack something up but I
> don't think this is that heavy a coding lift? What am I missing?
>
As Matt mentioned, many members of the bitcoin community would be hesitant
about giving miners this much power. It essentially lets them vote to
change the rules of the system. But miners are not the only part of this
ecosystem, and they are not the only ones affected by the choice of block
size limit, so they probably shouldn't be the only ones with a vote.
Instead, we vote with the software we run, and all upgrade.
So, while I think an idea like this has its merits, I would bet that it's
fairly unlikely to get enough support to be merged into bitcoin core.
Best,
Stephen
[-- Attachment #2: Type: text/html, Size: 1446 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
2015-06-03 2:33 ` Stephen Morse
@ 2015-06-03 3:08 ` Vincent Truong
2015-06-03 3:36 ` Stephen Morse
2015-06-03 4:18 ` Pindar Wong
1 sibling, 1 reply; 7+ messages in thread
From: Vincent Truong @ 2015-06-03 3:08 UTC (permalink / raw)
To: Stephen Morse; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]
Some changes:
Votes need to be 100%, not 50.01%. That way small miners have a fair
chance. A 50.01% vote means large miners call the shots.
Users (people who make transactions) need to vote. A vote by a miner
shouldn't count without user votes. Fee incentives should attract
legitimate votes from miners. A cheating miner will be defeated by another
miner who includes those votes, and take the fees.
This lets wallet providers and exchanges cast votes (few wallets will
implement prompts and will just auto vote, so if you don't agree, switch
wallets. Vote with your wallet).
~Vince
On Jun 3, 2015 12:34 PM, "Stephen Morse" <stephencalebmorse@gmail•com>
wrote:
> Pindar,
>
> yes and it's a good idea to separate the hard/soft fork upgrades. The
>> point being here is that we're also establishing a process for the
>> community to self-determine the way forward in a transparent and verifiable
>> manner.
>>
>> What's not to like? :)
>>
>> I'll probably have some time on Sunday to help hack something up but I
>> don't think this is that heavy a coding lift? What am I missing?
>>
>
> As Matt mentioned, many members of the bitcoin community would be hesitant
> about giving miners this much power. It essentially lets them vote to
> change the rules of the system. But miners are not the only part of this
> ecosystem, and they are not the only ones affected by the choice of block
> size limit, so they probably shouldn't be the only ones with a vote.
> Instead, we vote with the software we run, and all upgrade.
>
> So, while I think an idea like this has its merits, I would bet that it's
> fairly unlikely to get enough support to be merged into bitcoin core.
>
> Best,
> Stephen
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 2903 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
2015-06-03 3:08 ` Vincent Truong
@ 2015-06-03 3:36 ` Stephen Morse
0 siblings, 0 replies; 7+ messages in thread
From: Stephen Morse @ 2015-06-03 3:36 UTC (permalink / raw)
To: Vincent Truong; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]
Vincent,
> Some changes:
>
> Votes need to be 100%, not 50.01%. That way small miners have a fair
> chance. A 50.01% vote means large miners call the shots.
>
While I like the idea of possibly requiring more than 50%, you wouldn't
want to have a situation where a minority of uncooperative (or just lazy)
miners don't add their votes and hold up progress. Maybe 2/3 instead of
1/2, though.
> Users (people who make transactions) need to vote. A vote by a miner
> shouldn't count without user votes. Fee incentives should attract
> legitimate votes from miners. A cheating miner will be defeated by another
> miner who includes those votes, and take the fees.
>
> This lets wallet providers and exchanges cast votes (few wallets will
> implement prompts and will just auto vote, so if you don't agree, switch
> wallets. Vote with your wallet).
>
The idea of voting with your wallet, while appealing, is technically
infeasible. Miners can fill their blocks with any type of transactions,
including their own specially designed transactions. And any fees from
these transactions can be collected right back into their coinbase
transaction.
- Stephen
[-- Attachment #2: Type: text/html, Size: 1708 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
2015-06-03 2:33 ` Stephen Morse
2015-06-03 3:08 ` Vincent Truong
@ 2015-06-03 4:18 ` Pindar Wong
1 sibling, 0 replies; 7+ messages in thread
From: Pindar Wong @ 2015-06-03 4:18 UTC (permalink / raw)
To: Stephen Morse; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2764 bytes --]
On Wed, Jun 3, 2015 at 10:33 AM, Stephen Morse <stephencalebmorse@gmail•com>
wrote:
> Pindar,
>
> yes and it's a good idea to separate the hard/soft fork upgrades. The
>> point being here is that we're also establishing a process for the
>> community to self-determine the way forward in a transparent and verifiable
>> manner.
>>
>> What's not to like? :)
>>
>> I'll probably have some time on Sunday to help hack something up but I
>> don't think this is that heavy a coding lift? What am I missing?
>>
>
> As Matt mentioned, many members of the bitcoin community would be hesitant
> about giving miners this much power.
>
I understand this concern and it's a valid one, including other dimensions
such as better decentralization. Some might argue that the mining pools in
China currently have such power and that's a bad thing:-
https://blockchain.info/pools
I happen to think that it's unhealthy for the network but the irony is
that they are huge bitcoin fanbase that perhaps should be involved in this,
and other, decisions. The question is how.
Thus far our friends from f2pool have chimed in with some data from their
perspective. It would be interesting to hear from the others and I'm
finding ways to do exactly that.
So let's find a way to involve, and not alienate them or others. Let's find
a way to get more data and test assumptions and boundaries.
It essentially lets them vote to change the rules of the system.
>
It's data and yes, it gives then a very visible, verifiable 'vote' ...
though I prefer to think of this as 'voice' as in a ' hummmm. '
But miners are not the only part of this ecosystem, and they are not the
> only ones affected by the choice of block size limit, so they probably
> shouldn't be the only ones with a vote.
>
I fully agree and it doesn't have to be the only voice ... think 'choir'
... after all this is an ecosystem with each party playing their
respective roles. But sustainable ecosystems have 'keystone' species, and I
believe these to be the 'honest' miners that help secure the network.
Instead, we vote with the software we run, and all upgrade.
>
or not as the case may be. I think we're trying to find a level of rough
consensus where members of the community feel comfortable enough to do this
upgrade in their respective codebase.
>
> So, while I think an idea like this has its merits, I would bet that it's
> fairly unlikely to get enough support to be merged into bitcoin core.
>
Bitcoin was 'unlikely' ... yet it happened.
Nevertheless you raise the possibility of a different possible path forward
and that's positive. So thank you for doing that!
Bitcoin's humming in China, behind an GFW ... who could have guessed?
'Connect and Liberate' :)
p.
>
> Best,
> Stephen
>
>
[-- Attachment #2: Type: text/html, Size: 5141 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-06-03 4:18 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-31 19:04 [Bitcoin-development] Max Block Size: Simple Voting Procedure Stephen Morse
2015-06-02 21:26 ` Matt Whitlock
2015-06-03 0:30 ` Stephen Morse
[not found] ` <CAM7BtUod0hyteqx-yj8XMwATYp73Shi0pvdcTrW0buseLGc_ZQ@mail.gmail.com>
[not found] ` <CABHVRKT7H1p67Bz_T_caaGFnfuswnC+kXKGdkpRhtXUZQv3HtQ@mail.gmail.com>
[not found] ` <CAM7BtUrN9D__ha63Qfs2Fi4HSUFWb8BArHni9yFKRSdLSxCNnA@mail.gmail.com>
2015-06-03 2:33 ` Stephen Morse
2015-06-03 3:08 ` Vincent Truong
2015-06-03 3:36 ` Stephen Morse
2015-06-03 4:18 ` Pindar Wong
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox