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 0476725A for ; Tue, 28 Jul 2015 10:09:25 +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 567BC15A for ; Tue, 28 Jul 2015 10:09:24 +0000 (UTC) Received: by wibxm9 with SMTP id xm9so153119643wib.1 for ; Tue, 28 Jul 2015 03:09:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SB3103B6DlUwEJhImQCUs2V4BqzUv/cryAfRStEGaRQ=; b=lfYAQgSqDMGv5vjVXKVWM+rR6LOBIkd+BtekPxpyYfD4w4nUfVqS1BiMthQdWZ5knK uTi0ogilU5GmE93O16QlNvAnAFTAUSTuxt91ET5DIhyMBvZC85AbjFDHXUOyiusLhDMm FTt/vTB8H9eZvK7oH5LHQDS4yQwf+yXeui6SSRZJCn+R46tNGc4rpOaOPa6BwJTXoilo 2GZdto5gouRHSYcoQy+z3HSrGdL+GeKax0nlstRgbS5xdRShXX96T8YAheTE+1Vzeadl dy9Ksyb1kPVwql6ck4k1ZoaVvBOUzeS8EsTjhYnKHbhC8eyONDWiPnKufetT/wCkfrUV cMPw== X-Gm-Message-State: ALoCoQno8wUf/PR4Fykl8W84JlpV9gT8jmA328HQJi8NCQtwvX/eQm1DjSFRwr5095MzRAl5Vj7S MIME-Version: 1.0 X-Received: by 10.194.58.7 with SMTP id m7mr61652297wjq.109.1438078162921; Tue, 28 Jul 2015 03:09:22 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Tue, 28 Jul 2015 03:09:22 -0700 (PDT) In-Reply-To: <20150728084312.GA29453@amethyst.visucore.com> References: <20150728084312.GA29453@amethyst.visucore.com> Date: Tue, 28 Jul 2015 12:09:22 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: "Wladimir J. van der Laan" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 10:09:25 -0000 On Tue, Jul 28, 2015 at 10:43 AM, Wladimir J. van der Laan wrote: > On Thu, Jul 23, 2015 at 04:30:06PM +0200, Jorge Tim=C3=B3n via bitcoin-de= v 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 libra= ry. 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 purpos= e and introducing fork risk. > > If that can be avoided - for example by going from here to there using pu= re 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.