> I don't care how other central authorities audit themselves, that's completely off topic We're talking about GDPR here, which is most important in the contex

> I don't care how other central authorities audit themselves, that's completely off topic We're talking about GDPR here, which is most important in the context of centralized systems whose operators have to worry about compliance with European law; really, it's easier to argue that the fully trustless systems you're imagining - what Bitcoin attempts to be - are what are off topic here. > A simple list of "data", it's hash, and a counter would be better for what you want in just about every way. You'd still be able to see that data was modified or removed, and it would be faster, simpler, and easier to work with. If you implement this in a real system, you'll need to rehash all the data any time any of the data is changed. The obvious optimization there is to only hash new data plus a commitment (hash digest) of the old data, at which point you have a blockchain. > I never said anything about Bitcoin. I'm saying that using a blockchain while throwing out the "chain" part is more complicated, slower, and more expensive than using a simple append-only log file. How do you know the append-only log file was actually append-only? You'll want redundancy, which means multiple systems must have their own copies of that log file. Next you'll want auditors to be able to challenge those systems, which is often easiest if you have those systems sign cryptographic statements about what should be in that log file. Real-world systems have log files whose state changes over time, thus you'll want to the chain of blocks optimization so you don't have to re-download and re-hash everything every time the state changes to verify the latest set of signatures for the log file. And at that point, you have a blockchain whose consensus is defined by a centralized quorum of trusted but auditable entities.