<p>Essentially your goal is to increase the mempool's minimum fee rate to be higher than 1 sat/vb. The way to do this is to shrink the mempool and fill it with large high fee transactions.</p>
<p>First, you can make the mempool much smaller by setting <code>-maxmempool=&lt;n&gt;</code>. <code>&lt;n&gt;</code> is the size in MB, and the default is 300. You can set this to, e.g. 5 to get a 5 MB mempool, and that will be much easier to fill.</p>
<p>Then you can make transactions by having them contain large amounts of data in OP_RETURN outputs. You have to set <code>-datacarriersize=&lt;n&gt;</code> where <code>&lt;n&gt;</code> is the number of bytes to allow in an OP_RETURN. You could set this to 100000 and be able to add a single OP_RETURN output to each transaction that's up to 100000 bytes in size. Although the maximum standard tx size rule of 100000 vbytes is still in effect, so you should leave some space for the rest of the transaction.</p>
<p>Bitcoin Core's test framework does both of these things with those settings in order to test mempool eviction.</p>

CC BY-SA 4.0
2024-04-30T17:04:39.790Z
As far as I know LN nodes use estimatesmartfee for fee estimation. That rpc call only uses chain data and not mempool right? If so, I think the mempool size should not have any impact here.
polespinasa
CC BY-SA 4.0
2024-04-30T18:06:53.877Z
estimatesmartfee look at how long something was in the mempool before it got mined. So you need to both fill the mempool (maybe not all the way), and mine several blocks
Ava Chow
CC BY-SA 4.0
2024-04-30T18:12:47.677Z
Okay, that's a good point. Thanks Ava!
Is there any documentation on the exact behaviour and how estimatesmartfee work in detail?
polespinasa
CC BY-SA 4.0
2024-04-30T18:53:11.283Z
I think the only real documentation is this code comment: https://github.com/bitcoin/bitcoin/blob/2d3056751bb7d742a802a30503f07dbeb07310ee/src/policy/fees.h#L100
Ava Chow
CC BY-SA 4.0
2024-06-07T14:52:11.057Z
Ava, do you know how often the fee estimation algorithm is executed? Every time a new block is mined, every time the estimatesmartefee command is executed?
polespinasa
CC BY-SA 4.0
2024-06-07T16:14:53.083Z
The estimator updates per block.
Ava Chow
CC BY-SA 4.0
2024-04-30T17:00:52.637Z
2024-04-30T17:00:52.637Z
Ava Chow
<p>I have a Regtest environment with some Lightning nodes. I need to make the fees go up a lot to do some tests on how the Lightning nodes behave with high fees.</p>
<p>What would be the most efficient/simple method to increase the fees?
I was thinking of simply installing an ordinals wallet and generate tx of almost 1MB paying high commissions. Then I thought it might be easier to simply remove the datacarrier limit and add a lot of arbitrary text in an OP_RETURN to make very large tx.</p>
<p>Does anyone know of a more efficient way to do this?</p>

<lightning-network><transaction-fees><regtest><testing><fee-estimation>
Increase the fees in regtest
polespinasa
# Increase the fees in regtest

(Asked by: username_0 on 2024-04-30)

I have a Regtest environment with some Lightning nodes. I need to make the fees go up a lot to do some tests on how the Lightning nodes behave with high fees.

What would be the most efficient/simple method to increase the fees?
I was thinking of simply installing an ordinals wallet and generate tx of almost 1MB paying high commissions. Then I thought it might be easier to simply remove the datacarrier limit and add a lot of arbitrary text in an OP\_RETURN to make very large tx.

Does anyone know of a more efficient way to do this?

**Tags:** lightning-network, transaction-fees, regtest, testing, fee-estimation


---

## 1 answers

### Answer by username_1 on 2024-04-30. Score: 1 | Accepted answer

Essentially your goal is to increase the mempool's minimum fee rate to be higher than 1 sat/vb. The way to do this is to shrink the mempool and fill it with large high fee transactions.

First, you can make the mempool much smaller by setting `-maxmempool=<n>`. `<n>` is the size in MB, and the default is 300. You can set this to, e.g. 5 to get a 5 MB mempool, and that will be much easier to fill.

Then you can make transactions by having them contain large amounts of data in OP\_RETURN outputs. You have to set `-datacarriersize=<n>` where `<n>` is the number of bytes to allow in an OP\_RETURN. You could set this to 100000 and be able to add a single OP\_RETURN output to each transaction that's up to 100000 bytes in size. Although the maximum standard tx size rule of 100000 vbytes is still in effect, so you should leave some space for the rest of the transaction.

Bitcoin Core's test framework does both of these things with those settings in order to test mempool eviction.

> **Comments:**
> **username_0**: As far as I know LN nodes use estimatesmartfee for fee estimation. That rpc call only uses chain data and not mempool right? If so, I think the mempool size should not have any impact here.  
> **username_1**: estimatesmartfee look at how long something was in the mempool before it got mined. So you need to both fill the mempool (maybe not all the way), and mine several blocks  
> **username_0**: Okay, that's a good point. Thanks Ava! Is there any documentation on the exact behaviour and how estimatesmartfee work in detail?  
> **username_1**: I think the only real documentation is this code comment: https://github.com/bitcoin/bitcoin/blob/2d3056751bb7d742a802a30503f07dbeb07310ee/src/policy/fees.h#L100  
> **username_0**: Ava, do you know how often the fee estimation algorithm is executed? Every time a new block is mined, every time the estimatesmartefee command is executed?  
> **username_1**: The estimator updates per block.  

---

