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
|
Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 722F614A1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Sep 2015 08:42:53 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F237E12D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Sep 2015 08:42:52 +0000 (UTC)
Received: from mail-io0-f171.google.com ([209.85.223.171]) by
mrelay.perfora.net (mreueus002) with ESMTPSA (Nemesis) id
0MI7dw-1ZYLqM0nHi-003u3t for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 01 Sep 2015 10:42:52 +0200
Received: by ioeu67 with SMTP id u67so45352138ioe.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 01 Sep 2015 01:42:51 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.15.209 with SMTP id 78mr28654148iop.51.1441096971416;
Tue, 01 Sep 2015 01:42:51 -0700 (PDT)
Received: by 10.50.132.195 with HTTP; Tue, 1 Sep 2015 01:42:51 -0700 (PDT)
In-Reply-To: <CC252814-9AF6-4A28-926E-EE83C517E440@gmx.com>
References: <602b978abcedd92fbed85f305d9d7bfe@cock.li>
<55E4B8C9.5030606@openbitcoinprivacyproject.org>
<e786da226b8e9cfaad335454b299ffd5@cock.li>
<CAJfRnm4kwHkBLUUOmfzViUwsdAf3LYSTruvHw9+-RbgxSMHLRg@mail.gmail.com>
<5A3D7824-F1E3-421B-A32A-0EF21DD215BD@gmx.com>
<55E4E7AA.6010905@sky-ip.org>
<CC252814-9AF6-4A28-926E-EE83C517E440@gmx.com>
Date: Tue, 1 Sep 2015 01:42:51 -0700
Message-ID: <CALqxMTFKDmQnFZimJPttyDdyOHbc_ffs-vV7XDwwJLLu=UPVfA@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Peter R <peter_r@gmx.com>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:VVoIzZl5goJJD/dBKWULlGPT+JMtgtXr3UJ88L1irJ9+/bqBKVh
tE8Mb5Qzigrj6M2izf5fTlxQTFIYVPJ254A+86WM/0noFysiZr27fcWsQAXzj2gQNX63IGK
Q6HSFh+Kb8zTAjkJqnG970vBdvWNQ9iwrBskI3l9MtaaCzpfXytaKGznod9TbC4jspE8R/n
9EWolGvi+uls3tphWF92g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:FgbbcIEqkbs=:NlF/p479JhA/wfPQHJGTQL
2sB5EcSiw0EuGJiPwdty0dsJuION463Kw5rJnEJsaKiyCEHQItPPyqX7HbPgZ++fUXwKhR3S0
wTuwQjRao+PXDaSEMRWV9pGCAmVlm+0kdrZgJSBp8OvC5Cto2zMAY6mh2Tj3KW8lHMyMM89Dd
IdO5rcaZWaHygp4Y2g0fGIpjjUhNObdXkn8lNa9ZleA3pRgKvi0f5uWoSFMroLFVEhMMCr/5l
EuvGUZ23QIvQ0hBbvrY6mtg96Jt1qyuYDVXhaNRisGkNNsb26cTzRjsUBKGfk2PkE7U2a/LPy
RdqAe3vAihF/pr2HcmnwPd1xQ2NnHdgBGM1d4fz6UEruWM8UoUswC7eOPPpuY6HewvowkFjTn
RuItJ7FlbhlCIP85OagfspZ5U7sGljJgoKtyBmoTqaJ/VKqfOlc+pAtFokN57eHW5AD8hmlyl
yNf1kQM5AK/zEUzKcA1l6cCjHINmh+yUYSAmrAZ5rmTb94NwVqZK8OPwRK20lfkjgLkt74DE4
ftuZC4R5kQKrqND1iiUgG8Ed4oQGAGlljE/1phvR3EtKhpdzdqJ2LTCF0ZWKXOtSH9S0A8Wvt
nyYDllF/a00Y+GlqzFNfZTz0n4W04bcb/+sfJVyNf20nEcgWwjS5pqGi1ZIWs3mVkxcsRiGkB
7xRinu4pFLnLYsNUkO6PdXfnrpTv0J8ZMghLuqH2L2A0ynI6FFS8Hcur/DyfBhEiVEMPLlN6j
AtOIS4yeaogVFeIH
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's kill Bitcoin Core and allow the green
shoots of a garden of new implementations to grow from its fertile ashes
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: Tue, 01 Sep 2015 08:42:53 -0000
Peter this seems to be a not well thought through course of action,
fun though it maybe informally or philosophically or to tweak various
peoples sensibilities.
Bitcoin is a consensus system that does not work if there are
incompatible versions of consensus code competing on the network.
This is why work is underway on libconsensus so we can see diversity
of implementation without the risk of incompatibility arising by
software defect. It has proven quite hard to match independent
consensus implementations bit for bit against an adaptive adversary
looking for inconsistencies in interpretation.
In terms of protocol updates it is more constructive therefore that
people with a technical interest analyse and validate others proposals
via testing, or make their own proposals so that we can arrive at a
well validated upgrade mechanism that everyone upgrades to in a
coordinated fashion.
Previous intentional upgrades to bitcoin have been
backwards-compatible (via soft-fork which can be secured reasonably
using a miner vote trigger and temporary SPV security for those who
not yet upgraded) but the current topic of a throughput increase is
non-backwards-compatible (via a hard-fork), and the way to minimise
risk of such an upgrade is for everyone to try to upgrade well in
advance of an agreed upgrade schedule, and to be all upgrading to the
*same* consensus rule change.
Encouraging nodes or miners to "vote" by running a range of different
consensus rules isnt really constructive I feel - it alarms people who
understand the risks, sets things on a path that have to be fixed
while in flight by obvious implication, and isnt collaborative - so it
risks being a politicising suggestion on what should be a purely
technical topic of choosing the best approach, where it is best to
strive to keep things non-emotive and professional and technically
focussed. Such calls are offending the technical sensibilities of
people who understand the risks.
Anyway lets try to keep things constructive and focus on analysing proposals.
Adam
On 31 August 2015 at 19:16, Peter R via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I agree, s7r, that Bitcoin Core represents the most stable code base. To
> create multiple implementations, other groups would fork Bitcoin Core
> similar to what Bitcoin XT did. We could have:
>
> - Bitcoin-A (XT)
> - Bitcoin-B (Blockstream)
> - Bitcoin-C (promoting BIP100)
> - Bitcoin-D
> - etc.
>
> Innovation from any development group would be freely integrated by any
> other development group, if desired. Of course, each group would have a
> very strong incentive to remain fork-wise compatible with the other
> implementations.
>
> In fact, this just gave me a great idea! Since Wladimir has stated that he
> will not integrate a forking change into Core without Core Dev consensus, I
> suggest we work together to never reach consensus with Bitcoin Core. This
> will provide impetus for new implementations to fork from Core (like XT did)
> and implement whatever scaling solution they deem best. The users will then
> select the winning solution simply based on the code they choose to run.
> The other implementations will then rush to make compatible changes in order
> to keep their dwindling user bases.
>
> This is the decentralized spirit of Bitcoin in action. Creative
> destruction. Consensus formed simply by the code that gets run.
>
> Let's kill Bitcoin Core and allow the green shoots of a garden of new
> implementations to grow from its fertile ashes.
|
