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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1YMjH0-0007Dp-6t
for bitcoin-development@lists.sourceforge.net;
Sat, 14 Feb 2015 20:25:06 +0000
Received: from mail-wi0-f173.google.com ([209.85.212.173])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YMjGy-0005Wp-A7
for bitcoin-development@lists.sourceforge.net;
Sat, 14 Feb 2015 20:25:06 +0000
Received: by mail-wi0-f173.google.com with SMTP id bs8so18748377wib.0
for <bitcoin-development@lists.sourceforge.net>;
Sat, 14 Feb 2015 12:24:58 -0800 (PST)
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=XN2eDQVwtJX4vReBMpk7TDCJtwJVn5h7mGgvLwNJvuk=;
b=E0Kxt+u8DKhnf0+uIb5DC5SyElCXNJq+i6nWR7RIf2rFlJsikaj+yeuNXewPAkUQgI
0zPjFBaQjRDMxCmHMyLy8YT9vnL4PZ8aFtah5JHFlTs/01DTFaE/Wlh/RqRLZlJkiF+A
p627g2ImGzAe/w2XsuvrsrQP8vfIiF9lCB8uv/AqY5KFP6iiXJzVrglqk+yGLUJTyo/A
SOWhkPc+VarRrm2vL+Dt6DzGlXkZGj+FY1Irikl+hmMpcHQ1O8WR473EQ+oPv+DUxzGj
lInmUXVMyt77O0JUGXGSv+rUViTxr0nhfIoLF6PeUYAJY4JnglIVLNCwOiZWnvbM33ra
hbdQ==
X-Gm-Message-State: ALoCoQl9DM0F0aZyb1sA82GSuaQCQ+EGsf2KI/Sx+eyF5RdvhDWxk09EgOKOaOI0raBvPtHsu64m
MIME-Version: 1.0
X-Received: by 10.180.104.34 with SMTP id gb2mr29998397wib.7.1423944051608;
Sat, 14 Feb 2015 12:00:51 -0800 (PST)
Received: by 10.194.133.74 with HTTP; Sat, 14 Feb 2015 12:00:51 -0800 (PST)
X-Originating-IP: [12.203.200.220]
In-Reply-To: <3D4F2E23-CADE-4FE7-B960-3F79815E868C@bitsofproof.com>
References: <CABm2gDpReRty6TdfMDssjF27XgC_SYs_U__SFBNdsYW24Mzh8w@mail.gmail.com>
<54CC0E1D.7030409@voskuil.org>
<CABm2gDqM6q24tPEBKSHbbVQu-mvfV37PNc4hD=VjyRHk2jujZw@mail.gmail.com>
<54D0414F.6030806@voskuil.org>
<CABm2gDo_sYjNWU6EEsKmOXt5uUu87Lj1oFzqio79MxSx2SYrNg@mail.gmail.com>
<54DE7601.4070509@voskuil.org>
<CABm2gDpt60B=Sf_2X9xt4fPH7x4fff7K4h36XfosHigV5tP+4Q@mail.gmail.com>
<54DF07A5.1060004@voskuil.org>
<CABm2gDoS+XOR7Ugt91kNWNdvwsb1_Zb-aO0sma_Xps2Sx-0N5g@mail.gmail.com>
<54DF2E80.5060506@voskuil.org>
<20150214131320.GA26731@savin.petertodd.org>
<3D4F2E23-CADE-4FE7-B960-3F79815E868C@bitsofproof.com>
Date: Sat, 14 Feb 2015 21:00:51 +0100
Message-ID: <CABm2gDrFYyXX3B0=qj=Wdb8MDBAZEgWqs6zhTTSw6qbWWW9WPw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Tamas Blummer <tamas@bitsofproof.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1YMjGy-0005Wp-A7
Cc: "libbitcoin@lists.dyne.org" <libbitcoin@lists.dyne.org>,
Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] On Rewriting Bitcoin (was Re:
[Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 14 Feb 2015 20:25:06 -0000
On Sat, Feb 14, 2015 at 3:23 PM, Tamas Blummer <tamas@bitsofproof.com> wrot=
e:
> Peter,
> We have seen that the consensus critical code practically extends to Berk=
ley
> DB limits or OpenSSL laxness, therefore
> it is inconceivable that a consensus library is not the same as Bitcoin
> Core, less its P2P service rules, wallet and RPC server.
Right now libconsensus' only dependency is openSSL. Most of the
testing in libsecp256k1 has been in signing rather than verifying
signatures (please, anyone with more knowledge in the library don't
hesitate to correct me or clarify things). But eventually openSSL will
be completely replaced by libsecp256k1.
It does not store anything, 0.1 is just a dynamic library with a c API
to a single function: VerifyScript().
This function saves the hassle of reimplementing signature checking
(which is a really hard part) and reimplementing an interpreter that
must function in exactly the same way in many as many other nodes with
different software and/or hardware.
Guido van Rossum can say "some behaviours in python the language are
not specified, so it is ok if cpython and pypy do different things,
they're still both running python which is more abstract than any of
its implementation".
But a consensus system like bitcoin doesn't have the luxury of leaving
consensus rules unspecified. And the simplest way to fully specify a
language interpreter is by implementing it.
But coupling the consensus rules specification with a bigger project
like bitcoin core can result in implementation details of that bigger
project accidentally and unexpectedly becoming consensus rules. This
is what happened with bdb and nobody wants that to happen again,
that's the whole point.
Note that many parts of the bitcoin protocol (like the p2p messages)
are NOT part of the consensus rules.
You can have a look at
https://github.com/jtimon/bitcoin/commits/consensus2 and maybe you
would be surprised about how small they actually are. This branch is
incomplete and still a mess that needs to be cleaned up. And none of
that is included in libconsensus yet.
I was planning on writing a post here asking for feedback on the
interfaces for these higher level checks. I'm just putting the code
together in the same module, but obviously class CCoinsViewCache
cannot be an argument in functions of a c API.
> The Core code base is unfriendly to feature extensions because of its
> criticality, legacy design and ancient technology. It is also a commodity
> that the ecosystem takes for granted and free.
>
> I honestly admire the core team that works and progresses within these
> limits and perception.
>
> I am not willing to work within the core=E2=80=99s legacy technology limi=
ts. Does it
> mean I am dicking around? I think not.
> It was my way to go down the rabbit hole by re-digging it and I created
> successful commercial products on the way.
Nobody is attacking alternative implementations. This tool was created
mostly with alternative implementations in mind.
So input from them it's very welcomed on how to continue libconsensus
(or of course correct any flaws in verifyScript if there's any).
I just wanted to wait to have some more code to make things easier to
explain (and have a clearer idea of it myself).
There's a more limited branch on "next steps for libconsensus" in #5669.
> It is entirely rational for me to focus on innovation that uses the core =
as
> a border router for this block chain.
Sure, I think he is complaining that at the moment that's probably the
only safe way to operate with alternative implementations and still
have full node guarantees.
> I am rather thankful for the ideas of the side chains, that enable
> innovation that is no longer measured on unapologetic compatibility with =
a
> given code base, but its services to end user.
Sidechains are completely orthogonal to this discussion and, in fact,
it would be good to have libconsensuses for sidechains too, since
their nodes also need to come to consensus.
|
