4 ms·

> Read up on git internals, it's a very elegant and simple design and you seem to assume a few things about it that are flat out wrong. I am well acquainted wi

> Read up on git internals, it's a very elegant and simple design and you seem to assume a few things about it that are flat out wrong. I am well acquainted with git internals and object types, which include blobs, trees, commits, and tags. But I do acknowledge that I was wrong about git not hashing the object's contents – it does. > A git repository is in fact a Merkle tree. Every commit is chained to the previous commit via a hash that includes the commit content and the hash of the previous commit. Commits in git are grouped into commit trees that form a single atomic commit, and git allow manipulations of the commit trees, which is fundamentally unacceptable for an immutable, verifiable ledger. That is why I am asserting that git is not an acceptable technology for a ledger. > You can of course modify your local copy of a git repository and rewrite history (i.e. change all the hashes). But that makes it incompatible with upstream history. I have personally squashed commits in my local project copy and force pushed such a squashed commit into a upstream repository thereby completely decimating the commit history in the upstream repository. Previous commit history was completely gone every single time. It is an occasionally useful feature (i.e. fixing mistakes of young developers), but the commit history rewrite is absolutely unacceptable in the compliance world. Just the fact that there is direct, unabridged write access to the history or to the storage where the history is recorded makes such a solution untenable as a ledger database. I do concede that there are some conceptual similarities between git and ledger databases at the architectural level; I do, however, vociferously dispute the suitability of git as a foundation for building a ledger database without a substantial rewrite of the git foundation.

unionpivo 4y ago
You can do the same things with ledger databases, it's just no so convenient, as just typing --force If you have permission to replace database with with your new one (or spin up new instance of DB, adn redirect app to use that, depending on how you are set up), it's just not as convenient (by design). I used centera WORM disks at my previous jobs, for added guarantees. (not by choice, stay away of you have a choice) And once the GDPR came out, and we had to remove some content, that's what we did, made a copy, with bad data removed, nuked centera clean, (created new partition, and disabled old one) and restored now clean data on. As far as our applications were concerned nothing happened.
- inkyoto 4y ago
  You are not incorrect. Ledger databases, as a technology, do not eliminate a possibility of spinning up a shadow ledger and rebuilding the change history in the new ledger that is purged of inconvenient records. Managed ledger database services in the cloud (e.g. QLDB in AWS) offer a partial solution to the problem such as platform generated timestamps in the delete/change history table (hard to forge), delete operations not actually deleting the data but moving it into a separate history table, the separation of access to the ledger (app vs account administrator), disallowing direct access to the storage, setting up anomaly detection alarms in the monitoring layer etc etc. But none of that precludes the possibility of a ledger being nuked or rebuilt (and later nuked).
jillesvangurp 4y ago
You were arguing it's not a proper merkle tree and it is. You are not a little bit wrong there but flat out barking up the wrong tree. It's a merkle tree with full immutability and append only behavior. This is not an accidental/conceptual similarity. It's the single most important design decision that Git is based on. Force push only allows you to wipe out repositories that you control. The whole point of git is that you do not need write access at all to share commits. That's why it's called a pull request and not a push demand. You invite others to look at and maybe merge your changes. There is no way to force the other side to do that and force push rewriting their commit history is not going to help your case for obvious reasons.
- inkyoto 4y ago
  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.

unionpivo 4y ago

You can do the same things with ledger databases, it's just no so convenient, as just typing --force If you have permission to replace database with with your new one (or spin up new instance of DB, adn redirect app to use that, depending on how you are set up), it's just not as convenient (by design). I used centera WORM disks at my previous jobs, for added guarantees. (not by choice, stay away of you have a choice) And once the GDPR came out, and we had to remove some content, that's what we did, made a copy, with bad data removed, nuked centera clean, (created new partition, and disabled old one) and restored now clean data on. As far as our applications were concerned nothing happened.

inkyoto 4y ago
You are not incorrect. Ledger databases, as a technology, do not eliminate a possibility of spinning up a shadow ledger and rebuilding the change history in the new ledger that is purged of inconvenient records. Managed ledger database services in the cloud (e.g. QLDB in AWS) offer a partial solution to the problem such as platform generated timestamps in the delete/change history table (hard to forge), delete operations not actually deleting the data but moving it into a separate history table, the separation of access to the ledger (app vs account administrator), disallowing direct access to the storage, setting up anomaly detection alarms in the monitoring layer etc etc. But none of that precludes the possibility of a ledger being nuked or rebuilt (and later nuked).

jillesvangurp 4y ago

You were arguing it's not a proper merkle tree and it is. You are not a little bit wrong there but flat out barking up the wrong tree. It's a merkle tree with full immutability and append only behavior. This is not an accidental/conceptual similarity. It's the single most important design decision that Git is based on. Force push only allows you to wipe out repositories that you control. The whole point of git is that you do not need write access at all to share commits. That's why it's called a pull request and not a push demand. You invite others to look at and maybe merge your changes. There is no way to force the other side to do that and force push rewriting their commit history is not going to help your case for obvious reasons.

inkyoto 4y ago
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.