From: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin development mailing list <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard
Date: Fri, 18 Dec 2015 09:44:36 +0000 [thread overview]
Message-ID: <CAE-z3OXQpHFXY_vbTRMMcFSfP4tiFAsmCxkkZ+=Bfkppg=ciMQ@mail.gmail.com> (raw)
In-Reply-To: <20151217194407.GB1351@muck>
[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]
On Thu, Dec 17, 2015 at 7:44 PM, Peter Todd <pete@petertodd•org> wrote:
> If Bitcoin remains decentralized, miners have veto power over any
> blocksize increases. You can always soft-fork in a blocksize reduction
> in a decentralized blockchain that actually works.
>
The actual users of the system have significant power, if they (could)
choose to use it. There are "chicken" effects though. They can impose
costs on the other participants but using those options harms themselves.
If the cost of inaction is greater than the costs of action, then the
chicken effects go away.
In the extreme, they could move away from decentralisation and the concept
of miners and have a centralised checkpointing system. This would be a
bankrupting cost to miners but at the cost to the users of the
decentralised nature of the system.
At a lower extreme, they could change the mining hash function. This would
devalue all of the miner's investments. A whole new program of ASIC
investments would have to happen and the new miners would be significantly
different. It would also establish that merchants and users are not to be
ignored. On the other hand, bankrupting miners would make it harder to
convince new miners to make the actual investments in ASICs required to
establish security.
As a gesture, if merchants and exchanges wanted to get their "seat" at the
table, they could create a representative group that insists on a trivial
soft fork. For example, they could say that they will not accept any block
from block N to block N + 5000 that doesn't have a specific bit set in the
version.
Miners have an advantage where they can say that they have the majority of
the hashing power. As part of the public action problem that merchants
face, there is no equivalent metric.
[-- Attachment #2: Type: text/html, Size: 2374 bytes --]
next prev parent reply other threads:[~2015-12-18 9:44 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 14:53 Jeff Garzik
2015-12-16 18:34 ` Pieter Wuille
2015-12-16 21:08 ` Jeff Garzik
2015-12-16 21:11 ` Pieter Wuille
2015-12-17 2:06 ` Jameson Lopp
2015-12-17 16:58 ` Tier Nolan
2015-12-17 19:44 ` Peter Todd
2015-12-18 5:23 ` Jorge Timón
2015-12-18 9:44 ` Tier Nolan [this message]
2015-12-16 21:24 ` Jorge Timón
2015-12-16 21:36 ` Jeff Garzik
2015-12-18 5:11 ` Jeff Garzik
2015-12-18 7:56 ` Pieter Wuille
2015-12-18 10:13 ` sickpig
2015-12-18 15:48 ` Pieter Wuille
2015-12-19 19:04 ` Dave Scotese
[not found] ` <751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com>
2015-12-26 16:44 ` Pieter Wuille
2015-12-26 17:20 ` Jorge Timón
2015-12-26 22:55 ` Jonathan Toomim
2015-12-26 23:01 ` Pieter Wuille
2015-12-26 23:07 ` Jonathan Toomim
2015-12-26 23:16 ` Pieter Wuille
2015-12-27 0:03 ` Jonathan Toomim
2015-12-26 23:15 ` Justus Ranvier
2015-12-27 0:13 ` Bryan Bishop
2015-12-27 0:33 ` Justus Ranvier
2015-12-18 13:56 ` Jeff Garzik
2015-12-23 6:26 ` Aaron Voisine
2015-12-16 18:36 ` jl2012
2015-12-16 22:27 ` Jeff Garzik
2015-12-17 6:12 ` Dave Scotese
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='CAE-z3OXQpHFXY_vbTRMMcFSfP4tiFAsmCxkkZ+=Bfkppg=ciMQ@mail.gmail.com' \
--to=tier.nolan@gmail$(echo .)com \
--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