3 ms·
Indeed, this is an excellent thing to consider when you are using immutable databases. GDPR is another such requirement that people are now having to struggle
by mikekchar 9y ago
Indeed, this is an excellent thing to consider when you are using immutable databases. GDPR is another such requirement that people are now having to struggle with. Essentially, you need to be able to rewrite the DB with the new information. For merkle chains that are in the public record (like Google's scheme to to publish certificate requests so that CA shenanigans are obvious to anyone that looks -- the name of which escapes me at the moment), it's not going to be reasonable. It's not so much the merkle chain, but the fact that the data is already distributed. Getting everybody to resign the chain would be pretty hard, but getting them all to delete the data is unreasonable... "Pretty please. We got asked by a judge, you know!"
So essentially, you need to make sure you don't put that kind of information in that kind of DB.
(P.S. It's a bit of a shame that you're getting down voted for such a good question, but I suggest you substitute "merkle chain" for "blockchain" when you want to ask technical questions of this sort.)
- e_d_e_v_at 9y agoI believe the program you're looking for is Certificate Transparency. To be honest, write-permanently databases have been around for a while (for example pgp keyservers that peer and distribute keys relatively quickly). Basically, it is a problem unsolved except by having seriously smart people who do this stuff for its own sake, hacking at the data directly, and are distributed across and able to effectively communicate from many jurisdictions.