pull down to refresh
The 1mb (or 4 with witness) is well bounded and neat and has no issues with resources.
Yeah it is bounded per block. But the blockchain grows forever. That isn't bounded. And having a growth rate that's just slightly higher per block, does add up significantly over time. Keep in mind that a full node needs to download the entire chain. This gets harder and harder with time.
I really hope it stays that way once fees ramp up and we don't get yet another one of these spam hype cycles. But I am afraid that the spam hype might come back.
How did that happen?
( blocks are limited to 1mb, utxo set has no limit. )
Blocks are limited to 4 MB.
tldr utreexo solves the more serious problem.
Agreed.
Though that doesn't make big spam-filled blocks any better.
what is the difference between utxo set bloat and blockchain bloat?
There is no difference.
Of course there is a difference. The UTXO set are all of the unspent outputs, against which new transactions are verified. The blockchain is the entire history of transactions up until now. If you want to run a full node, you have to store the entire blockchain. You don't however need to store the entire UTXO set with UTreeXO, only the outputs that you own.
uteeexo is the most important thing happening in bitcoin right now.
UTreeXO fixes UTXO set bloat. But it doesn't fix blockchain bloat from inscriptions.
But how do we balance that with Bitcoin’s neutrality?
Where’s the line between protecting the protocol and restricting usage?
Data storage was always considered an abuse of Bitcoin.
https://en.bitcoin.it/wiki/Spam_transactions
https://en.bitcoin.it/wiki/Weaknesses#Illegal_content_in_the_block_chain
https://gnusha.org/pi/bitcoindev/CAAS2fgSkiqfhJxHJNw8i8G5yd1XY6tUTDynQ+AekbwmHP_jZmw@mail.gmail.com/t/#u
Yes, I have used FixedFloat multiple times in the past. Just make sure that your Lightning invoice doesn't expire before the swap completes.
I did actually refresh and the timer was still negative. Seems to be because the last blocks ntime was in the future.
https://mempool.space/block/00000000000000000001e83c25e2cc1f575bc3fa0d448041b26f3dd2271bac17
It has a timestamp of 23:17:46 UTC.
But on my node I got:2026-02-11T23:15:51Z Saw new header hash=00000000000000000001e83c25e2cc1f575bc3fa0d448041b26f3dd2271bac17 height=936123
I wonder if you're able to front run this, since Bitcoin blocks take some time to propagate around the network. 🤔
Do you think that was the reason?
Likely yes, but impossible to know for sure. The block after that was found by Foundry USA. It would seem that they happened to receive the SBI Crypto block first.
But sure, let's investigate a bit:
The MARA block was found at 00:54:09 UTC.
The SBI Crypto block was found at 00:54:32 UTC.
Miners can of course have an inaccurate clock but let's check:
The ntime of both SBI Crypto and MARA tends to be very close to UTC:
https://stratum.work/template/SBI%20Crypto
https://stratum.work/template/MARA%20Pool
I used https://www.epochconverter.com/hex to convert the hexadecimal ntime to a human readable format.
So it is likely that the times are indeed correct.
Even though the MARA block was found 23 seconds before the SBI Crypto block, MARA still lost the block race.
EDIT: On second thought, looking at the block template update intervals: (https://stratum.work/timing) MARA and SBI Crypto both update their block template in ~30 second intervals. A 23 second difference is still within that time frame. So hard to say when exactly these blocks were found.
Or it was the next block found that determined the outcome?
The next block always determines the outcome.
even if no one chooses to use it
Probably no one would use it, because the signatures are 100x larger. --> Therefore higher fees.
Also this quantum FUD is ridiculously overblown.
The backup transaction(s) are not financial transactions, since they do not move any monetary value. They are only used to store data, that could have been stored externally.