Bitcoin Forum

Unspendable coins, or just coins that the owner is holding for a long time have to be held in the unspent transaction output set.

This set is held in RAM and thus, as the blockchain gets longer, the RAM requirements will increase.  Outputs that are provably unspendable can be pruned.

What about a network rule that coins that haven't moved within the last N blocks can only be spent in blocks that have a height that is divisible by 16 (or some other number).  This would allow clients to only store UTXOs for the last N blocks in RAM.

This allows a light client to do a fair amount of verification of the chain.  It would still have to trust the rest of the network for the blocks that are divisible by 16.

The numbers could be tweaked and maybe even track general network operation.

The disadvantage is that users would need to wait for 8 blocks (1 hour 20 mins) on average to spent old coins.  However, those would be coins in long term storage.

This wouldn't even be a hard fork.

If a hard fork was being considered, then you could have a system where "old coin" transactions could be provisionally included and similar to a coinbase tx would be unspendable for a while.  Proof that they are invalid could be included in a later block.

I think that the problems you're trying to solve can be solved better without a network rule. If the problem is RAM, why not just page out the transactions that are old to disk? You can have a special database just for old on-disk transactions, and check it only when a block gets created that references it. If most nodes aren't relaying old transactions because they only look at the current set in their RAM, then the spender may need to send the transaction directly to a miner, but I think that might be an easier problem to solve.

I know that with the price skyrocketing I wanted to sell some of my reserve coins somewhat quickly, since I had suddenly a lot more value invested in Bitcoin than I was comfortable with. I would have been pretty annoying to need to wait 16 blocks (although perhaps the price would have moved in my favor, but perhaps not).

And if nodes need to load up the full unspent set every 16 blocks, they need to keeping referenced transactions in RAM for that time… I think you just end up with the same problem, but in a more complicated way.