[Sep 2025]Mempool empty, Consolidate your small inputs @0.24 sat/vbyte

[LoyceV]

yeah 64gb maybe even 128gb.

Those servers are much more expensive than I'm willing to pay for saving a few cents in transaction fees

[ABCbits]

My own Electrum server isn't ready yet. My VPS has an up-to-date Bitcoin Core node again, but it turns out there are several different versions to run Electrum server, and I think I should start with ElectrumX, but haven't decided yet. And as always, I'm limited in time to spend on the projects I want.

Since you haven't decided yet, i recommend you to see this article https://www.sparrowwallet.com/docs/server-performance.html. Sparrow developer benchmark 3 different Electrum server with detailed analysis.

I'm starting to think my 32 GB RAM (which is also used for other tasks) is on the low end for this, and my blocks directory is on slow network storage.

Have you checked whether OS on your server already enable Zram? It's handy feature when you're limited on RAM capacity.

[LoyceV]

Since you haven't decided yet, i recommend you to see this article https://www.sparrowwallet.com/docs/server-performance.html. Sparrow developer benchmark 3 different Electrum server with detailed analysis.

Thanks, this is helpful. The summary makes this a no-brainer:

Tl;dr: Fulcrum is 22x faster than ElectrumX, ~300x faster than Electrs
Tl;dr: Fulcrum is 8x faster than ElectrumX, 1.5x faster than Electrs

And since they ran this on a Raspberry Pi 4, my RAM may not be as restricting as I expected.

Have you checked whether OS on your server already enable Zram? It's handy feature when you're limited on RAM capacity.

My VPS doesn't use it. I would prefer a traditional swap file over compressed RAM.

Fulcrum is installing:

Code:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                                                         
  11626 electrum  20   0 1341700 603488  15616 S 175.1   1.8   5:48.64 Fulcrum                                                                                                                                         
   9573 electrum  20   0   16.7g   1.4g   1.1g S  48.8   4.6   3:09.62 bitcoind

Code:

[2025-08-13 15:49:37.940] <Controller> Processed height: 166000, 18.2%, 299.6 blocks/sec, 13986.5 txs/sec, 46136.0 addrs/sec
[2025-08-13 15:49:46.302] <Controller> Processed height: 167000, 18.4%, 119.6 blocks/sec, 6977.2 txs/sec, 21346.0 addrs/sec
[2025-08-13 15:49:49.854] <Controller> Processed height: 168000, 18.5%, 281.5 blocks/sec, 12709.2 txs/sec, 40880.1 addrs/sec
[2025-08-13 15:49:54.564] <Controller> Processed height: 169000, 18.6%, 212.3 blocks/sec, 9092.1 txs/sec, 31409.8 addrs/sec
[2025-08-13 15:49:58.307] <Controller> Processed height: 170000, 18.7%, 267.2 blocks/sec, 12563.5 txs/sec, 43759.6 addrs/sec

I'll forward this to a new topic: LoyceV's 0.1 sat/vbyte Electrum Server Adventure.

[Cricktor]

It will considerably slow down later. The initial sync of Fulcrum is not the fastest. To speed up initial sync of Fulcrum you might want to increase utxo_cache and maybe db_mem, too.

With a non-zero utxo_cache it's mandatory to always shutdown Fulcrum clean or your database likely will suffer irrecoverable issues.

The documentation of Fulcrum's config file is pretty verbose here: https://github.com/cculianu/Fulcrum/blob/master/doc/fulcrum-example-config.conf

I hope nobody minds because this is a bit off-topic. I'm very happy with Fulcrum as Electrum server. It's considerably faster than the usual suspects like ElectrumX or electrs. It's also easy to tweak the config so that Fulcrum can deliver very large address histories for those who need it. To cope with large address histories, Electrum wallet also needs a bit of tweaking, but there's a setting for the config file:

Code:

    "network_max_incoming_msg_size": 1000000,

The shown value is the default AFAIR, I use 50x more.

[LoyceV]

To speed up initial sync of Fulcrum you might want to increase utxo_cache and maybe db_mem, too.

