From: Stephen Morse <stephencalebmorse@gmail•com>
To: Matt Whitlock <bip@mattwhitlock•name>
Cc: bitcoin-development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
Date: Tue, 2 Jun 2015 20:30:58 -0400 [thread overview]
Message-ID: <CABHVRKTPevP-Z9te2W_N=SaJrF-yUkYgREQQ5O=khOzoL-sbZQ@mail.gmail.com> (raw)
In-Reply-To: <2342620.MypLiFWdOh@crushinator>
[-- 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 --]
next prev parent reply other threads:[~2015-06-03 0:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-31 19:04 Stephen Morse
2015-06-02 21:26 ` Matt Whitlock
2015-06-03 0:30 ` Stephen Morse [this message]
[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='CABHVRKTPevP-Z9te2W_N=SaJrF-yUkYgREQQ5O=khOzoL-sbZQ@mail.gmail.com' \
--to=stephencalebmorse@gmail$(echo .)com \
--cc=bip@mattwhitlock$(echo .)name \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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