3 ms·

> Ledgers are quite easy to build. Git is a ledger. It doesn't use a block chain but it does link commits via their hashes; which makes it an audit proof ledger

> Ledgers are quite easy to build. Git is a ledger. It doesn't use a block chain but it does link commits via their hashes; which makes it an audit proof ledger. Unless you can break the hashes, you can't modify its history. Easy as an arm chair theory, impossible in practice without a complete rewrite of git from scratch. You are also disregarding the immutability of the data and the append-only property of stored datasets in ledger DB's: the entire temporal history of changes to a document (or a table) must be available in a ledger database. Changes are linked by virtue a Merkle tree, and the content of each node (i.e. revision) can be cryptographically proven to be untampered with. QLDB documentation provides a visualisation of the cryptographic verification process and of a sequence of steps: https://docs.aws.amazon.com/qldb/latest/developerguide/verification.html https://docs.aws.amazon.com/qldb/latest/developerguide/verif... Git is absolutely the wrong tool for the job as hashes in git are used as identifiers to identify a specific change, but not to cyrptographically checksum the document/the change to the data. Git commits can also merged, rewritten, squashed or deleted – something is absolutely unacceptable in the compliance space. So no, Git it is not easy to build a ledger database out of git if there are strict compliance requirements as I can pull out a revision M out of N revisions of my documents stored in a ledger database, run the revision N through the proof interface and use it in a court hearing as evidence or turn it over to external auditors. And no external auditing body will ever certify a git based solution.

jillesvangurp 4y ago
> Git is absolutely the wrong tool for the job as hashes in git are used as identifiers to identify a specific change, but not to cyrptographically checksum the document/the change to the data. Git commits can also merged, rewritten, squashed or deleted – something is absolutely unacceptable in the compliance space. 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. 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. So, git history is immutable. You can't modify commits without breaking the chain of hashes. It's by definition append only. 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. People tend to use this to clean up their local change history before they send it upstream. With the exception of force push (i.e. just overwrite the remote repository), there is no way to merge a rewritten history. In order to merge changes, there MUST be a shared commit with the same history. It's not optional.
- inkyoto 4y ago
  > 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.
speleding 4y ago
> Easy as an arm chair theory, impossible in practice without a complete rewrite of git from scratch. > Git is absolutely the wrong tool for the job Our company uses ledger.cli on top of git as a bookkeeping ledger [https://www.ledger-cli.org https://www.ledger-cli.org]. Works brilliantly, so much easier to use the text wrangling tools we know and love instead of some brain dead GUI of an accounting program.

jillesvangurp 4y ago

> Git is absolutely the wrong tool for the job as hashes in git are used as identifiers to identify a specific change, but not to cyrptographically checksum the document/the change to the data. Git commits can also merged, rewritten, squashed or deleted – something is absolutely unacceptable in the compliance space. 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. 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. So, git history is immutable. You can't modify commits without breaking the chain of hashes. It's by definition append only. 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. People tend to use this to clean up their local change history before they send it upstream. With the exception of force push (i.e. just overwrite the remote repository), there is no way to merge a rewritten history. In order to merge changes, there MUST be a shared commit with the same history. It's not optional.

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

speleding 4y ago

> Easy as an arm chair theory, impossible in practice without a complete rewrite of git from scratch. > Git is absolutely the wrong tool for the job Our company uses ledger.cli on top of git as a bookkeeping ledger [https://www.ledger-cli.org https://www.ledger-cli.org]. Works brilliantly, so much easier to use the text wrangling tools we know and love instead of some brain dead GUI of an accounting program.