summaryrefslogtreecommitdiff
path: root/1c/01c433c4c08ca34556fa798620691d5a459c2d
blob: aa3089026b3280063ce18e76201641ab9308c7a4 (plain)
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
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5737745E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 00:43:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com
	[209.85.192.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D6475153
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 00:43:05 +0000 (UTC)
Received: by pdrg1 with SMTP id g1so146920233pdr.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 17:43:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:message-id:references:to;
	bh=USxp+Tkg1IsCDpHIqfQ/KDtQzOnPljesxAx/YI6yTKA=;
	b=WsPlCtdVWXLruoKxZADM6G0N1RdJBKOLDF2Gn/NGLOrWCpDJfPZN9nwU2jXjdxqg6G
	Ic67AkXGQLTDB3Le8jgJmNqx0JKpi/UltED5Ujk7bIvpafDXx26Yw1PlPXuRv4UKhQTi
	gZtjh2D+/XthZdWPNE4G3KWKxYuJR2TLzOP0aMS1Ni3fEW+L0Wfrm6yL4GIas/MHcQdj
	o/7eF+ATighpJzUlBcVLdc4ZbbG4wZj7RzPv/8FIxyjUQmum1xDXq/O5F3t4reLNdYSX
	hKyrYLhLpsKO1gUyPNVQ/4qzRjEepxGoTHqncNOupgq2lpnxdI3A0gwBAC3bYo4/j7Vs
	OFmA==
X-Received: by 10.66.162.198 with SMTP id yc6mr12062530pab.74.1437612185544;
	Wed, 22 Jul 2015 17:43:05 -0700 (PDT)
Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202])
	by smtp.gmail.com with ESMTPSA id t2sm5383741pdo.81.2015.07.22.17.43.03
	(version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 22 Jul 2015 17:43:04 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_72A70D00-E466-4464-B099-2943312A12B4";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CAApLimhFNeQ-1kpTT0YtOz2X0th563quOq1cFGhmL6VJcxFv8Q@mail.gmail.com>
Date: Wed, 22 Jul 2015 17:43:02 -0700
Message-Id: <D02A0586-83CA-4BD6-B607-73570C695081@gmail.com>
References: <COL402-EAS482BCC1B2EFF6D50273832CD830@phx.gbl>
	<CAApLimjMPvXHM4McB+xBrho2hktz8Rr7QZyU-Dgbgd7sFdoyLw@mail.gmail.com>
	<068B7F93-A1DF-4F8D-84FC-B787C5429D6A@gmail.com>
	<CAApLimjiF6zH8GAbTajMTW6p8GtXCGRa5GcV+N2z1soY5fQy+A@mail.gmail.com>
	<B340ACFF-600F-45A9-BFE9-B831A4C6DD8E@gmail.com>
	<CAApLimhFNeQ-1kpTT0YtOz2X0th563quOq1cFGhmL6VJcxFv8Q@mail.gmail.com>
To: Cory Fields <lists@coryfields.com>
X-Mailer: Apple Mail (2.2098)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
	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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
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: Thu, 23 Jul 2015 00:43:06 -0000


--Apple-Mail=_72A70D00-E466-4464-B099-2943312A12B4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jul 22, 2015, at 5:34 PM, Cory Fields <lists@coryfields.com> wrote:
>=20
> On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo <elombrozo@gmail.com> =
wrote:
>>=20
>>> On Jul 22, 2015, at 5:05 PM, Cory Fields <lists@coryfields.com> =
wrote:
>>>=20
>>> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <elombrozo@gmail.com> =
wrote:
>>>> FWIW, I had worked on something similar a while back:
>>>> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>>>>=20
>>>> I like the idea in principle=E2=80=A6but we should require a new =
genesis block,
>>>> different magic bytes, and a different network port at the very =
least. :)
>>>>=20
>>>=20
>>> Not sure if serious, so I'll assume you are :)
>>=20
>> Only being partly serious - I strongly am in favor of a sufficiently =
modularized codebase that swapping out consensus rules is fairly =
straightforward and easy to test. I=E2=80=99m not in favor of =
encouraging forking an existing blockchain without having mechanisms in =
place to gracefully merge back without significant network disruptions. =
We do not have this yet.
>>=20
>=20
> Again, why? If someone wants to create a scamcoin, they can. If
> someone wants to burn money on a scamcoin, equally, they can. I'm not
> sure how this is any different. If someone manages to garner realistic
> support for a hard-fork, I don't see the benefit in forcing them to
> use forked software.. that only leaves Core in the middle because it's
> forced to choose a side (not choosing is unfortunately a side as
> well). It doesn't remove the reality of the split.

