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
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EC35494A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 Nov 2015 02:10:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f179.google.com (mail-io0-f179.google.com
[209.85.223.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 53DDCCB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 Nov 2015 02:10:44 +0000 (UTC)
Received: by iouu10 with SMTP id u10so124070333iou.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 Nov 2015 18:10:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type:content-transfer-encoding;
bh=2BbPlE1Z44QoqqLQ5dCubzn1V3wPabvEFsB88bQeTCM=;
b=BAC57n+U1x5QzBMZ6uGmcHbSE66RpMPmD7istVVh2iKLYp4aA3AMlRD/HNg+Pu8Wbf
FUgUjlwhwHVFIiMWinN0ndG5F71iUIjKPjwMmfaOZvt6C/wsIEX6b1S3iFDDloDtMbue
jLBxOUxC6zwHnCTiKvpXekrAzeul9A4CNBxdyNewOjKbjauwAcBP8ID4CN7dEvyA/YnL
3ISIbDF9G9v+6KMRZ1ACXHytFX17nMjtSSmNK1qZViWrA1B+iO3cHB7UZ0RZz12bjRwq
tGaatCxiXj6/FuHuBU7eHX8Fts/zZvaRQchsaN7TGAEvJnoKi4As7oEQ6tVwHgFF7qBy
BQWw==
MIME-Version: 1.0
X-Received: by 10.107.4.83 with SMTP id 80mr28143033ioe.150.1447553443710;
Sat, 14 Nov 2015 18:10:43 -0800 (PST)
Received: by 10.107.192.199 with HTTP; Sat, 14 Nov 2015 18:10:43 -0800 (PST)
In-Reply-To: <6DAD1D38-A156-4507-B506-BF66F26E6594@gmx.com>
References: <5631C363.5060705@neomailbox.net>
<201510290803.52734.luke@dashjr.org>
<5632DE33.7030600@bitcartel.com>
<CAAS2fgTga_vTfOKrFu_hEzXSfTfg9FRfJ6aL6ginuGFqnbm7=w@mail.gmail.com>
<3CB90C47-293E-4C18-A381-E5203483D68F@gmx.com>
<CAAS2fgRdK4bDr3x_y9UpdH234PQSfD7U539HBLA==+hLQJ_7Fw@mail.gmail.com>
<571D9B7F-077D-4B80-B577-1C18FF2ECF31@gmx.com>
<CAAS2fgTLE1cpDqKTiy0r1VMex7zTAB8tgUC=Y0WXmbNBJL42xQ@mail.gmail.com>
<6DAD1D38-A156-4507-B506-BF66F26E6594@gmx.com>
Date: Sun, 15 Nov 2015 02:10:43 +0000
Message-ID: <CAAS2fgT+r4aRPe7Qjww6wgbAzkwafN+340pUaVO9F7MZEVY-zA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Peter R <peter_r@gmx.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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 <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 02:10:45 -0000
On Sun, Nov 15, 2015 at 1:45 AM, Peter R <peter_r@gmx.com> wrote:
> My previous email described how Type 1 consensus failures can be safely d=
ealt with. These include many kinds of database exceptions (e.g., the Leve=
lDB fork at block #225,430), or consensus mismatches regarding the max size=
of a block.
The size of a block is not a type 1 failure. There is a clear, known,
unambiguous, and easily measured rule in the system that a block is
not permitted to have a size over a threshold. A block that violates
this threshold is invalid. The only way I can see to classify that
as a type 1 failure is to call the violation of any known system rule
a type 1 failure. "Spends a coin that was already spent" "provides a
signature that doesn't verify with the pubkey" "creates bitcoins out
of thin air" -- these are not logically different than "if size>x
return false".
> Type 2 consensus failures are more severe but also less likely (I=E2=80=
=99m not aware of a Type 2 consensus failure besides the 92 million bitcoin=
bug from August 2010). If Core was to accept a rogue TX that created anot=
her 92 million bitcoins, I think it would be a good thing if the other impl=
ementations forked away from it (we don=E2=80=99t want bug-for-bug compatib=
ility here).
The only consensus consistency error we've ever that I would have
classified as potentially type 1 had has been the BDB locks issue.
Every other one, including the most recently fixed one (eliminated by
BIP66) was a type 2, by your description. They are _much_ more common;
because if the author understood the possible cases well enough to
create an "I don't know" case, they could have gone one step further
and fully defined it in a consistent way. The fact that an
inconsistency was possible was due to a lack of complete knowledge.
Even in the BDB locks case, I don't know that the type 1 distinction
completely applies, a lower layer piece of software threw an error
that higher layer software didn't know was possible, and so it
interpreted "I don't know" as "no"-- it's not that it chose to treat I
don't know as no, its that it wasn't authored with the possibility of
I don't know in mind, and that exceptions were used to handle general
failures (which should have been treated as no). Once you step back to
the boundary of the calling code (much less the whole application) the
"I don't know" doesn't exist anymore; there.
|
