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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1X8ORV-0000OH-Mi
for bitcoin-development@lists.sourceforge.net;
Sat, 19 Jul 2014 06:48:25 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.46 as permitted sender)
client-ip=209.85.215.46; envelope-from=gmaxwell@gmail.com;
helo=mail-la0-f46.google.com;
Received: from mail-la0-f46.google.com ([209.85.215.46])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1X8ORU-0007ww-ST
for bitcoin-development@lists.sourceforge.net;
Sat, 19 Jul 2014 06:48:25 +0000
Received: by mail-la0-f46.google.com with SMTP id b8so3533266lan.33
for <bitcoin-development@lists.sourceforge.net>;
Fri, 18 Jul 2014 23:48:18 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.129.9 with SMTP id ns9mr9542170lbb.23.1405752498162;
Fri, 18 Jul 2014 23:48:18 -0700 (PDT)
Received: by 10.112.35.138 with HTTP; Fri, 18 Jul 2014 23:48:18 -0700 (PDT)
In-Reply-To: <CAPkFh0thLcaAPaa7Xswu2vSxossRDziMCoStzTDWw+e0c3WqTw@mail.gmail.com>
References: <CA+iPb=EaX=bvOjNtZ+LnYTMRLQQ9nFcrefAkBdv8eActoX_b8A@mail.gmail.com>
<CABsx9T0ag_o_mu=5Q7Ju7s2hO3jz-o5g9FihE9h4B6+ednd2Pg@mail.gmail.com>
<CAJHLa0NZRF+1QjSwtwjaTE07NWJ_U-O-DE24=P5eSAutMqTupg@mail.gmail.com>
<CABsx9T2BDBNqvinVNk3FmBRWU7R8jf6Vm6NaH74te0FRCh1O-w@mail.gmail.com>
<CAJHLa0O=eCoyvV19dWgTnYd9Di0wLLZtWmCPidc-dWqPNQv_oQ@mail.gmail.com>
<CA+iPb=H2fkjCxS7-hYqHjFzfMh6onk5RqZMxa8zsXeTn6pQMpA@mail.gmail.com>
<CAJHLa0NRUdAPuKXgKDBmXOs9to7gMpHv9ECCz_hTfZpg7SVVJA@mail.gmail.com>
<CA+iPb=HhGkiuaAxQMvpDpUdeU0uA5unPa_0uHGkS3LrmJzEnyQ@mail.gmail.com>
<CA+iPb=FZS9FxP9uYWHTzLpSVJ2uaOwr4dTQSvYuJjhVYCcJOew@mail.gmail.com>
<CAJHLa0MSdafZiXNH_L8qqH63n3wP5hb0R=EX3SJtsD40Fq_VOA@mail.gmail.com>
<CAPkFh0uuo=vOiLVTvozPiO7L26A4DpJ9nrKGeQZ+DC6HbO27TQ@mail.gmail.com>
<CAAS2fgSfpTmNcexSV6U3wvbdddqZ8Pb0WVYh35jqNkJCMRbBkw@mail.gmail.com>
<CAPkFh0thLcaAPaa7Xswu2vSxossRDziMCoStzTDWw+e0c3WqTw@mail.gmail.com>
Date: Fri, 18 Jul 2014 23:48:18 -0700
Message-ID: <CAAS2fgRRfBtwRuANEvU7VEe2oS3dJ2aZQYU57Brmc6F-uYxePA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= <el33th4x0r@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: 1X8ORU-0007ww-ST
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: Sat, 19 Jul 2014 06:48:25 -0000
On Fri, Jul 18, 2014 at 8:06 PM, Emin G=C3=BCn Sirer <el33th4x0r@gmail.com>=
wrote:
>
>> Most things I've seen working in this space are attempting to minimize
>> the data transfered. At least for the miner-interested case the round
>> complexity is much more important because a single RTT is enough to
>> basically send the whole block on a lot of very relevant paths.
>
> Agreed. Yaron's scheme is magical because it is non-interactive. I send y=
ou
> a packet of O(expected-delta) and you immediately figure out the delta
> without further back and forth communication, each requiring an RTT.
Oh that does sound interesting=E2=80=94 its the property I was trying to
approximate with the FEC.. It achieves the one-shot, but there is
overhead. One plus we have is that we can do some tricks to make some
computational soundness arguments that we'd actually get average
performance on average (e.g. that someone can't author transactions in
such a way as to jam the process).
> In any case, I have no horse here (I think changing the client so it's
> multithreaded is the best way to go), but Yaron's work is pretty cool and
> may be applicable.
Thank you, I've certantly queued the paper for reading.
|
