Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 84D9B68 for ; Thu, 20 Aug 2015 07:14:17 +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 8FCBE13D for ; Thu, 20 Aug 2015 07:14:16 +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 1ZSK3B-0008PG-BZ; Thu, 20 Aug 2015 09:14:13 +0200 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_AF6D2BB3-3AF5-48B4-9A48-9D5B783E17FF"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.1 From: Tamas Blummer In-Reply-To: Date: Thu, 20 Aug 2015 09:14:11 +0200 Message-Id: References: <55B723EA.7010700@voskuil.org> <55B939CF.1080903@voskuil.org> To: =?utf-8?Q?Jorge_Tim=C3=B3n?= X-Mailer: Apple Mail (2.2102) X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1440054856; c6d5fa2e; X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev , Libbitcoin 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 07:14:17 -0000 --Apple-Mail=_AF6D2BB3-3AF5-48B4-9A48-9D5B783E17FF Content-Type: multipart/alternative; boundary="Apple-Mail=_CBC7B358-3364-4D7C-B79C-EF348AA6D2AA" --Apple-Mail=_CBC7B358-3364-4D7C-B79C-EF348AA6D2AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jorge, separating script engine into libconsensus was very helpful, since = wrapped the piece of consensus that would least likely to be captured exactly with an implementation = from scratch. Thank you for your effort there. Bits of Proof now uses its own or alternatively = libconsensus for full validation. I am sceptical however that a =E2=80=9Cfull=E2=80=9D consensus lib = extracted from satoshi=E2=80=99s code is worth trying. Not because it was impossible, but because the result would not be = higher quality, if measured on agreement with satoshi, than other re-implementations. It would actually be lower = quality because of the antique tool set. The rules outside script engine are simpler, therefore much easier to = capture exactly. They are however scattered around in the spaghetti and are often just a single if = statement, also repeated elsewhere. You would either have to very extensively refactor the code, that = unlikely goes through as a PR, or do what me and others did. Read satoshi code and rewrite the same. You = have a slight advantage of copy-paste small fragments, but I doubt the = consensus relevant advantage of that. Tamas Blummer > On Aug 20, 2015, at 02:53, Jorge Tim=C3=B3n via bitcoin-dev = wrote: >=20 >=20 > 1) Finish the libconsensus separation in an independent branch on top > of a given version, for example 0.11. > 2) Separate a repository from that. Alternative implementations can > start using a full libconsensus > 3) Rebase that branch on top of bitcoin/master and start to PR small > groups of commits. Once the whole branch has been merged, Bitcoin Core > can replace the consensus folder with the libconsensus subtree, so > that Bitcoin Core itself can start using a full libconsensus. >=20 > Ironically with this plan Bitcoin Core may not be the full node first > implementation to use a full libconsensus. > There will be some consensus fork bug risks during 3 (which at the > current speed I estimate it could easily take 3 or 4 years) and there > would be some redundant work (replicating every consensus change in > both Bitcoin Core and libconsensus). > On the bright side, we may be able to have a full libconsensus this > year (which was my goal after we exposed VerifyScript in the first > libconsensus). >=20 > Thoughts? > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_CBC7B358-3364-4D7C-B79C-EF348AA6D2AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Jorge,

separating script engine into = libconsensus was very helpful, since wrapped the piece of = consensus
that would least likely to be captured = exactly with an implementation from scratch. Thank you for = your
effort there.  Bits of Proof now uses its = own or alternatively libconsensus for full validation.

I am sceptical however = that a =E2=80=9Cfull=E2=80=9D consensus lib extracted from satoshi=E2=80=99= s code is worth trying. 
Not because it was = impossible, but because the result would not be higher quality, if = measured on agreement
with satoshi, than other = re-implementations. It would actually be lower quality because of the = antique tool set.

The rules outside script engine are simpler, therefore much = easier to capture exactly. They are however 
scattered around in the spaghetti and are often just a single = if statement, also repeated elsewhere.

You would either have to very = extensively refactor the code, that unlikely goes through as a PR, = or
do what me and others did. Read satoshi code and = rewrite the same. You have 
a slight advantage = of copy-paste small fragments, but I doubt the consensus relevant = advantage of that.

Tamas Blummer

On Aug 20, 2015, at 02:53, Jorge Tim=C3=B3n via bitcoin-dev = <bitcoin-dev@lists.linuxfoundation.org> wrote:


1) = Finish the libconsensus separation in an independent branch on top
of a given version, for example 0.11.
2) = Separate a repository from that. Alternative implementations can
start using a full libconsensus
3) Rebase that = branch on top of bitcoin/master and start to PR small
groups= of commits. Once the whole branch has been merged, Bitcoin Core
can replace the consensus folder with the libconsensus = subtree, so
that Bitcoin Core itself can start using a = full libconsensus.

Ironically with this = plan Bitcoin Core may not be the full node first
implementation to use a full libconsensus.
There = will be some consensus fork bug risks during 3 (which at the
current speed I estimate it could easily take 3 or 4 years) = and there
would be some redundant work (replicating every = consensus change in
both Bitcoin Core and = libconsensus).
On the bright side, we may be able to have = a full libconsensus this
year (which was my goal after we = exposed VerifyScript in the first
libconsensus).

Thoughts?
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">

= --Apple-Mail=_CBC7B358-3364-4D7C-B79C-EF348AA6D2AA-- --Apple-Mail=_AF6D2BB3-3AF5-48B4-9A48-9D5B783E17FF 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 iQEcBAEBCgAGBQJV1X5EAAoJEPZykcUXcTkc+VcIALmj+HHHJl1xED999/LCEB8W +P7bA/nuBWbPLwps44Ai2fpn1QMjBJadDTq3PGlBW9RtB6ijKr2vmvleKdvfteI6 YZdWIykccqeuqluQgQidFyHXwj4IQrECbt8/ELRO6VoLkv2V36vhceJBdpWPCaZc C93q+OsTch64TRXypAtI7Rh0K0w+bN+beExLsarzvAQ8HqQA3zZqK/332w1ELu3p 7oz/C/Od82S/pP6nZVWuQ1cAVExxN0IXs4lVAvYfTAAX7y3ktHUG+f7Mey7/LgNM U59Pm51UyMSPmUe0gPPpC//lq8PEAtLu/u4tlxBrfQ1PvYtz2WPfY1r0/ydYhPM= =D0EJ -----END PGP SIGNATURE----- --Apple-Mail=_AF6D2BB3-3AF5-48B4-9A48-9D5B783E17FF--