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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D142F8D7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2015 00:53:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com
[209.85.217.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 88E0F153
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2015 00:53:47 +0000 (UTC)
Received: by lbbtg9 with SMTP id tg9so14070926lbb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 17:53:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=mCAQUyjmqoqBaK4xOQMEdFqdJSltSFcJbHUnGv8lwOk=;
b=bF0ujfOYc5Qidh5TkwPvmzMjRbuE9ucx4ppA1FJfsldVGkmZr/4hCmGBI4FyI9Dj+6
JMTJFmhrb5dkJwNr7uyUtb4H1punA/USd1egYUg+ovw1v9EtqyWSs0joTS6L5XDJLx2K
4qFT3K3phtJMstQMlGZB5QUdRPuyq0XR2QefeRr1BwD3VftEi+OIvLZXG+bmuFAHfhXQ
nvtY3dCaZNGdSBws2kaBD75uqWubbxSX5XO66RJyGdbSgfnEEmETgWadU5cIbc+ei324
Z2JQyllS8/MTIso/y7jxQp+UtCHCv0poFt97hpr7UQmMwHxUpRDXSzXVlq3NtW6eXRon
YEEw==
X-Gm-Message-State: ALoCoQnbTyZ6bz3Ci6lPdjG8JeMIxgE6cqbCytvhyg6mzcx8a+Bh+10nBCdjuCRRvnfMQgaWfN99
MIME-Version: 1.0
X-Received: by 10.152.37.196 with SMTP id a4mr351735lak.59.1440032025498; Wed,
19 Aug 2015 17:53:45 -0700 (PDT)
Received: by 10.25.15.22 with HTTP; Wed, 19 Aug 2015 17:53:45 -0700 (PDT)
In-Reply-To: <CABm2gDq1wHP01Tncw3hu=SCWQHaAOMjWOVYQWdQsOZ+E7zp9Yw@mail.gmail.com>
References: <CABm2gDrApVuxF8DFf32V=pQhDKvvVfcDK=LeCXJ9h9o8CY+wNQ@mail.gmail.com>
<55B723EA.7010700@voskuil.org>
<CABm2gDok2gH2R8=x3a8PmPiM56WFg3TKzCum_WS=uV9-T1Ss3g@mail.gmail.com>
<55B939CF.1080903@voskuil.org>
<CABm2gDq1wHP01Tncw3hu=SCWQHaAOMjWOVYQWdQsOZ+E7zp9Yw@mail.gmail.com>
Date: Thu, 20 Aug 2015 02:53:45 +0200
Message-ID: <CABm2gDr_ePfPeWB8pEO8QNHDjUZpybVuCAdDmMxJxMaC8+2bGA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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] Libconsensus separated repository (was 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, 20 Aug 2015 00:53:48 -0000
Moving it here from the other thread.
On Thu, Aug 20, 2015 at 2:08 AM, Eric Voskuil <eric@voskuil.org> wrote:
> On 08/19/2015 04:27 PM, Jorge Tim=C3=B3n wrote:
>> 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.
Yes, unfortunately I don't see this happening any time soon either, at
least not with the amount of review I'm getting.
My initial hope was to complete libconsensus by 0.12 (one year should
be enough time, right?) but I was being too optimistic.
By "wait for it" I assume you mean waiting for libconsensus to be
complete before we separate it to a different repository.
The reason is just simplicity.
>>> In our discussion leading up to libbitcoin building libbitcoin-consensu=
s
>>> we disagreed on whether intentional hard forks would (or even could)
>>> happen. I think that issue is now settled. So my question remains how d=
o
>>> 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.
Mhmm, not sure I understand this point.
>> 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.]
Yes, you need to operate as if it can happen at any time. I now
understandbetter your position of having your own repository until a
complete libconsensus is separated.
In the meantime you will have to keep using your re-implementation of
the rest of the consensus rules (besides the script checks), but
fortunately the most risky and harder reimplementation is the part of
the script validation.
> My question is why you would not embrace an independent consensus
> repository? Your work to evolve it doesn't change.
Yes, I want a separated repository. I just wanted to start with a
separated folder first. Right now there's consensus code all over the
place, specially in main.cpp.
I think changing the order (separated repository first, moving code
from Bitcoin Core to libconsensus later) would increase the total
amount of work.
Here's another option that has recently crossed my mind:
1) Finish the libconsensus separation in an independent branch on top
of a given version, for example 0.11.
2) Separate a repository from that. Alternative implementations can
start using a full libconsensus
3) Rebase that branch on top of bitcoin/master and start to PR small
groups of commits. Once the whole branch has been merged, Bitcoin Core
can replace the consensus folder with the libconsensus subtree, so
that Bitcoin Core itself can start using a full libconsensus.
Ironically with this plan Bitcoin Core may not be the full node first
implementation to use a full libconsensus.
There will be some consensus fork bug risks during 3 (which at the
current speed I estimate it could easily take 3 or 4 years) and there
would be some redundant work (replicating every consensus change in
both Bitcoin Core and libconsensus).
On the bright side, we may be able to have a full libconsensus this
year (which was my goal after we exposed VerifyScript in the first
libconsensus).
Thoughts?
|
