summaryrefslogtreecommitdiff
path: root/6b/ce704a5b65ff0a392da02418676b5812593de2
blob: 6ede99c2636c0089362cbe969b31bc73fdc2026e (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
Return-Path: <simon@bitcartel.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 73E4967
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 30 Oct 2015 03:04:48 +0000 (UTC)
Received: by pacfv9 with SMTP id fv9so61794072pac.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <luke@dashjr.org>, telemaco <telemaco@neomailbox.net>
References: <5631C363.5060705@neomailbox.net>
	<201510290803.52734.luke@dashjr.org>
From: Simon Liu <simon@bitcartel.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
>