Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 224F689D for ; Thu, 6 Aug 2015 18:42:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B6CFBE8 for ; Thu, 6 Aug 2015 18:42:38 +0000 (UTC) Received: by igbij6 with SMTP id ij6so16983257igb.1 for ; Thu, 06 Aug 2015 11:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MjXqvWcn89H8EX8dcxRfQCo/J684vifAVct56SEZZoE=; b=ExvbG4W/ImH0rek/FP1CVMP9+nWIoUQRa/S3aqyCTrncmDtlT9ddmt32D65YEcTG0P wYtz0PK0ZKKH5UHJpBPdaAF5he/lXoRppWyEwukg227GXMHSW1Kux63h0b8TzxC5Tq6M AaaZe8H2zJrEDBlrT03hPT9csj98tiMDY7X4pjBfo/nuPAU3CFchaTUxfWjqwgEYZd58 Rj4uvCDKDsBQLRY7DPVpTgPsF2Vz/fdFz77miknpPlxh0uYUbWgneowY2J35H6XwzPmF hGkwQgcMlZnS2FM297FPxx5UO8p0TpWmBu5eNty7X8AodbLRe+8MJ1m9cgg7nLUXh13f p3xw== MIME-Version: 1.0 X-Received: by 10.50.59.242 with SMTP id c18mr5897815igr.66.1438886558243; Thu, 06 Aug 2015 11:42:38 -0700 (PDT) Received: by 10.107.14.136 with HTTP; Thu, 6 Aug 2015 11:42:38 -0700 (PDT) In-Reply-To: <55C3A4BF.1010509@thinlink.com> References: <55C3A4BF.1010509@thinlink.com> Date: Thu, 6 Aug 2015 18:42:38 +0000 Message-ID: From: Gregory Maxwell To: Tom Harding Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW 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 18:42:39 -0000 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 recently using block templates to learn transaction priority be a bit more immune to spam attacks, but its fairly simple. 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.