From: Michael Ruddy <mruddybtc@gmail•com>
To: Adam Back <adam@cypherspace•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A reason we can all agree on to increase block size
Date: Mon, 3 Aug 2015 09:57:55 -0400 [thread overview]
Message-ID: <CABFP+yP4-_XugCxNsUJ7eY=ATr-5bN4CdN5q8GuTjG7NWW4eMg@mail.gmail.com> (raw)
In-Reply-To: <CALqxMTEMajz6oHnGvocxy=xDFMBc1LaX1iWYM=w1PF0rH3syFg@mail.gmail.com>
Does that not sound like a useful check-and-balance? It does to me.
In a scenario where these network limitations and miner rate
distributions are the same to begin, and the block and transaction
size limits are raised or removed, your observation would seem to
indicate that blocks that are outstandingly large would not be mined
often or at all (due to orphan risk), until at least the network
limitations or rate distributions changed.
Such a scenario could shape up to be a non-event. Miner majority could
choose to not change their policy regarding effective block and
transaction sizes (which includes both the size of the blocks they
create and the size of the blocks that they choose to build upon). To
make it not a total non-event, then the miners might update their
policy to increase the effective sizes a measured amount. They
wouldn't want to go too far because of the risk of spooking the
economic majority, or because of their own technological limitations
(which I'm supposing would remain transport layer limitations).
To me, in absence of these transport layer limitations that have crept
up into the consensus rules layer (clear layer violations), it seems
that one thing that would otherwise naturally bound the upper and
lower limits of effective block and transaction size is the economic
majority feedback loop to miners. Get too far out of line and the
effect on usefulness, or properties of the system, will make people
react by lowering the purchasing power of the block rewards. For
example, attack other miners to drive more mining centralization, or
create blocks that are currently too big for people to validate/use,
and that feedback loop will start to direct negatively.
Why do miners not currently choose policy that favors smaller blocks
and transactions than they do? Laziness/indifference only explains so
much. I submit that they don't because if they make the system less
useful, then people will react by selling off coins and potentially
leaving the ecosystem (they might also just wait on the sidelines to
see if the system self-corrects). If the miners tested those waters,
and found out that they made a mistake, at least they would be free to
correct their actions (and quickly). Not all would be lost. Some value
could be (temporarily) lost. It could also be re-gained if the system
self-corrected.
To follow-up on the layer violation idea that I started on before, I
think a secondary, non-consensus rule layer, indication of what block
and transaction sizes are acceptable to the economic majority would be
found in the transport protocols that they use. For example, the
effective P2P protocol limit that is 2MB or 32MB (depending on version
of the Core client) would be one such indication. Doesn't anyone think
that separating the consensus layer rules from the transport layer
supporting it should be a goal?
On Mon, Aug 3, 2015 at 2:34 AM, Adam Back via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> If block-sizes are increased in a way detrimental to the Chinese miners, it
> is not the Chinese miners that lose, it is all of the non-Chinese miners -
> this is because the Chinese miners have the slight majority of the hashrate.
> The relatively low external bandwidth connecting China to the net is
> actually the problem of the non-Chinese miners problem. Non Chinese miners
> will experience higher orphan rate once Chinese miners cease to build on top
> of blocks that are too large to sync in a timely fashion into China.
>
> Adam
prev parent reply other threads:[~2015-08-03 13:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-02 21:02 Jim Phillips
2015-08-03 1:21 ` Pindar Wong
2015-08-03 4:33 ` Jim Phillips
2015-08-03 3:13 ` odinn
2015-08-03 6:34 ` Adam Back
2015-08-03 6:53 ` Jim Phillips
2015-08-04 10:53 ` Jorge Timón
2015-08-03 7:16 ` Simon Liu
2015-08-03 7:34 ` Hector Chu
2015-08-03 7:53 ` Adam Back
2015-08-03 8:06 ` Hector Chu
2015-08-03 8:20 ` Eric Lombrozo
2015-08-03 8:31 ` Hector Chu
2015-08-03 8:38 ` Eric Lombrozo
2015-08-03 8:52 ` Hector Chu
2015-08-03 9:01 ` Eric Lombrozo
2015-08-03 9:22 ` Hector Chu
2015-08-03 7:46 ` Adam Back
2015-08-03 13:57 ` Michael Ruddy [this message]
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='CABFP+yP4-_XugCxNsUJ7eY=ATr-5bN4CdN5q8GuTjG7NWW4eMg@mail.gmail.com' \
--to=mruddybtc@gmail$(echo .)com \
--cc=adam@cypherspace$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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