[Oct 2026]Mempool empty, Consolidate your small inputs @0.25 sat/vbyte

[LoyceV]

Just 3 blocks ago, transactions paying 0.31 sat/vbyte got included! It's been a while since I've seen fees this low, so if you're not in a hurry, now could be a good time to consolidate some small inputs.

[LoyceV]

September bump

[LFC_Bitcoin]

Incredible that not really that long ago we were having to pay > 500 sat/vB to get a confirmation within 1 hour.

That era when shitcoiners were messing around with Ordinals and Runes or whatever they were called was very frustrating.

[LoyceV]

That era when shitcoiners were messing around with Ordinals and Runes or whatever they were called was very frustrating.

That didn't stop: most transactions now are what mempool.space calls "Runestone". What changed, is that they're no longer paying $25 per transaction in fees. I never understood how they could spend millions per day on that, and I can only imagine how many gullible people lost money falling for it.
At least fees are affordable now, even when blocks are full

[pooya87]

It is fascinating to see how simply changing policy rules in bitcoin core MASSIVELY reduced fees we have to pay (an unused potential to prevent spam...) and although it is not the same as "free days" (sending tx with zero fee ) but 0.2 sat/vb which is my current personal record is pretty fantastic. I still have to break my own record by getting a 0.1 sat/vb tx confirmed though.

[LoyceV]

0.2 sat/vb which is my current personal record is pretty fantastic. I still have to break my own record by getting a 0.1 sat/vb tx confirmed though.

That's easy: just send it, and wait. I think my 0.15 sat/vbyte took about a month to confirm. Mempool says it was 2 hours though, maybe they dropped it in between. For my 0.21 sat/vbyte transaction it says it took 2 weeks. It's probably in my post history somewhere if anyone's curious enough to search.

[athanred]

sending tx with zero fee

It is possible, if you use transaction version 3, and use fee anchor bc1pfeessrawgf.

Some example: https://mempool.space/tx/67d6f4ab4838a65cd8ad2a5147e9bf84e61d726c0d119d2fffbcf0f79399a33d

Of course, it is intended for second layers, to use it as an anchor to set fees by the next transaction in a CPFP way, but well: if you are sending coins to someone else, then it is one of many ways, to let the recipient decide about fees. Another way is to use proper sighashes, but using fee anchor may be easier to handle for some users.

[LoyceV]

sending tx with zero fee

It is possible, if you use transaction version 3, and use fee anchor bc1pfeessrawgf.

Some example: https://mempool.space/tx/67d6f4ab4838a65cd8ad2a5147e9bf84e61d726c0d119d2fffbcf0f79399a33d

Of course, it is intended for second layers, to use it as an anchor to set fees by the next transaction in a CPFP way, but well: if you are sending coins to someone else, then it is one of many ways, to let the recipient decide about fees. Another way is to use proper sighashes, but using fee anchor may be easier to handle for some users.

Then how did this transaction get confirmed? Did someone take the 0 sat input sent to bc1pfeessrawgf an input for a transaction that pays a fee?
That's an evil way to send someone a payment

Is there a testnet version of bc1pfeessrawgf to mess around with?

[pooya87]

0.2 sat/vb which is my current personal record is pretty fantastic. I still have to break my own record by getting a 0.1 sat/vb tx confirmed though.

That's easy: just send it, and wait. I think my 0.15 sat/vbyte took about a month to confirm. Mempool says it was 2 hours though, maybe they dropped it in between. For my 0.21 sat/vbyte transaction it says it took 2 weeks. It's probably in my post history somewhere if anyone's curious enough to search.

I've already done that but with actual 1 sat/vb and the transaction has been stuck in mempool for more than 4 months

sending tx with zero fee

It is possible, if you use transaction version 3, and use fee anchor bc1pfeessrawgf.

Well it's still not like what I said though. What I was pointing out were truly "free" transactions. You would just set the fee to zero and a miner would pick it up and mine it.
What you are describing here is CPFP, so it is not actually "zero fee" since someone is still paying the fee. Some mining pools even have alternative ways of paying the fee like using fiat to get your low paying tx mined by them.

Of course, it is intended for second layers, to use it as an anchor to set fees by the next transaction in a CPFP way, but well: if you are sending coins to someone else, then it is one of many ways, to let the recipient decide about fees. Another way is to use proper sighashes, but using fee anchor may be easier to handle for some users.