In general, new consensus rules are not trivial to implement. Block size =
limits are exceptional in being so simple to change in the code. So what =
you=E2=80=99re proposing sounds more like a plugin model supporting =
dynamic linking than a configuration file.

>>> Why? The idea in this case would be to allow the user to decide
>>> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
>>> runtime rather than the likely alternative of "./bitcoind" vs
>>> "./bitcoin-fork=E2=80=9D.
>>=20
>> That=E2=80=99s exactly what my coinparams_new branch does. Adding a =
parameter for maximum block size would be straightforward.
>>=20
>>> Chain params may be identical other than the value of some future
>>> event (miner vote for example), in which case the configs would run
>>> identically until that point.
>>=20
>> Yes, indeed - this would be a special case.
>>=20
>>> If your concern is about nodes with different configs communicating
>>> with eachother, I'd like to reiterate: the idea really is no =
different
>>> than suggesting that someone fork the codebase and implement their =
own
>>> changes, it just cuts out most of the work required.
>>=20
>> I do not encourage anyone to try to fork an existing blockchain =
without first securing overwhelming (near unanimous) consensus=E2=80=A6or =
without having yet built a mechanism that can merge divergent chains =
gracefully.
>=20
> Well of course. It would be a terrible idea. People would try it and
> fail, and lose money. But for those crying foul at Core for being the
> consensus/policy gatekeeper, it seems to me that user-selectable
> params is the only logical solution.

The real problem isn=E2=80=99t so much the difficulty of creating forks =
of the codebase - but the fact that unless a fork has overwhelming =
support, blockchains cannot guarantee irreversibility of =
transactions=E2=80=A6which defeats their entire purpose.

--Apple-Mail=_72A70D00-E466-4464-B099-2943312A12B4
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

iQIcBAEBCgAGBQJVsDiWAAoJEJNAI64YFENUVwMP/j8//ocBVHxp1JeI+k3WppT5
0z6+yyCIR8eo5lyAj/ngAM1Jcah7l75/bYwcP0RjqS9cBxV5FlTBv0/bosTx9boK
ix7jE68X0jVq8fiUIhm7sFHbjdfx0c4/eh63MFjNdopDA7wXRKEzuf0CzJQQ5QkJ
skvvNXf8nuSoHoff+55kTiiGob1BT8xdxaenIB9VRgYAITOSJbqPVp8QeimzIGYd
XGTG8Xp4Bg+AttdJFDjsE/1lnKRv1Xzt2Ti7U8nHXkU0KBQ6nl5oVW+fGCtFEld3
3e8/AcW/bTgrrkOA5F1IV9gjbA8WoSaGqo6RUCY0o7tl8etkoREU/Xj9g/VZ7gLi
MgVU+1lMspx40lktoFJEc5aHzXLiKAErcZ6EMpJ7RQ9ot38DMeLZBdFhr/+LOQYE
/6oysni7UbAvZL3GLzDFcjQ+R1ojkb1efXF4Iq6QafcarGF5YymjAtXRrxTg/STU
UNN/XcvoCTyRKroPjiKSvr6tBRh1K1X9OpUT3kqLY16MpKHIR7I5p0oJ13F2J61e
shes8FV2EqKMTfef7c4lO1gi+8INe4B2qroExVkyupE+cYaPk3KSv2YLqYd29nVv
OQfXj/mbtB1RTWS9+C4YsLSwyRtx+2Hua4u+uWQQLFkar98GEFPZWGug6Gmo2uc/
OhM7vpdr0u7BQCbTKa/a
=9mEl
-----END PGP SIGNATURE-----

--Apple-Mail=_72A70D00-E466-4464-B099-2943312A12B4--