diff options
| author | Matt Corallo <lf-lists@mattcorallo.com> | 2015-08-06 20:50:32 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-06 20:50:39 +0000 |
| commit | 28c8fdd3bc66902eb67f23d0e038be8f92860133 (patch) | |
| tree | 2fe284b19a23c44591899230fbc0198c53c80e5b | |
| parent | 1be78e8f8279970c6d27ddc45e6b88a4f7e61d63 (diff) | |
| download | pi-bitcoindev-28c8fdd3bc66902eb67f23d0e038be8f92860133.tar.gz pi-bitcoindev-28c8fdd3bc66902eb67f23d0e038be8f92860133.zip | |
Re: [bitcoin-dev] Idea: Efficient bitcoin block propagation
| -rw-r--r-- | fd/1b219a52334d583de770a64c32567ec7868231 | 112 |
1 files changed, 112 insertions, 0 deletions
diff --git a/fd/1b219a52334d583de770a64c32567ec7868231 b/fd/1b219a52334d583de770a64c32567ec7868231 new file mode 100644 index 000000000..4cc6e91be --- /dev/null +++ b/fd/1b219a52334d583de770a64c32567ec7868231 @@ -0,0 +1,112 @@ +Return-Path: <lf-lists@mattcorallo.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 7199C8EB + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 6 Aug 2015 20:50:39 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DC19A1A5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 6 Aug 2015 20:50:38 +0000 (UTC) +Received: from [10.64.3.246] (unknown [79.143.111.208]) + by mail.bluematt.me (Postfix) with ESMTPSA id B96915706C; + Thu, 6 Aug 2015 20:50:36 +0000 (UTC) +In-Reply-To: <CAAS2fgRoapt+z4fQd53NDGKWwZD=JLFefNCopS6u4SKrhN9A=A@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> + <CALwsPgm9S3UNd3bEuWreyGS7bcvSD+cXxueoD+F_D9fC=xLz2Q@mail.gmail.com> + <CAAS2fgSXWzCv=4cF=0bwL9+udzBHSPR7goL3U_c1NjS22dpWzQ@mail.gmail.com> + <CAKzdR-qPtPsxAXsmUX=vTkq-ro=EAmH7M8nL_Px_b4D4Z0WAXg@mail.gmail.com> + <55C3A4BF.1010509@thinlink.com> + <CAAS2fgRoapt+z4fQd53NDGKWwZD=JLFefNCopS6u4SKrhN9A=A@mail.gmail.com> +MIME-Version: 1.0 +Content-Transfer-Encoding: 8bit +Content-Type: text/plain; + charset=UTF-8 +From: Matt Corallo <lf-lists@mattcorallo.com> +Date: Thu, 06 Aug 2015 20:50:32 +0000 +To: Gregory Maxwell <gmaxwell@gmail.com>, + Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>, + Tom Harding <tomh@thinlink.com> +Message-ID: <5C79A979-5D68-4A1C-B33A-177212506D24@mattcorallo.com> +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham + version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Cc: 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: Thu, 06 Aug 2015 20:50:39 -0000 + + + +On August 6, 2015 8:42:38 PM GMT+02:00, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: +>On Thu, Aug 6, 2015 at 6:17 PM, Tom Harding via bitcoin-dev +><bitcoin-dev@lists.linuxfoundation.org> wrote: +>> - Will the relay network at least validate block version numbers in +>the +>> future? +> +>It already validates block version numbers. +> +>It only relays valid transactions. +> +>Although, the block relaying itself is explicitly "unvalidated" and +>the software client can only usefully be used with a mempool +>maintaining full node (otherwise it doesn't provide much value, +>because the node must wait to validate the things). ... but that +>doesn't actually mean no validation at all is performed, many +>stateless checks are performed. +> +>On Thu, Aug 6, 2015 at 5:16 PM, Sergio Demian Lerner via bitcoin-dev +><bitcoin-dev@lists.linuxfoundation.org> wrote: +>> Is there any up to date documentation about TheBlueMatt relay network +>> including what kind of block compression it is currently doing? +>(apart from +>> the source code) +> +>I don't know if Matt has an extensive writeup. But the basic +>optimization it performs is trivial. I wouldn't call it compression, +>though it does have some analog to RTP "header compression". +> +>All it does is relay transactions verified by a local node and keeps a +>FIFO of the relayed transactions in both directions, which is +>synchronous on each side. +> +>When a block is recieved on either side, it replaces transactions with +>their indexes in the FIFO and relays it along. Transactions not in the +>fifo are escaped and sent whole. On the other side the block is +>reconstructed using the stored data and handed to the node (where the +>preforwarded transactions would have also been pre-validated). +> +>There is some more than basic elaboration for resource management +>(e.g. multiple queues for different transaction sizes)-- and more + +No, just one queue, but it has a count-of-oversize-txn-limit, in addition to a size. + +>recently using block templates to learn transaction priority be a bit +>more immune to spam attacks, but its fairly simple. + +Except it doesn't really work :( (see https://github.com/TheBlueMatt/RelayNode/issues/12#issuecomment-128234446) + +>Much better could be done about intelligently managing the queues or +>efficiently transmitting the membership sets, etc. It's just +>basically the simplest thing that isn't completely stupid. + +Patches welcome :) (read the issues list first... Rewriting the protocol from scratch is by far not the biggest win here). + +Matt + |