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 CC93CAD1 for ; Wed, 13 Jan 2016 08:37:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f50.google.com (mail-vk0-f50.google.com [209.85.213.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E520D137 for ; Wed, 13 Jan 2016 08:37:47 +0000 (UTC) Received: by mail-vk0-f50.google.com with SMTP id k1so257501533vkb.2 for ; Wed, 13 Jan 2016 00:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2YviUrguNL+sz3IVBVqqIp1yKQ536nNesEkKGwjfAJE=; b=jbF9nEkHa+W1j2zCr1rPTUXcZ8PsuFA9wVs3jx487dTQtIHMJ3dyLhxe+anZrCGc0d tPsijR4QzpRoTWVwOv1rntd396PWpGtyO1QG4I+5wHk2fL7K08eQ1nrQ8xJDhFFaM/bG knDv50jJ0uov4FFGsb62Ebz3yNCqOOYPy6BMJDVB95Js5SJWR5J4zPdVEUwoSPlof7q5 citNFXC0dWmX3dbQ4f9gASBSzmulE1M5c9V7nHq1bUF3Ufaw2MMlOufjcPS7K3/rr6QV KcmAwTdNL7MiJkvDxJicFzoIewN7w19ETxmxvOl8geGtshmBjoD0QpDr4CJcvOPg13zx p+2Q== 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; bh=2YviUrguNL+sz3IVBVqqIp1yKQ536nNesEkKGwjfAJE=; b=P2cyb7o5rwVMVj70zGiGQTLucfJL3/MtvFlQNc/meePQtgU/U12rhgznJQmUTSSWJh xlkr4aOH4ge1Deh8S0HHOYCobE3lHI++UWdfAjLNhgOWxNROplkryB6rtFBiWzibXpE3 K1q6IOYTlRIIdgl3goKMzxSZw5fa5RSmpu8llpQr1m6uzftVu/tRTDJw6oXoRsaoU32i tLf6iOnPnURd1NJhrxNM/g46yGDFJM8ouhj3GBRhAwHZotsan4V9ABnkO3fCudvfm6x8 lIgbfe/cAs2ChKkeHctModMo1pC7Iqr0ujeHnsYfBdDM/4hPMrARt/H9t7XE/hM/V9L8 9pww== X-Gm-Message-State: ALoCoQlcyUnEkMuzw9o0qoo45eLiXGY6ZMULkNdVE82pxrLDFxmhuvsFcFLfsczo7FyQbUo9x6WcmSFwXil9Ji9I/ob174GHTQ== MIME-Version: 1.0 X-Received: by 10.31.154.213 with SMTP id c204mr96318708vke.38.1452674266688; Wed, 13 Jan 2016 00:37:46 -0800 (PST) Received: by 10.31.141.73 with HTTP; Wed, 13 Jan 2016 00:37:46 -0800 (PST) In-Reply-To: <56955140.7050301@voskuil.org> References: <56955140.7050301@voskuil.org> Date: Wed, 13 Jan 2016 09:37:46 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Eric Voskuil Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 phase 2 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: Wed, 13 Jan 2016 08:37:48 -0000 On Tue, Jan 12, 2016 at 8:17 PM, Eric Voskuil wrote: > Jorge, first, thanks again for your work on this. > > Without creating and using a public blockchain interface in phase 2, how > will you isolate the database dependency from consensus critical code? > Is it that the interface will exist but you will recommend against its use? The interface will exist but it will be a C++ interface that fits better with Bitcoin Core internals. See an initial draft of what could be the storage interface: https://github.com/jtimon/bitcoin/blob/1717db89c6db17ea65ddbd5eb19034315db0b059/src/consensus/storage_interfaces_cpp.h Phase 3 will consist on discussing and refining that interface to also define the C interfaces using structs of function pointers instead of classes (see https://github.com/jtimon/bitcoin/blob/2bcc07c014e5dd000030e666be047dfa11f54c10/src/consensus/interfaces.h for an early draft) that is needed for the "final" C API. But since I think there will be more discussion and work defining those interfaces, I would rather start with ANY interface that allows us to decouple the consensus code from chain.o and coins.o, which we don't want to be built as part of the consensus building package (which is used for building both libbitcoinconsensus and Bitcoin Core). Future potential users are more than welcomed to draft their own C APIs and that experience should be useful for phase 3. I was expecting you, for example, to include the whole consensus code (even if it lacks a C API) in https://github.com/libbitcoin/libbitcoin-consensus for better testing of the equivalent code in libbitcoin. You are kind of taking the C API part out already, so this time you will just have less things to delete/ignore. > This work presumes that the users of the library reject the argument > that the database implementation is consensus critical code. Faithful > reproduction of stored data is a prerequisite for a validity. But a > common store implementation is only slightly more reasonable for this > library than a common RAM implementation. This is a concern that has been risen repeatedly. I am aware that faithful reproduction of the stored data is a prerequisite for consensus validity. On the other hand, my presumption is that a libbitcoinconsensus that forces its users to a given unifrom storage will likely had much less users and any alternative implementation that wants to implement its own custom storage would have to necessarily reimplement the consensus validation code. Doing it this way is more flexible. We can relatively easily implement another library (if I remember correctly, last time we talked about it we reffered to it as "libconsensus plus", but there's probably better names) also takes care of storage for the users that don't want to take the risks of reimplementing the storage (probably just using Bitcoin Core's structures). Unlike me, Luke Dashjr, for example, advocated for the storage-dependent version, but I believe that implementing both versions was an acceptable solution to him. It is certainly an acceptable solution for me. I don't want to force anyone that doesn't want or need to take the risks reimplementing the consensus storage part to do so. But at the same time I really believe that it would be a mistake to not allow it optionally. Does that make sense?