summaryrefslogtreecommitdiff
path: root/82/dc070f7e2cf84fb8c7feff91368b50769ef231
blob: 66293777f3beb7e75cb6baa6b1fe21157a80a4f0 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CANEZrP1BtD6Ps5h2zaxE5ePVhXtT6bXmpRw54+Fg7yWtJFD+=A@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Matt Corallo <bitcoin-list@bluematt.me>
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 <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bloom Filter Implementation
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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<uint256> vBranch;
  int nIndex;
}

class CMerkleBlock {
    int nVersion;
    uint256 hashPrevBlock;
    uint256 hashMerkleRoot;
    unsigned int nTime;
    unsigned int nBits;
    unsigned int nNonce;

    std::vector<CLiteMerkleTx> vMatchedTxns;
}