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 0EC78826 for ; Thu, 20 Aug 2015 21:26:25 +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 BD95619D for ; Thu, 20 Aug 2015 21:26:23 +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 1ZSXLp-0001Nh-JK; Thu, 20 Aug 2015 23:26:21 +0200 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_407FE1A1-EB42-4EBB-B0AD-E89A96BF57C5"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.1 From: Tamas Blummer In-Reply-To: <55D611FC.6010305@mattcorallo.com> Date: Thu, 20 Aug 2015 23:26:19 +0200 Message-Id: <9861CA5B-A13D-4CFB-9529-511F93E68A72@bitsofproof.com> References: <55B723EA.7010700@voskuil.org> <55B939CF.1080903@voskuil.org> <3390F712-879A-46E9-ABCD-D35B51190304@bitsofproof.com> <55D611FC.6010305@mattcorallo.com> To: Matt Corallo X-Mailer: Apple Mail (2.2102) X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1440105983; 064818b8; 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: Thu, 20 Aug 2015 21:26:25 -0000 --Apple-Mail=_407FE1A1-EB42-4EBB-B0AD-E89A96BF57C5 Content-Type: multipart/alternative; boundary="Apple-Mail=_8749E4FB-6C14-4E9D-9175-56691217DCCC" --Apple-Mail=_8749E4FB-6C14-4E9D-9175-56691217DCCC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I know what you mean as I already have such a component with pluggable = block store and networking. While you are at it you could aim for isolation of bitcoin specific = decisions and algos from generic block chain code. 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, and the result will not be = impressive, just hopefully working. I think a slim API server was a lower hanging fruit in Core=92s case. BTW, support for refactoring is an example where you see if your tool = set is modern. Tamas Blummer > 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 --Apple-Mail=_8749E4FB-6C14-4E9D-9175-56691217DCCC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I know what you mean as I already have such a = component with pluggable block store and networking.
While you are at it you could aim for isolation of bitcoin = specific decisions and algos from generic block chain = code. 

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, and the result will not be impressive, just = hopefully working.
I think a slim API server was a = lower hanging fruit in Core=92s case.

BTW, support for refactoring is an = example where you see if your tool set is modern.
Tamas Blummer

On Aug 20, 2015, at 19:44, Matt Corallo via bitcoin-dev = <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> = 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">
_______________________________________________bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">

= --Apple-Mail=_8749E4FB-6C14-4E9D-9175-56691217DCCC-- --Apple-Mail=_407FE1A1-EB42-4EBB-B0AD-E89A96BF57C5 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 iQEcBAEBCgAGBQJV1kX8AAoJEPZykcUXcTkcr5EH/2U0oDgzCzCLeRSp5x1T73/t b+JFxl/Ae7cNoS+6voi2PV6gJROj7DIVsnrzfpfS5Ktv8tC1BAW/OHxKoXHfq2rM 9wNnBy2KcMyZx55BpwWZ9cwzjMgRCe6ot+mXQW/ynWjwkrYScAZIu0aofEZFgkjv fiW0BSoQrxeEI7n8sbPujky2Bx2/FGM4yymW8K+ycLn/z1pWGV6TTlvzx/D5buHi HYXivA1585T2WizqLb535XcwJne7MEyrhH3jSaewbRcYcsuhvpym17Vvd6nySrBu ZsV9TmtOgoLRKHy7PsMxPCkdgyUk4T5kaA/1q1LY3RNVrjILi17WNdM2+4a1+J8= =aGDB -----END PGP SIGNATURE----- --Apple-Mail=_407FE1A1-EB42-4EBB-B0AD-E89A96BF57C5--