Raise the default limit but let users configure it via bitcoin.conf

Here you can see the size of the UTXO set over the past 5 years: https://statoshi.info/d/000000009/unspent-transaction-output-set?orgId=1&refresh=5s&from=now-5y&to=now

It completely exploded in 2023. No wonder your 8 GB RAM Pi performs poorly on a 11 GB UTXO set.

You could still try increasing the value of dbcache= in your bitcoin.conf to a number of Megabytes that still fits in your memory. Might improve performance a little.

"virtual Lightning channels" 👀️

I really like Spirited away. But honestly all of the listed movies are beautiful.

I watched the first season of Classroom of the Elite in 2019. It certainly peaked my interest but back then there was no 2nd season. When the 2nd season was announced in 2022, I got excited but I still did not get around to watching it until this day.

Be careful with Revolut! They froze and eventually banned my account after I used it for P2P trades on Robosats.

I can understand the argument that this change might reduce the pollution of the UTXO set in favor of OP_RETURN, but completely removing the option for the user to easily configure these mempool policies seems a bit extreme.

perhaps

Storage is not the problem. The problem is that the UTXO set no longer fits into memory on low-end systems. Thus slowing down the node since it has to access the disk more often now.

Are you saying that zero amount UTXOs are retained in the UTXO set?

Any non-zero unspent transaction output that is not provably unspendable.

An output script starting with OP_RETURN is provably unspendable, so it can be pruned.

But an output with a fake public key or fake script hash (such as produced by STAMPS) is unspendable, but that's not always obvious. Thus these outputs must be retained in the UTXO set. These are the most harmful ones.

The default mempool policies in Bitcoin Core are effective at preventing OP_RETURN outputs with more than 80 bytes of data. They are NOT effective at preventing OP_FALSE OP_IF ... OP_ENDIF (inscriptions) and fake public keys.

Yes, when my Lightning channel force closed

But are they really since the IMF agreement? Or are they just moving Bitcoin around to make it look like they are still stacking?

Oh right, I overlooked that you need BOLT12 support. LND does not have support for that yet. With Core Lightning however you could still use a pruned Bitcoin node or (although not recommended) you could use trustedcoin to immediately grant your Lightning node onchain access through public blockchain explorers.

You do not necessarily have to run your own full node to run a Lightning node. LND configured with bitcoin.node=neutrino will fetch onchain data from other Bitcoin nodes via compact filters.

More like 30% in the last 5 years. Still quite bad though

Yeah, but the transactions would have been included in the OCEAN block, if they weren't dropped due to the block template policy that the miner used.

It's technically not OCEAN who filtered these transactions since we are talking about a DATUM block. This means that the miner uses their own block template. In the case of this block, that miner was "Elektron Energy".

Well, I personally was never a fan of inscriptions.

No, because the overall fee to get into the next block was driven up by other transactions immediately after. Ironically, it was almost included—now it’s still stuck waiting in the mempool.