summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorArnoud Kouwenhoven - Pukaki Corp <arnoud@pukaki.bz>2015-08-05 13:53:52 -0600
committerbitcoindev <bitcoindev@gnusha.org>2015-08-05 19:53:55 +0000
commitbf9dfac63da4e4d22056bf3aa85b84e05fa4a6ab (patch)
treed49518b86e2532e0abd39fd2e3bd0b1b074724b7
parent4e12a46cf99ee7e797cb9349803736ec9a9f75fa (diff)
downloadpi-bitcoindev-bf9dfac63da4e4d22056bf3aa85b84e05fa4a6ab.tar.gz
pi-bitcoindev-bf9dfac63da4e4d22056bf3aa85b84e05fa4a6ab.zip
Re: [bitcoin-dev] Idea: Efficient bitcoin block propagation
-rw-r--r--fc/e4ba6988b61b308590927a24f87011b110b402246
1 files changed, 246 insertions, 0 deletions
diff --git a/fc/e4ba6988b61b308590927a24f87011b110b402 b/fc/e4ba6988b61b308590927a24f87011b110b402
new file mode 100644
index 000000000..140112742
--- /dev/null
+++ b/fc/e4ba6988b61b308590927a24f87011b110b402
@@ -0,0 +1,246 @@
+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--
+