path: root/8c/4e76f26913fa7e04826e42a8b94d7acebd99b7

Return-Path: <tamas@bitsofproof.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6DD5E93D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 21 Aug 2015 06:46:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from wp059.webpack.hosteurope.de (wp059.webpack.hosteurope.de
	[80.237.132.66])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 50669AB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 21 Aug 2015 06:46:29 +0000 (UTC)
Received: from [37.143.74.116] (helo=[192.168.2.15]); authenticated
	by wp059.webpack.hosteurope.de running ExIM with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	id 1ZSg5r-0001En-5Y; Fri, 21 Aug 2015 08:46:27 +0200
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_63F06019-9190-46A2-A187-C47590462D2C";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.1
From: Tamas Blummer <tamas@bitsofproof.com>
In-Reply-To: <55D64806.5060404@mattcorallo.com>
Date: Fri, 21 Aug 2015 08:46:26 +0200
Message-Id: <DE81C494-FB9F-49FA-9281-BF274345E411@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>
	<55D64806.5060404@mattcorallo.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
X-Mailer: Apple Mail (2.2102)
X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1440139589;
	d0609c06; 
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW,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: Fri, 21 Aug 2015 06:46:31 -0000


--Apple-Mail=_63F06019-9190-46A2-A187-C47590462D2C
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_7D9F8C56-3DA5-49E0-9495-2B15FDF727FA"


--Apple-Mail=_7D9F8C56-3DA5-49E0-9495-2B15FDF727FA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Thinking in Bitcoins only on the level of technology unnecessarily =
narrows your view.

OK, I hope to be pleasantly surprised.

Tamas Blummer

> On Aug 20, 2015, at 23:35, Matt Corallo <lf-lists@mattcorallo.com> =
wrote:
>=20
>=20
>=20
> 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.
>=20
> 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).
>=20
>> While you are at it you could aim for isolation of bitcoin specific
>> decisions and algos from generic block chain code.
>=20
> Are you suggesting to support altcoins? I dont think anyone cares =
about
> supporting that.
>=20
>> 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,
>=20
> I think you'd be very pleasantly surprised. It sounds like you havent
> dug into Bitcoin Core validation code in years.
>=20
>> and the result will not be
>> impressive, just hopefully working.
>=20
> 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).
>=20
>> I think a slim API server was a lower hanging fruit in Core=92s case.
>=20
> We have one, it just needs a few already obvious performance =
improvements.
>=20
>> BTW, support for refactoring is an example where you see if your tool
>> set is modern.
>=20
> There are a number of good development tools for C++ that allow =
this....
>=20
>> Tamas Blummer
>>=20
>>> On Aug 20, 2015, at 19:44, Matt Corallo via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org
>>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>>=20
>>> 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?
>>>=20
>>> 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.
>>>>=20
>>>>> On Aug 20, 2015, at 10:06, Jorge Tim=F3n <jtimon@jtimon.cc
>>>>> <mailto:jtimon@jtimon.cc>> wrote:
>>>>>=20
>>>>>=20
>>>>> 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.
>>>>=20
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> Tamas Blummer
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>=20
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>=20
>>=20
>=20


