[Mar 2026]Mempool empty, Consolidate your small inputs @0.11 sat/vbyte

[Pmalek]

Even though Trezor says the minimum is 1 sat/vB, if you type a lower amount and wait a few seconds it will actually create a valid transaction. Here I created a transaction with 0.5 sat/vB fee. If you’re connected to their backend, they enforce a higher minimum relay fee so it would get rejected but you can broadcast the raw hex on mempool.space.

This worked for me and I managed to perform a consolidation via Trezor Suite yesterday at 0.5 sat/vByte but not exactly how you explained it. Waiting didn't do anything on my end. The sign button remained unclickable after entering all other transaction information. To change that, I had to click the three horizontal dots in the top right corner of Trezor Suite and select "Send raw". That opens a new window where you can paste a raw transaction. Just close it and after that the software will have accepted your previous below 1 sat v/Byte entry and the sign button can be clicked.

Make sure you enter the transaction fee before clicking "Send raw" and also disable the "Broadcast" option.

[Pmalek]

Jochen Hoenicke's site is excellent for viewing how many unconfirmed transactions are currently in his mempool for each fee range. However, it still only shows transactions starting from 1 sat/vByte and paying higher fees. There is no information for below 1 sat/vByte transactions yet.

Does anyone know a different source where we could see the number of unconfirmed below 1 sat/vByte transactions for different fee ranges?
0.10 sat/vByte - 0.20 sat/vByte
0.30 sat/vByte - 0.40 sat/vByte
etc.

[LoyceV]

Does anyone know a different source where we could see the number of unconfirmed below 1 sat/vByte transactions for different fee ranges?

I'd use mempool.space for this: 3 transactions into the future, it's 0.63 sat/vbyte. 7 blocks into the future, it's down to 0.43 sat/vbyte.

[Cricktor]

~~~

You have to use the non-default BTC mempool at https://mempool.jhoenicke.de/#BTC,1w,weight,0 to see sub 1sat/vB stuff. The default BTC mempool has the default low cap of 1sat/vB.

See current screenshot:

[hosemary]

~~~

You have to use the non-default BTC mempool at https://mempool.jhoenicke.de/#BTC,1w,weight,0 to see sub 1sat/vB stuff. The default BTC mempool has the default low cap of 1sat/vB.

I don't think this is what Pmalek is looking for.
The link you shared display the total size of transactions paying less than 1 sat/vbyte, but it still doesn't give you the size of transaction made with the free rate of 0-0.1 sat/vbyte or 0.1-0.2 sat/vbyte. 

There's a same graph on mempool.space and like hoenicke's website, it only gives you the total size of transaction paying less than 1 sat/vbyte with no more details.

[Cricktor]

Yes indeed, I missed Pmalek's question about tenth sat buckets below 1sat/vB. It's not quite visible as he asks for and I only know mempool.space's mempool blocks https://mempool.space/mempool-block/7 which summarizes usually now the below 1sat/vB transactions is sort of a histogram, but not exactly as Pmalek wants.

[Findingnemo]

I guess it's time to change the lowest fee of 1sat/vb to something like 0.1sat/vb

0.1 sat/vb is the new 1 sat/vb!

I'm fantasizing it's me who ignited the fire.

From good luck convincing any miner to accept TXs below 1sat to 0.53sat/vb fee TXs are included in the mined blocks.

Now we need to convince the wallet providers to make those changes according to the new fee rate adjustments because I still see it's not possible to set the few below 1sat/vb on any wallet that I am using.

[LoyceV]

Now we need to convince the wallet providers to make those changes according to the new fee rate adjustments because I still see it's not possible to set the few below 1sat/vb on any wallet that I am using.

Many wallets seem to prefer high fee over slow confirmations. Coinomi's default fee for instance is still ridiculously high, even for altcoins that never need a higher fee.

The last block that wasn't full was 17 hours ago. I'd say this shows that lower minimum fees don't necessarily mean miners will earn less.

[Pmalek]

I'd use mempool.space for this: 3 transactions into the future, it's 0.63 sat/vbyte. 7 blocks into the future, it's down to 0.43 sat/vbyte.

