Is an Armageddon-like reset and new Genesis block feasible?

The size of the full blockchain is getting ridiculous, and it's becoming a real pain to run my own full node. So I started thinking: what if we had an "Armageddon" scenario where all addresses and their balances were saved in a massive block, essentially functioning as a new Genesis block? Sure, that would wipe out all transaction history, which might not be a bad thing depending on your perspective. This could also simplify things by flattening addresses and consolidating inputs, getting rid of all that dust.

Bitcoin community very unlikely to accept such idea. But on technical side, you'll face some difficulty such as certain output (such as P2PK and P2MS) actually doesn't have address. If you ever check on block explorer, it usually display wrong information, show error message it can't parse the address or show the raw output. But if this "armageddon" actually preserve all UTXO, then i would say it's technically possible.

If it's frustrating running full node, you have option to run prune node as relief you know. It's bad if you have to trust in Bitcoin. The essence of node is defeated with your idea, you don't have to trust anyone but verify every transactions from genesis to date blocks if you are going to run a node. Maybe you could have also added to help removed non financial records on the blockchain.  Worst suggestion if you ask me.

There's a thread for that here by LoyceV; List of all Bitcoin Addresses with a Balance Without the transactions this is not a replacement for a full node, it's just a repository of addresses. You can go for a printed node to save space and still contribute to the decentralization of the network.

You've been here since 2011. All you need to do is download 1-2 GB per week to keep your blockchain up to date. You can create your own Bitcoin Core Fork that does exactly this, but I don't think many people are going to run it. In this case your blocks will be incompatible with the rest of the world. I think you're missing the point of a blockchain: "a chain of blocks". If you don't want to download all of it, just use Electrum. If you want to verify everything, just sync Bitcoin Core from the very first block ever. Why would you want to trust someone just so you can avoid downloading and verifying 700 GB of data? If I wanted to trust people, I'd use an ETF.

True, but it still means I have to download everything first. And with a pruned node, you cannot import an old address because you need the pruned data to get the history, right? Maybe I explained it poorly. I did not mean the Armageddon block to be a clean cut, but more like a special (big) block that sits in the chain like every other block. So you can start with block 0 if you do not trust anybody, but if you think that the Armageddon block can be trusted because it is verified in the chain like every other block, you start with that one and skip the previous ones.

I think what you're looking for is UTXO Snapshots.

It is definitely feasible, and I see no good reason why nobody has implemented at least a draft of this in Bitcoin Core yet. I guess the starting block height would have to be chosen wisely, but I'd say maybe 900,000 or some arbitrary recent number is a good start.

I don't think that's needed. I haven't tried it, but it looks like Lopp's explanation above is enough to get started.

The blockchain is less than 1 TB, which costs something around $150. I think keeping a multi-trillion dollar asset intact is more important than saving $150 on a node runner. Besides, you can always just run a pruned node if storage is your problem. Theoretically an "armageddon" does not need a hardfork nor a softfork. You can just configure your client to forget every transaction after some block, and keep only the UTXO set. It's more like a local policy.

Home hardware scales much faster than the blockchain grows, so with a 2TB SSD you could easily get years of use (for storage). The problem isn't the hardware; well, I don't really know if I'd consider it a problem. The hardware disadvantage versus Bitcoin is that Bitcoin prefers to be accessible to computers that are 5 years old or more, since obviously if you keep the hardware updated you won't have any problems running a node. What slows things down currently depends on the CPU and the fact that block validation is serial. All of this is if we look at it from the perspective of Moore's Law, so I think the problem only exists for the maximum inclusion philosophy, which, by the way, is what keeps Bitcoin safe from centralization.

I'm more concerned about RAM than storage. Before and right after Bitcoin was created, PC RAM capacity doubled almost annually. That fast growth is long gone. I'm still stuck in 16 GB RAM, just like I was 10 years ago. Many laptops that are a few years old can't even handle 16 GB, and many new ones don't handle much more either. Ideally, you should be able to fit chainstate into RAM. It's now 11 GB, it has been 12 GB, and it will grow further in the future. Being short on RAM is a pain while syncing, and even now it significantly slows down my computer when it wakes up. At this rate, it's going to take 10 years for 64 GB RAM to become mainstream, and by then half of it is needed for chainstate alone.

If you can trust someone else, you can download folder of pruned Bitcoin Core. Some people/group provide it, including BTCPay under name "Fast sync". See https://github.com/btcpayserver/btcpayserver-docker/tree/master/contrib/FastSync. It's even worse if you consider current RAM shortage and price.

If there's demand, I could reactivate my Bitcoin Core pruned blockchain: download it here! (DON'T DO THIS!) topic But it's much easier to just install Electrum if you don't want to download and verify 770 GB. Note that it takes more than just trusting the person who offers it:

A 10+ (6xxx intel) year old PC with 12 GB of DDR3 RAM a well used 1TB SSD from about the same era can with a decent internet connection go from blank PC to fully running node in under a week. Since they can't run Win 11 people are ditching these things all over the place. I don't see it as frustrating to run a full node when you can do it with something that you just rescued from the recyclables pile. -Dave

Besides of AssumeUTXO, there is another technology under development which would not need such an "Armageddon" at all, but would have the same effect and would even be better: ZeroSync. In contrast to AssumeUTXO you don't need to trust a snapshot. ZeroSync would allow you to sync a quasi-full node in seconds. The technology is not that hard to understand: Instead of syncing the blockchain, some nodes create so called "Zero Knowledge Proofs" that the current blockchain state can be safely derived from the genesis block. A very simple mode to do this would be for example: hash all blocks - not only block headers -, then create a hash of that hash, and so on, like a merkle tree of blocks. Everybody can then check that all hashes are correct. But you can do that while your node is idle. You would also of course see on block explorers if the source of your "proofs" is correct. You would also need to integrate the UTXO set in these proofs. You could thus sync your chain with ZeroSync until a block X, compare block hash of X with the major block explorers, and then run your node as a pruned node. ZeroSync is not magic, on Ethereum there is already a working similar system, and afaik you could already run ZeroSync if you want, only it is still alpha/beta software. I think a competitor is SwiftSync, it is a bit more conservative but it takes longer to sync than ZeroSync, but still much shorter than the traditional method.

At first glance, pruning might seem like a solution. However, pruning nodes still download and fully validate the entire blockchain from genesis before discarding older blocks to save disk space. So in terms of reducing the initial validation burden, pruning doesn't really address the concern raised by the OP. As mentioned by LoyceV, UTXO snapshots are probably closer to what the OP is looking for. But rather than trusting blindly, you can optionally verify the historical chain in the background later(which might never happen) lol. Think of this, if concerns about downloading and validating the full chain continue to grow, we may see more users relying on pruned nodes and snapshot-based bootstrapping. In such a scenario, the number of archival node operators might become relatively small compared to the total number of nodes.

Like I pointed out, I do not mean to drop the history for everybody: Also, why should it weaken long-term value storage? As long as an address has a balance, it would appear in the Armageddon block. Not a single Satoshi would be lost.

From a purely accounting perspective, if you freeze all balances in a block, no satoshis disappear from the balance sheet. The issue isn't the existence of satoshis, but rather the guarantee that they haven't been created out of thin air or spent twice. And that guarantee isn't provided by a snapshot, but by verifiable history. In Bitcoin, we don't trust something because it has a serial number or because someone tells us it's correct; we trust it because we can verify every transaction from its Genesis. Bitcoin's value as a long-term store of value lies not only in the current balance, but also in the certainty that the system will remain secure tomorrow. That certainty is built on 15 years of uninterrupted and verifiable proof-of-work.