4
I've seen this option discussed, but I don't have a clear understanding of what is going on. Since this setting appears to reduce node bandwidth by as much as 88%, I assume it somehow communicates to other nodes that this traffic is unwelcome, but I don't understand the mechanism. Can someone elaborate?
3
This allows the bitcoin node to operate similar to a SPV client. These nodes advertise their capabilities to other nodes as they peer with them. A node running in blocksonly mode will indicate that it does not want to receive inv messages from any other peers. Nodes can supply a bloom filter if they are interested in messages for specific address(es), this is also using the same mechanisms that were designed for SPV nodes.
1
I've just read the complete description of the messages in Bitcoin Core, and it seems to me that there is no special announcement the node performs to tell its peers that it doesn't wish to be informed about transactions. I thought that it might announce its disinterest in transactions in the version message, but the service announcements don't seem to include such a flag.
Therefore, it seems to me that the node would just not follow up on inv messages announcing transactions, but only on inv messages announcing blocks. Especially, it doesn't supply any data on receiving a mempool message, but it does seem to serve getblocks requests.
Blocks only is not "similar to SPV". It's more like the opposite of SPV. – Jannes – 2016-06-13T14:04:54.397
2@Jannes: it uses a flag that was introduced in BIP37, to tell the peer "Do not send me transactions until I have uploaded a filter and tell you I'm ready", and then never send a filter. – Pieter Wuille – 2016-06-14T10:45:45.897
1Aah... in that way similar. I was thinking at a higher levels. Get it. Thanks for correcting me. – Jannes – 2016-06-14T11:30:38.467