4 ms·

A GitHub repository would provide the same level of guarantees right? Everyone else gets read access - the transporter gets write access. They can't rewrite his

A GitHub repository would provide the same level of guarantees right? Everyone else gets read access - the transporter gets write access. They can't rewrite history, or else it gets caught on a mirror that anyone else is maintaining. Certificate Transparency gets the same guarantees as well, without using a blockchain.

sebmellen 6y ago
No... I'm not sure where people get the idea that Git provides what a blockchain does. The biggest hiccup with this proposal is that whoever is provisioning the Git repository (most likely us) would also have the ability to change read/write permissions. This is not the case on a public blockchain. With the solution you describe, we would basically be running our own psuedo-private blockchain, with no advantages over a private blockchain like IBM Hyperledger. But we use a public blockchain for a reason.
- lucb1e 6y ago
  > I'm not sure where people get the idea that Git provides what a blockchain does. I think it's often used as a joke for how broad the definition of "a chain of blocks" is. Probably some people take the comparison too literally. Unless we manage to convince everyone and their moms that when EvilCorp pushed TheirCoin as "blockchain tech" (when really EvilCorp is the party controlling it) we should just laugh and call it EvilCorp Credits, which (last time an evilcorp tried that) we didn't, we need a more specific term than blockchain to distinguish EvilCorp Credits from Bitcoin.