It did indeed slow down to 2-5 blocks/sec now, but I'm not making any changes to it. If it takes 2 days, that's fine. Update: cache activated, it got slower and slower. Update: back to 10 blocks/second

I hope nobody minds because this is a bit off-topic.

I forgot to link my new topic here:

I'll forward this to a new topic: LoyceV's 0.1 sat/vbyte Electrum Server Adventure.

[stwenhao]

It is now merged into Bitcoin Core: https://github.com/bitcoin/bitcoin/pull/33106

Which means, that if you use the latest version from master, then it will be available by default. I guess other wallets will follow these changes, but it will take some time, and there will probably also be nodes, which will keep using 1 sat/vB anyway.

[LoyceV]

An easy solution to create a low-fee transaction on Electrum

Electrum settings
"Teach" your Electrum to sign transactions with less that 1 sat/vbyte:

Code:

wallet.relayfee = (lambda: 0)

Or automate it on startup:

I just wrote the smallest Electrum plugin ever that just runs this command at start.
https://files.ninjastic.space/relayfeezero-0.0.1.zip
Tools -> Plugins -> Add -> Select the zip and install.

Note: this allows to create transactions that pay less than 0.1 sat/vbyte fee, but at the moment no mining pool will accept those.

[LoyceV]

My 0.32 sat/vbyte transaction confirmed in 2 hours today (sent from Bitcoin Core)!

My 0.20 sat/vbyte transaction has many blocks ahead of it, but I could send it from Electrum directly without manually copying the raw transaction to mempool.space/tx/push for broadcasting. To do this, I used TryNinja's Electrum plugin (above) and connected to my own Electrum server:

Code:

tmp.loyce.club:50002

Feel free to try it

[LoyceV]

At the moment, 0.27 sat/vbyte could be enough to get confirmed in the next block. If you go as low as 0.25 sat/vbyte, there are many blocks ahead of you already. So for the purpose of this thread: 0.27 sat/vbyte is a very good opportunity!

My 0.20 sat/vbyte transaction has many blocks ahead of it

My 0.20 sat/vbyte transaction isn't anywhere near confirmation after 5 days (but this was only a test so that's okay).

[Pmalek]

My 0.20 sat/vbyte transaction isn't anywhere near confirmation after 5 days (but this was only a test so that's okay).

This transaction should have been confirmed during the night. I can see that blocks contained transactions paying as low as 0.11 sat/vByte seven to eight hours ago. Also, the last three blocks went down to 0.19 sat/vByte. I also had an unconfirmed transaction at 0.21 sat/vbyte laying in the mempools for a week. It's now confirmed.

[LoyceV]

This transaction should have been confirmed during the night.

It did: 61 confirmations.

I can see that blocks contained transactions paying as low as 0.11 sat/vByte seven to eight hours ago.

It turns out I would have been better off waiting instead of consolidating in the past. But you can never know that of course, fees could have gone in the other direction.

[stwenhao]

It turns out I would have been better off waiting instead of consolidating in the past.

And it would be even better, if you would use negative fees. For example: https://mempool.space/tx/8349df0753e80cce322322f1b76789e1d0fd6693aed2f4de4e49576423081ae7

This is what bc1qts0jh2d2nesmketmw3thedwrx939k2tqu04gy90x9hd4049g4uhs83ltjx signed:

Code:

+------------------------------------------------------------------------------------------------------------------------------------------------+
| bc1qts0jh2d2nesmketmw3thedwrx939k2tqu04gy90x9hd4049g4uhs83ltjx   0.00054000 BTC -> bc1qlv4nl3cfc8jxaulxe7gqvj32p02hp5tzhk4c72   0.00253872 BTC |
|                                                                                    OP_RETURN 796f145c28bad77e                   0.00000000 BTC |
+------------------------------------------------------------------------------------------------------------------------------------------------+

And this is what bc1q9nw84cph4dn2pw78pnaec68c82h7pxvv55cla8 signed:

Code:

