I refuse to use Google products for critical infrastructure until they prove they won't kill the product as soon as they lose interest to chase the next shiny trinket or maybe build their 78th chat app
Tamper-Evident Logs
11–20 of 51 posts
Re: Tamper-Evident Logs
#12While in theory, anyone publishing public information might find something like this useful, it's not clear there's much demand for it outside DNS. Something like Dolt [2] seems like it would better for publishing public datasets in a way that changes can be tracked?
[1] https://en.wikipedia.org/wiki/Certificate_Transparency [2] https://www.dolthub.com/
Re: Tamper-Evident Logs
#13Sorry I read the page and I found it very vague. Pretty graphics and lot of white space for not much meat. Basically, looks like the command pattern implemented with signed token for every time you read, you must mutate the 'chain' or array of information. Am I close?
It took quite a bit of time to get there.
Re: Tamper-Evident Logs
#14This isn't obviously anything new. From the github repo, it looks like Google open-sourced the underlying implementation for certificate transparency a while back. [1] Any DNS registry will need something similar to this to participate. While in theory, anyone publishing public information might find something like this useful, it's not clear there's much demand for it outside DNS. Something like Dolt [2] seems like…
The target audience seems to be organizations with strict regulatory requirements who want to prove that data hasn't been tampered with since write. Useful for payment records, storing a log immutable events (patient 23 had an appointment today), stuff like that. The applications aren't endless, but they extend further than just DNS.
Re: Tamper-Evident Logs
#15How long until this is strategically murdered? I refuse to use Google products for critical infrastructure until they prove they won't kill the product as soon as they lose interest to chase the next shiny trinket or maybe build their 78th chat app
Re: Tamper-Evident Logs
#16This isn't obviously anything new. From the github repo, it looks like Google open-sourced the underlying implementation for certificate transparency a while back. [1] Any DNS registry will need something similar to this to participate. While in theory, anyone publishing public information might find something like this useful, it's not clear there's much demand for it outside DNS. Something like Dolt [2] seems like…
Conceptually, maybe not, given the history of Merkle trees and hash chains.
But examples of production code using these ideas are few and far between. That's still valuable.
Re: Tamper-Evident Logs
#17I’m sorry, but Trillian? That seems like a pretty major name collision with a well known piece of software that has been around for decades and has zero chance of getting displaced in search rankings lol
Re: Tamper-Evident Logs
#18A similar data structure has been proposed as a cryptographic accumulator for the Bitcoin UTXO set: https://eprint.iacr.org/2019/611 (Although in this case, the "log" is not append-only; elements can be deleted.)
Re: Tamper-Evident Logs
#19This isn't obviously anything new. From the github repo, it looks like Google open-sourced the underlying implementation for certificate transparency a while back. [1] Any DNS registry will need something similar to this to participate. While in theory, anyone publishing public information might find something like this useful, it's not clear there's much demand for it outside DNS. Something like Dolt [2] seems like…
> This isn't obviously anything new. Conceptually, maybe not, given the history of Merkle trees and hash chains. But examples of production code using these ideas are few and far between. That's still valuable.
Certificate transparency itself has been in production for a while. Apparently since 2013 and required for all certificates since 2018, according to Wikipedia.
Depending on how you define it, everyone who publishes source code using git is already using these ideas. It seems they are all Merkle trees?
I would guess this code would be most useful when the logs are pretty big. If you can download the whole dataset (like with git) and you are making manual edits and sending pull requests, then Dolt's approach sounds more user-friendly? You get a change history, and if upstream rebases then you will see it. (I haven't used them; I just read their blog.)