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
|
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 F14B7D9D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 Sep 2019 06:53:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com
[209.85.221.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 15B06EC
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 Sep 2019 06:53:45 +0000 (UTC)
Received: by mail-wr1-f41.google.com with SMTP id u16so12507750wrr.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 08 Sep 2019 23:53:44 -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=VvXpInIAg7UXWqp7hu9Q4rJ/JoO+IVbatpaPx9a2JuU=;
b=O91/kxL0kVEOlD144afpQKmO9u8r5XgUSy3rq3MhXKfJPnfUeh7sLy7duXUHN0ix/q
cBnCuUPFG0kCSfAV+u2qyGoLB0Z6a1rTiK/ndgZRPHbVopZ79mDwMKhZAFe3OqA65yxo
zh6TjsUCel59XVrwi3qsMdu/gbkfgyMZXxHhGBMF1E4fP7apqUIG1As2PWFnlqyhTbvO
Ejf1MrJFqbkNY76Rd5XZ4NLrVzQhl5RjfkiTvG5fynt6pnbDkcglX1aYNfdtQ0zj6DNd
FjAXTSz0aYhE+uwKvtyg7+lrBv6v42EbtGUdJdCtsWdFuuO2/38+TTDaQEn3eP6KmegA
/llg==
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=VvXpInIAg7UXWqp7hu9Q4rJ/JoO+IVbatpaPx9a2JuU=;
b=Rn0RL3MW5EAllbsY21cEdPvJFga2RZz7QyA9UZ+q4OHZ7x/u0VyKcUNmUvNV7R8hyf
XCwvBmWKs2N3L1Q9C/FqTcAIudx/FF8EGY8zupt05CeJI8ZUtVMBYKdMJ3+nHVcQ317k
iWpQv23Piw+0jeOaS9QNtsqWx9oMdNsJXhaP+92PMsFTWjE3UlhVWQOuRKwhcL32jaN/
3GbV9iOCQXLrUJxppxjrKPjehTQYCH1ZRoqbAwwf4oMhf5P0s8KvACIRm15iWcsp/BH8
bt3crIK51jVeIApFFTjHP46dQqqG/vjW6NxSSXdCnQFYs/jUGeknL6WOS2tFEVXBCGLJ
zJVg==
X-Gm-Message-State: APjAAAVIa/p+/6fgP9ANhbBxy06vOxS/R4u7dfTW3JfDhTasp1TRX9Sh
0sIGGJm0ehdxgy5tZCj8X0/ndFmgDy5+V1Kyvrc=
X-Google-Smtp-Source: APXvYqx/VzN6muSW/wYgK01dmLhbKL8oLE+QakVePOwd7ltipf18ODw2lsSOwBuleTdkc2AQfj31CMoZ25u62ntopxo=
X-Received: by 2002:a5d:4408:: with SMTP id z8mr16997657wrq.106.1568012023701;
Sun, 08 Sep 2019 23:53:43 -0700 (PDT)
MIME-Version: 1.0
References: <CAPv7TjaE1wF-25R=LaOES33A78ovDAp9-waiC7n5YLJnMmNs9A@mail.gmail.com>
<uVQNn9hhpqlQuS-RzrUkpClVtegMRUoyIL6ITaYfNkjd_XYyu9Fh9vdAeLguzOyOrNx5FtuHk7yyZAdivqCVR2PKzF_PsoWJlsSY9oJTF7s=@protonmail.com>
In-Reply-To: <uVQNn9hhpqlQuS-RzrUkpClVtegMRUoyIL6ITaYfNkjd_XYyu9Fh9vdAeLguzOyOrNx5FtuHk7yyZAdivqCVR2PKzF_PsoWJlsSY9oJTF7s=@protonmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Mon, 9 Sep 2019 08:53:28 +0200
Message-ID: <CAPv7TjYE1rp2EEo247fKmmN=q9QBqCHPBy56xvBymOv418LFDw@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: Mon, 09 Sep 2019 06:55:00 +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: Mon, 09 Sep 2019 06:53:46 -0000
Hi ZmnSCPxj,
Thank you for your comments. You raise an important point that I should cla=
rify.
>1. In event of a sybil attack, a fullnode will stall and think the blockc=
hain 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 follow=
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 unsafe,
> > but there seems to be no impact on security (only bandwidth). The o=
nly
> > way you can be fooled is if all peers lie to you (Sybil), causing y=
ou
> > to follow a malicious minority chain. But even full nodes (or the
> > committed version of PoW fraud proofs) can be fooled in this way if
> > they are denied access to the valid most PoW chain. If there are
> > 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 block=
chain has no more miners.
> 2. In event of a sybil attack, an SPV, even using this style, will follo=
w the false blockchain.
>
> This has some differences when considering automated systems.
>
> Onchain automated payment processing systems, which use a fullnode, will =
refuse to acknowledge any incoming payments.
> This will lead to noisy complaints from clients of the automated payment =
processor, but this is a good thing since it warns the automated payment pr=
ocessor of the possibility of this attack occurring on them.
> The use of a timeout wherein if the fullnode is unable to see a new block=
for, say, 6 hours, could be done, to warn higher-layer management systems =
to pay attention.
> While it is sometimes the case that the real network will be unable to fi=
nd 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 fulln=
ode.
>
> On the other hand, such a payment processing system, which uses an SPV wi=
th PoW fraud proofs, will be able to at least see incoming payments, and co=
ntinue to release product in exchange for payment.
> Yet this is precisely a point of attack, where the automated payment proc=
essing system is sybilled and then false payments are given to the payment =
processor on the attack chain, which are double-spent on the global consens=
us chain.
> And the automated system may very well not be able to notice this.
>
> Regards,
> ZmnSCPxj
|
