<blockquote>
  <p>would it be possible for the full node serving this request to attack the Neutrino node by providing a fake block filter that omits certain transactions?</p>
</blockquote>

<p>Yes.  Indeed, the protocol actually specifies that data carrier outputs (<code>OP_RETURN</code> outputs) are always excluded from the filter.</p>

<blockquote>
  <p>Do block filters include a mechanism that enables the thin client to verify that it is an accurate representation of the corresponding block's content?</p>
</blockquote>

<p>The properties of a Golomb-coded set, which is what BIP157/158 uses (not a Bloom filter) are that an honest default filter is guaranteed to match any of the wallet's data that were included in the block chain data used to generate the filter, but that it might also sometimes match wallet data that weren't part of the filter data.   For example:</p>

<ul>
<li>Alice's wallet has the addresses bc1abcd...wxyz</li>
<li>If block 123 includes address bc1abcd...wxyz and a node sends Alice an honest filter, it's guaranteed to generate a match for her</li>
<li>If block 456 doesn't include the address bc1abcd...wxyz, it might still produce a match for Alice's wallet by accident</li>
</ul>

<p>This creates a very simple situation that as long as the lite client has at least one honest peer---an assumption lite clients (SPV clients) depend on to get the most-PoW chain---Alice is guaranteed to always download blocks with transactions interesting to her wallet because one of the filters Alice downloads will be honest.  This is similar in security to BIP37.</p>

<p>Unlike BIP37, BIP157/158 can allow a griefer (Mallory) to stuff a filter full of extraneous data to cause a greater number of matches than indicated by the BIP157/158 false positive rate (which I think is about 1-in-20-million).  Since Alice is probably downloading blocks from a different node than she used to get her filters (for increased privacy), this can create a weak DoS bandwidth vulnerability against honest nodes, like a DNS amplification attack.</p>

<p>Happily, with BIP157/158 filters having such a low false-positive rate, Alice can detect that Mallory is griefing her pretty quickly by noticing that Mallory's filters are resulting in a much higher false positive rate than expected.</p>

<p>Additionally, BIP157/158 filters are deterministic and a small hash commitment to a particular filter can be distributed using a small <code>cfheaders</code> message.  This makes it very bandwidth efficient for Alice to query a large number of nodes for filters at the same block height.  If any of them disagree, Alice can download all the different filters and the corresponding block, check for omissions or high false positive rates, ban deceitful peers, and continue on in relative bliss.  This is much better than BIP37 which requires quite a bit of bandwidth (and even more node CPU cycles) to query a large number of peers.</p>

<blockquote>
  <p>Would it be possible to construct the block filters in a fashion that lying by omission becomes impossible when the thin client is aware of the correct latest block's header already?</p>
</blockquote>

<p>Sort of.  A consensus rule change (possible as a soft fork) could require that a block commit to the filter for that block.  A miner could still create an invalid block with a fake filter, but since miners can just as easily create invalid blocks with fake transactions, there's no advantage to creating fake filters.</p>

CC BY-SA 4.0
2019-01-19T04:51:18.687Z
`Unlike BIP37, BIP157/158 can allow a griefer (Mallory) to stuff a filter full of extraneous data to cause a greater number of matches than indicated by the BIP157/158 false positive rate` I'm not sure this is correct. BIP37 has no restriction on what the node actually returns, it's trivial to short circuit the filtering command to return just everything, and the clients as far as I know have no defense against massive amounts of non-matches. The code I've looked at never even compares the filters to what is returned.
Claris
CC BY-SA 4.0
2019-01-19T20:22:41.930Z
@Anonymous you're absolutely correct that a BIP37 node can return extraneous data. The difference here is that BIP37 clients download data (merkleblocks) from the node that returns extraneous data, whereas BIP157 clients are expected to download data (blocks) from *different* nodes than those that returned filters. So for every byte a BIP37 node causes the client to download, the BIP37 node uses a byte of its bandwidth, but for every byte a BIP157 node causes a client to download, the BIP157 node only needs to use about 0.03 bytes of is bandwidth.  Hence it's like an DNS amplification attack.
David A. Harding
CC BY-SA 4.0
2019-01-18T23:11:46.147Z
2019-01-18T23:20:18.673Z
2019-01-18T23:20:18.673Z
David A. Harding
<p>They can lie to you about the filters, yes. However due to the filters being deterministic you can query other nodes for the hashes of their filters to gauge relative correctness. You can also use a watchtower like service to give a trusted set of the filters in some cases. </p>

<p>The original design document includes an extension for committing to these filters as a consensus rule. It is designed and presented as “levels” which can improve the reliability and security of using client side filtering in this manner. </p>

<blockquote>
  <p>The security model of the oracle bloom filter can be vastly improved
  by instead committing a hash of the BFD inside every block as a soft-
  fork consensus rule change. After this, every node in the network would
  build the filter and validate that the hash in the block is correct,
  then make a conscious choice discard it for space savings or cache the
  data to disk.</p>
</blockquote>

<p><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html" rel="nofollow noreferrer">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html</a></p>

CC BY-SA 4.0
2019-01-18T22:39:31.997Z
2019-01-18T22:39:31.997Z
Claris
<p>When a thin client using BIP157/BIP158 (Neutrino) requests the block filter for the latest block, would it be possible for the full node serving this request to attack the Neutrino node by providing a fake block filter that omits certain transactions?</p>

