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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <dscvlt@gmail.com>) id 1Wo356-0002mX-9z
for bitcoin-development@lists.sourceforge.net;
Sat, 24 May 2014 03:57:12 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.46 as permitted sender)
client-ip=209.85.219.46; envelope-from=dscvlt@gmail.com;
helo=mail-oa0-f46.google.com;
Received: from mail-oa0-f46.google.com ([209.85.219.46])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wo355-00052X-Cu
for bitcoin-development@lists.sourceforge.net;
Sat, 24 May 2014 03:57:12 +0000
Received: by mail-oa0-f46.google.com with SMTP id i4so6448529oah.5
for <bitcoin-development@lists.sourceforge.net>;
Fri, 23 May 2014 20:57:05 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.28.134 with SMTP id b6mr9525322obh.27.1400903825758;
Fri, 23 May 2014 20:57:05 -0700 (PDT)
Received: by 10.182.225.66 with HTTP; Fri, 23 May 2014 20:57:05 -0700 (PDT)
Date: Sat, 24 May 2014 13:27:05 +0930
Message-ID: <CAOXABZohe93SSRm1FN5ai2H97eBJV2j+LAjA-39YAaNmX=ep0Q@mail.gmail.com>
From: Ashley Holman <dscvlt@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=001a11c2903ce61e3e04fa1d56a5
X-Spam-Score: -0.6 (/)
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
(dscvlt[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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
X-Headers-End: 1Wo355-00052X-Cu
Subject: [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 03:57:12 -0000
--001a11c2903ce61e3e04fa1d56a5
Content-Type: text/plain; charset=UTF-8
Hi,
On this list there has been some discussion around techniques to speed up
block propagation, with a particular focus on reducing the extra orphan
risk carried by larger blocks.
The current store-and-forward method means that larger blocks will
propagate with higher latency. One proposed solution has been to broadcast
two separate messages: a fast, fixed-size header message, and a 2nd, slower
body message containing the full block. Whilst this allows larger blocks
to compete equally with smaller blocks on the "which came first" rule, it
creates a new area of uncertain delay between receiving the header, and
receiving the body, where there may be perverse incentives to mine empty
blocks on top of not-yet-valid headers.
So I would like to propose another method which is hopefully a less
significant change to the existing protocol rules, but should help reduce
the latency gap between large and small blocks.
* Skip the inv/getdata sequence for new blocks - just push them out
directly to save 1 roundtrip per hop
* When receiving a new block from a peer, as soon as we have the first 80
bytes (header) we can validate the PoW and, with only a low-level change to
the networking code, begin streaming that block to our peers (in the style
of cut-through switching).
* No other rules need to change. Block primacy can still be determined as
of the moment they are fully validated and accepted, but now the latency
caused by larger blocks is only (1 * BlockSize * BottleneckHopSpeed),
instead of (Sum[n=0 to NumHops](BlockSize * NodeBandwidth(n))).
* 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.
Thoughts?
Thanks
--001a11c2903ce61e3e04fa1d56a5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<div><br></div><div>On this list there has been some di=
scussion around techniques to speed up block propagation, with a particular=
focus on reducing the extra orphan risk carried by larger blocks.</div><di=
v>
<br></div><div>The current store-and-forward method means that larger block=
s will propagate with higher latency. =C2=A0One proposed solution has been =
to broadcast two separate messages: a fast, fixed-size header message, and =
a 2nd, slower body message containing the full block. =C2=A0Whilst this all=
ows larger blocks to compete equally with smaller blocks on the "which=
came first" rule, it creates a new area of uncertain delay between re=
ceiving the header, and receiving the body, where there may be perverse inc=
entives to mine empty blocks on top of not-yet-valid headers.</div>
<div><br></div><div>So I would like to propose another method which is hope=
fully a less significant change to the existing protocol rules, but should =
help reduce the latency gap between large and small blocks.</div><div><br>
</div><div>* Skip the inv/getdata sequence for new blocks - just push them =
out directly to save 1 roundtrip per hop</div><div>* =C2=A0When receiving a=
new block from a peer, as soon as we have the first 80 bytes (header) we c=
an validate the PoW and, with only a low-level change to the networking cod=
e, begin streaming that block to our peers (in the style of cut-through swi=
tching).</div>
<div>* No other rules need to change. =C2=A0Block primacy can still be dete=
rmined as of the moment they are fully validated and accepted, but now the =
latency caused by larger blocks is only (1 * BlockSize * BottleneckHopSpeed=
), instead of (Sum[n=3D0 to NumHops](BlockSize * NodeBandwidth(n))).</div>
<div>* As far as I can tell, this shouldn't change any game theory or i=
ncentives because nodes still receive blocks exactly as they do now, just s=
ooner. =C2=A0The difference is, invalid blocks that meet the PoW will be br=
oadcast to everyone, but this is nothing new since someone can peer with yo=
u and send you an invalid block already. =C2=A0Network DoS should not be a =
possibility since it is very expensive to make invalid blocks that meet net=
work PoW.</div>
<div><br></div><div>Thoughts?</div><div><br></div><div>Thanks</div></div>
--001a11c2903ce61e3e04fa1d56a5--
|
