<p>Compact Blocks in Bitcoin Core provides similar functionality (see <a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki" rel="nofollow">BIP 152</a> for spec). The main improvement is in the way it gets rid of bloom filters, as those add a DoS attack risk.</p>

<p>There's a bit more in commentary from nullc (Gregory Maxwell) in <a href="https://www.reddit.com/r/Bitcoin/comments/4lwtgp/part_2_of_5_xthin_blocks_are_faster_than_standard/" rel="nofollow">this thread on Reddit</a></p>

CC BY-SA 3.0
2016-06-03T08:26:10.127Z
2016-06-03T08:26:10.127Z
Нонн Болдырев
<p><a href="https://forum.bitcoin.com/ama-ask-me-anything/i-m-mike-hearn-creator-of-lighthouse-bitcoinj-and-bitcoin-xt-ask-me-anything-t2207.html">Mike Hearn talked about a patch he applied to BitcoinXT recently in his AMA</a>:</p>

<blockquote>
  <p>I posted a <a href="https://github.com/bitcoinxt/bitcoinxt/pull/91">patch</a> last week that makes XT download blocks as lists of hashes instead of duplicating the transaction data, so a full 1mb block would drop to about ~70 kilobytes, in theory, if you were online for the whole time since the last block. However, the patch needs more work and testing before it can be shipped to users.</p>
</blockquote>

<p>If I understand correctly:</p>

<ul>
<li>Blocks themselves would stay exactly the same.</li>
<li>Transactions only need to be downloaded once (instead of once or twice)</li>
<li>Each node reassembles the block from this "ingredient list"</li>
<li>Missing transactions can be requested from peers by transaction hash.</li>
</ul>

<p>This would reduce the total traffic to transfer a full block roughly from 2MB to 1.07MB. This seems like an obvious improvement of the current status quo which could be introduced cheaply, especially reducing the network load during the peak demand right after a block is found.</p>

<p>Are there any drawbacks that I'm missing?</p>

CC BY-SA 3.0
2015-11-17T17:45:07.387Z
I think the primary drawback is that it makes it harder to build another client from the ground up, because more state needs to be kept in memory when accepting and processing a newly mined block. Otherwise the concept is functionally equivalent to the existing system.
Nayuki
CC BY-SA 3.0
2016-03-31T23:38:17.783Z
@Nayuki: Not sure I understand what you mean. From what I understand regular block propagation would continue to work as before, running the thinblock patch would be optional.
Murch
<network><bitcoin-core-development><bitcoin-xt><block-propagation-time>
Are there drawbacks to the Thin Block patch?
Murch
# Are there drawbacks to the Thin Block patch?

(Asked by: username_0 on 2015-11-10)

[Mike Hearn talked about a patch he applied to BitcoinXT recently in his AMA](https://forum.bitcoin.com/ama-ask-me-anything/i-m-mike-hearn-creator-of-lighthouse-bitcoinj-and-bitcoin-xt-ask-me-anything-t2207.html):

> I posted a [patch](https://github.com/bitcoinxt/bitcoinxt/pull/91) last week that makes XT download blocks as lists of hashes instead of duplicating the transaction data, so a full 1mb block would drop to about ~70 kilobytes, in theory, if you were online for the whole time since the last block. However, the patch needs more work and testing before it can be shipped to users.

If I understand correctly:

* Blocks themselves would stay exactly the same.
* Transactions only need to be downloaded once (instead of once or twice)
* Each node reassembles the block from this "ingredient list"
* Missing transactions can be requested from peers by transaction hash.

This would reduce the total traffic to transfer a full block roughly from 2MB to 1.07MB. This seems like an obvious improvement of the current status quo which could be introduced cheaply, especially reducing the network load during the peak demand right after a block is found.

Are there any drawbacks that I'm missing?

**Tags:** network, bitcoin-core-development, bitcoin-xt, block-propagation-time

> **Comments:**
> **username_1**: I think the primary drawback is that it makes it harder to build another client from the ground up, because more state needs to be kept in memory when accepting and processing a newly mined block. Otherwise the concept is functionally equivalent to the existing system.  
> **username_0**: @username_1: Not sure I understand what you mean. From what I understand regular block propagation would continue to work as before, running the thinblock patch would be optional.  

---

## 1 answers

### Answer by username_2 on 2016-06-03. Score: 1 | Accepted answer

Compact Blocks in Bitcoin Core provides similar functionality (see [BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) for spec). The main improvement is in the way it gets rid of bloom filters, as those add a DoS attack risk.

There's a bit more in commentary from nullc (Gregory Maxwell) in [this thread on Reddit](https://www.reddit.com/r/Bitcoin/comments/4lwtgp/part_2_of_5_xthin_blocks_are_faster_than_standard/)


---