Yeah, that's the only below 1 sat/vByte representation of transactions I have seen. I have never stopped to inspect how accurate it is so I am just going to assume that it's the best one we have currently.

Now we need to convince the wallet providers to make those changes according to the new fee rate adjustments because I still see it's not possible to set the few below 1sat/vb on any wallet that I am using.

Electrum server operators should be able to do this with a simple settings change. That would already help significantly if we take into account how popular the wallet is.
If you are using Trezor and Trezor Suite, then you can create and sign your transaction using the software and broadcast the raw transaction on mempool.space.
Bitcoin Core can be set up accordingly as well.

[NotATether]

Does anyone know a different source where we could see the number of unconfirmed below 1 sat/vByte transactions for different fee ranges?

I'd use mempool.space for this: 3 transactions into the future, it's 0.63 sat/vbyte. 7 blocks into the future, it's down to 0.43 sat/vbyte.

Most people would not want to schedule their transaction that far in time, so the <1sat/vbyte fees are so far only looking a little bit useful.

[stwenhao]

I'm fantasizing it's me who ignited the fire.

Well, many users wanted that change: https://bitcointalk.org/index.php?topic=5528323

Also, some code changes are in progress, but it seems people reconfigured their nodes earlier, before Bitcoin Core accepted any changes like that: https://github.com/bitcoin/bitcoin/pull/32959

I still think it may be bad in the long-term, but well, if users want cheaper transactions today, then they can get them, because why not. Any miner can accept as low fee, as needed, including free transactions. Also, there are ways to have negative fee transactions in decentralized way, the only reason why nobody implements it, is because it would make nodes open for many DoS attacks.

Now we need to convince the wallet providers to make those changes

If you use Bitcoin Core, then you can change your settings, without recompiling your wallet. For example:

Code:

minrelaytxfee=0.00000100

I think some other wallets may have similar config files. If they don't have it, then they should introduce it, because it would make it possible to make future changes, without recompiling source code, and waiting for wallet developers to change the default settings.

Also, another option is to import transaction proofs into Bitcoin Core. But then, you have to get a proof for your transaction somehow, to have something to import.

Code:

gettxoutproof ["txid",...] ( "blockhash" )
verifytxoutproof "proof"

I guess it is easier to use PSBT anyway, at least for now. Because in general, Bitcoin Core will accept the data you provide. Which means, that if you tell the client somehow, that you have 50 BTC on output badc0dedbadc0dedbadc0dedbadc0dedbadc0dedbadc0dedbadc0dedbadc0ded:1, then it will accept that fact, if it will be in your database, and it will allow you to use GUI, to sign your output. Of course, if you do that in a hackish way, then Bitcoin Core won't check it, and will allow you to sign anything, but that's just the price of avoiding chain verification, if you want to use it as some kind of SPV wallet, instead of sticking to the default way of downloading and verifying everything.

Many wallets seem to prefer high fee over slow confirmations.

Yes, that's another thing. If you use 1 sat/vB, then your transaction will be seen by pretty much everyone, because this de-facto standard was there for years. And if there will be people paying higher fees, then you can send even free transactions. There could be even miners accepting them. But still: other limits will still protect nodes from being flooded, for example block size limit of 4 MB, or default mempool size limit of 300 MB.

I'd say this shows that lower minimum fees don't necessarily mean miners will earn less.

In the long-term, it is hard to raise minimal fees, if they will be lowered too much. Going from de-facto standard of 1 sat/vB into 0.1 sat/vB is much easier, than raising it into 10 sat/vB. Which means, that if fees will be lowered now, then users may disagree to raise them in the future. And then, it may become a problem, if miners won't have enough incentives to produce next blocks (because then, they will be produced, when it will be profitable, so delays between blocks can be more driven by transaction fees, than they are today).

[Findingnemo]

Which means, that if fees will be lowered now, then users may disagree to raise them in the future. And then, it may become a problem, if miners won't have enough incentives to produce next blocks (because then, they will be produced, when it will be profitable, so delays between blocks can be more driven by transaction fees, than they are today).

