<blockquote>
  <p>How does this change your node's interaction with its peers? Do peers send data that exceeds your node's preferences and your node drops that data upon arrival or does your node inform its peers what to send?</p>
</blockquote>

<p>The protocol supports a fee filtering command, simply, only relay transactions which meet a specific feerate and nothing below. This prevents pointless relaying of transactions which would result in immediate eviction from the memool. </p>

<blockquote>
  <p>If you allow more data via higher values, does your node forward previously unacceptable data to its peers once their backlog clears enough for the data to be accepted by them?</p>
</blockquote>

<p>No. Wallets in Bitcoin are expected to re-send transactions periodically if they have not been confirmed. If they will successfully relay at a later date with less mempool pressure, re-broadcasting it would be required. </p>

CC BY-SA 4.0
2020-06-02T13:21:07.963Z
2020-06-02T13:21:07.963Z
Claris
<p>Bitcoin Core by default allows up to 300 MiB of mempool data, and restricts unconfirmed transaction trees to an ancestry set of at most 25 transactions and 101 kvB of transaction data. Since these are config values, you can obviously use other values than these. How does this change your node's interaction with its peers? Do peers send data that exceeds your node's preferences and your node drops that data upon arrival or does your node inform its peers what to send? Is this the same for mempool data generally and unconfirmed chains specifically? If you allow more data via higher values, does your node forward previously unacceptable data to its peers once their backlog clears enough for the data to be accepted by them?</p>

<unconfirmed-transactions><mempool><peers><relay>
How does having a large mempool and allowing a greater transaction ancestry set change the interaction with your peers?
Murch
# How does having a large mempool and allowing a greater transaction ancestry set change the interaction with your peers?

(Asked by: username_0 on 2020-06-01)

Bitcoin Core by default allows up to 300 MiB of mempool data, and restricts unconfirmed transaction trees to an ancestry set of at most 25 transactions and 101 kvB of transaction data. Since these are config values, you can obviously use other values than these. How does this change your node's interaction with its peers? Do peers send data that exceeds your node's preferences and your node drops that data upon arrival or does your node inform its peers what to send? Is this the same for mempool data generally and unconfirmed chains specifically? If you allow more data via higher values, does your node forward previously unacceptable data to its peers once their backlog clears enough for the data to be accepted by them?

**Tags:** unconfirmed-transactions, mempool, peers, relay


---

## 1 answers

### Answer by username_1 on 2020-06-02. Score: 1

> How does this change your node's interaction with its peers? Do peers send data that exceeds your node's preferences and your node drops that data upon arrival or does your node inform its peers what to send?

The protocol supports a fee filtering command, simply, only relay transactions which meet a specific feerate and nothing below. This prevents pointless relaying of transactions which would result in immediate eviction from the memool.

> If you allow more data via higher values, does your node forward previously unacceptable data to its peers once their backlog clears enough for the data to be accepted by them?

No. Wallets in Bitcoin are expected to re-send transactions periodically if they have not been confirmed. If they will successfully relay at a later date with less mempool pressure, re-broadcasting it would be required.


---

