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
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3DCB694F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2015 00:08:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com
[209.85.220.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A3EBF16E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2015 00:08:21 +0000 (UTC)
Received: by pawq9 with SMTP id q9so13858959paw.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 17:08:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:cc:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=cz/P6byh20989Rx4QmXWIk8NOai4uwG1AVJVL5gX6WY=;
b=ig1IWxOpJT5XYArFTf4zw4Jeq6SDiGS6EWLDeGqf0B1RWkicgmAUkCaJkVeB9pQzU8
MG9gN4tEnJScCsGR8Bpem21lFVaLnXeEChB9XCapeOACtHY2MiC1yWieJuDJ2wsh9El+
O0BRZ1sIFM9u9TwKwGkMum46hfmQ+kgCKxSBAwBHQAmZCBgKMaqFilV1PhftB9tiqw2A
Qdhtq0HiLUoAzrV9rIeqGLCxAsOXANHGmMYWUD9K9J+NNOgVn3B0AZsa1v9hoORwzbC+
JUzs1yMNCd3ZBXBemP1jdA1MhnqTj05JDCnMPQGDY3mwGO5v2tHDvWyaEYXJxUwZgo4p
TICw==
X-Gm-Message-State: ALoCoQnkQS/TtoOFYrbnJ+h2z8oorrxZdBgp1mumoqrCiW4Bwj7496ZkyPv31N6NVoZCl4Kzl8qv
X-Received: by 10.68.253.65 with SMTP id zy1mr420746pbc.159.1440029301427;
Wed, 19 Aug 2015 17:08:21 -0700 (PDT)
Received: from [10.0.1.13] (c-73-225-134-208.hsd1.wa.comcast.net.
[73.225.134.208]) by smtp.googlemail.com with ESMTPSA id
ob4sm2123967pbb.40.2015.08.19.17.08.20
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 19 Aug 2015 17:08:20 -0700 (PDT)
Message-ID: <55D51A7E.9030301@voskuil.org>
Date: Wed, 19 Aug 2015 17:08:30 -0700
From: Eric Voskuil <eric@voskuil.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
References: <CALqxMTFkgGx0FxMiZ77inOZSs_+TQ88Wpj-q-c12COkO9tP4gQ@mail.gmail.com> <CADJgMzv+cKPY9wrAzbk5pgQJS0=R9KWu-+EuppM=nmXs8RHxYg@mail.gmail.com> <20150819182010.GB12306@muck> <CADJgMzskK9iNoRzVr0BtK+XH-x2w5mGZtBiieQpwcGevnHRjGg@mail.gmail.com> <55D4D9C3.5070004@riseup.net> <C47D37EE-AE42-4175-AD6B-F6FD0841287B@gmail.com> <CABm2gDpAOQim63Q7r9r-Pv-K+FqizgDHNUmQ7uheGMuMt-e2QA@mail.gmail.com> <E3D72CF4-3D1C-4235-87F9-A035AFF28C27@gmail.com> <CABm2gDrefdHeYWF2y_o7A9NxRssC=ddHqY--ExxLv00TS4ShKQ@mail.gmail.com> <55D50C15.9020402@voskuil.org>
<CABm2gDpzAL9Rci8m60ruhHeDXx3gvGgPHMbupZKUZA1wys-AiQ@mail.gmail.com>
In-Reply-To: <CABm2gDpzAL9Rci8m60ruhHeDXx3gvGgPHMbupZKUZA1wys-AiQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
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>,
Libbitcoin <libbitcoin@lists.dyne.org>
Subject: Re: [bitcoin-dev] Bitcoin XT Fork
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, 20 Aug 2015 00:08:22 -0000
On 08/19/2015 04:27 PM, Jorge Timón wrote:
> On Thu, Aug 20, 2015 at 1:07 AM, Eric Voskuil <eric@voskuil.org> wrote:
>> [cross-posted to libbitcoin]
>>
>> On 08/19/2015 03:00 PM, Jorge Timón via bitcoin-dev wrote:> On Wed, Aug
>> 19, 2015 at 10:04 PM, Eric Lombrozo <elombrozo@gmail.com> wrote:
>>>> But the consensus code should NOT be subject to the same commit
>> policies…and we should make an effort to separate the two clearly. And
>> we should find a way to communicate the difference succinctly and
>> clearly to laypeople (which is something I think the XT opponents have
>> been horrible at doing so far).
>>>
>>> I think that effort is in progress (again, much slower that I would
>>> like it to be) and it's called libconsensus.
>>> Once we have libconsensus Bitcoin Core it's just another
>>> implementation (even if it is the reference one) and it's not "the
>>> specification of the consensus rules" which is a "privileged" position
>>> that brings all sorts of misunderstandings and problems (the block
>>> size debate is just one example).
>>
>> Jorge,
>>
>> I applaud your efforts and objectives WRT libconsensus independence. But
>> as you know I differ with you on this point:
>>
>>> Once we have libconsensus Bitcoin Core it's just another
>>> implementation
>>
>> I do not consider Bitcoin Core just another implementation as long as
>> libconsensus is built directly out of the bitcoind repository. It's a
>> finer point, but an important one. Eric makes this point emphatically as
>> well:
>>
>>>> But the consensus code should NOT be subject to the same commit
>> policies...and we should make an effort to separate the two clearly.
>>
>> As you have implied, it's not likely to happen in the Bitcoin Core repo.
>> Taking a dependency on Bitcoin Core is a metaphorical deal with the
>> devil from our perspective. So my question is, how do you expect other
>> implementations to transition off of that repository (and commit
>> policies)? Or do you expect the dependency to be perpetual?
>
> No, as previously explained, once libconsensus is complete it can be
> moved to a separate repository like libsecp256k1.
I don't see this happening any time soon, and I'm not sure why we should
wait for it.
> At first it will need to be a subtree/subrepository of Bitcoin Core
> (like libsecp256k1 currently is), but I still don't undesrtand how
> that can possibly be a problem for alternative implementations (they
> can use a subtree as well if they want to). Depending on a separated
> libconsensus doesn't "make Bitcoin Core a dependency" more than
> depending on libsecp256k1 currently does.
>
>> In our discussion leading up to libbitcoin building libbitcoin-consensus
>> we disagreed on whether intentional hard forks would (or even could)
>> happen. I think that issue is now settled. So my question remains how do
>> stakeholders (users/miners) maintain consensus when it's their
>> individual intent (the first objective of libconsensus), and diverge
>> when intended (which a direct dependency on libconsensus makes harder)?
>> IMO it's unreasonable to operate as if this won't happen, given that it has.
>
> I believe the simplest option...
You might consider this as feedback from your customer base.
> would be to fork the libconsensus
> project and do the schism/controversial/contentious hardfork there.
> But of course modifying libconsensus will be much easier than
> modifying Bitcoin Core (if anything, because the amount of code is
> much smaller).
That's a false dichotomy. We never would have considered forking Bitcoin
Core, and still wouldn't. Why would we set ourselves up for this
disruption, which would inevitably lead to us factoring the consensus
portions of libconsensus out of /bitcoin at the 11th hour?
We have to operate as if it can happen at any time. Otherwise we have
relinquished control of this vote and failed our users. Given that
operating assumption, it is much safer for us to have already done this
work (which we did). [It also provides a forcing function for us to
review in detail any consensus changes that get pushed out.]
My question is why you would not embrace an independent consensus
repository? Your work to evolve it doesn't change.
>> There are a very small number of implementations that rely on consensus
>> (fewer that aren't also forks of Bitcoin Core). I think it's time we
>> discuss how to work together to achieve our mutual goal. I assume you
>> have been in contact with all of us. If you would like to facilitate
>> this I'd be happy to join in an offline discussion.
>
> Unfortunately I only directly contacted libbitcoin because I was
> subscribed to the list at the time (maybe I'm still subscribed, not
> really sure).
> The other attempts to get feedback from other alternative
> implementations have been just mostly-ignored threads in bitcoin-dev.
> So, no, I cannot facilitate such a discussion, but I'm more than happy
> to collaborate to achieve our mutual goal.
OK
e
|
