[JoshTriplett]

It seems reasonable even on a massive chain. Some people do need to keep the whole archived part of the chain, and anyone who wants to verify it can do so, while day-to-day transactions can just compress that part of the chain down to a hash.

You'd need to keep enough of the chain live for all "live" transactions; that would likely have a time bound (days, perhaps). People who run a "full" client that verifies the complete blockchain then just need to have enough storage for the complete transaction volume over that time period. (And people who only need to worry about their own transactions and don't care about verifying other people's transactions can hold onto even less data.)

[DougN7]

I'm a blockchain noob, but what about people like me that own some bitcoin, but don't touch them for a decade. I imagine my ownership of said coins would be in that part that is truncated/archived/hashed. So how would I then use them?

[wc-]

Someone more familiar with this than me feel free to correct me here, but this is my basic understanding:

If you think of your bitcoins as following a path from address to address, the pruning process would retain the final node or two on that path but discard any previous nodes. So your 10 year old bitcoins at address X are still the most recent node on that chain and are kept around. However, once they are finally sent to another address the bits recording your current address can be forgotten.

[TD-Linux]

In Bitcoin, these final nodes are called UTXOs (unspent transaction outputs), and indeed if you use chain pruning or a light client, they are all you need. They also need to be searched quickly to verify transactions, so they are usually kept in RAM. Because they cannot be pruned, there is a soft fork being developed called SegWit that changes the accounting so that transactions cost more if they create many unspent outputs, or cost less if they spend more outputs than they create.

[artursapek]

Yep. If people are familiar with Redis, it would be much like how Redis periodically rewrites its append-only-file to make it smaller. So you go from a file with full history like

    SET a 2
    SET b 4
    SET a 6
    SET b 10
    SET a 20

to just

    SET a 20
    SET b 10

The snapshot would just retain resulting balances at a certain block height, and no history of how they got there (previous transactions). If people wanted that history it could obviously be archived and accessed separately.

[aeijdenberg]

Would be interested in your feedback on Verifiable Maps as implemented at https://www.continusec.com/ which can give verifiable answers to specific questions such as what is the current balance as well as a full history log of all mutations to the map.

[hinkley]

This is probably a gap in my knowledge, but I hope this isn't a terribly obvious question.

So let's say I buy a bunch of bitcoins and I just sit on them.

A year or two from now, they're worth a bunch of money, so I use them or sell them. How does everyone with the truncated blockchain know that the bitcoins I'm using aren't being double-spent?

[buzzdenver]

The truncated blockchain would contain at least the latest amounts for any wallets. Truncation loses the old transactions, but cannot exclude any wallets that have any BC in them.