Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.54 as permitted sender)
	client-ip=209.85.213.54; envelope-from=gavinandresen@gmail.com;
	helo=mail-yh0-f54.google.com; 
MIME-Version: 1.0
In-Reply-To: <CA+iPb=EaX=bvOjNtZ+LnYTMRLQQ9nFcrefAkBdv8eActoX_b8A@mail.gmail.com>
References: <CA+iPb=EaX=bvOjNtZ+LnYTMRLQQ9nFcrefAkBdv8eActoX_b8A@mail.gmail.com>
Date: Thu, 17 Jul 2014 18:46:52 -0400
Message-ID: <CABsx9T0ag_o_mu=5Q7Ju7s2hO3jz-o5g9FihE9h4B6+ednd2Pg@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Kaz Wesley <keziahw@gmail.com>
Content-Type: multipart/alternative; boundary=20cf304273e0c3595204fe6b6af3
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Squashing redundant tx data in blocks on
 the wire
Precedence: list

--20cf304273e0c3595204fe6b6af3
Content-Type: text/plain; charset=ISO-8859-1

A couple of half-baked thoughts:

On Thu, Jul 17, 2014 at 5:35 PM, Kaz Wesley <keziahw@gmail.com> wrote:

> If there's support for this proposal, I can begin working on the specific
> implementation details, such as the bloom filters, message format, and
> capability advertisment, and draft a BIP once I have a concrete proposal
> for
> what those would look like and a corresponding precise cost/benefit
> analysis.
>

I'd encourage you to code up a prototype first (or at the same time), in
whatever programming language / networking library you're most familiar
with.

Maybe not even using the existing p2p protocol; there could be a
mining-only very-fast-block-propagation network separate from the existing
p2p network.

Combining your optimizations with "broadcast as many near-miss blocks as
bandwidth will allow" on a mining backbone network should allow insanely
fast propagation of most newly solved blocks.

-- 
--
Gavin Andresen

--20cf304273e0c3595204fe6b6af3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">A co=
uple of half-baked thoughts:</div><div class=3D"gmail_quote"><br></div><div=
 class=3D"gmail_quote">On Thu, Jul 17, 2014 at 5:35 PM, Kaz Wesley <span di=
r=3D"ltr">&lt;<a href=3D"mailto:keziahw@gmail.com" target=3D"_blank">keziah=
w@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>If there&#39;s support for this proposa=
l, I can begin working on the specific</div><div>implementation details, su=
ch as the bloom filters, message format, and</div>
<div>capability advertisment, and draft a BIP once I have a concrete propos=
al for</div>

<div>what those would look like and a corresponding precise cost/benefit an=
alysis.</div><span class=3D"HOEnZb"><font color=3D"#888888"><div></div></fo=
nt></span></blockquote></div><br>I&#39;d encourage you to code up a prototy=
pe first (or at the same time), in whatever programming language / networki=
ng library you&#39;re most familiar with.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Maybe not e=
ven using the existing p2p protocol; there could be a mining-only very-fast=
-block-propagation network separate from the existing p2p network.</div><di=
v class=3D"gmail_extra">
<br></div><div class=3D"gmail_extra">Combining your optimizations with &quo=
t;broadcast as many near-miss blocks as bandwidth will allow&quot; on a min=
ing backbone network should allow insanely fast propagation of most newly s=
olved blocks.</div>
<div class=3D"gmail_extra"><br>-- <br>--<br>Gavin Andresen<br>
</div><div class=3D"gmail_extra"><br></div></div>

--20cf304273e0c3595204fe6b6af3--