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
181
|
Return-Path: <eth3rs@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2AFE51D51
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Apr 2019 20:12:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com
[209.85.214.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 27A876C5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Apr 2019 20:12:58 +0000 (UTC)
Received: by mail-pl1-f176.google.com with SMTP id n8so1644392plp.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Apr 2019 13:12:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc:content-transfer-encoding;
bh=5VWu37CpKckfwfHLfcOqqUvfBXQEmDOZ66Y9u052YDU=;
b=k0zkZ0y5ZVrFTZh4GbjQP7G5eCwCKUMxCxfdW6roJwy9pmr9VjYc0L8cIzMNRJ3JIx
xLr2nhWzqLydH4WY83PCaPV74ed2WBZD70f4q6txDnlw1nmH2iwU5wx8IbPZcpwML3n4
DmT2Gkj4NItvDV08e5DfneQta6wDBfP47Thkr/aM8D0vG1QRhwp4Eg7XwaH62VGjl5pQ
wjcvcgwuRjHHk7jAwEFk+IHqow60adbPSdGghTkdqVHZXhDZE30rj49SR3LUT0zCVhlk
wIyhCxNGoXT2EhTdFBYJ23K47tGDV7O/vkcyA4u+vV+FgGLAAsAgkXFDK62/6h+rsXOU
U7VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc:content-transfer-encoding;
bh=5VWu37CpKckfwfHLfcOqqUvfBXQEmDOZ66Y9u052YDU=;
b=Wt9fah7vUTJ2OPI7AMDmUzvtkuvHJpd0+tLHGw9qRWruvDcd9Y3e+UkcYeRCg9/PTf
IrV+YbimkCJtfen6ijbuLrPkAq+14szvO0PnRsLrti85WFc/F3i4v6/PQzbr+KmGnlZl
M/qE3aEUuxaNjHZlPNOXc2GepZVj3nbUPW9ZX55Peuh8XfgzlWNtlCxYfGD6xJ50WJpL
8CezlvBYoUbPxshYVwZARUr7tEcnZE7tHB97j/W0rCgeJkKsdQPnJN17tWtpZCyl/zyW
3BFHW2c/1j10iIq5lhBqbSEfA/dWhnsQDICRFCPUt/6ArWqM7x+Y8icXWZv7NULiiWL4
W/vQ==
X-Gm-Message-State: APjAAAUk4Iw0w2SncTQaEMLmGHS+gwhlL6c6ba2jNKh2Cv4IHbYkdamZ
GHZDCLCkO+9orE8w27jvEOIBjez3QEzReE5mOgM=
X-Google-Smtp-Source: APXvYqzbNYBA3RvRpwr7w9DiFDO7zyG6qXsRc1o3yCaW+pYaxFUwveEji41TGClWWKFGfHon6dWlyO+H1yIUkUMGEuM=
X-Received: by 2002:a17:902:b78c:: with SMTP id
e12mr45350095pls.29.1555618377561;
Thu, 18 Apr 2019 13:12:57 -0700 (PDT)
MIME-Version: 1.0
References: <CAPv7TjYspkc1M=TKmBK8k0Zy857=bR7jSTarRDCr_5m2ktYHDQ@mail.gmail.com>
<-tCD0qh97dAiz-VGkDQTwSbSQIm9cLF1kOzaWCnUDTI4dKdsmMgHJsGDntQhABZdE2_yBYpPAAdulm8EpdNxOB8o3lI6ZQJBJZWF1INzUrE=@protonmail.com>
In-Reply-To: <-tCD0qh97dAiz-VGkDQTwSbSQIm9cLF1kOzaWCnUDTI4dKdsmMgHJsGDntQhABZdE2_yBYpPAAdulm8EpdNxOB8o3lI6ZQJBJZWF1INzUrE=@protonmail.com>
From: Ethan Heilman <eth3rs@gmail.com>
Date: Thu, 18 Apr 2019 16:12:20 -0400
Message-ID: <CAEM=y+W==_+AW6ga9WMf=aAX-xPGUfhEJQFvUtdFodGGv-6eAg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE 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, 19 Apr 2019 13:57:03 +0000
Subject: Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Thu, 18 Apr 2019 20:12:59 -0000
I'm probably repeating a point which has been said before.
>I suppose a minority miner that wants to disrupt the network could simply =
create a *valid* block at block N+1 and deliberately ignore every other val=
id block at N+1, N+2, N+3 etc. that it did not create itself.
If this minority miner has > 10% of network hashrate, then the rule of
thumb above would, on average, give it the ability to disrupt the
SPV-using network.
Proposed rule:
Whenever a chainsplit occurs SPV clients should download and validate
the "longest chain" up to more than one block greater than the height
of the losing chain.
Lets say a block split causes chain A and chain B: Chain A is N blocks
long, chain B is M blocks long, and N < M. Then the SPV client should
download all the block data of N+1 blocks from Chain B to verify
availability of chain B. Once the SPV client has verified that chain B
is available they can use fraud proofs determine if chain B is valid.
An attacker could use this to force SPV clients to download 1 block
per block the attacker mines. This is strictly weaker security than
provided by a full-node because chain B will only be validated if the
client knows chain A exists. If the SPV client's view of the
blockchain is eclipsed then the client will never learn that chain A
exists and thus never validate chain B's availability nor will the
client be able to learn fraud proofs about chain B. A full node in
this circumstance would notice that the chain B is invalid and reject
it because a full node would not depend on fraud proofs. That being
said this rule would provide strictly more security than current SPV
clients.
On Thu, Apr 18, 2019 at 3:08 PM ZmnSCPxj via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Good morning Ruben,
>
>
> Sent with ProtonMail Secure Email.
>
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original =
Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
> On Thursday, April 18, 2019 9:44 PM, Ruben Somsen via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org> wrote:
>
> > Simplified-Payment-Verification (SPV) is secure under the assumption
> > that the chain with the most Proof-of-Work (PoW) is valid. As many
> > have pointed out before, and attacks like Segwit2x have shown, this is
> > not a safe assumption. What I propose below improves this assumption
> > -- invalid blocks will be rejected as long as there are enough honest
> > miners to create a block within a reasonable time frame. This still
> > doesn=E2=80=99t fully inoculate SPV clients against dishonest miners, b=
ut is a
> > clear improvement over regular SPV (and compatible with the privacy
> > improvements of BIP157[0]).
> >
> > The idea is that a fork is an indication of potential misbehavior --
> > its block header can serve as a PoW fraud proof. Conversely, the lack
> > of a fork is an indication that a block is valid. If a fork is created
> > from a block at height N, this means a subset of miners may disagree
> > on the validity of block N+1. If SPV clients download and verify this
> > block, they can judge for themselves whether or not the chain should
> > be rejected. Of course it could simply be a natural fork, in which
> > case we continue following the chain with the most PoW.
>
> I presume you mean a chain split?
>
> >
> > The way Bitcoin currently works, it is impossible to verify the
> > validity of block N+1 without knowing the UTXO set at block N, even if
> > you are willing to assume that block N (and everything before it) is
> > valid. This would change with the introduction of UTXO set
> > commitments, allowing block N+1 to be validated by verifying whether
> > its inputs are present in the UTXO set that was committed to in block
> > N. An open question is whether a similar result can be achieved
> > without a soft fork that commits to the UTXO set[0][1].
> >
> > If an invalid block is created and only 10% of the miners are honest,
> > on average it would take 100 minutes for a valid block to appear.
> > During this time, the SPV client will be following the invalid chain
> > and see roughly 9 confirmations before the chain gets rejected. It may
> > therefore be prudent to wait for a number of confirmations that
> > corresponds to the time it may take for the conservative percentage of
> > miners that you think may behave honestly to create a block (including
> > variance).
>
> I suppose a minority miner that wants to disrupt the network could simply=
create a *valid* block at block N+1 and deliberately ignore every other va=
lid block at N+1, N+2, N+3 etc. that it did not create itself.
> If this minority miner has > 10% of network hashrate, then the rule of th=
umb above would, on average, give it the ability to disrupt the SPV-using n=
etwork.
>
> >10% of network hashrate to disrupt the SPV-using nodes would be a rather=
low bar to disruption.
> Consider that SPV-using nodes would be disrupted, without this rule, only=
by >50% network hashrate.
>
> It is helpful to consider that every rule you impose is potentially a loo=
phole by which a new attack is possible.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
