diff options
| author | Arnoud Kouwenhoven - Pukaki Corp <arnoud@pukaki.bz> | 2015-08-05 15:19:17 -0600 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-05 21:19:21 +0000 |
| commit | 0241962cf57e0a1955e540f56de00bd04f43c343 (patch) | |
| tree | f63e2de6c7dec92ce1eb98ae246f701275375300 | |
| parent | 700be1bb55e9d6ac852538ff8cb6c1e4838c02f7 (diff) | |
| download | pi-bitcoindev-0241962cf57e0a1955e540f56de00bd04f43c343.tar.gz pi-bitcoindev-0241962cf57e0a1955e540f56de00bd04f43c343.zip | |
Re: [bitcoin-dev] Idea: Efficient bitcoin block propagation
| -rw-r--r-- | 01/fa727b9fd64969f1f80442514336af4448263c | 191 |
1 files changed, 191 insertions, 0 deletions
diff --git a/01/fa727b9fd64969f1f80442514336af4448263c b/01/fa727b9fd64969f1f80442514336af4448263c new file mode 100644 index 000000000..6f943b3e7 --- /dev/null +++ b/01/fa727b9fd64969f1f80442514336af4448263c @@ -0,0 +1,191 @@ +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 18AC77E + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 5 Aug 2015 21:19:21 +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 F2BC0241 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 5 Aug 2015 21:19:18 +0000 (UTC) +Received: (qmail 29573 invoked by uid 1008); 5 Aug 2015 21:18:08 +0000 +Received: from mail-ob0-f181.google.com (arnoud@pop.affil.co@209.85.214.181) + by mail.affil.co with RC4-SHA encrypted SMTP; 5 Aug 2015 21:18:08 +0000 +Received: by obnw1 with SMTP id w1so41465877obn.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 05 Aug 2015 14:19:17 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.182.246.202 with SMTP id xy10mr9913744obc.64.1438809557211; + Wed, 05 Aug 2015 14:19:17 -0700 (PDT) +Received: by 10.76.83.136 with HTTP; Wed, 5 Aug 2015 14:19:17 -0700 (PDT) +In-Reply-To: <CAAS2fgQLNH+rivNNTFz6xt_9SxO3fFj7-3z7A-_B_2X2x-6M5w@mail.gmail.com> +References: <CALwsPgnnkbfUBhL=Qyspz13pnZ-6RHdaZOGvfLG34JjJRgt2Dw@mail.gmail.com> + <B3546CB9-6A24-474C-8B56-9B1E2D33B470@mattcorallo.com> + <CALwsPgm6xcBfLXZTNTZ40R_s3oUawE0ANZycDWpSo0cXZ+=-Vg@mail.gmail.com> + <CAAS2fgQLNH+rivNNTFz6xt_9SxO3fFj7-3z7A-_B_2X2x-6M5w@mail.gmail.com> +Date: Wed, 5 Aug 2015 15:19:17 -0600 +Message-ID: <CALwsPgm9S3UNd3bEuWreyGS7bcvSD+cXxueoD+F_D9fC=xLz2Q@mail.gmail.com> +From: Arnoud Kouwenhoven - Pukaki Corp <arnoud@pukaki.bz> +To: Gregory Maxwell <gmaxwell@gmail.com> +Content-Type: multipart/alternative; boundary=089e01634d6a8ea04f051c96f431 +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 21:19:21 -0000 + +--089e01634d6a8ea04f051c96f431 +Content-Type: text/plain; charset=UTF-8 + +Thanks for this (direct) feedback. It would make sense that if blocks can +be submitted using ~5kb packets, that no further optimizations would be +needed at this point. I will look into the relay network transmission +protocol to understand how it works! + +I hear that you are saying that this network solves speed of transmission +and thereby (technical) block size issues. Presumably it would solve speed +of block validation too by prevalidating transactions. Assuming this is all +true, and I have no reason to doubt that at this point, I do not understand +why there is any discussion at all about the (technical) impact of large +blocks, or why there are large numbers of miners building on invalid blocks +(SPV mining, https://bitcoin.org/en/alert/2015-07-04-spv-mining), or why +there is any discussion about the speed of block validation (cpu processing +time to verify blocks and transactions in blocks being a limitation). + +Our proposal aims at solving all three issues. + +Now I would be glad if the suggestions we made are already implemented, +especially if that is in a more elegant approach. Great! Yet we still see +all three discussions, which is a surprise if they have been solved. + +On Wed, Aug 5, 2015 at 2:16 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote: + +> On Wed, Aug 5, 2015 at 7:53 PM, Arnoud Kouwenhoven - Pukaki Corp via +> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: +> > 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. +> +> Your understanding is outdated. +> +> The relay network includes an optimized transmission protocol which +> enables sending the "entire" block typically in just a smal number of +> bytes (much smaller than the summaries you suggest, which still leave +> the participants needing to send the block). +> +> E.g. block 000ce90846 was 999950 bytes and the relay network protocol +> sent it using at most 4906 bytes. +> +> No trust is required in this scheme because the entire block is +> communicated using only a couple packets. +> +> The current scheme is highly simplified and its efficiency could be +> increased greatly with small improvements, or if miners created blocks +> in an aware manner.... but with a maximum size blocks turning into 5kb +> with the current setup, there hardly appears to be a reason to do so +> right now. +> +> Ultimately there is no need for information communicated with a block +> at discovery time proportional to the size of the block; with the +> right affordances it can be accomplished with a small constant amount +> of data. +> +> If not for this already being deployed I personally believe the +> network would have already fallen into complete centeralization as a +> response to larger blocks: this was constructed and deployed in order +> to pull the network back from having a single pool with more than half +> the hashrate. +> + +--089e01634d6a8ea04f051c96f431 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Thanks for this (direct) feedback. It would make sense tha= +t if blocks can be submitted using ~5kb packets, that no further optimizati= +ons would be needed at this point. I will look into the relay network trans= +mission protocol to understand how it works!<div><br></div><div>I hear that= + you are saying that this network solves speed of transmission and thereby = +(technical) block size issues. Presumably it would solve speed of block val= +idation too by prevalidating transactions. Assuming this is all true, and I= + have no reason to doubt that at this point, I do not understand why there = +is any discussion at all about the (technical) impact of large blocks, or w= +hy there are large numbers of miners building on invalid blocks (SPV mining= +, <a href=3D"https://bitcoin.org/en/alert/2015-07-04-spv-mining">https://bi= +tcoin.org/en/alert/2015-07-04-spv-mining</a>), or why there is any discussi= +on about the speed of block validation (cpu processing time to verify block= +s and transactions in blocks being a limitation).=C2=A0</div><div><br></div= +><div>Our proposal aims at solving all three issues.</div><div><br></div><d= +iv>Now I would be glad if the suggestions we made are already implemented, = +especially if that is in a more elegant approach. Great! Yet we still see a= +ll three discussions, which is a surprise if they have been solved.<br></di= +v></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, A= +ug 5, 2015 at 2:16 PM, Gregory Maxwell <span dir=3D"ltr"><<a href=3D"mai= +lto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>></span>= + wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor= +der-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Wed, Aug 5, 2= +015 at 7:53 PM, Arnoud Kouwenhoven - Pukaki Corp via<br> +bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bi= +tcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +> Thanks for the reply. My understanding is that the bitcoin relay netwo= +rk is<br> +> a backbone of connected high speed servers to increase the rate at whi= +ch<br> +> transactions and new blocks propagate - and remove a number of delays = +in<br> +> processing. But it would still require the miners to download the enti= +re<br> +> block before building on top of it with any degree of confidence.<br> +<br> +</span>Your understanding is outdated.<br> +<br> +The relay network includes an optimized transmission protocol which<br> +enables sending the "entire" block typically in just a smal numbe= +r of<br> +bytes (much smaller than the summaries you suggest, which still leave<br> +the participants needing to send the block).<br> +<br> +E.g. block 000ce90846 was 999950 bytes and the relay network protocol<br> +sent it using at most 4906 bytes.<br> +<br> +No trust is required in this scheme because the entire block is<br> +communicated using only a couple packets.<br> +<br> +The current scheme is highly simplified and its efficiency could be<br> +increased greatly with small improvements, or if miners created blocks<br> +in an aware manner.... but with a maximum size blocks turning into 5kb<br> +with the current setup, there hardly appears to be a reason to do so<br> +right now.<br> +<br> +Ultimately there is no need for information communicated with a block<br> +at discovery time proportional to the size of the block; with the<br> +right affordances it can be accomplished with a small constant amount<br> +of data.<br> +<br> +If not for this already being deployed I personally believe the<br> +network would have already fallen into complete centeralization as a<br> +response to larger blocks: this was constructed and deployed in order<br> +to pull the network back from having a single pool with more than half<br> +the hashrate.<br> +</blockquote></div><br></div> + +--089e01634d6a8ea04f051c96f431-- + |