Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_1987B860-9AA1-4526-8652-B85B66B25195";
	protocol="application/pgp-signature"; micalg=pgp-sha512
From: Jonathan Toomim <j@toom.im>
In-Reply-To: <20151230190043.GJ18200@mcelrath.org>
Date: Wed, 30 Dec 2015 15:49:35 -0800
Message-Id: <16BFC301-58C1-49F9-B2E5-A2C09C82A8CA@toom.im>
References: <1bf64a5b514d57ca37744ae5f5238149@openmailbox.org>
	<e170f3a10164019824edaafe5a04f067@xbt.hk>
	<f9ad1348fb7dedca35b594782fee7e0f@openmailbox.org>
	<20151230190043.GJ18200@mcelrath.org>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Increasing the blocksize as a (generalized)
	softfork.
Precedence: list


--Apple-Mail=_1987B860-9AA1-4526-8652-B85B66B25195
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Dec 30, 2015, at 11:00 AM, Bob McElrath via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:

> joe2015--- via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] =
wrote:
>> That's the whole point.  After a conventional hardfork everyone
>> needs to upgrade, but there is no way to force users to upgrade.  A
>> user who is simply unaware of the fork, or disagrees with the fork,
>> uses the old client and the currency splits.
>>=20
>> Under this proposal old clients effectively enter "zombie" mode,
>> forcing users to upgrade.
>=20
> This is a very complex way to enter zombie mode.


Another way you could make non-upgraded nodes enter zombie mode is to =
explicitly 51% attack the minority fork.

All soft forks are controlled, coordinated, developer-sanctioned 51% =
attacks against nodes that do not upgrade. The generalized softfork =
technique is a method of performing a soft fork that completely =
eliminates any usefulness to non-upgraded nodes while merge-mining =
another block structure to provide functionality to the nodes who have =
upgraded and know where to look for the new data.

Soft forks are "safe" forks because you can trust the miners to censor =
blocks and transactions that do not conform to the new consensus rules. =
Since we've been relying on the trustworthiness of miners during soft =
forks in the past (and it only failed us once!), why not

The generalized softfork method has the advantage of being merge-mined, =
so miners don't have to lose any revenue while performing this 51% =
attack against non-upgraded nodes. But then you're stuck with all of =
your transactions in a merge-mined/commitment-based data structure, =
which is a bit awkward and ugly. But you could avoid all of that code =
ugliness by just convincing the miners to donate some hashrate (say, =
5.1% if the IsSupermajority threshold is 95%, or you could make it =
dynamic to save some money) to ensuring that the minority fork never has =
any transactions in the chain. That way, you can replace the everlasting =
code ugliness with a little bit of temporary sociopolitical ugliness. =
Fortunately, angry people are easier to ignore than ugly code. /s

Maybe we could call this a softly enforced hard fork? It's basically a =
combined hard fork for the supermajority and a soft fork to make the =
minority chain useless.

I don't personally think that these 51% attacks are useful or necessary. =
This is one of the main reasons why I don't like soft forks. I find them =
distasteful, and think that leaving minorities free to practice their =
own religions and blockchain rules is a good thing. But I could see how =
this could address some of the objections that others have raised about =
the dangers of hardforks, so I'm putting it out there.

> Once a chain is seen to be 6 or more blocks ahead of my chain tip, we =
should
> enter "zombie mode" and refuse to mine or relay

I like this method. However, it does have the problem of being =
voluntary. If nodes don't upgrade to a version that has the latent =
zombie gene long before a fork, then it does nothing.


--Apple-Mail=_1987B860-9AA1-4526-8652-B85B66B25195
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJWhG2QAAoJEIEuMk4MG0P1VqcH/08x9vjnFt/xrX8Bb3VPoOUg
7Juy6iYcXUuD7TjxM27+OSZryUwEqi3phfZ4mDSvN0PS9EGd3jyFel8HhW8EZWIH
Nxr/EOvVUh6g6/uGMo9A5edIWj4tyJCQip1VgTuPdSwd4M7hRY+/WNSq2PNOdpYu
syCg3G4h3h03aTbOzo0dXCbn4g3nnb3Zl8BFOeqqRnl9fJUsTbL8uBTy+w/v6tYi
H9VXcMgBwK9TY/BwE3Js7h0lYHUuFAmRhSKsDevMCF4QDAm54ws//yNz/1IgSgUg
WlGwZGV8DLO8A3KjOTI4KyTnT9gcOw30gGThHteb/lbrZBbTNuif8uD0gDCUd2k=
=eUoV
-----END PGP SIGNATURE-----

--Apple-Mail=_1987B860-9AA1-4526-8652-B85B66B25195--