<p>The minimum fee for relaying a transaction through the peer to peer network depends on the peer policy. It's up to the node (peer) operators to set the minimum relay fee.</p>

<p>Since Bitcoin Core uses a maximum mempool limit (before it was unlimited), this minimal relay fee will auto-adjust.</p>

<p>It's difficult to say feerate (fee per byte) x is the minimum fee required fee for the network.</p>

<p>And, later, you want that your transaction get mined, which is different from transaction propagation through the network.</p>

<p>This depends on the miners. They have full control if they include your transactions into a block or not.</p>

<p>If we assume, they act rational following financial incentives, then the higher your fee is, the more likely is, that it will be included.</p>

<p>It also highly depends on what other transactions in the mempool uses what ferrates.</p>

<p>EDIT:</p>

<ul>
<li><p>deleting transactions as a user action is impossible, though you can assume, that over time, the transaction will vanish from the mempool(s) due to size limitations.</p></li>
<li><p>Best thing you can do is use RBF BIP125 (replace by fee) to ensure you have the capabilities to later replace the transaction with a new transaction paying higher fees.</p></li>
<li><p>In case your old (stuck) transactions hasn't signalled BIP125 RBF, then child pays for parent may help (CPFP, maybe google it). The concept there is that you use the change output of the stuck transactions as an input for a new transaction and use "relatively high fee" (pay for the missing fee and the new transaction). Therefore a miner likes to include that transaction (because of the fee incentives), but, needs also to pick the older (stuck) transaction.</p></li>
</ul>

CC BY-SA 3.0
2017-12-19T06:34:07.040Z
2017-12-19T06:34:07.040Z
Jonas Schnelli
<p>I would like to know when a transaction will reject if the fee was to low to be confimed.</p>

<p>If this transaction never will be rejected, what is to do to delete this transaction?</p>

<transaction-fees><client><replace-by-fee><sendtoaddress>
When a transaction will reject if the fee was to low?
kornholio
# When a transaction will reject if the fee was to low?

(Asked by: username_0 on 2017-12-19)

I would like to know when a transaction will reject if the fee was to low to be confimed.

If this transaction never will be rejected, what is to do to delete this transaction?

**Tags:** transaction-fees, client, replace-by-fee, sendtoaddress


---

## 1 answers

### Answer by username_1 on 2017-12-19. Score: 0

The minimum fee for relaying a transaction through the peer to peer network depends on the peer policy. It's up to the node (peer) operators to set the minimum relay fee.

Since Bitcoin Core uses a maximum mempool limit (before it was unlimited), this minimal relay fee will auto-adjust.

It's difficult to say feerate (fee per byte) x is the minimum fee required fee for the network.

And, later, you want that your transaction get mined, which is different from transaction propagation through the network.

This depends on the miners. They have full control if they include your transactions into a block or not.

If we assume, they act rational following financial incentives, then the higher your fee is, the more likely is, that it will be included.

It also highly depends on what other transactions in the mempool uses what ferrates.

EDIT:

* deleting transactions as a user action is impossible, though you can assume, that over time, the transaction will vanish from the mempool(s) due to size limitations.
* Best thing you can do is use RBF BIP125 (replace by fee) to ensure you have the capabilities to later replace the transaction with a new transaction paying higher fees.
* In case your old (stuck) transactions hasn't signalled BIP125 RBF, then child pays for parent may help (CPFP, maybe google it). The concept there is that you use the change output of the stuck transactions as an input for a new transaction and use "relatively high fee" (pay for the missing fee and the new transaction). Therefore a miner likes to include that transaction (because of the fee incentives), but, needs also to pick the older (stuck) transaction.


---