+---------------------------------------------------------------------------------+
| bc1q9nw84cph4dn2pw78pnaec68c82h7pxvv55cla8                       0.00200000 BTC |
| bc1qts0jh2d2nesmketmw3thedwrx939k2tqu04gy90x9hd4049g4uhs83ltjx   0.00054000 BTC |
+---------------------------------------------------------------------------------+

Which means, that the first user set fees to negative 199872 satoshis, the second user added 200k satoshis to the UTXO, owned by the first one, and bumped the whole transaction from -199872 satoshis to +128 satoshis.

And in general, this is what should be done with dust: you want to receive some payment, so you use some dust, sign it with SIGHASH_ANYONECANPAY, so all of your outputs are protected (you can combine it with SIGHASH_SINGLE, if you care only about a single output), and then, you give that PSBT as an invoice. The second user can get your invoice, add more coins, and then, you can sweep your dust, while also receiving your payment.

But you can never know that of course, fees could have gone in the other direction.

The lowest possible fee is not zero, but minus 21 million coins. And, as you can see, negative fees are great for sweeping dust, because then, you pick a single dust coin, you pick a destination with bigger amount, than you have, and if your transaction don't use SIGHASH_ALL, and is open for modifications, then you can make an invoice out of it, so that other users can add more coins, and make the whole fee non-negative.

Edit: (-199872 sat) / 193.25 vB = -1034.26649418 sat/vB, so the next title should be: [Aug 2025] Don't care about mempool, Use PSBT, Consolidate your dust inputs @-1034.26 sat/vbyte

[LoyceV]

And in general, this is what should be done with dust: you want to receive some payment, so you use some dust, sign it with SIGHASH_ANYONECANPAY, so all of your outputs are protected (you can combine it with SIGHASH_SINGLE, if you care only about a single output), and then, you give that PSBT as an invoice. The second user can get your invoice, add more coins, and then, you can sweep your dust, while also receiving your payment.

That sounds like a lot of work to avoid dust inputs. I don't really see how this is better than manually consolidating (which costs only a few sats at the right moment), or using coin control to add the dust input when making a transaction.

The lowest possible fee is not zero, but minus 21 million coins. And, as you can see, negative fees are great for sweeping dust, because then, you pick a single dust coin, you pick a destination with bigger amount, than you have, and if your transaction don't use SIGHASH_ALL, and is open for modifications, then you can make an invoice out of it, so that other users can add more coins, and make the whole fee non-negative.

Why would other users do that? I don't expect the average (or even advanced) Bitcoin user to be able to do this if it's not handled in a GUI wallet.

Consolidate your dust inputs @-1034.26 sat/vbyte

I like your new title suggestion

[Forsyth Jones]

I just added the following configuration to allow both the creation and transmission of transactions below 1 sat/vB in Bitcoin Core:

Code:

mintxfee=0.000001
minrelaytxfee=0.000001
fallbackfee=0.000001

However, I don't think I'll be able to send transactions < 1 sat/vB through the UI in the send tab. So, I'll only be able to create transactions below 1 sat/vB through the console, right?

Remember that Bitcoin Core's fee configuration is in sat/kvb, meaning that for transactions with 0.1 sat/vB, I'd need to customize the fee to 0.000001 BTC/kvB.

I will list below what each command does:

-mintxfee=<amt>
Fee rates (in BTC/kvB) smaller than this are considered zero fee for transaction creation (default: 0.00001)

-minrelaytxfee=<amt>
Fees (in BTC/kvB) smaller than this are considered zero fee for relaying, mining and transaction creation (default: 0.00001)

-fallbackfee=<amt>
A fee rate (in BTC/kvB) that will be used when fee estimation has insufficient data. 0 to entirely disable the fallbackfee feature. (default: 0.00)

[LoyceV]

However, I don't think I'll be able to send transactions < 1 sat/vB through the UI in the send tab. So, I'll only be able to create transactions below 1 sat/vB through the console, right?

It should work, I used the GUI for this:

My 0.32 sat/vbyte transaction confirmed in 2 hours today (sent from Bitcoin Core)!

