3 ms·

I am not arguing the case of git having or not having Merkle trees (git has a «weak» implementation of the Merkle trees, for in a ledger database every block's

I am not arguing the case of git having or not having Merkle trees (git has a «weak» implementation of the Merkle trees, for in a ledger database every block's cryptographic signature derives from the contents of the preceding block – a property that git does not possess as it does not support the concept of blocks and operates of commit trees instead that are allowed to be moved around). I am arguing two points, specifically: Point no. 1: > Ledgers are quite easy to build. Cryptographically provable, tamper-proof ledgers that will sustain a 3rd party compliance certification are not easy to build, they are expensive to build, test and certify (very expensive!), and are very expensive to operate, especially in large scale environments. Point no. 2: > Git is a ledger. git is not a proper ledger due to the lack of two fundamental properties of a ledger, as originally stated: 1. an immutable, tamper proof, append-only transaction log; git does not satisfy this requirement by virtue of allowing one to tamper with the commit history. Write access to commits is the major offender here as it is there, and it opens the door for the commit history abuse. An append-only transaction log also offers a linear, entirely immutable, history (a very important quality from the compliance perspective!), whereas git (by virtue of allowing branches) allows for a non-linear, mutable, temporal history that breaks the linear progression of revisions of valuable documents/assets being stored in it. 2. cryptographically verifiable datasets; git offers a limited facility into the verification due to allowing one to modify the commit trees, and, by extension, to rewrite the commit history. A git commit history can't be trusted to from the compliance perspective. What I am sensing is a misconstruction of the purpose of git. git is designed to track changes but not to provide the evidence of changes having not been tampered with. Both purposes have their own places and their own use cases, and the git design is sound and solid, yet it serves an entirely different purpose altogether, and – no – it can't be repurposed as a ledger. That is the case I am arguing.

ProblemFactory 4y ago
Git provides all of those things, as long as everyone agrees on what the current HEAD commit id (hash) is. You could publish that hash in a printed newspaper or with a government regulator. After publishing it is impossible to rewrite commit history without evidence of tampering. Rewriting history and amending commits forces the recalculation of all commit hashes that follow it, and you end up with a completely different final hash. AWS QLDB does the same thing with Amazon holding the final hash.
- inkyoto 4y ago
  Publishing a commit ID in a printed newspaper does not prevent the data loss nor the tampering with the data. Destructive operations in a ledger database are simply not available at the API/interface contract level. A delete operation in a ledger database is non-destructive and does not delete the data but rather creates a new «deleted» revision in the history table. The deleted revision is always available, and it can be «undeleted» as there is nothing special about the deleted revision: it is merely another document revision with the N+1 revision number. The document can be deleted (revision N+1), undeleted (revision N+2), updated multiple times (revision N + M1, N + M2 …), deleted again (revision N + M1 + M2 + P), yet the entire history of all past and current revision(s) is always available, and it can be retrieved/inspected; even after the table is dropped, it can still be undropped without incurring a data loss – all of that is the append-only ledger guarantee. The only destructive operation that is practically possible is tearing down the entire ledger at the infrastructure level, which is irreversible and will result in a full data loss. However it can be mitigated (to a very large extent) through segregating and locking down access to the infrastructure. git does not provide the immutability guarantee as it allows destructive operations, therefore it does not qualify for a ledger proper. A commit history can be rewritten or deleted resulting in a data loss. Published commit ID's are of no use if the data has been tampered with later and valuable revisions have been deleted in perpetuity.
jillesvangurp 4y ago
> every block's cryptographic signature derives from the contents of the preceding block Eh no. Every git commits hash derives from the previous commit hash. That's a bona-fide cryptographic hash. And you can verify it. And git in fact does that when you merge changes. By recalculating the hashes. And it rejects your changes if things don't line up. > git is not a proper ledger due to .... an immutable, tamper proof, append-only transaction log; Also no. It's called a commit log which is exactly this. It's tamper proof because you can verify the chain of hashes (and git does this). It's append only because of those hashes. If you break the chain, git will reject your merge attempts. Any repository fork you don't own, is read-only and won't be able to accept your force pushes with modified hashes because you won't be able to push anything at all. You can only request others to pull; which triggers the before mentioned checks. So you have no way of tricking others into pulling your broken chain of commits. You can only do that to your own repositories. And you have to opt in to it via force push. This is not a weakness but a simple feature. Your data, your choice. > ... cryptographically verifiable datasets Also no. Git uses sha1 hashes, which are cryptographic hashes that you can verify. Better hash algorithms are available and sha1 is not super safe at this point. But good luck creating commits that look legit and preserve the sha1 hash. As mentioned before, they include the hash of the previous commit. Your central, and only, argument is that you can modify your own copies of a repository via force push or poking around on the filesystem. Or whatever. Yes you can; just like with your local copy of whatever blockchain! But don't do that. Because you won't be able to get others to accept your changes/transactions because they'll trivially detect that you tampered with the merkle tree and reject your changes. That's why it's called force push, you opt into this. And others will opt out of it. So, that too is simply wrong.

ProblemFactory 4y ago

Git provides all of those things, as long as everyone agrees on what the current HEAD commit id (hash) is. You could publish that hash in a printed newspaper or with a government regulator. After publishing it is impossible to rewrite commit history without evidence of tampering. Rewriting history and amending commits forces the recalculation of all commit hashes that follow it, and you end up with a completely different final hash. AWS QLDB does the same thing with Amazon holding the final hash.

inkyoto 4y ago
Publishing a commit ID in a printed newspaper does not prevent the data loss nor the tampering with the data. Destructive operations in a ledger database are simply not available at the API/interface contract level. A delete operation in a ledger database is non-destructive and does not delete the data but rather creates a new «deleted» revision in the history table. The deleted revision is always available, and it can be «undeleted» as there is nothing special about the deleted revision: it is merely another document revision with the N+1 revision number. The document can be deleted (revision N+1), undeleted (revision N+2), updated multiple times (revision N + M1, N + M2 …), deleted again (revision N + M1 + M2 + P), yet the entire history of all past and current revision(s) is always available, and it can be retrieved/inspected; even after the table is dropped, it can still be undropped without incurring a data loss – all of that is the append-only ledger guarantee. The only destructive operation that is practically possible is tearing down the entire ledger at the infrastructure level, which is irreversible and will result in a full data loss. However it can be mitigated (to a very large extent) through segregating and locking down access to the infrastructure. git does not provide the immutability guarantee as it allows destructive operations, therefore it does not qualify for a ledger proper. A commit history can be rewritten or deleted resulting in a data loss. Published commit ID's are of no use if the data has been tampered with later and valuable revisions have been deleted in perpetuity.

jillesvangurp 4y ago

> every block's cryptographic signature derives from the contents of the preceding block Eh no. Every git commits hash derives from the previous commit hash. That's a bona-fide cryptographic hash. And you can verify it. And git in fact does that when you merge changes. By recalculating the hashes. And it rejects your changes if things don't line up. > git is not a proper ledger due to .... an immutable, tamper proof, append-only transaction log; Also no. It's called a commit log which is exactly this. It's tamper proof because you can verify the chain of hashes (and git does this). It's append only because of those hashes. If you break the chain, git will reject your merge attempts. Any repository fork you don't own, is read-only and won't be able to accept your force pushes with modified hashes because you won't be able to push anything at all. You can only request others to pull; which triggers the before mentioned checks. So you have no way of tricking others into pulling your broken chain of commits. You can only do that to your own repositories. And you have to opt in to it via force push. This is not a weakness but a simple feature. Your data, your choice. > ... cryptographically verifiable datasets Also no. Git uses sha1 hashes, which are cryptographic hashes that you can verify. Better hash algorithms are available and sha1 is not super safe at this point. But good luck creating commits that look legit and preserve the sha1 hash. As mentioned before, they include the hash of the previous commit. Your central, and only, argument is that you can modify your own copies of a repository via force push or poking around on the filesystem. Or whatever. Yes you can; just like with your local copy of whatever blockchain! But don't do that. Because you won't be able to get others to accept your changes/transactions because they'll trivially detect that you tampered with the merkle tree and reject your changes. That's why it's called force push, you opt into this. And others will opt out of it. So, that too is simply wrong.