[Sep 2026]Mempool empty, Consolidate your small inputs @0.32 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.