Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.48 as permitted sender)
	client-ip=209.85.219.48; envelope-from=el33th4x0r@gmail.com;
	helo=mail-oa0-f48.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAAS2fgSfpTmNcexSV6U3wvbdddqZ8Pb0WVYh35jqNkJCMRbBkw@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>
Date: Fri, 18 Jul 2014 23:06:21 -0400
Message-ID: <CAPkFh0thLcaAPaa7Xswu2vSxossRDziMCoStzTDWw+e0c3WqTw@mail.gmail.com>
From: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= <el33th4x0r@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8f83a7c98c5a7f04fe8328d9
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Squashing redundant tx data in blocks on
 the wire
Precedence: list

--e89a8f83a7c98c5a7f04fe8328d9
Content-Type: text/plain; charset=UTF-8

> 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 you
a packet of O(expected-delta) and you immediately figure out the delta
without further back and forth communication, each requiring an RTT.

> I know much better is possible (see up-thread where I linked to an old
> proposal to use forward error correction to transfer with low data
> transfer (but not optimal) and negligible probability of needing a
> round-trip, with a tradeoff for more overhead for lower roundtrip
> probability).

FEC schemes are both fairly complex, because the set is constantly
changing, and (if i understand your suggestion correctly) they add
additional metadata overhead (albeit mostly during tx propagation). Set
reconciliation is near optimal.

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.

- egs

--e89a8f83a7c98c5a7f04fe8328d9
Content-Type: text/html; charset=UTF-8

<p dir="ltr"><br>
&gt; Most things I&#39;ve seen working in this space are attempting to minimize<br>
&gt; the data transfered. At least for the miner-interested case the round<br>
&gt; complexity is much more important because a single RTT is enough to<br>
&gt; basically send the whole block on a lot of very relevant paths.</p>
<p dir="ltr">Agreed. Yaron&#39;s scheme is magical because it is non-interactive. I send you a packet of O(expected-delta) and you immediately figure out the delta without further back and forth communication, each requiring an RTT.</p>

<p dir="ltr">&gt; I know much better is possible (see up-thread where I linked to an old<br>
&gt; proposal to use forward error correction to transfer with low data<br>
&gt; transfer (but not optimal) and negligible probability of needing a<br>
&gt; round-trip, with a tradeoff for more overhead for lower roundtrip<br>
&gt; probability).</p>
<p dir="ltr">FEC schemes are both fairly complex, because the set is constantly changing, and (if i understand your suggestion correctly) they add additional metadata overhead (albeit mostly during tx propagation). Set reconciliation is near optimal. </p>

<p dir="ltr">In any case, I have no horse here (I think changing the client so it&#39;s multithreaded is the best way to go), but Yaron&#39;s work is pretty cool and may be applicable.</p>
<p dir="ltr">- egs</p>

--e89a8f83a7c98c5a7f04fe8328d9--