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
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
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 A8C1B411
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Dec 2015 08:26:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com
[209.85.213.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 75BFC8F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Dec 2015 08:26:23 +0000 (UTC)
Received: by igcph11 with SMTP id ph11so28327025igc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 04 Dec 2015 00:26:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:date:message-id:subject:from:to:content-type;
bh=ieYwut4f/ThACvTfljao0mXYPKU9w1kHiMPLEztKZ+c=;
b=KV1yEYx2yDoyZDaPMLBLre8iUWG9N6ShGbTFBH3vJaEi8ZYJbo0TrMl4CwlKRc62j9
ibja4v4Hl8IWXX6C1l4KwrbKasaqVvIGudEqDREMfSxgCyMu2Fv9cXBAyYxIR5izfTiy
P4JWotdpLyBU+65fFYH4/lJXKLZnGLGzgtOyZJNL+HVVW+PCcYVUwpcmRR6F4umqHU8w
Opz5tkSTTSpCA2HO6AIx9Nn+FtHwvrXSpVGIrBoc7WLeFTrmun1gK4a10yf5BHJu+H44
awAdoFMvVKsD2vvzGlBKUtFNKzjOSiM/pByM9B6qjhIOvEmO3EZ3bEgcmk02AVn6k4Ao
BHsQ==
MIME-Version: 1.0
X-Received: by 10.50.107.3 with SMTP id gy3mr2819679igb.48.1449217582993; Fri,
04 Dec 2015 00:26:22 -0800 (PST)
Sender: gmaxwell@gmail.com
Received: by 10.107.192.70 with HTTP; Fri, 4 Dec 2015 00:26:22 -0800 (PST)
Date: Fri, 4 Dec 2015 08:26:22 +0000
X-Google-Sender-Auth: kwymZw0bjQ-jVqhX1Rdmyv9OkfU
Message-ID: <CAAS2fgRwfQNYxCmDPAnVudyAti9v8PPXQjxe9M13pmrFxKcSCQ@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, 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
X-Mailman-Approved-At: Fri, 04 Dec 2015 11:35:29 +0000
Subject: [bitcoin-dev] Blockchain verification flag (BIP draft)
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, 04 Dec 2015 08:26:27 -0000
For discussion,
A significant fraction of hashrate currently mines blocks without
verifying them for a span of time after a new block shows up on the
network for economically rational reasons. This otherwise harmful
behavior can be made a beneficial to the whole network; but only if it
is communicated.
This BIP proposal suggests a communication channel and describes its
use and the motivations for it. I wrote it in response to suggestions
that Bitcoin Core add explicit support for this kind of mining, which
could also implement best in class risk mitigations. I believe
signaling the behavior is a necessary component for risk mitigation
here.
-----------------------------------------------------------------
<pre>
BIP: draft-maxwell-flagverify
Title: Blockchain verification flag
Author: Greg Maxwell <greg@xiph.org>
Status: Draft
Type: Standards Track
Created: 2015-12-02
</pre>
==Abstract==
This BIP describes a flag that the authors of blocks can use to voluntarily
signal that they have completely validated the content of their
block and the blocks before it.
Correct use of this signaling is not enforced internally to the network
but if used it can act as a hint allowing more intelligent risk analysis.
If deployed and adhered to, this mechanism turns otherwise harmful
validation skipping by miners into a behavior which benefits the public.
==Summary==
The version field in a Bitcoin block header is a 32-bit signed integer.
The most significant bit (30) of the block version is defined to signal that
the author of the block has validated the whole chain up to and including the
content of the block.
Conforming miners MUST NOT set this flag when they have not completely
validated the prior block(s) or the content of their own block. Miners
should continue to try to minimize the amount of time spent mining
on a non-validated chain. Blocks which extend an invalid chain will
continue to be rejected and ultimately orphaned as validation catches up.
It is recommended, but not required, that miners also not set the flag on blocks
created by the same device which created the block immediately prior. This
will reduce the incorrect implication of independent validation when the two
most recent blocks are both the product of the same, single, faulty system.
The set state for the bit is defined as verified so that that
un(der)maintained systems do not falsely signal validation.
Non-verifying clients of the network may check this bit (e.g. checking
that the version is >= 1073741824) and use it as an input to their risk
modeling. It is recommended that once this BIP is widely accepted by the
network that non-full-node wallets refrain from counting confirmations on
blocks where the bit is not set.
The authors of non-verifying clients should keep in mind that this flag
is only correct with the cooperation of the block author, and even then
a validating miner may still accidentally accept or produce an invalid
block due to faulty hardware or software. Additionally, any miner which
correctly uses this flag could stop doing so at any time, and might
do so intentionally in order to increase the effectiveness of an attack.
As a result of misunderstanding, misconfiguration, laziness, or other
human factors some miners may falsely set the flag. Because invalid
blocks are rare it may take a long time to detect misuse of the flag.
As such, the accuracy of this field MUST NOT be strongly relied upon.
Especially due to the non-enforceability of the flag, the user community
should keep in mind that both setting the flag correctly and mining
without verification (for brief periods of time) are healthy for the
network. If participants are punished for following this specification
they will simply lie, and its utility will be diminished.
==Motivation==
Some applications of the Bitcoin system such as thin-client wallets make
a strong assumption that all the authors of the blocks have faithfully
verified the blockchain. Because many of these applications also take
irreversible actions based on only one or two confirmations and the time
between blocks is often very short, these clients are vulnerable to
even small and short-duration violations of this assumption.
Processing and propagation delays resulting from increased transaction
load contribute to block orphaning when multiple blocks are found at
close to the same time. This has caused some miners to work on extending
the chain with the most proof-of-work prior to validating the latest
block(s).
Although this validation skipping undermines the security assumptions
of thin clients, it also has a beneficial effect: these delays also
make the mining process unfair and cause increased rewards for the
largest miners relative to other miners, resulting in a centralization
pressure. Deferring validation can reduce this pressure and improve
the security of the Bitcoin system long term.
This BIP seeks to mitigate the harm of breaking the thin client
assumption by allowing miners to efficiently provide additional
information on their level of validation. By doing so the
network can take advantage of the benefits of bypassed
validation with minimal collateral damage.
==Deployment==
Because there is no consensus enforced behavior there is no special
deployment strategy required. [BIP 9 will need to be updated.]
==Credits==
Thanks goes to Jeremy Rubin for his two-phase mining suggestion
which inspired this simplified proposal.
==Copyright==
This document is placed in the public domain.
|