--Apple-Mail=_7D9F8C56-3DA5-49E0-9495-2B15FDF727FA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D"">Thinking in Bitcoins only on the level of =
technology unnecessarily narrows your view.</div><div class=3D""><br =
class=3D""></div><div class=3D"">OK, I hope to be pleasantly =
surprised.</div><br class=3D""><div apple-content-edited=3D"true" =
class=3D"">
<div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" =
class=3D"">Tamas Blummer</div><div style=3D"color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;" class=3D""><br =
class=3D""></div></div><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Aug 20, 2015, at 23:35, Matt Corallo &lt;<a =
href=3D"mailto:lf-lists@mattcorallo.com" =
class=3D"">lf-lists@mattcorallo.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><br class=3D""><br =
class=3D"">On 08/20/15 21:26, Tamas Blummer wrote:<br =
class=3D""><blockquote type=3D"cite" class=3D"">I know what you mean as =
I already have such a component with pluggable<br class=3D"">block store =
and networking.<br class=3D""></blockquote><br class=3D"">I'm not =
suggesting pluggable networking, I'm suggesting (and I think<br =
class=3D"">everyone thinks the design should be) NO networking. The API =
is<br class=3D"">ValidationResult libconsensus.HeyIFoundABlock(Block) =
and<br class=3D"">ListOfBlocksToDownloadNext =
libconsensus.HeyIFoundAHeaderList(ListOfHeaders).<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">While you are at it you =
could aim for isolation of bitcoin specific<br class=3D"">decisions and =
algos from generic block chain code. <br class=3D""></blockquote><br =
class=3D"">Are you suggesting to support altcoins? I dont think anyone =
cares about<br class=3D"">supporting that.<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">The magnitude of =
refactoring you would have to do to get there from<br class=3D"">main.cpp =
and the rest of the hairball<br class=3D"">is harder than a re-write =
from scratch,<br class=3D""></blockquote><br class=3D"">I think you'd be =
very pleasantly surprised. It sounds like you havent<br class=3D"">dug =
into Bitcoin Core validation code in years.<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">and the result will not =
be<br class=3D"">impressive, just hopefully working.<br =
class=3D""></blockquote><br class=3D"">Hmm? The result would be an =
obviously correct consensus implementation<br class=3D"">that everyone =
could use, instead of everyone going off and writing their<br =
class=3D"">own and either being wrong, or never updating in the case of =
forks. Its<br class=3D"">a huge deal to allow people to focus on making =
their libraries have good<br class=3D"">APIs/Wallets/etc instead of =
focusing on making a working validation<br class=3D"">engine (though =
maybe for that the p2p layer needs to also be in a library).<br =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">I think a =
slim API server was a lower hanging fruit in Core=92s case.<br =
class=3D""></blockquote><br class=3D"">We have one, it just needs a few =
already obvious performance improvements.<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">BTW, support for =
refactoring is an example where you see if your tool<br class=3D"">set =
is modern.<br class=3D""></blockquote><br class=3D"">There are a number =
of good development tools for C++ that allow this....<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">Tamas Blummer<br =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">On Aug =
20, 2015, at 19:44, Matt Corallo via bitcoin-dev<br class=3D"">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">mailto:bitcoin-dev@lists.linuxfoundation.org</a>&gt;&gt; =
wrote:<br class=3D""><br class=3D"">I dont think a libconsensus would =
have any kind of networking layer, nor<br class=3D"">is C++ an antique =
tool set (hopefully libconsensus can avoid a boost<br =
class=3D"">dependency, though thats not antique either). Ideally it =
would have a<br class=3D"">simple API to give it blocks and a simple API =
for it to inform you of<br class=3D"">what the current chain is. If you =
really want to get fancy maybe it has<br class=3D"">pluggable block =
storage, too, but I dont see why you couldnt use this in<br =
class=3D"">~any client?<br class=3D""><br class=3D"">On 08/20/15 08:35, =
Tamas Blummer via bitcoin-dev wrote:<br class=3D""><blockquote =
type=3D"cite" class=3D"">Every re-implementation, re-factoring even =
copy-paste introduces a<br class=3D"">risk of disagreement,<br =
class=3D"">but also open the chance of doing the work better, in the =
sense of<br class=3D"">software engineering.<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">On Aug 20, 2015, at =
10:06, Jorge Tim=F3n &lt;<a href=3D"mailto:jtimon@jtimon.cc" =
class=3D"">jtimon@jtimon.cc</a><br class=3D"">&lt;<a =
href=3D"mailto:jtimon@jtimon.cc" =
class=3D"">mailto:jtimon@jtimon.cc</a>&gt;&gt; wrote:<br class=3D""><br =
class=3D""><br class=3D"">But the goal is not reimplementing the =
consensus rules but rather<br class=3D"">extract them from Bitcoin Core =
so that nobody needs to re-implement<br class=3D"">them again.<br =
class=3D""></blockquote><br class=3D""><br class=3D""><br class=3D"">My =
goal is different. Compatibility with Bitcoin is important as I<br =
class=3D"">also want to deal with Bitcoins,<br class=3D"">but it is also =
imperative to be able to create and serve other block<br class=3D"">chains=
 with other rules and for those<br class=3D"">I do not want to carry on =
the legacy of an antique tool set and a<br class=3D"">spaghetti =
style.<br class=3D""><br class=3D"">Bits of Proof uses scala (akka =
networking), java (api service), c++<br class=3D"">(leveledb and now =
libconsensus)<br class=3D"">and I am eager to integrate secp256k1 (c) as =
soon as part of<br class=3D"">consensus. The choices were<br =
class=3D"">made because each piece appears best in what they do.<br =
class=3D""><br class=3D"">Tamas Blummer<br class=3D""><br class=3D""><br =
class=3D""><br =
class=3D"">_______________________________________________<br =
class=3D"">bitcoin-dev mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">&lt;mailto:bitcoin-dev@lists.linuxfoundation.org&gt;<br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""><br =
class=3D""></blockquote>_______________________________________________<br=
 class=3D"">bitcoin-dev mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">&lt;mailto:bitcoin-dev@lists.linuxfoundation.org&gt;<br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""><br class=3D""></blockquote><br class=3D""></blockquote><br =
class=3D""></div></blockquote></div><br class=3D""></body></html>=

--Apple-Mail=_7D9F8C56-3DA5-49E0-9495-2B15FDF727FA--

--Apple-Mail=_63F06019-9190-46A2-A187-C47590462D2C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJV1slCAAoJEPZykcUXcTkcWvoH/2jhd3cl5Y6IQ6Y5np1z8wqE
1/8Lxs4tVgzegJa+LYkUGy0rr89ZD3tTBwRD5OvnHh8XoLcgz3jPgGdXX2Gr16OO
RJ4IZ2xmP7+iEf78fRPANfh7YXkrPJxYiaxPG5B80GNVQvTorwAOvQXyRiaG1ZFb
tYPulG+cXSNVYsa9ii7vR1cc2Jls9V6nifYbbZ00fGfaSsSsiux7j1RFss0XwBm1
rUFpNHoS63C22AMKkxkVbItJr91slD0XyAOp+8MuG8vtK5hCOmwCIck+zuSYA51H
zf/wF0CbWdnCtJEA0P7c6+OpZPA3P8I/tHgIyMN1YFU+vr9OnqrutWI+nnphqAA=
=2nxX
-----END PGP SIGNATURE-----

--Apple-Mail=_63F06019-9190-46A2-A187-C47590462D2C--