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: <rsomsen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BD97C7F6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Apr 2019 06:38:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com
[209.85.221.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2E14E828
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Apr 2019 06:38:06 +0000 (UTC)
Received: by mail-wr1-f52.google.com with SMTP id k17so15611030wrx.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 14 Apr 2019 23:38:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to
:content-transfer-encoding;
bh=K4rUtFZl3tCXw/ujeDAs/ih6lBYTB4HzVP2wevL3nI4=;
b=Y9kcv4nFgC9RDV5IIgZU8ZlGu2SKJyEM7dmOcL9cJh81Ff7ayHpEW1lkRENOL6x5IH
SF0t9pU6PXKo7hiaILNfqMjSDqSOCFJiIO0TcVIomZFmARMu1fQp6dvuPCUboeVSW77m
f27/SzmTFnOPt5yTTHFaKmVzF7ieMJ5H2aBLcxcufotilu5ln49kwEVELAVxpGESc/dN
8Zq+gMpKwRyficYJqeygNPe7PSIQuKu/p75pciA212UpRrb1QpqhDANt9PJcalYz1UwG
dTAuFB8ulANQaj+bU3xAfJfyZ8HpGLAEW4TRCqL3SZlWPoF7gIRPvIeduzgqCy6Fja3k
pZ9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to
:content-transfer-encoding;
bh=K4rUtFZl3tCXw/ujeDAs/ih6lBYTB4HzVP2wevL3nI4=;
b=R2oywN11hKU1KRbI47xO9389VkLoJVX2IUE0t5Ze8Mn01k2hG/6i6s5qpVgXRaSfyb
ScryS+j7I7gr9LviDEotKhP78Ybw6Q34liY45Xdgif+x3aCmVRSuombW1zfqsnUO7PxZ
Gc8O1Yn9XSyQlYFV4EuBsGBlAX1ZepHJeOY3djIRRq6AQVPxSiLBz/VEYwsxFmXJljPD
5d8Us1q+YiA4QE897NvZSn4kfK4F9CRROfd2YV7lIHUan8mB4/t8QEcGLiqFAyleRiQz
IdwPBqpC8McLSC9l+1pUGJr5xSzkrMm1GgfB4OpwVWgLJZQLwliKsjOeL0c5+hYuXOBV
9v7A==
X-Gm-Message-State: APjAAAUsf4lnFYYPh4sGXDu0/nhv6Y7mTsxSkzgCS9nEpKrgbhXJXCGq
DjQcRHY4OppSWTrGlMqnClInh4GPp35lUq2hYqhmVsRp
X-Google-Smtp-Source: APXvYqx/nAJ+KE3EvYgCi1F/dK6ZWRy0rPiBQkIqH7nFnYAKac3xHKLyXQ1BPuKRtWn3g6CaN5roOZ4lLGp1Xx0h4CM=
X-Received: by 2002:adf:ff88:: with SMTP id j8mr45614162wrr.1.1555310284589;
Sun, 14 Apr 2019 23:38:04 -0700 (PDT)
MIME-Version: 1.0
From: Ruben Somsen <rsomsen@gmail.com>
Date: Mon, 15 Apr 2019 08:37:43 +0200
Message-ID: <CAPv7TjYspkc1M=TKmBK8k0Zy857=bR7jSTarRDCr_5m2ktYHDQ@mail.gmail.com>
To: 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: Thu, 18 Apr 2019 13:43:50 +0000
Subject: [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: Mon, 15 Apr 2019 06:38:06 -0000
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, but i=
s 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.
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).
If users do not wait and happen to accept payments from an invalid
chain during this time, these payments could get reverted. This is a
weakness, but still seems preferably to continually following an
invalid chain. As long as a reasonable number of miners remains
honest, a dishonest majority can only temporarily control the network,
and their blocks (and all coins gained from it) will eventually be
rejected.
-- Ruben Somsen
[0] Olaoluwa Osuntokun, BIP 157: Client Side Block Filtering,
https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki
[1] Peter Todd, TXO commitments do not need a soft-fork to be useful,
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/01359=
1.html
|
