From: Stephen Morse <stephencalebmorse@gmail.com>
To: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] Max Block Size: Simple Voting Procedure
Date: Sun, 31 May 2015 15:04:32 -0400 [thread overview]
Message-ID: <CABHVRKSFV_dXZeLnhBLfRK=wrBFsRH5kFBZqwECh-LyCkwrmtQ@mail.gmail.com> (raw)
[-- 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 --]
next reply other threads:[~2015-05-31 19:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-31 19:04 Stephen Morse [this message]
2015-06-02 21:26 ` [Bitcoin-development] Max Block Size: Simple Voting Procedure 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABHVRKSFV_dXZeLnhBLfRK=wrBFsRH5kFBZqwECh-LyCkwrmtQ@mail.gmail.com' \
--to=stephencalebmorse@gmail.com \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox