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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1XCyG1-0005vO-RG
for bitcoin-development@lists.sourceforge.net;
Thu, 31 Jul 2014 21:51:29 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.170 as permitted sender)
client-ip=209.85.213.170; envelope-from=gmaxwell@gmail.com;
helo=mail-ig0-f170.google.com;
Received: from mail-ig0-f170.google.com ([209.85.213.170])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XCyG0-0004SN-TI
for bitcoin-development@lists.sourceforge.net;
Thu, 31 Jul 2014 21:51:29 +0000
Received: by mail-ig0-f170.google.com with SMTP id h3so2442504igd.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 31 Jul 2014 14:51:23 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.111.132 with SMTP id ii4mr171680igb.8.1406843483572; Thu,
31 Jul 2014 14:51:23 -0700 (PDT)
Received: by 10.107.14.67 with HTTP; Thu, 31 Jul 2014 14:51:23 -0700 (PDT)
In-Reply-To: <CA+iPb=Fa4YSTjPuCfyWy0wB2XBV=Mi99G3Hb84gjy+muNDin+g@mail.gmail.com>
References: <CA+iPb=EaX=bvOjNtZ+LnYTMRLQQ9nFcrefAkBdv8eActoX_b8A@mail.gmail.com>
<CABsx9T2PSa3MpfMMDCb8ACVF5vDOZOFLEK9zfP9PakgHA4U16w@mail.gmail.com>
<CAPkFh0vKFnKRE-sd-Z9t1zB73VLPsiaQ3o=OYgBqqtUE4_rTaw@mail.gmail.com>
<CA+iPb=GC7iw1LP6boyfX22oMO2k2=YcAuRhE0E3OzzJHYapsow@mail.gmail.com>
<CAAS2fgS-KiP-tiy91Ah2hJ0pepA0OJDCG+Bv+redFtsqrUTevQ@mail.gmail.com>
<CA+iPb=Fa4YSTjPuCfyWy0wB2XBV=Mi99G3Hb84gjy+muNDin+g@mail.gmail.com>
Date: Thu, 31 Jul 2014 14:51:23 -0700
Message-ID: <CAAS2fgSObqk=rD1vtV6LZzxUuyQMh+nwGuatOq1hUaQz2od0sg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Kaz Wesley <keziahw@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.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
(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
X-Headers-End: 1XCyG0-0004SN-TI
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Squashing redundant tx data in blocks on
the wire
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: Thu, 31 Jul 2014 21:51:30 -0000
On Thu, Jul 31, 2014 at 2:41 PM, Kaz Wesley <keziahw@gmail.com> wrote:
>> the need to have transmitted the transaction list [..] first
>
> 32 bits per transaction is at least double the communication overhead
> of the simple approach, and only offers a bound on the probability of
> needing a round trip.
"(e.g. from a reconciliation step first)" the list can be communicated
in the space roughly equal to the size of the difference in sets plus
coding the permutation from the permissible orderings. If you did
have some "simple approach" that guaranteed that some transactions
would be present, then you could code those with indexes... the FEC
still lets you fill in the missing transactions without knowing in
advance all that will be missing. (Also, the suggestion on the
network block coding page of using part of a cryptographic permutation
as the key means that for unknown transactions the transmission of the
new unknown keys is always goodput=E2=80=94 doesn't add overhead)
It's "only a bound" but you can pick whatever bound you want,
including=E2=80=94 if you send data equal to the missing amount, then it'll=
be
always successful, but no bandwidth savings. Though if the transport
is unordered (e.g. UDP or non-blocking SCTP) even sending 100% of the
missing amount can save time by eliminating a round trip that might
otherwise be needed for a retransmission.
|
