<p>The answer partially depends on on what you mean by "how bitcoin propagates" and "improvements"-- <a href="https://bitcoin.stackexchange.com/a/56494">Fibre</a> transmits blocks vanishingly close to the lowest latency possible, but at the expense of using extra bandwidth. It doesn't seems likely that significantly greater protocol wise improvement to latency is possible, beyond more widespread usage of it.</p>

<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki" rel="noreferrer">BIP 152</a>, avoids the bandwidth waste, but doesn't achieve quite as as low a latency by default.  The bandwidth usage of BIP152-like transmission could be improved further, but improvements seem kinda pointless: Right now with BIP-152 blocks are transferred with an average of 11802 bytes each... I have code that reduces it to about 550 bytes/block on average, at considerable CPU expense. But who really cares about saving 1.54 MB/day against a >>288MB background (transaction data) except perhaps for specialized applications like satellite transmission that use their own protocols?</p>

<p>On the other hand, transaction relay clearly <a href="https://bitcointalk.org/index.php?topic=1377345.0" rel="noreferrer">has room for improvement</a>. The existing approach is not very efficient especially for nodes with many peers. The issue there is that to be robust against malicious peers nodes announce all transactions to all peers. Transactions are announced by sending short hashes rather than whole transactions, but this still results in a ton of duplication. Effectively Bitcoin nodes use O(peers*transactions) bandwidth for tx relay, the use of short inv hashes only shrinks the bandwidth a constant factor (of 10-ish). A long time back I proposed <a href="https://people.xiph.org/~greg/mempool_sync_relay.txt" rel="noreferrer">using set reconciliation</a> (also described on the forum post above in less detail) to make the relay of lose transactions more efficient without compromising robustness. Gleb Naumenko, Pieter Wuille, and I have spent much of the last year designing and implementing practical protocol based on this idea and should have something out somewhat soon.</p>

<p>Relay can also be improved in ways other than bandwidth efficiency. E.g. There have been several recent efforts to improve the privacy of TX relay, including the outbound peer grouping in 0.17 and the ongoing work on low fanout relay in dandelion. </p>

CC BY-SA 4.0
2018-11-11T22:00:18.920Z
2018-11-11T22:00:18.920Z
G. Maxwell
<p>As of 2018 what are the known improvements that could be made to how bitcoin propagates its transactions and blocks?</p>

CC BY-SA 4.0
2018-11-11T22:00:50.857Z
Someone asked this on reddit: https://www.reddit.com/r/Bitcoin/comments/9w7i95/are_there_any_improvements_that_could_be_made_to/
G. Maxwell
<network><relay><transaction-propagation><compact-blocks><fibre>
Improvements that could be made to how bitcoin propagates its transactions and blocks?
G. Maxwell
# Improvements that could be made to how bitcoin propagates its transactions and blocks?

(Asked by: username_0 on 2018-11-11)

As of 2018 what are the known improvements that could be made to how bitcoin propagates its transactions and blocks?

**Tags:** network, relay, transaction-propagation, compact-blocks, fibre

> **Comments:**
> **username_0**: Someone asked this on reddit: https://www.reddit.com/r/Bitcoin/comments/9w7i95/are_there_any_improvements_that_could_be_made_to/  

---

## 1 answers

### Answer by username_0 on 2018-11-11. Score: 9 | Accepted answer

The answer partially depends on on what you mean by "how bitcoin propagates" and "improvements"-- [Fibre](https://bitcoin.stackexchange.com/a/56494) transmits blocks vanishingly close to the lowest latency possible, but at the expense of using extra bandwidth. It doesn't seems likely that significantly greater protocol wise improvement to latency is possible, beyond more widespread usage of it.

[BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki), avoids the bandwidth waste, but doesn't achieve quite as as low a latency by default. The bandwidth usage of BIP152-like transmission could be improved further, but improvements seem kinda pointless: Right now with BIP-152 blocks are transferred with an average of 11802 bytes each... I have code that reduces it to about 550 bytes/block on average, at considerable CPU expense. But who really cares about saving 1.54 MB/day against a >>288MB background (transaction data) except perhaps for specialized applications like satellite transmission that use their own protocols?

On the other hand, transaction relay clearly [has room for improvement](https://bitcointalk.org/index.php?topic=1377345.0). The existing approach is not very efficient especially for nodes with many peers. The issue there is that to be robust against malicious peers nodes announce all transactions to all peers. Transactions are announced by sending short hashes rather than whole transactions, but this still results in a ton of duplication. Effectively Bitcoin nodes use O(peers\*transactions) bandwidth for tx relay, the use of short inv hashes only shrinks the bandwidth a constant factor (of 10-ish). A long time back I proposed [using set reconciliation](https://people.xiph.org/~greg/mempool_sync_relay.txt) (also described on the forum post above in less detail) to make the relay of lose transactions more efficient without compromising robustness. Gleb Naumenko, Pieter Wuille, and I have spent much of the last year designing and implementing practical protocol based on this idea and should have something out somewhat soon.

Relay can also be improved in ways other than bandwidth efficiency. E.g. There have been several recent efforts to improve the privacy of TX relay, including the outbound peer grouping in 0.17 and the ongoing work on low fanout relay in dandelion.


---

