From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6DD5E93D for ; 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 ; 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 In-Reply-To: <55D64806.5060404@mattcorallo.com> Date: Fri, 21 Aug 2015 08:46:26 +0200 Message-Id: References: <55B723EA.7010700@voskuil.org> <55B939CF.1080903@voskuil.org> <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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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 >>> >> > 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 >>>> > 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 >>>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>=20 >>> _______________________________________________ >>> bitcoin-dev mailing list >>> 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
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:



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=92s 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=F3n <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<= br class=3D"">
_______________________________________________bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
<mailto:bitcoin-dev@lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">



= --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--