I'm confused, if the recipient is supposed to pay the fee then why do you need this address anyway? That's just a waste of precious bytes. Just send it to them directly and they'll pay the fee using CPFP.

[LoyceV]

Just send it to them directly and they'll pay the fee using CPFP.

I don't think you can broadcast a normal zero-fee transaction, even if you add CPFP right on top.

[athanred]

Then how did this transaction get confirmed?

In the latest version, transactions are treated as "packages". So, you have zero-fee transaction, and some fee-paying transaction, and the whole package is checked against relay rules. So, formally, the first transaction has zero fee, but the second one actually pays, what is needed to get it confirmed, through CPFP. In this way, when you have second layer protocols, you can always write a zero fee transaction, and then, the user, who will want to push it on-chain, will bump it in the future, with the right fees, without having to guess them upfront, and underpay (which will keep the multiparty transaction stuck) or overpay (which will cost more satoshis, than it should). If you use zero fees, then the second transaction is made, when you want to finalize things on-chain.

That's an evil way to send someone a payment

Why it is evil? Traditionally, the sender picks the fees, but from the protocol's perspective, the recipient can do that as well. Another thing is that in most nodes, you won't be able to broadcast a zero fee transaction directly. Which means, that you can make a free transaction, sign it, and pass it to the recipient, but if you try to broadcast it, then most nodes will reject it, because of relay rules. However, if the recipient will take your signed transaction, and combine it through CPFP with something else, then it will be broadcastable.

Is there a testnet version of bc1pfeessrawgf to mess around with?

Of course.

https://mempool.space/testnet/address/tb1pfees9rn5nz
https://mempool.space/testnet4/address/tb1pfees9rn5nz
https://mempool.space/signet/address/tb1pfees9rn5nz

And it also works in regtest, if you use bcrt1pfeesnyr2tx. The script is "51024e73":

Code:

decodescript 51024e73
{
  "asm": "1 29518",
  "desc": "addr(bcrt1pfeesnyr2tx)#swxgse0y",
  "address": "bcrt1pfeesnyr2tx",
  "type": "anchor"
}

If you can see "anchor" in a "type" field, then your node can support it properly.

why do you need this address anyway?

Because for CPFP rules, you need some "anchor", where you can connect a new transaction to the previous one.

Just send it to them directly and they'll pay the fee using CPFP.

That would reveal the fact, that the recipient can spend the coins directly. For privacy reasons, when anchor is in use, then you can always outsource it to another party. And then, if you have second layers, and the first anchored transaction is between Alice and Bob, then the fee bumping transaction can be done by Bob, by Charlie, or by Zack, who will be the 20th recipient in a chain of second-layer transactions.

That's just a waste of precious bytes.

Well, it consumes three bytes more than needed, because the Script is "51024e73", and not just "51". But well, people cared about making it "the shortest valid Segwit address", which is why we have, what we have. And it is still better, than using P2WSH equivalent:

Code:

decodescript 51
{
  "asm": "1",
  "desc": "raw(51)#8lvh9jxk",
  "type": "nonstandard",
  "p2sh": "2ND8PB9RrfCaAcjfjP1Y6nAgFd9zWHYX4DN",
  "segwit": {
    "asm": "0 4ae81572f06e1b88fd5ced7a1a000945432e83e1551e6f721ee9c00b8cc33260",
    "desc": "addr(bcrt1qft5p2uhsdcdc3l2ua4ap5qqfg4pjaqlp250x7us7a8qqhrxrxfsqseac85)#vch92e55",
    "hex": "00204ae81572f06e1b88fd5ced7a1a000945432e83e1551e6f721ee9c00b8cc33260",
    "address": "bcrt1qft5p2uhsdcdc3l2ua4ap5qqfg4pjaqlp250x7us7a8qqhrxrxfsqseac85",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "2N3i4C56DiqfpdcAJsAdZd2xYpCQMRAroye"
  }
}

Would you rather see bc1qft5p2uhsdcdc3l2ua4ap5qqfg4pjaqlp250x7us7a8qqhrxrxfsq2gp3gp instead of bc1pfeessrawgf?

I don't think you can broadcast a normal zero-fee transaction, even if you add CPFP right on top.

You can do that only as a package, if it has version three. And maybe it is even limited to anchors like bc1pfeessrawgf, these rules are quite new, and they probably won't work for older transactions or nodes.

[LoyceV]

