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 8DB2B282 for ; Tue, 28 Jul 2015 08:43:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EDFBC14D for ; Tue, 28 Jul 2015 08:43:17 +0000 (UTC) Received: by wibxm9 with SMTP id xm9so146388487wib.0 for ; Tue, 28 Jul 2015 01:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to; bh=hwnAA73CpuG8SMTRTHaR1AkANnbY19+XerVxvUTDpY0=; b=DIFywu/duNZg7lYCrGKZiTeyST5+LUdNe4qltmf/cH5MpJTXwhTfT+SVKzSTyo6TtI SdQ0voDSzor7YpIr9O4lYPpRLOPuKl3tz9cx8qzXGWaLoaINFOgp4+OTDLxHYlzBzTmh HZLTSGMZIdE5jbtk3elAzT5TfcSft3wNd6XOUhcZqxGfuPnfz1DfG5faa6jzfoDriyhn sUiD9daJgYo/72waFP/TktJc/7DH5LtqAps030nej+VoG7rsocaz0TLcCn6HfCG0g/7i IGeVodG4MbaZiuyC0IX1oiv9nUjooLHhXRbpbRIwxV9xnhrHhhGf9WCZDLlTiShSEDX5 1Haw== X-Received: by 10.180.73.200 with SMTP id n8mr32785810wiv.94.1438072996581; Tue, 28 Jul 2015 01:43:16 -0700 (PDT) Received: from amethyst.visucore.com (dhcp-089-098-228-253.chello.nl. [89.98.228.253]) by smtp.gmail.com with ESMTPSA id w8sm32093034wja.15.2015.07.28.01.43.15 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 28 Jul 2015 01:43:15 -0700 (PDT) Date: Tue, 28 Jul 2015 10:43:14 +0200 From: "Wladimir J. van der Laan" To: Jorge =?utf-8?B?VGltw7Nu?= Message-ID: <20150728084312.GA29453@amethyst.visucore.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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@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: Tue, 28 Jul 2015 08:43:18 -0000 On Thu, Jul 23, 2015 at 04:30:06PM +0200, Jorge Timón via bitcoin-dev wrote: > I think there were some misunderstandings in our previous conversation > about this topic. > I completely agree with having a separated repository for libconsensus > (that's the whole point, alternative implementations can be > consensus-safe by using it, and in the event of a schism fork[1], they > can fork just that smaller project without having to relay on Bitcoin > Core [satoshi] at all). Indeed. > 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. 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. > 2) Finish libconsensus's API: expose more things than VerifyScript, at > the very least, also expose VerifyTx, VerifyHeader and VerifyBlock. > Feedback from alternative implementations like libbitcoin is extremely > valuable here. Some related closed-for-now PRs: Agreed. > 3) Move libconsensus to a separate repository as a > subtree/subrepository of Bitcoin Core. If the rest is done, this is the easy part :) > Unfortunately and ironically again, safer, small and incremental > changes are less interesting for reviewers. > For example, I've been trying to move consensus code to the consensus > folder for a long time. The correctness of a MOVEONLY change is > trivial to review for anyone who knows how to copy/paste in its > favorite editor and how to use git diff, but will I ever get answers > to my questions in [1]? Code review capacity is still our greatest bottleneck. And I don't see any way out of that, unfortunately. > I know there's many people who really care about this, Cory Fields, > Wladimir and Pieter Wuille to name a few have reviewed many of this > changes (I've just got used to publicly whine about lack of review on > this front and policy encapsulation [very related fronts] as an > attempt to get some attention: not always, but begging for review > actually works some times). I do really care about this. Wladimir