Remember that Bitcoin Core's fee configuration is in satBTC/kvb, meaning that for transactions with 0.1 sat/vB, I'd need to customize the fee to 0.000001 BTC/kvB.

I fixed your quote this to avoid confusion.

[stwenhao]

That sounds like a lot of work to avoid dust inputs.

Of course. The lower the fee, the harder it is to confirm it. And for negative fees, you have to convince someone, to actually add more coins, and pay for your transaction. Which usually means selling something, because the other party needs a good reason to pay you.

I don't really see how this is better than manually consolidating

Because then, literally anyone can add more coins in. Which means, that if you sign something with SIGHASH_ALL, then it creates quite strong assumption, that all coins are yours. But here, it is not the case.

And of course, you can always pretend, that you sold something, and use your own coins with different sighashes, just to test it, before making some real transaction with someone else.

Why would other users do that?

Because then, fees can be dynamically set. If everything is signed, then you have to use pre-signed fees, which can be too high, or too low, if a given transaction is broadcasted in the future. But if you make it partially open, then you can adjust it just before broadcasting. And also, fees can be paid by the receiver, instead of the sender, or the payer can be dynamically chosen, if needed.

In general, I think transactions open for modifications will be more and more useful. Because for example if you need only a single input, and only a single output, then it can be safely signed with SIGHASH_SINGLE, combined with SIGHASH_ANYONECANPAY. And then, miners could collect a lot of low-fee transactions into a single, batched transaction, which would take less on-chain bytes, because of stripping some repeated fields.

Which also means, that a bunch of transactions with less than 1 sat/vB can be then collected, and combined, to form a single transaction with at least 1 sat/vB, which would be seen by everyone, without increasing fees for any participant (exactly the same amounts could take less on-chain bytes, after being combined into a single transaction).

I don't expect the average (or even advanced) Bitcoin user to be able to do this if it's not handled in a GUI wallet.

Yes, it is something like coin control: it probably shouldn't be available by default. But I think it should be possible to pick different sighashes from GUI, and see, what exactly is signed by every input.

I don't think I'll be able to send transactions < 1 sat/vB through the UI in the send tab.

I remember when Garlo Nicon used Bitcoin Core to send testnet transactions with one or two satoshis per transaction in his own blocks. If that was possible in the old Bitcoin Core version from 2024, then it should be also possible now, because I think nobody blocked it.

As far as I know, 0.001 sat/vB is something, that you can do from GUI, if you want. Confirming it is another matter, but you can create it and try to broadcast it, just by using the official client.

[LoyceV]

The last block was for 80% filled with 0.23 sat/vbyte transactions. Paying 0.24 sat/vbyte would have been enough for a fast confirmation. Unfortunately, most of them are just spamming made-up tokens.

[joker_josue]

The last block was for 80% filled with 0.23 sat/vbyte transactions. Paying 0.24 sat/vbyte would have been enough for a fast confirmation. Unfortunately, most of them are just spamming made-up tokens.

Unfortunately, this is always the problem of the advantages that emerge in the network.
They are used to abuse and spread garbage.

I know it will be difficult to control this situation. But I see people more concerned about the rates being lower than 1sat, than really fighting this garbage, which only harms the network regardless of the rate in force.

[stwenhao]

I know it will be difficult to control this situation.

Yeah. I checked my node, and noticed many peers, where "minfeefilter" is set to 0.00000000. Which means, that such nodes potentially enabled completely free transactions. I don't know why, but I feel like free relay could be really free, if your peers declare to accept anything unconditionally.

[LoyceV]

Just 2 blocks ago, almost the entire block was filled with transactions paying only 0.25-0.26 sat/vbyte. You could end up in the next block at 0.26 sat/vbyte if it's mined quickly, and the block after that allows 0.24 sat/vbyte.
Note that this depends on the miner, and will vary depending on how long it takes to mine those blocks. But fees are still very low

The sad part: almost all low-fee transactions are just data spam abusing the Bitcoin blockchain to earn money from gullible people. I'm really surprised barely anyone uses Bitcoin for normal payments nowadays.