- ReactiveJelly 6y ago
  > the idea that Git provides what a blockchain does. Because Git is a Merkle DAG and blockchain is a Merkle chain. (I think that's the word) So, although it would be ugly, you could store data in Git as a linear series of commits and get the same public or private ledger. > whoever is provisioning the Git repository (most likely us) would also have the ability to change read/write permissions But if your clients who don't trust you are monitoring the repo, and you do something like a `push --force`, they would see the hashes change. > But we use a public blockchain for a reason. I've tried to guess the reasons: 1. If the public ledger is watched by 100 other people, it's much harder to roll back an event than if it's only watched by a few clients who might not notice if you post an event and then immediately revoke it. 2. Since the public ledger gets a lot more traffic, its clock is more accurate. With a private ledger (Like the Git hack) you could still use the latest Bitcoin hash to prove "Commit B is made after Time A", but the window for "Commit B is made before Time C" is very large. Honestly, my problem with blockchain is just the word "blockchain". I love public notarized ledgers. But I don't want to buy something that's riding off the hype of Bitcoin and buzzwords, and I don't want to sell that to people. I need an audit log for something at work and I'm trying to figure out if this is useful. If it is, I would never tell my boss that someone called it blockchain. Non-programmers will think it's unbreakable Hollywood magic crypto.
  - sebmellen 6y ago
    I agree with you on the word blockchain. I hate it. I hate the crypto associations too. How about we start calling real use cases PNL (Public Notarized Ledger) use cases? I love that term.
    - ReactiveJelly 6y ago
      Sure. I'm also thinking, how do they trust my server? With photographs it makes sense - A server that can tamper with photos live is not sci-fi, but it's also just a little bit expensive. In my case I want to notarize text. What if I store "evil message" in my database and publish "good message" to the PNL? Unless the end recipient of "evil message" is also logging to the PNL, (Which is hard, they're supposed to be a dumb client) nobody will ever contradict the server. I could round-trip the messages through the PNL. Make the recipient pull them from there instead of the server. But that sounds like extra risk. It's a tricky problem, and in the end I'll have to cut lots of corners for convenience. That makes me sad.
      - sebmellen 6y ago
        I have to be honest — I don't really understand what you're trying to say. RE: Timestamping text, check out https://app.assembl.net https://app.assembl.net and open "Chronos". It should be self-explanatory to create a timestamp.
  - captn3m0 6y ago
    As an addendum to the idea, perhaps have the git commits signed via a public timestamping server. (ie to say, any commits that do not have a corresponding timestamped signature will not be accepted). As CT shows, there are other ways to solve the audit-logging-for-untrusted-parties problem.
noxer 6y ago
If you ignore the fact that people at GitHub can delete whatever they want. The difference is that they probably wont tamper with someones data but they can. On a distributed ledger however "they" are many different humans who don't know each other and have only one common interest and that is that no one tampers with the data. And even if a majority would collude and tamper it would be impossible to hide that from the others.
- tupputuppu 6y ago
  Well, considering the business is transporting sports cars, what's the threat model here? Someone wants to take the car on a 15min joyride and will bribe a Github employee to be able to do that? And you think the actual implementation of the blockchain will be more secure and tamper pro of?
  - noxer 6y ago
    I didn't meant to say that this is a legit reason to use a DL instead of Github/a database. I just wanted to point out the difference. It may or may not matter in this case because the thread is very limited. There are still very valid reasons to use a DL for example the XRPL had a uptime of 100% in the last year. GitHub certainly does not have that. Also using a public DL means zero maintenance. Again I use the XRPL as example it runs stable and public since over 8 years. To use it you need nothing but an address of a node or better a few for backup because a single nodes obviously can have downtime. No server, no domain register, no cloud computing provider, no backup plans, nothing. The only thing you pay is the Tx "fee" which is only there to prevent spam Tx. Its like 0.00001 XRP so thousands of transactions will cost you cents at most. >And you think the actual implementation of the blockchain will be more secure and tamper pro of? Yes, absolutely. Again XRPL as example because I know it best. There has never been a single byte tampered with in the last 8 years and its several TB of Tx data by now.

sebmellen 6y ago

No... I'm not sure where people get the idea that Git provides what a blockchain does. The biggest hiccup with this proposal is that whoever is provisioning the Git repository (most likely us) would also have the ability to change read/write permissions. This is not the case on a public blockchain. With the solution you describe, we would basically be running our own psuedo-private blockchain, with no advantages over a private blockchain like IBM Hyperledger. But we use a public blockchain for a reason.

lucb1e 6y ago
> I'm not sure where people get the idea that Git provides what a blockchain does. I think it's often used as a joke for how broad the definition of "a chain of blocks" is. Probably some people take the comparison too literally. Unless we manage to convince everyone and their moms that when EvilCorp pushed TheirCoin as "blockchain tech" (when really EvilCorp is the party controlling it) we should just laugh and call it EvilCorp Credits, which (last time an evilcorp tried that) we didn't, we need a more specific term than blockchain to distinguish EvilCorp Credits from Bitcoin.
ReactiveJelly 6y ago
> the idea that Git provides what a blockchain does. Because Git is a Merkle DAG and blockchain is a Merkle chain. (I think that's the word) So, although it would be ugly, you could store data in Git as a linear series of commits and get the same public or private ledger. > whoever is provisioning the Git repository (most likely us) would also have the ability to change read/write permissions But if your clients who don't trust you are monitoring the repo, and you do something like a `push --force`, they would see the hashes change. > But we use a public blockchain for a reason. I've tried to guess the reasons: 1. If the public ledger is watched by 100 other people, it's much harder to roll back an event than if it's only watched by a few clients who might not notice if you post an event and then immediately revoke it. 2. Since the public ledger gets a lot more traffic, its clock is more accurate. With a private ledger (Like the Git hack) you could still use the latest Bitcoin hash to prove "Commit B is made after Time A", but the window for "Commit B is made before Time C" is very large. Honestly, my problem with blockchain is just the word "blockchain". I love public notarized ledgers. But I don't want to buy something that's riding off the hype of Bitcoin and buzzwords, and I don't want to sell that to people. I need an audit log for something at work and I'm trying to figure out if this is useful. If it is, I would never tell my boss that someone called it blockchain. Non-programmers will think it's unbreakable Hollywood magic crypto.
- sebmellen 6y ago
  I agree with you on the word blockchain. I hate it. I hate the crypto associations too. How about we start calling real use cases PNL (Public Notarized Ledger) use cases? I love that term.
  - ReactiveJelly 6y ago
    Sure. I'm also thinking, how do they trust my server? With photographs it makes sense - A server that can tamper with photos live is not sci-fi, but it's also just a little bit expensive. In my case I want to notarize text. What if I store "evil message" in my database and publish "good message" to the PNL? Unless the end recipient of "evil message" is also logging to the PNL, (Which is hard, they're supposed to be a dumb client) nobody will ever contradict the server. I could round-trip the messages through the PNL. Make the recipient pull them from there instead of the server. But that sounds like extra risk. It's a tricky problem, and in the end I'll have to cut lots of corners for convenience. That makes me sad.
    - sebmellen 6y ago
      I have to be honest — I don't really understand what you're trying to say. RE: Timestamping text, check out https://app.assembl.net https://app.assembl.net and open "Chronos". It should be self-explanatory to create a timestamp.
- captn3m0 6y ago
  As an addendum to the idea, perhaps have the git commits signed via a public timestamping server. (ie to say, any commits that do not have a corresponding timestamped signature will not be accepted). As CT shows, there are other ways to solve the audit-logging-for-untrusted-parties problem.

noxer 6y ago

If you ignore the fact that people at GitHub can delete whatever they want. The difference is that they probably wont tamper with someones data but they can. On a distributed ledger however "they" are many different humans who don't know each other and have only one common interest and that is that no one tampers with the data. And even if a majority would collude and tamper it would be impossible to hide that from the others.

tupputuppu 6y ago
Well, considering the business is transporting sports cars, what's the threat model here? Someone wants to take the car on a 15min joyride and will bribe a Github employee to be able to do that? And you think the actual implementation of the blockchain will be more secure and tamper pro of?
- noxer 6y ago
  I didn't meant to say that this is a legit reason to use a DL instead of Github/a database. I just wanted to point out the difference. It may or may not matter in this case because the thread is very limited. There are still very valid reasons to use a DL for example the XRPL had a uptime of 100% in the last year. GitHub certainly does not have that. Also using a public DL means zero maintenance. Again I use the XRPL as example it runs stable and public since over 8 years. To use it you need nothing but an address of a node or better a few for backup because a single nodes obviously can have downtime. No server, no domain register, no cloud computing provider, no backup plans, nothing. The only thing you pay is the Tx "fee" which is only there to prevent spam Tx. Its like 0.00001 XRP so thousands of transactions will cost you cents at most. >And you think the actual implementation of the blockchain will be more secure and tamper pro of? Yes, absolutely. Again XRPL as example because I know it best. There has never been a single byte tampered with in the last 8 years and its several TB of Tx data by now.