Open andronoob opened 4 years ago
This is more a bitcoinj issue.
The reason for slowdown is most likely the bloom filter getting dirty due to the filter being updated automatically. See the BLOOM_UPDATE_
flags in the BIP37 spec. If chain download switches to a new peer, it sync should resume with high speed.
Sadly with SegWit this problem was amplified, since SegWit inputs don't contain the pubkey any more (and the witnesses are not matched by BIP37). A fix for this would be a new filter matching rule that matches a tx on all output scripts and on the scripts of the outputs being spent by the all inputs. It would improve bloom filter privacy too.
So far no one has volunteered to implement that into Bitcoin Core (and handle the politics involved). I would implement the bitcoinj part.
If chain download switches to a new peer, it sync should resume with high speed.
Restarting the wallet app seemed to achieve this as well, without connecting to a new peer.
How resttaring apps and without connecting dose mettar
I've heard that Bitcoin Core has been deprecating BIP37 bloom filter protocol for quite some time, so that this issue is probably duplicate, sorry.
I have a non-pruning Bitcoin Core 0.20.0 full node running on a PC, with
-peerbloomfilter
enabled. I tried to let my schildbach wallet app on my phone to connect my full node in the LAN as the only trusted peer. It seemed to work well in the beginning, however, the syncing speed would slow down drastically after a while. According to my observation, when the syncing was still not slow, the Bitcoin Core process was intensively reading the hard drive; then the I/O burden suddenly relieved at the time the syncing started to slow down, meanwhile the uploading network traffic also went up significantly.Then I guessed that this was probably an intentional counter measure against the alleged DoS vector? Because it seems that the light-weight client can make a full node "server" really busy with little resource, so that simply uploading the full block data to the client might be a way to "fight back" the potential attacker without breaking legit client completely.
Maybe Bitcoin Core had implemented something like that? I don't know. However I think this should be informed to the user - oh, the wallet on the phone was completely empty/unused, maybe that's the reason which had triggered such countermeasure?