public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tamas Blummer <tamas@bitsofproof.com>
To: "Jorge Timón" <jtimon@jtimon.cc>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Libbitcoin <libbitcoin@lists.dyne.org>
Subject: Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)
Date: Thu, 20 Aug 2015 09:14:11 +0200	[thread overview]
Message-ID: <C4EA4A39-1920-4F33-822C-FBD12DF81004@bitsofproof.com> (raw)
In-Reply-To: <CABm2gDr_ePfPeWB8pEO8QNHDjUZpybVuCAdDmMxJxMaC8+2bGA@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2510 bytes --]

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 “full” consensus lib extracted from satoshi’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ón 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


[-- Attachment #1.2: Type: text/html, Size: 4394 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

  reply	other threads:[~2015-08-20  7:14 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-23 14:30 [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks) Jorge Timón
2015-07-23 14:57 ` Milly Bitcoin
2015-07-23 21:02   ` Jorge Timón
2015-07-23 21:30     ` Milly Bitcoin
2015-07-28  6:40 ` Eric Voskuil
2015-07-28  8:47   ` Wladimir J. van der Laan
2015-07-28  9:58   ` Jorge Timón
2015-07-29 20:38     ` Eric Voskuil
2015-07-29 21:46       ` Jorge Timón
2015-08-20  0:53         ` Jorge Timón
2015-08-20  7:14           ` Tamas Blummer [this message]
2015-08-20  8:06             ` Jorge Timón
2015-08-20  8:35               ` Tamas Blummer
2015-08-20 17:44                 ` Matt Corallo
2015-08-20 21:26                   ` Tamas Blummer
2015-08-20 21:35                     ` Matt Corallo
2015-08-21  6:46                       ` Tamas Blummer
2015-08-21 19:46                 ` Jorge Timón
2015-08-21 20:07                   ` Eric Lombrozo
2015-08-22 11:04                   ` Tamas Blummer
2015-08-23  1:23                     ` Eric Lombrozo
2015-08-23  2:19                       ` Eric Lombrozo
2015-08-23  6:42                       ` Tamas Blummer
2015-08-29 23:30                         ` Jorge Timón
2015-08-29 23:25                       ` Jorge Timón
2015-08-29 22:08                     ` Jorge Timón
2015-07-28  8:43 ` Wladimir J. van der Laan
2015-07-28 10:09   ` Jorge Timón

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C4EA4A39-1920-4F33-822C-FBD12DF81004@bitsofproof.com \
    --to=tamas@bitsofproof.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jtimon@jtimon.cc \
    --cc=libbitcoin@lists.dyne.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox