public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil.org>
To: bitcoin-dev@lists.linuxfoundation.org,
	Libbitcoin Development <libbitcoin@lists.dyne.org>
Subject: Re: [bitcoin-dev] Moving towards user activated soft fork activation
Date: Tue, 7 Mar 2017 09:37:15 -0800	[thread overview]
Message-ID: <48f6c6a5-ba7e-cf75-e272-e713321f04b8@voskuil.org> (raw)
In-Reply-To: <CA+su7OXOfG2AsLqh-i4YZHc42tFPm+4OBqOV4jCrpADtx4U71g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2850 bytes --]

On 03/06/2017 05:07 PM, Edmund Edgar via bitcoin-dev wrote:
> On 7 March 2017 at 08:23, Gareth Williams <gjw@posteo.net> wrote:
>> What you're describing is a hashpower activated soft fork to censor
transactions, in response to a user activated soft fork that the
majority of hashpower disagrees with.

This definition of censorship would apply to all validation.

A miner is free to select whatever transactions he wants, for whatever
reasons he wants. Bitcoin's defense against censorship (and disruption)
is in the broad distribution of over 50% (anecdotally) of the hash power
among a large number of people.

> Well, they'd be censoring transactions to prevent the thing from
> activating in the first place. (As opposed to censoring a subset of
> those transactions to enforce the new rule, which is the behaviour
> that the people promoting the change want.)

Exactly, a soft fork expects that people start rejecting a previously
valid style of transaction, or that they ignore it. It's perfectly
reasonable to conclude that some miners may continue to accept the
soft-fork-invalidated transactions and instead reject the new style of
transactions as invalid. Reliance on their acceptance of the soft fork
is based on the weak assumption that they won't change their software or
that they live in fear of a retaliatory POW change.

>> Bitcoin only works if the majority of hashpower is not hostile to the
users.

Honesty in this context refers to double spending. Selecting a different
rule set effectively moves one to another coin, which is not dishonest
(hostile to anyone).  Miners have zero technical or ethical obligation
to follow any particular set of rules. Bitcoin has one golden rule, run
whatever code you want. Security is based on decentralization, not
well-behaved people (or well-behaved software).

> This is true. But what we're talking about here is hostility to *a
> particular proposal to change the network rules* which is (in this
> hypothetical case) supported by the economic majority of users. This
> doesn't, in itself, break Bitcoin, although the economic majority are
> of course always free to hard-fork to something new if they're
> unhappy.

Again spot on. Users of the money purchase security from miners. Miners
are under no obligation to provide that service nor are users under any
obligation to purchase it.

One thing to consider is how different the landscape would look if every
person on the planet was a miner, and the economy was similarly
distributed. Would it be easier to get 51% hash power on board with a
soft fork, or some much higher percentage on board with a hard fork? It
seems likely that any proposed material change would fail. Regardless of
how one feels about that, it is the nature of a sound money that it
doesn't change.

e


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2017-03-07 17:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-05 14:33 [bitcoin-dev] Moving towards user activated soft fork activation Chris Belcher
2017-03-05 18:10 ` David Vorick
2017-03-05 18:48   ` Eric Voskuil
2017-03-05 21:31   ` Nick ODell
2017-03-06  9:18     ` David Vorick
2017-03-06 10:29       ` Edmund Edgar
2017-03-06 23:23         ` Gareth Williams
2017-03-07  1:07           ` Edmund Edgar
2017-03-07 17:37             ` Eric Voskuil [this message]
2017-03-07  9:17           ` Tom Zander
2017-03-07 18:13             ` Eric Voskuil
2017-03-07 19:13             ` Alphonse Pace
  -- strict thread matches above, loose matches on Subject: below --
2017-02-25 23:55 shaolinfry
2017-02-26 17:34 ` Jameson Lopp
2017-02-27 16:02   ` shaolinfry
2017-02-27 16:50     ` Eric Voskuil
2017-02-28 21:20 ` Luke Dashjr
2017-03-12 15:47 ` shaolinfry

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=48f6c6a5-ba7e-cf75-e272-e713321f04b8@voskuil.org \
    --to=eric@voskuil.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=libbitcoin@lists.dyne.org \
    /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