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
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
|
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 A13EB3EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 Sep 2019 04:59:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com
[209.85.128.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A78D77DB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 Sep 2019 04:59:11 +0000 (UTC)
Received: by mail-wm1-f51.google.com with SMTP id p7so1780077wmp.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Sep 2019 21:59:11 -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=qzkfBvADrLqaTbL3moLNA5P/o8ZTVG8AL64DAurudlI=;
b=PyqF5CpPm054QqbYBrSZuY89VJsZT9B8A4VQhduf0GxsJU2YhZNuYo4Z7olLnvFhRf
Xcm8PkiNQShYY6qZuzpl/IUdC7LOyOF//kP8ZlIyIs8BvFRc6N0u7IrG/mp8UEHrhnep
6onP9L1/HmJ9w1pLxh/527BUgwJ1kLWBYqMK6ECU+HUG18ldKyvmRFqa5pcFOBHUBEeD
W5SynfRa5BJ2bxijR/EwwvY3m0/JXogmG5yjtFnsk/T4O8vSKUq7CY7sI91oRX/c0YN/
NIcOfP1csAXvAV+3S6nxsaNtrO/gpS/26URkVX/bRuS278CEfzEUIHnDjDQpP/6vCnTJ
1j+Q==
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=qzkfBvADrLqaTbL3moLNA5P/o8ZTVG8AL64DAurudlI=;
b=NityY04DNb2OGDK1coMuGgI/X2nJBtTYr3lpFbnr3yYF+Hg5mt+qiNlFZ7mZ5Ese52
XwAbJcECrFLBBgVZDdwzNPaCnZocxiQYGoCoT598vxp0cTMdtaxCCy92L6A6Dvkrnb0j
VCuVF0Osu1DCRHijdBUC0QOcH6pyXEtJzoa0bUigDrlGp8n//it8yd2e2VOisGBPW8XX
B6uW07w5ou8kXiseiAwSY7fkrXV9FTwniyXkPH8pOUajchNO2RQoHKGbQ1ujWsqDeP72
utIE9UksL6jinsW5VTtRxB2jnZq3QcYKwNtxJVl00I1Btts6ZtNRj8ldB79Th8WiIF9/
vbjg==
X-Gm-Message-State: APjAAAWyXtVdUHHuS/jYBaQpl3GT8QS1YKORgvHuLoEfFkvxNWKUxPGr
pTYB5RT2ShU2zyon6jwh/pql8h/kSldr2RBeSzw=
X-Google-Smtp-Source: APXvYqzVI9RZ/09A6VSBoWa+/HOPkKapO8EIyiXhAA973Pd7uaHGNbLlWtxkxh1DDJxEmB5Bpaxf2KQLFSXTQ2AZNC4=
X-Received: by 2002:a1c:cf05:: with SMTP id f5mr2184355wmg.131.1568177950231;
Tue, 10 Sep 2019 21:59:10 -0700 (PDT)
MIME-Version: 1.0
References: <CAPv7TjaE1wF-25R=LaOES33A78ovDAp9-waiC7n5YLJnMmNs9A@mail.gmail.com>
<uVQNn9hhpqlQuS-RzrUkpClVtegMRUoyIL6ITaYfNkjd_XYyu9Fh9vdAeLguzOyOrNx5FtuHk7yyZAdivqCVR2PKzF_PsoWJlsSY9oJTF7s=@protonmail.com>
<CAPv7TjYE1rp2EEo247fKmmN=q9QBqCHPBy56xvBymOv418LFDw@mail.gmail.com>
<y8brIayR1YQIud3TxdgiBJK3zrxclhcICAJgSw3tqqJM2jP9WA1SWiesXcNSrRxiIM7m8cRkZlLdu0sz2lNFEe5HbQI4TIRvkoA3yysMzKE=@protonmail.com>
In-Reply-To: <y8brIayR1YQIud3TxdgiBJK3zrxclhcICAJgSw3tqqJM2jP9WA1SWiesXcNSrRxiIM7m8cRkZlLdu0sz2lNFEe5HbQI4TIRvkoA3yysMzKE=@protonmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Wed, 11 Sep 2019 06:58:57 +0200
Message-ID: <CAPv7TjaMm5q8Q-AXbVcjx5RoKt-5y7t4Fx+CMhJ=cabLysc9=w@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
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: Wed, 11 Sep 2019 04:59:37 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] PoW fraud proofs without a soft fork
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: Wed, 11 Sep 2019 04:59:12 -0000
Hi ZmnSCPxj,
>I suppose the critical difference is that invalid inflation can fool the S=
PV node, the fullnode will not be so fooled.
That is correct. If you sybil the SPV node, you can break any
consensus rule you like. I believe this is inherent to fraud proofs in
general, because you skip consensus checks unless you're able to
receive a fraud proof.
But note that my goal in the comparison was to assert that there is no
security difference between committing or not committing the utreexo
hash into a block. The attack your describe works in either situation,
so my conclusion remains that committing the hash adds no security.
Other weaknesses compared to full nodes are:
- the SPV nodes rely on the existence of a healthy network of utreexo
supporting full nodes
- at least one honest block needs to be mined
- consensus slows down, because you need to allow time for an honest
minority to produce a block
Cheers,
Ruben
On Mon, Sep 9, 2019 at 8:58 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> Good morning Ruben,
>
> Yes, I suppose that is correct.
>
> I suppose the critical difference is that invalid inflation can fool the =
SPV node, the fullnode will not be so fooled.
>
> A somewhat larger-scale attack is to force a miner-supported miner-subsid=
y-increase / blocksize-increase hard fork.
> If enough such SPV nodes can be sybilled, they can be forced to use the h=
ard fork, which might incentivize them to support the hard fork rather than=
back-compatible consensus chain.
>
> Regards,
> ZmnSCPxj
>
> > Hi ZmnSCPxj,
> >
> > Thank you for your comments. You raise an important point that I should=
clarify.
> >
> > > 1. In event of a sybil attack, a fullnode will stall and think the b=
lockchain has no more miners.
> >
> > You can still attack the full node by feeding it a minority PoW chain,
> > then it won't stall.
> >
> > > 2. In event of a sybil attack, an SPV, even using this style, will f=
ollow the false blockchain.
> >
> > Correct, but this false blockchain does need to have valid PoW.
> >
> > So in both cases valid PoW is required to fool nodes. The one
> > difference is that for a full node, the blocks themselves also need to
> > be valid (except for the fact that they are in a minority chain), but
> > the end result is still that a victim can be successfully double spent
> > and lose money.
> >
> > I hope this clarifies why I consider the security for these two
> > situations to be roughly equivalent. In either situation, victims can
> > be fooled into accepting invalid payments.
> >
> > Cheers,
> > Ruben
> >
> > On Mon, Sep 9, 2019 at 6:14 AM ZmnSCPxj ZmnSCPxj@protonmail.com wrote:
> >
> > > Good morning Ruben,
> > >
> > > > One might intuitively feel that the lack of a commitment is uns=
afe,
> > > > but there seems to be no impact on security (only bandwidth). T=
he only
> > > > way you can be fooled is if all peers lie to you (Sybil), causi=
ng you
> > > > to follow a malicious minority chain. But even full nodes (or t=
he
> > > > committed version of PoW fraud proofs) can be fooled in this wa=
y if
> > > > they are denied access to the valid most PoW chain. If there ar=
e
> > > > additional security concerns I overlooked, I=E2=80=99d love to =
hear them.
> > > >
> > >
> > > I think it would be better to more precisely say that:
> > >
> > > 1. In event of a sybil attack, a fullnode will stall and think the b=
lockchain has no more miners.
> > > 2. In event of a sybil attack, an SPV, even using this style, will f=
ollow the false blockchain.
> > >
> > > This has some differences when considering automated systems.
> > > Onchain automated payment processing systems, which use a fullnode, w=
ill refuse to acknowledge any incoming payments.
> > > This will lead to noisy complaints from clients of the automated paym=
ent processor, but this is a good thing since it warns the automated paymen=
t processor of the possibility of this attack occurring on them.
> > > The use of a timeout wherein if the fullnode is unable to see a new b=
lock for, say, 6 hours, could be done, to warn higher-layer management syst=
ems to pay attention.
> > > While it is sometimes the case that the real network will be unable t=
o find a new block for hours at a time, this warning can be used to confirm=
if such an event is occurring, rather than a sybil attack targeting that f=
ullnode.
> > > On the other hand, such a payment processing system, which uses an SP=
V with PoW fraud proofs, will be able to at least see incoming payments, an=
d continue to release product in exchange for payment.
> > > Yet this is precisely a point of attack, where the automated payment =
processing system is sybilled and then false payments are given to the paym=
ent processor on the attack chain, which are double-spent on the global con=
sensus chain.
> > > And the automated system may very well not be able to notice this.
> > > Regards,
> > > ZmnSCPxj
>
>
|
