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
|
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 224F689D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Aug 2015 18:42:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com
[209.85.213.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B6CFBE8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Aug 2015 18:42:38 +0000 (UTC)
Received: by igbij6 with SMTP id ij6so16983257igb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 06 Aug 2015 11:42:38 -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=MjXqvWcn89H8EX8dcxRfQCo/J684vifAVct56SEZZoE=;
b=ExvbG4W/ImH0rek/FP1CVMP9+nWIoUQRa/S3aqyCTrncmDtlT9ddmt32D65YEcTG0P
wYtz0PK0ZKKH5UHJpBPdaAF5he/lXoRppWyEwukg227GXMHSW1Kux63h0b8TzxC5Tq6M
AaaZe8H2zJrEDBlrT03hPT9csj98tiMDY7X4pjBfo/nuPAU3CFchaTUxfWjqwgEYZd58
Rj4uvCDKDsBQLRY7DPVpTgPsF2Vz/fdFz77miknpPlxh0uYUbWgneowY2J35H6XwzPmF
hGkwQgcMlZnS2FM297FPxx5UO8p0TpWmBu5eNty7X8AodbLRe+8MJ1m9cgg7nLUXh13f
p3xw==
MIME-Version: 1.0
X-Received: by 10.50.59.242 with SMTP id c18mr5897815igr.66.1438886558243;
Thu, 06 Aug 2015 11:42:38 -0700 (PDT)
Received: by 10.107.14.136 with HTTP; Thu, 6 Aug 2015 11:42:38 -0700 (PDT)
In-Reply-To: <55C3A4BF.1010509@thinlink.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>
<CALwsPgm9S3UNd3bEuWreyGS7bcvSD+cXxueoD+F_D9fC=xLz2Q@mail.gmail.com>
<CAAS2fgSXWzCv=4cF=0bwL9+udzBHSPR7goL3U_c1NjS22dpWzQ@mail.gmail.com>
<CAKzdR-qPtPsxAXsmUX=vTkq-ro=EAmH7M8nL_Px_b4D4Z0WAXg@mail.gmail.com>
<55C3A4BF.1010509@thinlink.com>
Date: Thu, 6 Aug 2015 18:42:38 +0000
Message-ID: <CAAS2fgRoapt+z4fQd53NDGKWwZD=JLFefNCopS6u4SKrhN9A=A@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Tom Harding <tomh@thinlink.com>
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: 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: Thu, 06 Aug 2015 18:42:39 -0000
On Thu, Aug 6, 2015 at 6:17 PM, Tom Harding via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> - Will the relay network at least validate block version numbers in the
> future?
It already validates block version numbers.
It only relays valid transactions.
Although, the block relaying itself is explicitly "unvalidated" and
the software client can only usefully be used with a mempool
maintaining full node (otherwise it doesn't provide much value,
because the node must wait to validate the things). ... but that
doesn't actually mean no validation at all is performed, many
stateless checks are performed.
On Thu, Aug 6, 2015 at 5:16 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Is there any up to date documentation about TheBlueMatt relay network
> including what kind of block compression it is currently doing? (apart from
> the source code)
I don't know if Matt has an extensive writeup. But the basic
optimization it performs is trivial. I wouldn't call it compression,
though it does have some analog to RTP "header compression".
All it does is relay transactions verified by a local node and keeps a
FIFO of the relayed transactions in both directions, which is
synchronous on each side.
When a block is recieved on either side, it replaces transactions with
their indexes in the FIFO and relays it along. Transactions not in the
fifo are escaped and sent whole. On the other side the block is
reconstructed using the stored data and handed to the node (where the
preforwarded transactions would have also been pre-validated).
There is some more than basic elaboration for resource management
(e.g. multiple queues for different transaction sizes)-- and more
recently using block templates to learn transaction priority be a bit
more immune to spam attacks, but its fairly simple.
Much better could be done about intelligently managing the queues or
efficiently transmitting the membership sets, etc. It's just
basically the simplest thing that isn't completely stupid.
|
