public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@jtimon•cc>
To: "Wladimir J. van der Laan" <laanwj@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)
Date: Tue, 28 Jul 2015 12:09:22 +0200	[thread overview]
Message-ID: <CABm2gDo-ziQLpDiFbmkYjMcsFJ2EVXe1hMOjm0gXQiRxp-K78Q@mail.gmail.com> (raw)
In-Reply-To: <20150728084312.GA29453@amethyst.visucore.com>

On Tue, Jul 28, 2015 at 10:43 AM, Wladimir J. van der Laan
<laanwj@gmail•com> wrote:
> On Thu, Jul 23, 2015 at 04:30:06PM +0200, Jorge Timón via bitcoin-dev wrote:
>> But I thought you also wanted Bitcoin Core to use libconsensus instead
>> of just having a subtree/subrepository like it currently does with
>> libsecp256k1.
>> I'm not sure if that would ever be accepted, but in any case we're
>> certainly far away from that goal. Here are some things that need to
>> happen first:
>
> I don't see any reason why Bitcoin Core would not use the consensus library. Eating our own dogfood and such.

As explained to Eric, it's not that I don't want Bitcoin Core to use
future-libconsensu through the API instead of a subtree: it's just
that that's more long-term and more work. And I don't see why other
implementations should really care about it.

> Biggest risk, as I've said before, is that the refactoring loading to a (more complete) consensus library will result in code that is no longer bug-for-bug compatible with previous versions, thus defeating its entire purpose and introducing fork risk.
>
> If that can be avoided - for example by going from here to there using pure code moves, as you're trying to do - I'm all for it.

Well, pure movements will not be enough, parameters will have to
change, incompatible dependencies have to be removed (ie util.h which
contains globals), etc.
But yes, I think we can do it with only low-risk and easy-to-review commits.

>> 3) Move libconsensus to a separate repository as a
>> subtree/subrepository of Bitcoin Core.
>
> If the rest is done, this is the easy part :)

And still, this doesn't require Bitcoin Core to use the API, a subtree
is enough at first.
This "easy step" doesn't guarantee that Bitcoin Core is using
future-libconsensus' API.

> Code review capacity is still our greatest bottleneck.
> And I don't see any way out of that, unfortunately.

I really think these code separations help with this (ie there are
many more people in the world with enough knowledge to review the qt
or even policy parts than there's people able to review consensus
changes).

> I do really care about this.

I know and I said so.


      reply	other threads:[~2015-07-28 10:09 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-23 14:30 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
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 [this message]

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=CABm2gDo-ziQLpDiFbmkYjMcsFJ2EVXe1hMOjm0gXQiRxp-K78Q@mail.gmail.com \
    --to=jtimon@jtimon$(echo .)cc \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=laanwj@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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