path: root/fc/e4ba6988b61b308590927a24f87011b110b402

Return-Path: <arnoud@pukaki.bz>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 94FD5486
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  5 Aug 2015 19:53:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.affil.co (mail.affil.co [75.101.133.5])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 81E117C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  5 Aug 2015 19:53:54 +0000 (UTC)
Received: (qmail 29428 invoked by uid 1008); 5 Aug 2015 19:52:43 +0000
Received: from mail-oi0-f41.google.com (arnoud@pop.affil.co@209.85.218.41)
	by mail.affil.co with RC4-SHA encrypted SMTP; 5 Aug 2015 19:52:43 +0000
Received: by oihn130 with SMTP id n130so28505753oih.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 05 Aug 2015 12:53:53 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.202.186.132 with SMTP id k126mr9370150oif.60.1438804432997; 
	Wed, 05 Aug 2015 12:53:52 -0700 (PDT)
Received: by 10.76.83.136 with HTTP; Wed, 5 Aug 2015 12:53:52 -0700 (PDT)
In-Reply-To: <B3546CB9-6A24-474C-8B56-9B1E2D33B470@mattcorallo.com>
References: <CALwsPgnnkbfUBhL=Qyspz13pnZ-6RHdaZOGvfLG34JjJRgt2Dw@mail.gmail.com>
	<B3546CB9-6A24-474C-8B56-9B1E2D33B470@mattcorallo.com>
Date: Wed, 5 Aug 2015 13:53:52 -0600
Message-ID: <CALwsPgm6xcBfLXZTNTZ40R_s3oUawE0ANZycDWpSo0cXZ+=-Vg@mail.gmail.com>
From: Arnoud Kouwenhoven - Pukaki Corp <arnoud@pukaki.bz>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary=001a113cd8522153af051c95c337
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Arnoud Kouwenhoven - Pukaki Corp via bitcoin-dev
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Idea: Efficient bitcoin block propagation
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2015 19:53:55 -0000

--001a113cd8522153af051c95c337
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for the reply. My understanding is that the bitcoin relay network is
a backbone of connected high speed servers to increase the rate at which
transactions and new blocks propagate - and remove a number of delays in
processing. But it would still require the miners to download the entire
block before building on top of it with any degree of confidence. With a
tweak to only send the required information for other miners to build on
top of that block, this is a step towards what we propose, yet would
require trust that the header information sent is accurate. The bitcoin
relay network website states that blocks are not fully verified and should
be checked by the miners before building on top of them.

What we propose is more complex (granted!), yet that complexity serves a
purpose. We reduce (and hopefully eliminate) the adverse incentive to
entice miners to build on inaccurate data. This is achieved by making the
financial losses of fake messages outweigh the financial gains of such
attack vectors. It could also help in the block size debate if this
proposed solution would eliminate the disadvantages of large blocks.

On Wed, Aug 5, 2015 at 1:27 PM, Matt Corallo <lf-lists@mattcorallo.com>
wrote:

