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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bernd.jendrissek@gmail.com>) id 1WoKum-0001DL-EQ
for bitcoin-development@lists.sourceforge.net;
Sat, 24 May 2014 22:59:44 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.176 as permitted sender)
client-ip=209.85.217.176;
envelope-from=bernd.jendrissek@gmail.com;
helo=mail-lb0-f176.google.com;
Received: from mail-lb0-f176.google.com ([209.85.217.176])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WoKul-00043K-5E
for bitcoin-development@lists.sourceforge.net;
Sat, 24 May 2014 22:59:44 +0000
Received: by mail-lb0-f176.google.com with SMTP id p9so3527803lbv.35
for <bitcoin-development@lists.sourceforge.net>;
Sat, 24 May 2014 15:59:36 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.21.130 with SMTP id v2mr9936645lae.1.1400972376403; Sat,
24 May 2014 15:59:36 -0700 (PDT)
Sender: bernd.jendrissek@gmail.com
Received: by 10.112.94.228 with HTTP; Sat, 24 May 2014 15:59:36 -0700 (PDT)
In-Reply-To: <CAOXABZohe93SSRm1FN5ai2H97eBJV2j+LAjA-39YAaNmX=ep0Q@mail.gmail.com>
References: <CAOXABZohe93SSRm1FN5ai2H97eBJV2j+LAjA-39YAaNmX=ep0Q@mail.gmail.com>
Date: Sun, 25 May 2014 00:59:36 +0200
X-Google-Sender-Auth: pTTOZdPxUIH9UCaRKAZ-C9hN0ho
Message-ID: <CAF7PVPoGAyhQhU-p-SiT1H86A+Zs3Fb-s9wgFZQtxdb6674k3w@mail.gmail.com>
From: Bernd Jendrissek <bitcoin@bpj-code.co.za>
To: Ashley Holman <dscvlt@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(bernd.jendrissek[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WoKul-00043K-5E
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Cut-through propagation of blocks
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 24 May 2014 22:59:44 -0000
On Sat, May 24, 2014 at 5:57 AM, Ashley Holman <dscvlt@gmail.com> wrote:
> * As far as I can tell, this shouldn't change any game theory or incentives
> because nodes still receive blocks exactly as they do now, just sooner. The
> difference is, invalid blocks that meet the PoW will be broadcast to
> everyone, but this is nothing new since someone can peer with you and send
> you an invalid block already. Network DoS should not be a possibility since
> it is very expensive to make invalid blocks that meet network PoW.
The difference is that with cut-through forwarding of blocks, a
sufficiently motivated attacker (being willing to blow 25BTC's worth
of electricity on the effort) can subjugate the entire Bitcoin network
to its DoS attack, rather than having to connect to every node
individually and then still have those individual nodes reject that
invalid block without relaying any knowledge of its existence.
An attack could also take the form of a block body that never arrives
- a sort of teergrube attack, where the goal is to get the network
mining empty block upon empty block on top of that valid-PoW header
whose body never arrives. It doesn't have to be with an explicitly
invalid block.
Could one mitigate such attacks by allowing nodes to send a message to
the effect of, "Oops, I know that header i just sent is valid PoW, but
I'd like you to forget about it - I think its body is invalid"?
|
