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
|
Return-Path: <arnoud@pukaki.bz>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 18AC77E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Aug 2015 21:19:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.affil.co (mail.affil.co [75.101.133.5])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F2BC0241
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Aug 2015 21:19:18 +0000 (UTC)
Received: (qmail 29573 invoked by uid 1008); 5 Aug 2015 21:18:08 +0000
Received: from mail-ob0-f181.google.com (arnoud@pop.affil.co@209.85.214.181)
by mail.affil.co with RC4-SHA encrypted SMTP; 5 Aug 2015 21:18:08 +0000
Received: by obnw1 with SMTP id w1so41465877obn.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 05 Aug 2015 14:19:17 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.246.202 with SMTP id xy10mr9913744obc.64.1438809557211;
Wed, 05 Aug 2015 14:19:17 -0700 (PDT)
Received: by 10.76.83.136 with HTTP; Wed, 5 Aug 2015 14:19:17 -0700 (PDT)
In-Reply-To: <CAAS2fgQLNH+rivNNTFz6xt_9SxO3fFj7-3z7A-_B_2X2x-6M5w@mail.gmail.com>
References: <CALwsPgnnkbfUBhL=Qyspz13pnZ-6RHdaZOGvfLG34JjJRgt2Dw@mail.gmail.com>
<B3546CB9-6A24-474C-8B56-9B1E2D33B470@mattcorallo.com>
<CALwsPgm6xcBfLXZTNTZ40R_s3oUawE0ANZycDWpSo0cXZ+=-Vg@mail.gmail.com>
<CAAS2fgQLNH+rivNNTFz6xt_9SxO3fFj7-3z7A-_B_2X2x-6M5w@mail.gmail.com>
Date: Wed, 5 Aug 2015 15:19:17 -0600
Message-ID: <CALwsPgm9S3UNd3bEuWreyGS7bcvSD+cXxueoD+F_D9fC=xLz2Q@mail.gmail.com>
From: Arnoud Kouwenhoven - Pukaki Corp <arnoud@pukaki.bz>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=089e01634d6a8ea04f051c96f431
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Arnoud Kouwenhoven - Pukaki Corp via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Idea: Efficient bitcoin block propagation
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 05 Aug 2015 21:19:21 -0000
--089e01634d6a8ea04f051c96f431
Content-Type: text/plain; charset=UTF-8
Thanks for this (direct) feedback. It would make sense that if blocks can
be submitted using ~5kb packets, that no further optimizations would be
needed at this point. I will look into the relay network transmission
protocol to understand how it works!
I hear that you are saying that this network solves speed of transmission
and thereby (technical) block size issues. Presumably it would solve speed
of block validation too by prevalidating transactions. Assuming this is all
true, and I have no reason to doubt that at this point, I do not understand
why there is any discussion at all about the (technical) impact of large
blocks, or why there are large numbers of miners building on invalid blocks
(SPV mining, https://bitcoin.org/en/alert/2015-07-04-spv-mining), or why
there is any discussion about the speed of block validation (cpu processing
time to verify blocks and transactions in blocks being a limitation).
Our proposal aims at solving all three issues.
Now I would be glad if the suggestions we made are already implemented,
especially if that is in a more elegant approach. Great! Yet we still see
all three discussions, which is a surprise if they have been solved.
On Wed, Aug 5, 2015 at 2:16 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Wed, Aug 5, 2015 at 7:53 PM, Arnoud Kouwenhoven - Pukaki Corp via
> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Thanks for the reply. My understanding is that the bitcoin relay network
> is
> > a backbone of connected high speed servers to increase the rate at which
> > transactions and new blocks propagate - and remove a number of delays in
> > processing. But it would still require the miners to download the entire
> > block before building on top of it with any degree of confidence.
>
> Your understanding is outdated.
>
> The relay network includes an optimized transmission protocol which
> enables sending the "entire" block typically in just a smal number of
> bytes (much smaller than the summaries you suggest, which still leave
> the participants needing to send the block).
>
> E.g. block 000ce90846 was 999950 bytes and the relay network protocol
> sent it using at most 4906 bytes.
>
> No trust is required in this scheme because the entire block is
> communicated using only a couple packets.
>
> The current scheme is highly simplified and its efficiency could be
> increased greatly with small improvements, or if miners created blocks
> in an aware manner.... but with a maximum size blocks turning into 5kb
> with the current setup, there hardly appears to be a reason to do so
> right now.
>
> Ultimately there is no need for information communicated with a block
> at discovery time proportional to the size of the block; with the
> right affordances it can be accomplished with a small constant amount
> of data.
>
> If not for this already being deployed I personally believe the
> network would have already fallen into complete centeralization as a
> response to larger blocks: this was constructed and deployed in order
> to pull the network back from having a single pool with more than half
> the hashrate.
>
--089e01634d6a8ea04f051c96f431
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks for this (direct) feedback. It would make sense tha=
t if blocks can be submitted using ~5kb packets, that no further optimizati=
ons would be needed at this point. I will look into the relay network trans=
mission protocol to understand how it works!<div><br></div><div>I hear that=
you are saying that this network solves speed of transmission and thereby =
(technical) block size issues. Presumably it would solve speed of block val=
idation too by prevalidating transactions. Assuming this is all true, and I=
have no reason to doubt that at this point, I do not understand why there =
is any discussion at all about the (technical) impact of large blocks, or w=
hy there are large numbers of miners building on invalid blocks (SPV mining=
, <a href=3D"https://bitcoin.org/en/alert/2015-07-04-spv-mining">https://bi=
tcoin.org/en/alert/2015-07-04-spv-mining</a>), or why there is any discussi=
on about the speed of block validation (cpu processing time to verify block=
s and transactions in blocks being a limitation).=C2=A0</div><div><br></div=
><div>Our proposal aims at solving all three issues.</div><div><br></div><d=
iv>Now I would be glad if the suggestions we made are already implemented, =
especially if that is in a more elegant approach. Great! Yet we still see a=
ll three discussions, which is a surprise if they have been solved.<br></di=
v></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, A=
ug 5, 2015 at 2:16 PM, Gregory Maxwell <span dir=3D"ltr"><<a href=3D"mai=
lto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Wed, Aug 5, 2=
015 at 7:53 PM, Arnoud Kouwenhoven - Pukaki Corp via<br>
bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bi=
tcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> Thanks for the reply. My understanding is that the bitcoin relay netwo=
rk is<br>
> a backbone of connected high speed servers to increase the rate at whi=
ch<br>
> transactions and new blocks propagate - and remove a number of delays =
in<br>
> processing. But it would still require the miners to download the enti=
re<br>
> block before building on top of it with any degree of confidence.<br>
<br>
</span>Your understanding is outdated.<br>
<br>
The relay network includes an optimized transmission protocol which<br>
enables sending the "entire" block typically in just a smal numbe=
r of<br>
bytes (much smaller than the summaries you suggest, which still leave<br>
the participants needing to send the block).<br>
<br>
E.g. block 000ce90846 was 999950 bytes and the relay network protocol<br>
sent it using at most 4906 bytes.<br>
<br>
No trust is required in this scheme because the entire block is<br>
communicated using only a couple packets.<br>
<br>
The current scheme is highly simplified and its efficiency could be<br>
increased greatly with small improvements, or if miners created blocks<br>
in an aware manner.... but with a maximum size blocks turning into 5kb<br>
with the current setup, there hardly appears to be a reason to do so<br>
right now.<br>
<br>
Ultimately there is no need for information communicated with a block<br>
at discovery time proportional to the size of the block; with the<br>
right affordances it can be accomplished with a small constant amount<br>
of data.<br>
<br>
If not for this already being deployed I personally believe the<br>
network would have already fallen into complete centeralization as a<br>
response to larger blocks: this was constructed and deployed in order<br>
to pull the network back from having a single pool with more than half<br>
the hashrate.<br>
</blockquote></div><br></div>
--089e01634d6a8ea04f051c96f431--
|
