To: bitcoin-dev@lists.linuxfoundation.org,
	Libbitcoin Development <libbitcoin@lists.dyne.org>
References: <0ba5bf9c-5578-98ce-07ae-036d0d71046b@riseup.net>
	<CAFVRnyomgeXu2pRO=+B7bwB-bZdEL2DcpJNPMz=tAhht6eZXAQ@mail.gmail.com>
	<CANN4kmcLTcqHL53tEFk=g9o0_PsGzwArm9wgd0__ZXZpvhrs1g@mail.gmail.com>
	<CAFVRnyr4QoU5Rn2ryQ-jG8sZ18J7NKcpd3Cg+uN1sfiA=FiB+Q@mail.gmail.com>
	<CA+su7OV0Cpe=4AKdNhJXOCbYVriEN1vHSoA_0r31GXCAP1=NCA@mail.gmail.com>
	<964E4801-234F-4E30-A040-2C63274D27F2@posteo.net>
	<CA+su7OXOfG2AsLqh-i4YZHc42tFPm+4OBqOV4jCrpADtx4U71g@mail.gmail.com>
From: Eric Voskuil <eric@voskuil.org>
Message-ID: <48f6c6a5-ba7e-cf75-e272-e713321f04b8@voskuil.org>
Date: Tue, 7 Mar 2017 09:37:15 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
	Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CA+su7OXOfG2AsLqh-i4YZHc42tFPm+4OBqOV4jCrpADtx4U71g@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="0es2irxUKE31CaAQ2d8FMpNfHRQ7TxuHL"
Subject: Re: [bitcoin-dev] Moving towards user activated soft fork activation
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--0es2irxUKE31CaAQ2d8FMpNfHRQ7TxuHL
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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


--0es2irxUKE31CaAQ2d8FMpNfHRQ7TxuHL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJYvu/MAAoJEDzYwH8LXOFOMsAH/1ZEID79z3okKQhYeFRpAL4v
8g6KCnuye2FlwtXdQ3+i2aS5HNcYS+qaviBGo50DIFfou9uC//z0ffbzxdR2SonF
x/YL1xA0ZLsfONWdrkb/zZO8+zflUCh5eG/9P25W9t2YXr0g4ya64HWOHLOkw1/D
J0Pg9ph/Rm2allNVd0MT3ZMs9bK4qtbuRjergsNWYsg+Y/9t0ISdeoN0uN+Vhx0Z
gbAsQ8dN5le3NDVGYjVZ7jIEcYANQE/0nzMZtI2MUC8zvd36Tjno3jlLrxcx8xTH
2FkyvcIxn1G4uWLmIhzuQgdeV+sPyfKGt5EZb1w+iz9jXdiLf92FcAFID/gk7lM=
=00vX
-----END PGP SIGNATURE-----

--0es2irxUKE31CaAQ2d8FMpNfHRQ7TxuHL--