Topic: When miners do his job with ... a good version of Bitcoin Core = Full but GOOD ! (Read 364 times)
November 20, 2016, 01:33:33 PM
Yep, not only does the low number of 0 tx blocks look good, but it makes nodes easier to run in low bandwidth situations. I used to sometimes close Bitcoin if it's bandwidth got too noisy when I wanted all the bandwidth, that doesn't seem to be a problem since compact blocks (BIP152). It just trickles 2-3 kB/s all day. There are some little enhancements to the compact blocks protocol planned, apparently
November 20, 2016, 12:10:26 PM
it's work ... the BIP152 ... when Mempool is full, it can be purge more quickly and avoid 0 transaction block creation.
perfect.
https://bitcointalksearch.org/topic/2016-08-22-bitcoin-core-v0130-1594659
perfect.
https://bitcointalksearch.org/topic/2016-08-22-bitcoin-core-v0130-1594659
Code:
+Compact Block support (BIP 152)
+-------------------------------
+
+Support for block relay using the Compact Blocks protocol has been implemented
+in PR 8068.
+
+The primary goal is reducing the bandwidth spikes at relay time, though in many
+cases it also reduces propagation delay. It is automatically enabled between
+compatible peers.
+[BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki)
+
+As a side-effect, ordinary non-mining nodes will download and upload blocks
+faster if those blocks were produced by miners using similar transaction
+filtering policies. This means that a miner who produces a block with many
+transactions discouraged by your node will be relayed slower than one with
+only transactions already in your memory pool. The overall effect of such
+relay differences on the network may result in blocks which include widely-
+discouraged transactions losing a stale block race, and therefore miners may
+wish to configure their node to take common relay policies into consideration.
+-------------------------------
+
+Support for block relay using the Compact Blocks protocol has been implemented
+in PR 8068.
+
+The primary goal is reducing the bandwidth spikes at relay time, though in many
+cases it also reduces propagation delay. It is automatically enabled between
+compatible peers.
+[BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki)
+
+As a side-effect, ordinary non-mining nodes will download and upload blocks
+faster if those blocks were produced by miners using similar transaction
+filtering policies. This means that a miner who produces a block with many
+transactions discouraged by your node will be relayed slower than one with
+only transactions already in your memory pool. The overall effect of such
+relay differences on the network may result in blocks which include widely-
+discouraged transactions losing a stale block race, and therefore miners may
+wish to configure their node to take common relay policies into consideration.
Jump to: