1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
Return-Path: <j@toom.im>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D62BD105D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 23:48:34 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 396DD162
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 23:48:34 +0000 (UTC)
Received: from [192.168.1.190] (63.135.62.197.nwinternet.com [63.135.62.197]
(may be forged)) (authenticated bits=0)
by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tBUNmUmr015960
(version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Wed, 30 Dec 2015 15:48:32 -0800
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
X-Pgp-Agent: GPGMail 2.5.2
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>
X-Mailer: Apple Mail (2.1878.6)
X-Sonic-CAuth: UmFuZG9tSVbxJDSLgnRt/i076HfCZVucX7JssAb73sMQR3Efa0k79juZS8IRh/e3GAZ8XOa5ohN50/4Pn0OPvvxr1PEkPAgY
X-Sonic-ID: C;brmV1E+v5RGbf8gxU3XIUw== M;cAgw1U+v5RGbf8gxU3XIUw==
X-Sonic-Spam-Details: 3.8/5.0 by cerberusd
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Increasing the blocksize as a (generalized)
softfork.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Dec 2015 23:48:34 -0000
--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--
|
