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
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C32714D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Aug 2015 20:16:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f177.google.com (mail-io0-f177.google.com
[209.85.223.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4507DED
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Aug 2015 20:16:35 +0000 (UTC)
Received: by iodd187 with SMTP id d187so60910704iod.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 05 Aug 2015 13:16:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=9jYN0AAn5JnlR6UK3gduVTip6rkRkYPcVSIcYCMuDQs=;
b=xIpU6tIKtivIxo3F93WeVmsxyQ3ZDLjlQ8e0Q52oKKWaAgy2OBdpr1aMUQHBABZbYI
nFb+PXVCOWZ3TUXEWwuEcmkjO3uQwsKMKP8yW1i8dEyiayIQ7UXZvzN8QT0uVj9fjFhO
FWXHdWnqkOYUJdMwhZoOmqtkI+wTmtVEzoIZ1nT/5YFP0hl+DTtZpNY2sksqIqasCbsT
RPOWae6Zl5mJ3c9yXXQ42MjCcxmjYWIdaTl9MoABVahKUZ1HWuUp8C6YrshsNCdj4b1N
r89/Un7vtuHts4h9ZIqe94WGkeTJk/ci1G1+T/VVOR6KT+4VuLkR8GOWO5cl9Dvi6fR7
JcLw==
MIME-Version: 1.0
X-Received: by 10.107.132.15 with SMTP id g15mr12056149iod.134.1438805794707;
Wed, 05 Aug 2015 13:16:34 -0700 (PDT)
Received: by 10.107.14.136 with HTTP; Wed, 5 Aug 2015 13:16:34 -0700 (PDT)
In-Reply-To: <CALwsPgm6xcBfLXZTNTZ40R_s3oUawE0ANZycDWpSo0cXZ+=-Vg@mail.gmail.com>
References: <CALwsPgnnkbfUBhL=Qyspz13pnZ-6RHdaZOGvfLG34JjJRgt2Dw@mail.gmail.com>
<B3546CB9-6A24-474C-8B56-9B1E2D33B470@mattcorallo.com>
<CALwsPgm6xcBfLXZTNTZ40R_s3oUawE0ANZycDWpSo0cXZ+=-Vg@mail.gmail.com>
Date: Wed, 5 Aug 2015 20:16:34 +0000
Message-ID: <CAAS2fgQLNH+rivNNTFz6xt_9SxO3fFj7-3z7A-_B_2X2x-6M5w@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Arnoud Kouwenhoven - Pukaki Corp <arnoud@pukaki.bz>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW 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 20:16:35 -0000
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.
|
