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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1SgPli-0005HX-0q
for bitcoin-development@lists.sourceforge.net;
Mon, 18 Jun 2012 00:24:34 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.46 as permitted sender)
client-ip=209.85.216.46; envelope-from=gmaxwell@gmail.com;
helo=mail-qa0-f46.google.com;
Received: from mail-qa0-f46.google.com ([209.85.216.46])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1SgPlh-0005Eu-4I
for bitcoin-development@lists.sourceforge.net;
Mon, 18 Jun 2012 00:24:34 +0000
Received: by qadb17 with SMTP id b17so850544qad.12
for <bitcoin-development@lists.sourceforge.net>;
Sun, 17 Jun 2012 17:24:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.188.7 with SMTP id cy7mr24251371qab.34.1339979067578; Sun,
17 Jun 2012 17:24:27 -0700 (PDT)
Received: by 10.229.144.205 with HTTP; Sun, 17 Jun 2012 17:24:27 -0700 (PDT)
Date: Sun, 17 Jun 2012 20:24:27 -0400
Message-ID: <CAAS2fgR3SGeHOJ5CcnHhM-ETUA7=SwozfZH4yhYpnMFJ5Vm_XA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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
0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SgPlh-0005Eu-4I
Subject: [Bitcoin-development] Block preview for faster relaying
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: Mon, 18 Jun 2012 00:24:34 -0000
Right now we're seeing cases where block propagation is sometimes
taking minutes.
This doesn't cause much of a problem for general Bitcoin users but for
miners its problematic because it potentially increases the risk for
orphaning.
There are probably many contributing factors which can be improved
here but one of the most obvious is that nodes fully validate blocks
before relaying them. The validation is IO intensive and can currently
take a minute alone on sufficiently slow nodes with sufficiently large
blocks and larger blocks require more data to be transmitted. Because
this slowness is proportional to the size of the block this risks
creating mismatched incentives where miners are better off not mining
(many) transactions in order to maximize their income.
The validation speed can and should be improved but there is at least
one short term improvement that can be made at the protocol level:
Make it possible to relay blocks to other nodes before fully
validating them.
This can be reasonable secure because basic validation (such as the
difficulty, previous block identity, and timestamps) can be done first
so an attacker would need to burn enormous amounts of computing power
just to make very modest trouble with it... and it's a change which
would be beneficial even after any other performance improvements were
made.
Luke has been working on a patch for this:
https://github.com/luke-jr/bitcoin/commit/0ce6f590dc2b9cbb46ceecd7320220f55d814bca
One aspect of it that I wanted to see more comments on was the use of
a new message for the preview-blocks instead of just announcing them
like normal. The reason for this is two-fold: To prevent existing full
nodes from blacklisting nodes sending a bad preview block due to the
existing misbehavior checks, otherwise an attacker could burn one
block to partition the network, and also so that SPV nodes which
aren't able to fully validate the block themselves can opt-out or at
least know that the data is not yet validated by the peer.
I don't see any better way to address this but I thought other people
might have comments.
|
