diff options
author | Arnoud Kouwenhoven - Pukaki Corp <arnoud@pukaki.bz> | 2015-08-05 13:53:52 -0600 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-05 19:53:55 +0000 |
commit | bf9dfac63da4e4d22056bf3aa85b84e05fa4a6ab (patch) | |
tree | d49518b86e2532e0abd39fd2e3bd0b1b074724b7 | |
parent | 4e12a46cf99ee7e797cb9349803736ec9a9f75fa (diff) | |
download | pi-bitcoindev-bf9dfac63da4e4d22056bf3aa85b84e05fa4a6ab.tar.gz pi-bitcoindev-bf9dfac63da4e4d22056bf3aa85b84e05fa4a6ab.zip |
Re: [bitcoin-dev] Idea: Efficient bitcoin block propagation
-rw-r--r-- | fc/e4ba6988b61b308590927a24f87011b110b402 | 246 |
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"><<a href=3D"mailto:lf-lists@mattcorallo.= +com" target=3D"_blank">lf-lists@mattcorallo.com</a>></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'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'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'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 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= + <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">bitcoin-dev@lists.linuxfoundation.org</a>> 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-- + |