<p>Do block filters include a mechanism that enables the thin client to verify that it is an accurate representation of the corresponding block's content? Would it be possible to construct the block filters in a fashion that lying by omission becomes impossible when the thin client is aware of the correct latest block's header already?</p>

<security><block-header><thin-clients><sybil-attack><compact-client-side-block-filters>
Can a full node provide a bogus block bloomfilter to a Neutrino node?
Murch
# Can a full node provide a bogus block bloomfilter to a Neutrino node?

(Asked by: username_0 on 2019-01-18)

When a thin client using BIP157/BIP158 (Neutrino) requests the block filter for the latest block, would it be possible for the full node serving this request to attack the Neutrino node by providing a fake block filter that omits certain transactions?

Do block filters include a mechanism that enables the thin client to verify that it is an accurate representation of the corresponding block's content? Would it be possible to construct the block filters in a fashion that lying by omission becomes impossible when the thin client is aware of the correct latest block's header already?

**Tags:** security, block-header, thin-clients, sybil-attack, compact-client-side-block-filters


---

## 2 answers

### Answer by username_1 on 2019-01-18. Score: 2 | Accepted answer

> would it be possible for the full node serving this request to attack the Neutrino node by providing a fake block filter that omits certain transactions?

Yes. Indeed, the protocol actually specifies that data carrier outputs (`OP_RETURN` outputs) are always excluded from the filter.

> Do block filters include a mechanism that enables the thin client to verify that it is an accurate representation of the corresponding block's content?

The properties of a Golomb-coded set, which is what BIP157/158 uses (not a Bloom filter) are that an honest default filter is guaranteed to match any of the wallet's data that were included in the block chain data used to generate the filter, but that it might also sometimes match wallet data that weren't part of the filter data. For example:

* Alice's wallet has the addresses bc1abcd...wxyz
* If block 123 includes address bc1abcd...wxyz and a node sends Alice an honest filter, it's guaranteed to generate a match for her
* If block 456 doesn't include the address bc1abcd...wxyz, it might still produce a match for Alice's wallet by accident

This creates a very simple situation that as long as the lite client has at least one honest peer---an assumption lite clients (SPV clients) depend on to get the most-PoW chain---Alice is guaranteed to always download blocks with transactions interesting to her wallet because one of the filters Alice downloads will be honest. This is similar in security to BIP37.

Unlike BIP37, BIP157/158 can allow a griefer (Mallory) to stuff a filter full of extraneous data to cause a greater number of matches than indicated by the BIP157/158 false positive rate (which I think is about 1-in-20-million). Since Alice is probably downloading blocks from a different node than she used to get her filters (for increased privacy), this can create a weak DoS bandwidth vulnerability against honest nodes, like a DNS amplification attack.

Happily, with BIP157/158 filters having such a low false-positive rate, Alice can detect that Mallory is griefing her pretty quickly by noticing that Mallory's filters are resulting in a much higher false positive rate than expected.

Additionally, BIP157/158 filters are deterministic and a small hash commitment to a particular filter can be distributed using a small `cfheaders` message. This makes it very bandwidth efficient for Alice to query a large number of nodes for filters at the same block height. If any of them disagree, Alice can download all the different filters and the corresponding block, check for omissions or high false positive rates, ban deceitful peers, and continue on in relative bliss. This is much better than BIP37 which requires quite a bit of bandwidth (and even more node CPU cycles) to query a large number of peers.

> Would it be possible to construct the block filters in a fashion that lying by omission becomes impossible when the thin client is aware of the correct latest block's header already?

Sort of. A consensus rule change (possible as a soft fork) could require that a block commit to the filter for that block. A miner could still create an invalid block with a fake filter, but since miners can just as easily create invalid blocks with fake transactions, there's no advantage to creating fake filters.

> **Comments:**
> **username_2**: `Unlike BIP37, BIP157/158 can allow a griefer (Mallory) to stuff a filter full of extraneous data to cause a greater number of matches than indicated by the BIP157/158 false positive rate` I'm not sure this is correct. BIP37 has no restriction on what the node actually returns, it's trivial to short circuit the filtering command to return just everything, and the clients as far as I know have no defense against massive amounts of non-matches. The code I've looked at never even compares the filters to what is returned.  
> **username_1**: @Anonymous you're absolutely correct that a BIP37 node can return extraneous data. The difference here is that BIP37 clients download data (merkleblocks) from the node that returns extraneous data, whereas BIP157 clients are expected to download data (blocks) from *different* nodes than those that returned filters. So for every byte a BIP37 node causes the client to download, the BIP37 node uses a byte of its bandwidth, but for every byte a BIP157 node causes a client to download, the BIP157 node only needs to use about 0.03 bytes of is bandwidth.  Hence it's like an DNS amplification attack.  

---

### Answer by username_2 on 2019-01-18. Score: 4

They can lie to you about the filters, yes. However due to the filters being deterministic you can query other nodes for the hashes of their filters to gauge relative correctness. You can also use a watchtower like service to give a trusted set of the filters in some cases.

The original design document includes an extension for committing to these filters as a consensus rule. It is designed and presented as “levels” which can improve the reliability and security of using client side filtering in this manner.

> The security model of the oracle bloom filter can be vastly improved
> by instead committing a hash of the BFD inside every block as a soft-
> fork consensus rule change. After this, every node in the network would
> build the filter and validate that the hash in the block is correct,
> then make a conscious choice discard it for space savings or cache the
> data to disk.

<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html>


---

