<p>With the blockchain experiencing extremely high transaction volumes (most blocks at the 1MB size limit), I am interested in studying the "backlog" of transactions in the memory pool on my own full node. In order to make such an analysis meaningful, I want only "honest" transactions in my mempool (loosely defined as: transactions that should be mined someday).</p>

<p>I've tried adjusting minrelaytxfee to 0.0001, but I find that TONS of "unqualified" transactions build up in my mempool. Here is a representative transaction:
effec9299f18314a7a13e525a7bdbaa9316be9d9cac9d082078ae325fff30500</p>

<p>That transaction is 14,799 bytes (100+ infinitesimal inputs) with a fee of 0.15 mBTC. At the risk of stating the obvious, that transaction should NOT pass a minrelaytxfee of 0.1 mBTC/KB. My mempool collects ~1000 transaction per day that are VERY similar to the one cited above.</p>

<p>Also at the risk of stating the obvious, these transactions are NEVER mined.</p>

<p>QUESTION #1: how do these transactions "fool" the minrelaytxfee test?</p>

<p>QUESTION #2: is there a better mechanism for filtering out such transactions?</p>

<p>QUESTION #4: might these transactions originate on "my" SPV clients?</p>

<p>QUESTION #3: are these transactions SPAM or something else?</p>

<p>Thanks for the insight.</p>

<p>UPDATE ----------</p>

<p>For debugging purposes only, I increased minrelaytxfee to 0.0002 and re-started my Bitcoin Core full node.</p>

<p>Observation: on the vast majority of transactions, minrelaytxfee <em>is</em> applied correctly. In other words, transactions will a fee lower than 0.2 mBTC/KB are not added to my mempool.</p>

<p>I continue to get ~250 transactions/hour that somehow "fool" the minrelaytxfee filter. Here are three representative transactions:</p>

<p>c299d3bd4e79590bf5d5b9cfb1f3db4378ffc5e9e64752f6deb8134d43f54501</p>

<p>ffc1ad32c1d8ca496fa52e5451c6abe56003029819029de9a0f941611f942402</p>

<p>65871d2e0bc438d5019e606daba59d7af1a2ce3eb079e5f0e6c9e21ef8373402</p>

<p>All of these "foolish" transactions follow a specific template:</p>

<ul>
<li><p>Size is between 14790 and 14810 bytes</p></li>
<li><p>Roughly 100 transaction inputs, all of exactly 0.1 mBTC</p></li>
<li><p>Transaction fee is always exactly 0.15 mBTC</p></li>
</ul>

<p>QUESTION: how are these transactions fooling the minrelaytxfee filter?</p>

<p>Tracing a large sample of the 0.1 mBTC transaction inputs, they are always produced by a transaction that follows its own specific template:</p>

<ul>
<li><p>A single transaction input</p></li>
<li><p>Roughly 100 transaction outputs, all but one of exactly 0.1 mBTC</p></li>
</ul>

<p>QUESTION: Am I correct in suggesting that this pattern appears suspicious and deliberate?</p>

CC BY-SA 3.0
2016-06-10T07:44:06.893Z
What software and version are you using for your full node, and how are you setting the minrelayfee? It has a fee of slightly above 0.01mBTC/KB, which is the default min relay fee of many recent Bitcoin Core versions. Perhaps you made a typo in the config setting, and it remained at the default?
Pieter Wuille
CC BY-SA 3.0
2016-06-10T14:45:00.157Z
I am running Bitcoin Core 0.12.0.
Pressed250
CC BY-SA 3.0
2016-06-10T14:46:23.133Z
Ok, now the other question: how are you setting the min relay fee exactly (command-line option, which? config file entry, which?)
Pieter Wuille
CC BY-SA 3.0
2016-06-10T14:46:58.367Z
I added the following line to bitcoin.conf:

minrelaytxfee=0.0001
Pressed250
CC BY-SA 3.0
2016-06-10T14:48:41.820Z
Did you restart bitcoind after adding that line?
Pieter Wuille
CC BY-SA 3.0
2016-06-10T14:56:40.393Z
Additional observation: the minrelaytxfee=0.0001 does properly filter *most* transactions ... it is "fooled" by the referenced class of transactions with 100+ very small inputs.
Pressed250
CC BY-SA 3.0
2016-06-10T14:57:11.767Z
Yes. And to be safe, I re-started Ubuntu as well.
Pressed250
CC BY-SA 3.0
2016-06-10T23:06:11.200Z
FYI. These transactions are from "coinwallet.eu stress test". The outputs have enough age. Combining transactions were created and broadcasted to a network long ago. Now they are migrating [s]from Middle East to Europe[/s] to your node. Enjoy!
amaclin
CC BY-SA 3.0
2016-06-11T14:46:08.467Z
Amaclin: I read up on the "coinwallet.eu stress test," and I cannot connect the dots. I see that the UTXOs were created last year, check. The new transactions (TXIDs listed above in the UPDATE) are actively being created at the rate of ~250 per hour for the past month. So yes, the UTXOs are "old" and boost the transaction in the legacy prioritization formula ... but what does that have to do with the minrelaytxfee filter?
Pressed250
<transaction-fees><bitcoin-cli><mempool>
Mempool filled with 14KB transactions, tons of inputs, 0.15 mBTC fee
Pressed250
# Mempool filled with 14KB transactions, tons of inputs, 0.15 mBTC fee

