Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1T1aVX-0000fP-Fk for bitcoin-development@lists.sourceforge.net; Wed, 15 Aug 2012 10:07:23 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.175 as permitted sender) client-ip=209.85.217.175; envelope-from=mh.in.england@gmail.com; helo=mail-lb0-f175.google.com; Received: from mail-lb0-f175.google.com ([209.85.217.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1T1aVU-0003Qw-M7 for bitcoin-development@lists.sourceforge.net; Wed, 15 Aug 2012 10:07:23 +0000 Received: by lban1 with SMTP id n1so742982lba.34 for ; Wed, 15 Aug 2012 03:07:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.104.77 with SMTP id gc13mr18690148lab.31.1345025234106; Wed, 15 Aug 2012 03:07:14 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.114.67.199 with HTTP; Wed, 15 Aug 2012 03:07:14 -0700 (PDT) In-Reply-To: <1344990391.4355.21.camel@bmthinkpad.lan.bluematt.me> References: <1344990391.4355.21.camel@bmthinkpad.lan.bluematt.me> Date: Wed, 15 Aug 2012 12:07:14 +0200 X-Google-Sender-Auth: KT7Mejikvuk215Q03hsefog4dSo Message-ID: From: Mike Hearn To: Matt Corallo Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1T1aVU-0003Qw-M7 Cc: bitcoin-development Subject: Re: [Bitcoin-development] Bloom Filter Implementation X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 10:07:23 -0000 This is great, thanks! A few remarks: If you have to update the filter after every block, IBD will require a round-trip after every single block download instead of doing bulk requests with getblocks. That sounds like it'd kill any performance gains won by the feature. There needs to be a way to do bulk getblocks on hundreds/thousands of blocks at a time and then have the data stream in. Perhaps the server node can update the filter for you, as the rules are deterministic? As you know the remote end will request the transactions given their hashes anyway, why not save the bandwidth for the hashes and the network round-trip by just providing the transactions immediately in the block? I was imagining something like: // A CMerkleTx without the redundant block hash class CLiteMerkleTx : public CTransaction { std::vector vBranch; int nIndex; } class CMerkleBlock { int nVersion; uint256 hashPrevBlock; uint256 hashMerkleRoot; unsigned int nTime; unsigned int nBits; unsigned int nNonce; std::vector vMatchedTxns; }