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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 197D48A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2015 21:35:07 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EA58A15D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2015 21:35:05 +0000 (UTC)
Received: from [172.17.0.2] (gw.vpn.bluematt.me [162.243.132.6])
by mail.bluematt.me (Postfix) with ESMTPSA id 52EE957717;
Thu, 20 Aug 2015 21:35:04 +0000 (UTC)
To: Tamas Blummer <tamas@bitsofproof.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>
<CABm2gDr_ePfPeWB8pEO8QNHDjUZpybVuCAdDmMxJxMaC8+2bGA@mail.gmail.com>
<C4EA4A39-1920-4F33-822C-FBD12DF81004@bitsofproof.com>
<CABm2gDqkF20ZoexQSV8iORb3ukxxZr5RasTLxJqQfSTsTqHvog@mail.gmail.com>
<3390F712-879A-46E9-ABCD-D35B51190304@bitsofproof.com>
<55D611FC.6010305@mattcorallo.com>
<9861CA5B-A13D-4CFB-9529-511F93E68A72@bitsofproof.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <55D64806.5060404@mattcorallo.com>
Date: Thu, 20 Aug 2015 21:35:02 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <9861CA5B-A13D-4CFB-9529-511F93E68A72@bitsofproof.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,URIBL_BLACK
autolearn=no 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: Thu, 20 Aug 2015 21:35:07 -0000
On 08/20/15 21:26, Tamas Blummer wrote:
> I know what you mean as I already have such a component with pluggable
> block store and networking.
I'm not suggesting pluggable networking, I'm suggesting (and I think
everyone thinks the design should be) NO networking. The API is
ValidationResult libconsensus.HeyIFoundABlock(Block) and
ListOfBlocksToDownloadNext libconsensus.HeyIFoundAHeaderList(ListOfHeaders).
> While you are at it you could aim for isolation of bitcoin specific
> decisions and algos from generic block chain code.
Are you suggesting to support altcoins? I dont think anyone cares about
supporting that.
> The magnitude of refactoring you would have to do to get there from
> main.cpp and the rest of the hairball
> is harder than a re-write from scratch,
I think you'd be very pleasantly surprised. It sounds like you havent
dug into Bitcoin Core validation code in years.
> and the result will not be
> impressive, just hopefully working.
Hmm? The result would be an obviously correct consensus implementation
that everyone could use, instead of everyone going off and writing their
own and either being wrong, or never updating in the case of forks. Its
a huge deal to allow people to focus on making their libraries have good
APIs/Wallets/etc instead of focusing on making a working validation
engine (though maybe for that the p2p layer needs to also be in a library).
> I think a slim API server was a lower hanging fruit in Core’s case.
We have one, it just needs a few already obvious performance improvements.
> BTW, support for refactoring is an example where you see if your tool
> set is modern.
There are a number of good development tools for C++ that allow this....
> Tamas Blummer
>
>> On Aug 20, 2015, at 19:44, Matt Corallo via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>
>> I dont think a libconsensus would have any kind of networking layer, nor
>> is C++ an antique tool set (hopefully libconsensus can avoid a boost
>> dependency, though thats not antique either). Ideally it would have a
>> simple API to give it blocks and a simple API for it to inform you of
>> what the current chain is. If you really want to get fancy maybe it has
>> pluggable block storage, too, but I dont see why you couldnt use this in
>> ~any client?
>>
>> On 08/20/15 08:35, Tamas Blummer via bitcoin-dev wrote:
>>> Every re-implementation, re-factoring even copy-paste introduces a
>>> risk of disagreement,
>>> but also open the chance of doing the work better, in the sense of
>>> software engineering.
>>>
>>>> On Aug 20, 2015, at 10:06, Jorge Timón <jtimon@jtimon.cc
>>>> <mailto:jtimon@jtimon.cc>> wrote:
>>>>
>>>>
>>>> But the goal is not reimplementing the consensus rules but rather
>>>> extract them from Bitcoin Core so that nobody needs to re-implement
>>>> them again.
>>>
>>>
>>>
>>> My goal is different. Compatibility with Bitcoin is important as I
>>> also want to deal with Bitcoins,
>>> but it is also imperative to be able to create and serve other block
>>> chains with other rules and for those
>>> I do not want to carry on the legacy of an antique tool set and a
>>> spaghetti style.
>>>
>>> Bits of Proof uses scala (akka networking), java (api service), c++
>>> (leveledb and now libconsensus)
>>> and I am eager to integrate secp256k1 (c) as soon as part of
>>> consensus. The choices were
>>> made because each piece appears best in what they do.
>>>
>>> Tamas Blummer
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
|