(Asked by: username_0 on 2016-06-10)

With the blockchain experiencing extremely high transaction volumes (most blocks at the 1MB size limit), I am interested in studying the "backlog" of transactions in the memory pool on my own full node. In order to make such an analysis meaningful, I want only "honest" transactions in my mempool (loosely defined as: transactions that should be mined someday).

I've tried adjusting minrelaytxfee to 0.0001, but I find that TONS of "unqualified" transactions build up in my mempool. Here is a representative transaction:
effec9299f18314a7a13e525a7bdbaa9316be9d9cac9d082078ae325fff30500

That transaction is 14,799 bytes (100+ infinitesimal inputs) with a fee of 0.15 mBTC. At the risk of stating the obvious, that transaction should NOT pass a minrelaytxfee of 0.1 mBTC/KB. My mempool collects ~1000 transaction per day that are VERY similar to the one cited above.

Also at the risk of stating the obvious, these transactions are NEVER mined.

QUESTION #1: how do these transactions "fool" the minrelaytxfee test?

QUESTION #2: is there a better mechanism for filtering out such transactions?

QUESTION #4: might these transactions originate on "my" SPV clients?

QUESTION #3: are these transactions SPAM or something else?

Thanks for the insight.

UPDATE ----------

For debugging purposes only, I increased minrelaytxfee to 0.0002 and re-started my Bitcoin Core full node.

Observation: on the vast majority of transactions, minrelaytxfee *is* applied correctly. In other words, transactions will a fee lower than 0.2 mBTC/KB are not added to my mempool.

I continue to get ~250 transactions/hour that somehow "fool" the minrelaytxfee filter. Here are three representative transactions:

c299d3bd4e79590bf5d5b9cfb1f3db4378ffc5e9e64752f6deb8134d43f54501

ffc1ad32c1d8ca496fa52e5451c6abe56003029819029de9a0f941611f942402

65871d2e0bc438d5019e606daba59d7af1a2ce3eb079e5f0e6c9e21ef8373402

All of these "foolish" transactions follow a specific template:

* Size is between 14790 and 14810 bytes
* Roughly 100 transaction inputs, all of exactly 0.1 mBTC
* Transaction fee is always exactly 0.15 mBTC

QUESTION: how are these transactions fooling the minrelaytxfee filter?

Tracing a large sample of the 0.1 mBTC transaction inputs, they are always produced by a transaction that follows its own specific template:

* A single transaction input
* Roughly 100 transaction outputs, all but one of exactly 0.1 mBTC

QUESTION: Am I correct in suggesting that this pattern appears suspicious and deliberate?

**Tags:** transaction-fees, bitcoin-cli, mempool

> **Comments:**
> **username_1**: What software and version are you using for your full node, and how are you setting the minrelayfee? It has a fee of slightly above 0.01mBTC/KB, which is the default min relay fee of many recent Bitcoin Core versions. Perhaps you made a typo in the config setting, and it remained at the default?  
> **username_0**: I am running Bitcoin Core 0.12.0.  
> **username_1**: Ok, now the other question: how are you setting the min relay fee exactly (command-line option, which? config file entry, which?)  
> **username_0**: I added the following line to bitcoin.conf:  minrelaytxfee=0.0001  
> **username_1**: Did you restart bitcoind after adding that line?  
> **username_0**: Additional observation: the minrelaytxfee=0.0001 does properly filter *most* transactions ... it is "fooled" by the referenced class of transactions with 100+ very small inputs.  
> **username_0**: Yes. And to be safe, I re-started Ubuntu as well.  
> **username_2**: FYI. These transactions are from "coinwallet.eu stress test". The outputs have enough age. Combining transactions were created and broadcasted to a network long ago. Now they are migrating [s]from Middle East to Europe[/s] to your node. Enjoy!  
> **username_0**: username_2: I read up on the "coinwallet.eu stress test," and I cannot connect the dots. I see that the UTXOs were created last year, check. The new transactions (TXIDs listed above in the UPDATE) are actively being created at the rate of ~250 per hour for the past month. So yes, the UTXOs are "old" and boost the transaction in the legacy prioritization formula ... but what does that have to do with the minrelaytxfee filter?  

---

## 0 answers