> See-also: Bitcoinrelaynetwork.org. It's already in use my the majority of
> large miners, is publicly available to anyone, and the protocol is rather
> simple and the client could be tweaked easily to keep exactly it's block
> ready to quickly relay to the nearest server (ie only have to relay the
> header, the coinbase transaction, and only small other data... Experience
> shows this is really easy to fit into one packet on the wire). It's not
> nearly as complicated as your suggestion, but may still marginally favor
> well-connected miners, but hopefully not much (when you're taking about
> single packets, it should all be latency, and the servers are well
> distributed). If you feel so inclined, there are some todos to make it
> really meet is efficiency limits filled on
> github.com/TheBlueMatt/RelayNode, feel free to rewrite the protocol if
> you really want :).
>
> Matt
>
> On August 5, 2015 9:07:44 PM GMT+02:00, Arnoud Kouwenhoven - Pukaki Corp
> via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hello all.
>>
>> We=E2=80=99d like to share an idea we have to dramatically increase the =
bitcoin
>> block propagation speed after a new block has been mined for the first t=
ime.
>>
>> Efficient bitcoin block propagation
>> A proposed solution to provide near-instantaneous block propagation on
>> the bitcoin network, even with slow network connections or large block
>> sizes. Increasing mining efficiency for everyone while decreasing
>> transaction confirmation times and strengthening the distributed nature =
of
>> bitcoin.
>>
>> Short summary: we propose to introduce bitcoin-backed guarantees
>> (=E2=80=9CGuarantee Messages=E2=80=9D) between miners. This would allow =
miners to mine on
>> blocks that are not yet fully transmitted. This reduces the effect of sl=
ow
>> internet connections, leveling the playing field between the 1st world
>> fiberoptic datacenter miners and the rest of the world. We also believe =
it
>> strengthens the bitcoin network by using existing processing power that =
is
>> currently wasted into further securing the blockchain, and it reduces th=
e
>> likelihood of transactions becoming confirmed, then unconfirmed and then
>> -hopefully- confirmed again (due to different miners finding competing
>> blocks with different transactions at approx the same time).
>>
>> It is possible to implement our idea as a fork of bitcoind, or as layer
>> between the standard bitcoind and the mining equipment. In the future it
>> could be incorporated in the bitcoin core if and when that becomes a
>> priority, but that step would not make sense until it becomes a priority=
.
>>
>> There are a lot of nuances in this idea, and the first reaction is quite
>> probably that this is a crazy idea. We have attempted to address the mos=
t
>> important nuances in our proposal, which is currently at v.0.2.
>>
>> We cannot guarantee that there are no =E2=80=98hidden devils in the deta=
ils=E2=80=99 and
>> we invite you to be critical in a friendly and constructive manner. We w=
ill
>> do our best to answer all questions that arise.
>>
>> The =E2=80=98official=E2=80=99 proposal is at:
>> PDF: http://pukaki.bz/efficient-bitcoin-block-propagation-v.0.2.pdf
>> HTML: http://pukaki.bz/efficient-bitcoin-block-propagation-v.0.2.html
>>
>> -- Arnoud Kouwenhoven
>>
>> ------------------------------
>>
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>

--001a113cd8522153af051c95c337
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for the reply. My understanding is that the bitcoin=
 relay network is a backbone of connected high speed servers to increase th=
e rate at which transactions and new blocks propagate - and remove a number=
 of delays in processing. But it would still require the miners to download=
 the entire block before building on top of it with any degree of confidenc=
e. With a tweak to only send the required information for other miners to b=
uild on top of that block, this is a step towards what we propose, yet woul=
d require trust that the header information sent is accurate. The bitcoin r=
elay network website states that blocks are not fully verified and should b=
e checked by the miners before building on top of them.<div><br></div><div>=
What we propose is more complex (granted!), yet that complexity serves a pu=
rpose. We reduce (and hopefully eliminate) the adverse incentive to entice =
miners to build on inaccurate data. This is achieved by making the financia=
l losses of fake messages outweigh the financial gains of such attack vecto=
rs. It could also help in the block size debate if this proposed solution w=
ould eliminate the disadvantages of large blocks.</div></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Wed, Aug 5, 2015 at 1:27 PM,=
 Matt Corallo <span dir=3D"ltr">&lt;<a href=3D"mailto:lf-lists@mattcorallo.=
com" target=3D"_blank">lf-lists@mattcorallo.com</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div>See-also: <a href=3D"http://Bitcoinrelayn=
etwork.org" target=3D"_blank">Bitcoinrelaynetwork.org</a>. It&#39;s already=
 in use my the majority of large miners, is publicly available to anyone, a=
nd the protocol is rather simple and the client could be tweaked easily to =
keep exactly it&#39;s block ready to quickly relay to the nearest server (i=
e only have to relay the header, the coinbase transaction, and only small o=
ther data... Experience shows this is really easy to fit into one packet on=
 the wire). It&#39;s not nearly as complicated as your suggestion, but may =
