Connect to a peer serving the testnet3 blockchain. I tested against a bitcoind 0.17.1-cosmic1 (latest Debian binary running on Ubuntu 18.10), as well as against various random non-pruning testnet3 peers.
Load the BLOOM_UPDATE_ALL bloom filter that matches our wallet. The complete FILTERLOAD message is at the bottom of this report.
Start synching using GETBLOCKS.
It will match tx1 1d72ce53418f4cc33c1e470e186852a92bdc024561dc20a8996d74893c4933e4 in block 1287284. See txn dumps below. Tx1 is a payment into our wallet using a P2WPKH output (index 1). The contained pubkey hash is the element that matches the bloom filter. Because BLOOM_UPDATE_ALL is set, bitcoind should add the outpoint 1d72ce53418f4cc33c1e470e186852a92bdc024561dc20a8996d74893c4933e4:1 to the filter.
Continue synching in chunks of 500 blocks, all on the same connection.
When it arrives at block 1454417, the filter should match tx2 9227f5aa788590a1d3a7f9e79abf74b35fe8a228f5a474d45ac1c2e63f01629c. Tx2 is a payment from our wallet, spending the entire UTXO created by tx1 without any change. This means the filter cannot match any scriptSig (it is empty as per BIP141), nor any scriptPubKey(s) (they only contain foreign pubKeys) nor any witness (BIP37 does not match witnesses). It should match the outpoint inserted above though.
But bitcoind ignores tx2 (doesn't send it via MERKLEBLOCK) and we miss tx2 forever. (A replay could fix this of course, but typically it will run into the same problem over and over again.)
I made sure my client stays connected to the same peer for the whole test.
In the above testcase, the two txns are several months apart. I have created a similar testcase with the transactions just being 1 block apart and in this case all works as expected so both tx1 and tx2 are received in the same chunk of GETBLOCKS responses. This makes me believe the changes to the bloom filter caused by a GETBLOCKS message somehow do not carry over to the next GETBLOCKS message.
I suspect if this turns out to be a bug in bitcoind, it never surfaced because usecases for BLOOM_UPDATE_* have been pretty rare. For SPV wallets however this would be a blocker for native segwit support.
Dump of the two transactions:
tx1:
0.005 BTC total value (sends 0.00 BTC and receives 0.005 BTC)
1d72ce53418f4cc33c1e470e186852a92bdc024561dc20a8996d74893c4933e4
in <empty>
outpoint:f1c1b18646803ad57e70e1d927deb3d0c7dbfedd837664bba1a4e50a702e01d9:0
sequence:fffffffe
out 0[] PUSHDATA(20)[41463c41de6a59414111ee92ad5ab7e3416ffb65] 0.004997 BTC
P2WPKH addr:tb1qg9rrcsw7dfv5zsg3a6f26k4hudqkl7m9s8clsw
out 0[] PUSHDATA(20)[10f6e37cf6f388406229daf0b0c3c18d2e5e4bba] 0.005 BTC Spent by 9227f5aa788590a1d3a7f9e79abf74b35fe8a228f5a474d45ac1c2e63f01629c
P2WPKH addr:tb1qzrmwxl8k7wyyqc3fmtctps7p35h9uja6n9z7kp
tx2:
-0.005 BTC total value (sends 0.005 BTC and receives 0.00 BTC)
9227f5aa788590a1d3a7f9e79abf74b35fe8a228f5a474d45ac1c2e63f01629c
in <empty> 0.005 BTC
outpoint:1d72ce53418f4cc33c1e470e186852a92bdc024561dc20a8996d74893c4933e4:1 hash160:10f6e37cf6f388406229daf0b0c3c18d2e5e4bba
out DUP HASH160 PUSHDATA(20)[ce072408e965b49dcad762eac1910477c5499d6b] EQUALVERIFY CHECKSIG 0.00499 BTC
P2PKH addr:mzJL3ihrhroYj3JKXvPgHU4JmfJ6zsqAVo
Here is the FILTERLOAD message:
fd7d0742cc31a594850e462ab88f0784ba872ed012ed658bb534462cff085718263529829e4c89806789190881e534a06c06dd78500bea2598c0301b9392ff28de0208ae60296c59279885912d001cdcff5249968eba3d28b0c5c4286b32dfd154c4a54897080c89b220422a0400401b8e87264900006d6ef5d0bec8a71ba9245120f8d101e8489c162f648da04a24850b080860e97415d6aa15c670612a896403ba7a2ee6cb1d8522883811730b25f59a24dcad69b2174301160c043637b41fbf11921317dcea2219c85b81ea0c0049e4a1220077f8ed9e29cf743b6d160393b775a81701315bdb831d3390979409e935c857cd22f4d8a6b46a543e54b07f98636a45d1442f28554a310868aa61c07a698f6d48377029270c1fc00e614491c11ae38a090c12986c6e522c401d041f87345c2c3a6eaa582a060e268a9b000020c0f334f836f3d7e8a8a7734eb3059de9b28957524e422ca1c020107641cc1d8008a0d447eb0d9d34c10daaca4e95da0c6f9f0a300b486c4a803659f4df487750a13c385c727189641a2d848518300961971245642ea25ac4eae65c80ec4ba89fea0ac17b23ddd339b0ec3fa95280a62e663359240d1d0607ef006785f014b89523e5ae101018c205085096cd6c4af25bb7009edc205743d453e1c473ba143ced68485cd81a487db7b12043d6679987f132ded79466d4768c17cd2ac9549ce32b4ee2e45b856e3c70bfd47b5bef3f47486c1d8b1430c352c3e0e489c602adc500227354c66d02abe2cddf6149478e24118b7a2c6e42656c4890151218104946b635e12789b94044282ac701abcfb4756022821f83184ae839d74b221a00c08eb18e97c0428194061119c0366c462b43d58714d11217f99e40a17a552357a61e2d4ee4d1e3031e7142a853615301bb36156bbd84687080223bfc487010e74ca28007a924ea6c4bd256bb950b443842d134e5d270a0fa00c0382321a7c8cc8560d5663191ab2e07d5041584c3da29631111360083a8f0a020b0ae8107722919554096a06c107c1b14e71d6eb4ce61b78e495a6405508891038c2136e0169a22a74dd6a30cdd5f3cdd08754f68b293e58a0f22c8d6449c00023d401ea03c485ce7f2fb2c4790f34a33cb93030e814d3a0316bec645dd20c584688ad92d0fe9a9d50225a42304f94e99adb72a47a8815e65f551bb4bb215848663aa488320eccc169704215b9697dd8a16bfad12010fa8e452818b79814782e9478c916a112be09a40717ac2a120455f145285c140615dadb2d5cb46c449600f7d892c65e7520c00853e2862131b7a57560865b12a36fad0da28b35fab787258bd182acd2e90b5dc604b529e88a94c0f003023eb142d18a4772fb1028568c969630fd8f9ced28d8d30bc88b2b25a8ee00c64d6874a228368d6d1e220f1c521e2686869359864ede2f0a1464a55608d047fc527414c38224890182a1826052da47454b7410b25b4150124ae40102029c52af4b25b53a2158205b5c997072704a058a59e18e82e6c43e1810756a00cd8bfa4ee3390569bc81ec7a01946cb9440d4b2ac5c62404192750365fa1752ad10e0e2b40003e1921eb7610082ba5d2c009a207e4c256990f13a20dc8d6516275ad40034809d479827088254c60b80cb1481c7406a41013fc84140c543c30450c8543a581402dca16d050e946b32431b35e2935404725ab90c6de3dbfd61f8a010cc6c61102c2b233b305c67ac46850d042d0f04d127720d24aa02d47614f035c452444f888fc3330508b02082c4e0020e97252cf43539b1c4942394803b45fec30581294c1aad460bc050561b728b441854d9980f7420ac03c12cc4ad57eea5829d4065d7e36448174c008681b02469719afb901c81915fc703d08984b42c17a4dc2116fd27d6e81c073598ee30a98f7dccca21f44a508918a91d47c39a134c158a6ecd0ab1029c1c14d64427f10809a0dc49c21c124ad755082e819447c04a4d481112021dd451b2d27dab12e180199d2828a84a0a9c0dedb16fa0bc8d18b174512d507b008c028f62d26208b1130f0a550f2e071611813b00e6915667c2265dea23080016832415152e23ff42491cc80c4969d40331c8e332ec67e100a42b190644a888a1e0e8dc704aa7614ee64bdaf2d25c128341b2a84a7725e9e8a41a65a6b19a64f034b06da5c45b561c862a361830d1465485c3aca0519149e36dd29f6a6d72216a48b9d561c03a2c1b29e06986be501b81b724777120123d0358cf8b77ce343fa8b12a810eab461917c87006c86836f2428d7bef683901dcc101b39a1493c0cdaf5b934329ac3c2419f652541d18fea574129e800e199b9641b2b7dbd168e1534cce70f004d65e684528060d75d0481ab680a6d886b0a53509edd9841e23468314b99e3d9024138537253a541c18138808cba62731b493a21e0480393005aa7802b3785e84145001722fa93e0040490348c30305e56ee112928c294140afa837a2206ea1b082a005043dcd14452af28f6160d8536b07566e6523b59fdeda8c0a9319846041209a5a0c11b804bc3ba57009f99477a07f38b30810a1c494b6cc1afb5ecb1148c5cf7e38aa8544a12c6aa48601544b9dc0034133a52209039d106c437551605c753923bcc5c2ed08386c06df916b9fe60542ea46c421efaad0a27d6998ce15e172372a0ce3b19766536189767c5e1876e01000000000a8ae7d01