Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
In-Reply-To: <9086552.5NYgjOP6f4@strawberry>
Date: Tue, 7 Mar 2017 10:13:36 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <08254322-D7BC-4BF8-ACB2-189588D93325@voskuil.org>
References: <0ba5bf9c-5578-98ce-07ae-036d0d71046b@riseup.net>
	<CA+su7OV0Cpe=4AKdNhJXOCbYVriEN1vHSoA_0r31GXCAP1=NCA@mail.gmail.com>
	<964E4801-234F-4E30-A040-2C63274D27F2@posteo.net>
	<9086552.5NYgjOP6f4@strawberry>
To: Tom Zander <tomz@freedommail.ch>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Moving towards user activated soft fork activation
Precedence: list

> Bitcoin would lose the security and in the short term even the ability to=20=

mine blocks every 10 minutes.

Presumably a POW hard fork would be accompanied by a difficulty reset, so th=
at the deployment didn't have *both* of these problems from the outset.  The=
re's really little difference between 10 minutes at little/no security and z=
ero conf. See testnet. But people might feel better about still seeing block=
s.

But in any case it's not clear to me why you assume a loss of security in th=
e "short term" is something that can be overcome. The short term can presuma=
bly prevent the long term from ever becoming.

e

> On Mar 7, 2017, at 1:17 AM, Tom Zander via bitcoin-dev <bitcoin-dev@lists.=
linuxfoundation.org> wrote:
>=20
>> On Tuesday, 7 March 2017 00:23:47 CET Gareth Williams via bitcoin-dev wro=
te:
>> 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.
>=20
> It is incorrect to say that censoring of transactions is what Edmund=20
> suggested. It's purely about the form they take, you can re-send the=20
> transaction in a different form with the same content and they go through.=
=20
> Hence, not transaction censoring.
>=20
> I do believe the point that Edmund brought up is a very good one, the idea=
=20
> that a set of users can force the miners to do something is rather silly a=
nd=20
> the setup that a minority miner fraction can force the majority to do=20
> something is equally silly. This is because the majority mining hashpower=20=

> can fight back against this attack upon them.
>=20
> Don=E2=80=99t be mistaken; a hash-minority attacking the hash-majority is i=
n actual=20
> fact an attack upon Bitcoin as a whole.
> If this were possible then next year we=E2=80=99d see governments try to p=
ush=20
> through changes in the same UASF way. I=E2=80=99m very happy that UASFs ca=
n=E2=80=99t work=20
> because that would be the end of Bitcoin's freedom and decentralized natur=
e.
>=20
>> It is always possible for a majority of hashpower to censor transactions
>> they disagree with. Users may view that as an attack, and can always
>> respond with a POW hard fork.
>=20
> I definitely welcome that approach.
>=20
> The result would be that you have two chains, but also you ensure that the=
=20
> chain that the miners didn=E2=80=99t like will no longer be something they=
 can mine.=20
> Not even the minority set of miners that like the softfork can mine on it.=
=20
> This is a win-win and then the market will decide which one will "win".
>=20
>> Bitcoin only works if the majority of hashpower is not hostile to the
>> users.
>=20
> This goes both ways, miners both generate value (in the form of security)=20=

> and they take value (in the form of inflation).
> If the majority of the users are hostile and reject blocks that the miners=
=20
> create, or change the POW, then what the miners bring to the table is also=
=20
> removed.
> Bitcoin would lose the security and in the short term even the ability to=20=

> mine blocks every 10 minutes.
>=20
> So, lets correct your statement a little;
> =C2=ABBitcoin only works when the majority of the hashpower and the (econo=
mic)
>  majority of the users are balanced in power and have their goals aligned.=
=C2=BB
>=20
> --=20
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev