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
|
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 0476725A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jul 2015 10:09:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com
[209.85.212.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 567BC15A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jul 2015 10:09:24 +0000 (UTC)
Received: by wibxm9 with SMTP id xm9so153119643wib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jul 2015 03:09:23 -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=SB3103B6DlUwEJhImQCUs2V4BqzUv/cryAfRStEGaRQ=;
b=lfYAQgSqDMGv5vjVXKVWM+rR6LOBIkd+BtekPxpyYfD4w4nUfVqS1BiMthQdWZ5knK
uTi0ogilU5GmE93O16QlNvAnAFTAUSTuxt91ET5DIhyMBvZC85AbjFDHXUOyiusLhDMm
FTt/vTB8H9eZvK7oH5LHQDS4yQwf+yXeui6SSRZJCn+R46tNGc4rpOaOPa6BwJTXoilo
2GZdto5gouRHSYcoQy+z3HSrGdL+GeKax0nlstRgbS5xdRShXX96T8YAheTE+1Vzeadl
dy9Ksyb1kPVwql6ck4k1ZoaVvBOUzeS8EsTjhYnKHbhC8eyONDWiPnKufetT/wCkfrUV
cMPw==
X-Gm-Message-State: ALoCoQno8wUf/PR4Fykl8W84JlpV9gT8jmA328HQJi8NCQtwvX/eQm1DjSFRwr5095MzRAl5Vj7S
MIME-Version: 1.0
X-Received: by 10.194.58.7 with SMTP id m7mr61652297wjq.109.1438078162921;
Tue, 28 Jul 2015 03:09:22 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Tue, 28 Jul 2015 03:09:22 -0700 (PDT)
In-Reply-To: <20150728084312.GA29453@amethyst.visucore.com>
References: <CABm2gDrApVuxF8DFf32V=pQhDKvvVfcDK=LeCXJ9h9o8CY+wNQ@mail.gmail.com>
<20150728084312.GA29453@amethyst.visucore.com>
Date: Tue, 28 Jul 2015 12:09:22 +0200
Message-ID: <CABm2gDo-ziQLpDiFbmkYjMcsFJ2EVXe1hMOjm0gXQiRxp-K78Q@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: "Wladimir J. van der Laan" <laanwj@gmail.com>
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@lists.linuxfoundation.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: Tue, 28 Jul 2015 10:09:25 -0000
On Tue, Jul 28, 2015 at 10:43 AM, Wladimir J. van der Laan
<laanwj@gmail.com> wrote:
> On Thu, Jul 23, 2015 at 04:30:06PM +0200, Jorge Tim=C3=B3n via bitcoin-de=
v wrote:
>> But I thought you also wanted Bitcoin Core to use libconsensus instead
>> of just having a subtree/subrepository like it currently does with
>> libsecp256k1.
>> I'm not sure if that would ever be accepted, but in any case we're
>> certainly far away from that goal. Here are some things that need to
>> happen first:
>
> I don't see any reason why Bitcoin Core would not use the consensus libra=
ry. Eating our own dogfood and such.
As explained to Eric, it's not that I don't want Bitcoin Core to use
future-libconsensu through the API instead of a subtree: it's just
that that's more long-term and more work. And I don't see why other
implementations should really care about it.
> Biggest risk, as I've said before, is that the refactoring loading to a (=
more complete) consensus library will result in code that is no longer bug-=
for-bug compatible with previous versions, thus defeating its entire purpos=
e and introducing fork risk.
>
> If that can be avoided - for example by going from here to there using pu=
re code moves, as you're trying to do - I'm all for it.
Well, pure movements will not be enough, parameters will have to
change, incompatible dependencies have to be removed (ie util.h which
contains globals), etc.
But yes, I think we can do it with only low-risk and easy-to-review commits=
.
>> 3) Move libconsensus to a separate repository as a
>> subtree/subrepository of Bitcoin Core.
>
> If the rest is done, this is the easy part :)
And still, this doesn't require Bitcoin Core to use the API, a subtree
is enough at first.
This "easy step" doesn't guarantee that Bitcoin Core is using
future-libconsensus' API.
> Code review capacity is still our greatest bottleneck.
> And I don't see any way out of that, unfortunately.
I really think these code separations help with this (ie there are
many more people in the world with enough knowledge to review the qt
or even policy parts than there's people able to review consensus
changes).
> I do really care about this.
I know and I said so.
|