You mean when there are no more block rewards and miners need to entirely rely on transaction fees for their incentive to run their machines? But it's a problem that will not be given much attention for a few decades at least and in 2140 we may have cheaper electricity than now, we may have more powerful machines and who knows people will be generous and send some money for fee even when it's not necessary.

Is it possible to allocate only certain blockspace for 0.1sat/vb and the remaining stays with 1sat/vb? I know it is not possible but is there any way we can make it happen so miners can still make more than 0.1sat tx while users who wants to consolidate can enjoy the limited block space.

[stwenhao]

Is it possible to allocate only certain blockspace for 0.1sat/vb and the remaining stays with 1sat/vb?

Possible? Yes. Implemented? Maybe. But definitely possible to implement, if needed. More than that: there could be a buffer even for free transactions if needed.

In general, miners can use this command:

Code:

prioritisetransaction "txid" ( dummy ) fee_delta

And they can say: "this transaction should be treated in the same way, as it would have this fee". Then, they can accept all transactions first, and set their priorities later.

Now, some miners use such things, to prioritize their own transactions. For example: miners can send their own transactions as free, and place them at the beginning of the blocks they produce. But it is possible to make rules, which would collect transactions from mempool, and auto-assign them different priorities, based on their fee range.

[Pmalek]

Sparrow Wallet might soon become the next bitcoin wallet that supports transactions paying less than 1 sat/vByte when they release version 2.2.4, which is currently in pre-release stage. Craigraw has already added the needed support for this to work. The server you are connected to must also also change the minrelaytxfee in their wallet configuration file to broadcast these transactions successfully.

Those who are interested can test if this works using the 2.2.4 pre-release version of Sparrow Wallet:
https://github.com/craigraw/beta/releases/tag/2.2.4-support-minrelaytxfee
https://github.com/sparrowwallet/sparrow/issues/1771#issuecomment-3083035351

I also found this GitHub node directory that catalogues Bitcoin Core nodes that accept below 1 sat/vByte transactions. There isn't much activity, though.
https://github.com/theDavidCoen/sub1sat-node-list

[LoyceV]

If the pool that finds the next block accepts it, you could get a next-block confirmation for as low as 0.4 sat/vbyte.

[LoyceV]

I just made my first <1.00 sat/vbyte transaction in many years. It took about an hour to confirm.

I'm working on my own Electrum node, to make it easier to create those transactions. But I need some time to complete it.

[joker_josue]

I just made my first <1.00 sat/vbyte transaction in many years. It took about an hour to confirm.

I'm working on my own Electrum node, to make it easier to create those transactions. But I need some time to complete it.

Very good.

I have to see if I can find the time to connect my node to Electrum, to test that.

[Pmalek]

I just made my first <1.00 sat/vbyte transaction in many years. It took about an hour to confirm.

I'm working on my own Electrum node, to make it easier to create those transactions. But I need some time to complete it.

What software did you use to send that below 1 sat/vByte transaction? Was it Bitcoin Core with your custom settings changes or something else? The only wallet I know that is accepting such transactions is Trezor Suite, where you can sign it but the broadcasting has to be done via mempool.space. Blue Wallet and Sparrow Wallet should allows sub 1 sat/vByte transactions sometimes in the near future. 

[LoyceV]

What software did you use to send that below 1 sat/vByte transaction?

Electrum But I used what I think is a bug: I created a 1.0 sat/vbyte transaction from an uncompressed legacy address using a watch-only wallet. When signing this transaction, it becomes larger and ends up with less than 1 sat/vbyte.

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.
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.

[philipma1957]

What software did you use to send that below 1 sat/vByte transaction?

Electrum But I used what I think is a bug: I created a 1.0 sat/vbyte transaction from an uncompressed legacy address using a watch-only wallet. When signing this transaction, it becomes larger and ends up with less than 1 sat/vbyte.

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.
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.

yeah 64gb maybe even 128gb.

i am looking to pickup a new pc and weighing 64gb or 128gb.

my newer mac studio is hanging at times with  its 36gb