BIP 37 automatic filter update not inserting outputs

I’m having a problem with bloom filters when using the getdata message.

As I understand BIP 37, setting the bloom filter on a connection using the loadfilter message with flag BLOOM_UPDATE_P2PUBKEY_ONLY set, the responding client automatically inserts all outpoints (TXID and output index) in the bloom filter of transactions matching the filter. However, when I attempt to do exactly this, the node only ever sends transactions containing outputs TO the address I am filtering for, never transaction that contain outputs FROM the address I am filtering for.

My approach is as follows:

  1. Add the following public key to the bloom filter: 1JbFvyaMyHHmvvjc54h4YARq3uoX2ZZ4Qj (randomly picked)
  2. Send the filterload message containing the filter (as seen in the wireshark snippet below).

    Bitcoin protocol Packet magic: 0xf9beb4d9 Command name: filterload Payload Length: 261 Payload checksum: 0x2bb02c45 Filterload message     Filter         Count: 251         Data: 000000040004010000000100000000000000020000400000...     nHashFunc: 13     nTweak: 0x1a689ff4     nFlags: BLOOM_UPDATE_P2PUBKEY_ONLY (0x02) 
  3. Send the getdata message with the hash of all blocks containing transactions to and from the wallet (which I have identified on a block explorer for the purpose of testing this). The inventories are typed MSG_FILTERED_BLOCK.

The node responds with the following messages in order:

MerkleBlock: 000000000000000001201ab2679db7c87a432967c060596bad0ac093dac94111 Tx:......... 187b00588e8d7844c405da9a15d78dbd7ebb9b2887fb5aace6651719fede923e Tx:......... dbbca0d839435ac77db65378a9607d17b0aa965f3027d84dcf0ee5115dc8d32f Tx:......... 17c12f45956082a913c0c862d573cf067fa5ee96ba5b954914371da6bef51f7f Tx:......... 36cce25d34a5da0f7d69253743eae7bb7c576e5543d0eb16db0f72967edb4bc6 Tx:......... 6ea48c6286b1691cd1ecec271a3f52a3fe099467bb6c926b41ba8942e21d4aa6 MerkleBlock: 0000000000000000049ee67931f6d4970a7d06b14b8aadd406223ab65efe5025 MerkleBlock: 0000000000000000019f3fc2c8da43e8a81373ae189ace4caec6c59969f46ff6 MerkleBlock: 000000000000000000f67dad206798db2e6c5dffec84d213397784be894e66fa 

The 5 transactions in the list are correct, as the contain outputs targeting said wallet. However, block 0000000000000000019f3… contains transactions with inputs from said wallet, but the merkleblock message of this block is not followed by these transactions. Shouldn’t the node add the outputs of these 5 transactions to the bloom filter, and thereby match the later transactions containing inputs pointing at them?

I have confirmed that the node is in possession of the relevant transactions. If i load the filter manually, adding the outputs myself, this works as intended.

Am I misunderstanding how BIP 37 is used?

Recent Questions – Bitcoin Stack Exchange

Why Satoshi’s Identity Matters & Why It’s Irrelevant for Bitcoin

There is one credible argument about why it is important to know Satoshi Nakamoto’s identity. His public wallets will account for about 5.5 % of the total number of bitcoins which will be in circulation after the 21 millionth – the last- bitcoin has been mined in approximately the year 2140. That theoretically could undermine […]

The post Why Satoshi’s Identity Matters & Why It’s Irrelevant for Bitcoin appeared first on CCN: Financial Bitcoin & Cryptocurrency News.

News – CCN: Financial Bitcoin & Cryptocurrency News

Would this scheme allow faster verification of transactions? (Multiple parallel block chains)

One issue with one block chain is that it needs to be globally synchronized. One way to elevate this would be to use multiblock chains.

Namely, we can imagine that there are N block chains, working in parallel. To make double spending impossible, a you can only spend a total of 1/N of your total money on each chain. (If they need to spend more, you can do so on multiple chains. This is slower, but hopefully you don’t need to do that as often. If, for example, there 10 chains, you have 100 units, and you are buying something for 15 units, you would spend 10 on one chain and 5 on another.)

After about 10 blocks or so (specifically when it happens is unspecified for now), a meta-block is mined that ties the chains together. This resets the 1/N limit, and allows money earned on one block to spent on the others. Otherwise, it would just be N different currencies.

Each individual block chain can go faster, since they will involve only 1/N of the community. More total blocks also means miners are rewarded more often, and more spread out.

Would this work? Would it verify transactions more often? Do any currencies currently use this?

Recent Questions – Bitcoin Stack Exchange

How does each miner know when to create a block?

I have been trying to understand the protocol and reading related documents, there is a point where i get stuck.

As far as i understand (correct me if not), when a transaction occurs, it is broadcast to the network and some miners receive it. When a certain number of transactions are reached, they are packed in a block and hash race begins.

What i fail to understand is; in this scheme, don’t all the miners have to be in perfect memory coherence and time sync, so that they know when a block is to be sealed and start to iterate for hashes? Or do they not need to mine and hash the same global block, but have separate blocks which are later validated by other miners and interblock transaction collisions don’t matter?

I know i misunderstand a very basic point in the protocol, but i can’t figure what.

Recent Questions – Bitcoin Stack Exchange