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
|
Return-Path: <peter_r@gmx.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 63C0C89E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 Nov 2015 03:17:19 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6289611C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 Nov 2015 03:17:18 +0000 (UTC)
Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx103)
with ESMTPSA (Nemesis) id 0MVedf-1ZtYQS0y2J-00YzuY;
Sun, 15 Nov 2015 04:17:11 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Peter R <peter_r@gmx.com>
In-Reply-To: <201511150304.41003.luke@dashjr.org>
Date: Sat, 14 Nov 2015 19:17:08 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <F2D5CE08-FEF1-4E56-8B76-3E7964FC1C7B@gmx.com>
References: <5631C363.5060705@neomailbox.net>
<CAAS2fgRdK4bDr3x_y9UpdH234PQSfD7U539HBLA==+hLQJ_7Fw@mail.gmail.com>
<571D9B7F-077D-4B80-B577-1C18FF2ECF31@gmx.com>
<201511150304.41003.luke@dashjr.org>
To: Luke Dashjr <luke@dashjr.org>
X-Mailer: Apple Mail (2.2104)
X-Provags-ID: V03:K0:TuQFOSXxAHIy48qrbfbrYDa4qzKkFj94NhPVqJ1DAjD11IR5mNo
fALDWiVeIh1/MU0oNP1v0rAIkB9pcNIQeZ4eIVFASL45ZLSlkpWwwdIdjnk33d1J0E+owtH
Z1+KiiauT4BCHRt5Prpb0hb76zMAO5GNCIl8NPk6shsESipwYqUo3sUo+8vHPrDbjq2CYLP
Cv3WgXjjOAyPm2rZRprKg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:Mnhvomf/0Tw=:CotC+ATnPo/CD+B/RMHJYB
R82+DCoPv35mOHl+sRlSFXoGKTzoXxfNZ/yyXgsKkelGMeEWoUoco+eCdZWX7435fvcmjWMIl
uNEUPIRFUzXNeJ8Z6orrgiWFfkelpU11LT9V2I2slSGvXD3pvIRg6K16mry0nqtz295Or5Ntq
MFPyfUdTKGwuG6lLJcNuak+d5kZiKYpHNTMWroVp4LFm7O2icGPzujlWR+aik5t570CYI4BUn
+lMYf7FvsbP1FR94nYOTKwh8awvdCiHaISTIKkPhAVGTgUcOV7swqlxpsN4OEDPKuDsGzZQhZ
DGE2fhrKwrCC7HlnNbU/+CIpMbQeQHHJicVjNcXDWW0FOhWGul5K1zT63b0nn/klXOYtFV9CH
0+2Vt6t0arBil2VXcc3fCDd0B8OBPieXtZF7Nai1qdnkMC6vrnj9dpo0XrNK2Wk8uRlm3edlG
zmaRFWGMhCzpFMM0tKI6Xof9WN+yrPWyBaWO+VxGuPIdJbYNG2KygnIucNnOPWsJmHKpNSZaI
0yv3WSXtuhXLQBLv5IWQp0CDogYb4NPOQy4zzSrueVoZRFmxALPnZsGbPiNQzD/Qy4rSZgPkH
RTwlfzwSYCGsOOLBFk+kwB9fkmkXfRJFQrfmsp6kaPrRGnCl1qVmhT9aeyWCSqide4bkQoMJw
n3phF0MDOyi1SMrEBjACZZgDKp7H3FoFF1+kJXCA1bnA6rCchiXrjIMMhKF8gJZPkjmLYSYd8
ilef+lF43tRlgPqZJx41jb4FJ7bBQeKIijtw/z2q0xWYmBapJjR9sIF9bmVck57sPKZw93erq
U28Kvs8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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, telemaco <telemaco@neomailbox.net>
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: Sun, 15 Nov 2015 03:17:19 -0000
> On Sunday, November 15, 2015 1:02:33 AM Peter R via bitcoin-dev wrote:
>> A group of us have been exploring this =E2=80=9Cmeta-cognition=E2=80=9D=
idea with Bitcoin
>> Unlimited. For example, Bitcoin Unlimited can be (optionally) made =
to
>> automatically fork to the longest chain if it =E2=80=9Cgets stuck=E2=80=
=9D and can neither
>> prove that a block is valid nor that the block is invalid.
>=20
> This situation isn't something that can be ignored and simply moved =
past. If=20
> you can't determine the validity of a block, you also cannot process =
its=20
> results correctly. Taking for example the BDB/LevelDB issue, the =
result was=20
> that BDB failed to accept further changes to the UTXO set. Unless the =
UTXO set=20
> could be updated correctly, there is no way to even attempt to =
validate the=20
> next block or any new transactions.
Great point, Luke!=20
Indeed, whether the program can or cannot continue after a Type 1 =
consensus mismatch depends on the specifics of the situation and exactly =
how the code was written. But I agree: there are cases where the =
program *can=E2=80=99t* continue. In those cases it would halt. This =
would require manual intervention to fix but avoids the problem of =
potential double-spends during the fork event. This would be preferable =
to knowingly causing a fork. =20
Peter=
|
