Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.172 as permitted sender)
	client-ip=209.85.217.172; envelope-from=gmaxwell@gmail.com;
	helo=mail-lb0-f172.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAPkFh0uuo=vOiLVTvozPiO7L26A4DpJ9nrKGeQZ+DC6HbO27TQ@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>
Date: Fri, 18 Jul 2014 18:25:44 -0700
Message-ID: <CAAS2fgSfpTmNcexSV6U3wvbdddqZ8Pb0WVYh35jqNkJCMRbBkw@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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Squashing redundant tx data in blocks on
 the wire
Precedence: list

On Fri, Jul 18, 2014 at 5:54 PM, Emin G=C3=BCn Sirer <el33th4x0r@gmail.com>=
 wrote:
> The problem being tackled here is very similar to "set reconciliation,"
> where
> peer A thinks that the set of transactions that should be in the block is
> S_A,

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.

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).