From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7199C8EB for ; 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 ; 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: References: <55C3A4BF.1010509@thinlink.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Matt Corallo Date: Thu, 06 Aug 2015 20:50:32 +0000 To: Gregory Maxwell , Gregory Maxwell via bitcoin-dev , Tom Harding 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: >On Thu, Aug 6, 2015 at 6:17 PM, Tom Harding via bitcoin-dev > 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 > 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