Why it is evil?

If I understand this correctly, you'll receive a transaction that never confirms unless you take action by using CPFP.

Is there a testnet version of bc1pfeessrawgf to mess around with?

Of course.

Electrum's testnet server doesn't accept a zero-fee transaction, unfortunately.

[athanred]

Electrum's testnet server doesn't accept a zero-fee transaction, unfortunately.

Because usual relay rules also apply. As I said, it is intended for second layers, or for any cases, when you don't want to guess fees upfront. Then, you can have for example signed 2-of-2 multisig with zero fees, and another transaction, with a proper fee rate, which can be broadcasted months or years later, where mempools can be more or less congested, than today.

So, you can send a transaction with zero fees, but you have to relay it as a package, where N transactions will take X bytes, and pay Y fees collectively. That's how transaction packages work: then, fees are counted for the whole group of transactions, rather than for a single one, and then some of them can have zero fees.

[LoyceV]

An hour ago, spam-consolidations paying 0.25 sat/vbyte got confirmed. Just 12 large transactions filled most of the block.

[NotATether]

sending tx with zero fee

It is possible, if you use transaction version 3, and use fee anchor bc1pfeessrawgf.

Some example: https://mempool.space/tx/67d6f4ab4838a65cd8ad2a5147e9bf84e61d726c0d119d2fffbcf0f79399a33d

Of course, it is intended for second layers, to use it as an anchor to set fees by the next transaction in a CPFP way, but well: if you are sending coins to someone else, then it is one of many ways, to let the recipient decide about fees. Another way is to use proper sighashes, but using fee anchor may be easier to handle for some users.

Goddamn it, how many transactions does this address have? It won't even load in my custom mempool site!

Surely it would have to be in the hundreds of thousands? Otherwise the link wouldn't 404 with an "Error loading address data" error.

An hour ago, spam-consolidations paying 0.25 sat/vbyte got confirmed. Just 12 large transactions filled most of the block.

I'm guessing there were several blocks being mined in that timeframe that reduced the paying pool to just those large spam transactions at the highest point at the tip.

[LoyceV]

Goddamn it, how many transactions does this address have? It won't even load in my custom mempool site!
Surely it would have to be in the hundreds of thousands?

Use Bitcoin block data (1013 GB): outputs for an easy check: there are about 15-100k outputs per day on address bc1pfeessrawgf. It's just over 2 million in the past month.

[NotATether]

Use Bitcoin block data (1013 GB): outputs for an easy check: there are about 15-100k outputs per day on address bc1pfeessrawgf. It's just over 2 million in the past month.

OK, so there is honestly no way I can load this into my mempool without heavy modifications to the source code.

[LoyceV]

OK, so there is honestly no way I can load this into my mempool without heavy modifications to the source code.

I'm still running my search (the data is on a slow disk), I want to see when this started. And how quickly it started.

Interesting data:
blockchair_bitcoin_outputs_20260703.tsv.gz: 20377x
blockchair_bitcoin_outputs_20260702.tsv.gz: 31345x
blockchair_bitcoin_outputs_20260701.tsv.gz: 20x
blockchair_bitcoin_outputs_20260630.tsv.gz: 0x
.....
blockchair_bitcoin_outputs_20260626.tsv.gz: 5x
.....
blockchair_bitcoin_outputs_20260529.tsv.gz: 57x

So, on July 2 this year, someone decided to start spamming tens of thousands of outputs per day, and hasn't stopped since. The total is over 5 million outputs to bc1pfeessrawgf.
Disclaimer: I ended my search, and didn't check if there's another peak in earlier days.

[athanred]

how many transactions does this address have?

Well, mempool.space says "50 of 5,471,063 transactions", at the time of writing.

And it is quite natural, because it is spendable by anyone, unconditionally. So, it is used as an anchor in all places, where you need to have a short, spendable-by-anyone place, to connect two transactions together. Because then, you can bump fees through CPFP, without touching other inputs and outputs, so in case of any multisig, you don't have to worry about proper fees upfront, and you can just write a zero-fee transaction, which will be paid by the next one.

But of course, it is not only used by some second layers, but also abused by Runes, and other protocols like that, just because they can. If it would be blocked, then they could use private key, equal to one, or OP_TRUE, wrapped in P2WSH, or any other method. This address is just shorter, and can be easily marked as spendable by anyone, without consuming too much processing power, to check it, and accept as always valid.