still marginally favor well-connected miners, but hopefully not much (when =
you&#39;re taking about single packets, it should all be latency, and the s=
ervers are well distributed). If you feel so inclined, there are some todos=
 to make it really meet is efficiency limits filled on <a href=3D"http://gi=
thub.com/TheBlueMatt/RelayNode" target=3D"_blank">github.com/TheBlueMatt/Re=
layNode</a>, feel free to rewrite the protocol if you really want
:).<br>
<br>
Matt<br><br><div class=3D"gmail_quote"><div><div class=3D"h5">On August 5, =
2015 9:07:44 PM GMT+02:00, Arnoud Kouwenhoven - Pukaki Corp via bitcoin-dev=
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div></div><block=
quote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div><div class=3D"h5">
<div dir=3D"ltr">Hello all.<br><br>We=E2=80=99d like to share an idea we ha=
ve to dramatically increase the bitcoin block propagation speed after a new=
 block has been mined for the first time.<br><br>Efficient bitcoin block pr=
opagation<br>A proposed solution to provide near-instantaneous block propag=
ation on the bitcoin network, even with slow network connections or large b=
lock sizes. Increasing mining efficiency for everyone while decreasing tran=
saction confirmation times and strengthening the distributed nature of bitc=
oin.<br><br>Short summary: we propose to introduce bitcoin-backed guarantee=
s (=E2=80=9CGuarantee Messages=E2=80=9D) between miners. This would allow m=
iners to mine on blocks that are not yet fully transmitted. This reduces th=
e effect of slow internet connections, leveling the playing field between t=
he 1st world fiberoptic datacenter miners and the rest of the world. We als=
o believe it strengthens the bitcoin network by using existing processing p=
ower that is currently
wasted into further securing the blockchain, and it reduces the likelihood =
of transactions becoming confirmed, then unconfirmed and then -hopefully- c=
onfirmed again (due to different miners finding competing blocks with diffe=
rent transactions at approx the same time).<br><br>It is possible to implem=
ent our idea as a fork of bitcoind, or as layer between the standard bitcoi=
nd and the mining equipment. In the future it could be incorporated in the =
bitcoin core if and when that becomes a priority, but that step would not m=
ake sense until it becomes a priority.<br><br>There are a lot of nuances in=
 this idea, and the first reaction is quite probably that this is a crazy i=
dea. We have attempted to address the most important nuances in our proposa=
l, which is currently at v.0.2.<br><br>We cannot guarantee that there are n=
o =E2=80=98hidden devils in the details=E2=80=99 and we invite you to be cr=
itical in a friendly and constructive manner. We will do our best to answer=
 all questions that
arise.<br><br>The =E2=80=98official=E2=80=99 proposal is at:<br>PDF: <a hre=
f=3D"http://pukaki.bz/efficient-bitcoin-block-propagation-v.0.2.pdf" target=
=3D"_blank">http://pukaki.bz/efficient-bitcoin-block-propagation-v.0.2.pdf<=
/a><br>HTML: <a href=3D"http://pukaki.bz/efficient-bitcoin-block-propagatio=
n-v.0.2.html" target=3D"_blank">http://pukaki.bz/efficient-bitcoin-block-pr=
opagation-v.0.2.html</a><br><div><br></div><div>-- Arnoud Kouwenhoven</div>=
</div>
<p style=3D"margin-top:2.5em;margin-bottom:1em;border-bottom:1px solid #000=
"></p></div></div><pre><hr><br>bitcoin-dev mailing list<br><a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@list=
s.linuxfoundation.org</a><br><a href=3D"https://lists.linuxfoundation.org/m=
ailman/listinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundatio=
n.org/mailman/listinfo/bitcoin-dev</a><br></pre></blockquote></div></div></=
blockquote></div><br></div>

--001a113cd8522153af051c95c337--