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 73E4967 for ; Fri, 30 Oct 2015 03:04:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 02CC9109 for ; Fri, 30 Oct 2015 03:04:48 +0000 (UTC) Received: by pacfv9 with SMTP id fv9so61794072pac.3 for ; Thu, 29 Oct 2015 20:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitcartel_com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=svWVhKcpm9c5UmI7UFLkTppIOysK3orEmrO6+ObIQK0=; b=EJKXAQHcWzwQpr9eFc9Fa57hVKcV1L+Jva/JDv8+DtbOSYzCGtR83pNCZRrOohKN0a l7M/sdmHeuGlEqNLeztI6TZj7ZfY0RyL8eqJelFR7U5dBj2bhO17W45Z1H2Y9zFNgUcB ouLy6d409DjLHmxAQw0mq3nyE60HEK30Z2/c2vfaZUiyxgjdS970E8gitsdLinjW0sQj 2svLMJhtCHLX1kwfNp3QrojIg/ETC+VWmlFP59/8hSX4Rs+jUvSVYEfvObVgxwkZ6OLr oJdCm/5acHcRz2i65ra0nfCvdNzyCGZVxxsp242gahGBHva5GTHpTUXGmZ1vgLppPGDS uXPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=svWVhKcpm9c5UmI7UFLkTppIOysK3orEmrO6+ObIQK0=; b=RSbnYqNM5JvI2qk2RkLY7x4yCj5A1IIrcEZv/BNRb9enjRJdkJJO0+wkCddBiw4dmz vDEXK234bFVUvpJbdRih1EGKqzrh0fEgUMorZ87Of/l9Krq4vVHppb9Hp0W1Bz9eEMj5 d5yz1UvU6T1AfLgHCWIFBV0WKkPXL51J6lNJTOFxA0rV2hXs6K6KWL3Y/Hy9oHhH0wXb Zct+cdQwM3Beh9AmKwbiHoafvk+N+/vkjZHjv4Ehmpg1piNEZ1oBC3ZjoB7AjMidKVDG 7HBn5a7ptIswMor1e+q0XjrYU4xz707P3JSvQWefE+4MibUelsbRF4fP8TjnlOggadq8 69IQ== X-Gm-Message-State: ALoCoQkSyOM/nEPMdGfM2ADRIAO9uFsLuWE0CnefMCuOnK2MW6GyfYPLxdbg88FdfDRh2scj6lS0 X-Received: by 10.68.254.137 with SMTP id ai9mr5751515pbd.68.1446174288680; Thu, 29 Oct 2015 20:04:48 -0700 (PDT) Received: from [192.168.2.8] (c-50-161-101-12.hsd1.ca.comcast.net. [50.161.101.12]) by smtp.googlemail.com with ESMTPSA id xm9sm4925176pbc.32.2015.10.29.20.04.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Oct 2015 20:04:27 -0700 (PDT) To: Luke Dashjr , telemaco References: <5631C363.5060705@neomailbox.net> <201510290803.52734.luke@dashjr.org> From: Simon Liu Message-ID: <5632DE33.7030600@bitcartel.com> Date: Thu, 29 Oct 2015 20:04:19 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <201510290803.52734.luke@dashjr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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 X-Mailman-Approved-At: Fri, 30 Oct 2015 03:29:33 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db 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: Fri, 30 Oct 2015 03:04:49 -0000 Storage of UTXO data looks like an implementation detail and thus one would have thought that the choice of database would not increase the odds of consensus protocol failure. Btcd, a full node implementation written in Go, already provides a database interface which supports different backends: https://github.com/btcsuite/btcd/tree/master/database Given that UTXO storage is considered critical, it seems reasonable to let a node operator decide for themselves if they want data stored in LevelDB (which is not fully ACID compliant) or a database like Sqlite, Oracle, DB2 etc. If the storage requirements for UTXO data are fairly simple, consisting mainly of puts and gets, there is a decent argument that using a dedicated key-value store provides superior performance over a traditional SQL database. However, from a practical perspective, given that nodes operate on a range of different hardware and even a little Raspberry Pi can run a full node and keep up with the network, why not let those users with the resources to operate big iron databases do so? It would be a good feature to have. On 10/29/2015 01:03 AM, Luke Dashjr via bitcoin-dev wrote: > I predict this would be a disaster. UTXO storage is CONSENSUS-CRITICAL code. > Any divergence in implementation behaviour, including bugs AND bugfixes, may > cause consensus failure. For this to have a reasonable *hope* of working, we > need to choose one storage engine, and *will* need to maintain consensus- > compatibility of it ourselves (since nobody else cares). > > Fixing LevelDB frankly seems like an easier task than switching to anything > SQL-based, which would require a *lot* more *difficult-to-get-consensus- > compatible* code that we are all (or at least mostly) very unfamiliar with. > > Research is fine, but let's be realistic about deployment. > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >