4 ms·

Blockchains are great for one-thing... guarantee that data is being appended and never modified. When you want to display a record, you can aggregate the data

Blockchains are great for one-thing... guarantee that data is being appended and never modified. When you want to display a record, you can aggregate the data historically and allow people to see changes and attribute them to users and time but you can always see what was originally added. However that's kinda risky for HR because anything committed to that DB will be there... forever!

andreareina 4y ago
That's not the full story, certificate transparency logs (and many other applications) achieve that without using a blockchain.
- yokem55 4y ago
  This is true as long as you trust the issuer of the transparency log to not go back and re-write the history of the log. That's a trust assumption that most folks are fine with, but it should be explicitly be understood to be there. A blockchain takes that trust assumption and spreads it out amongst the social consensus of the chain, so re-witing of history could only occur if there is a consensus to do so.
  - Dylan16807 4y ago
    Who is both internal enough to get a copy of your HR database but external enough that their logs can't be changed as easily as a non-blockchain system's?
    - WrtCdEvrydy 4y ago
      Honestly, it might be possible to do this magic by having the third party issue a signing certificate based on a hash. Send me a hash as new data is added to your DB and I cut you a cert... the next cert includes hash of the last cert plus the new hash you just gave me...
      - Dylan16807 4y ago
        An external service that signs and dates [a hash of] your database is very viable! But at that point there's no longer a distributed ledger.
  - ulrikrasmussen 4y ago
    Isn't the whole idea of certificate transparency to detect that situation? That's why the system also has auditors which would detect such tampering.
    - acdha 4y ago
      CT doesn’t require anonymity: the trust in CT comes from the tamper-evident design creating a risk to your reputation if you cheat. Once you have third-party trust relationships you no longer benefit from the expensive blockchain mechanism designed to work without them.
    - yokem55 4y ago
      The challenge is that if a discrepency is shown, how do you know who is lying? The whistleblowers or the CT log vendor? A consensus mechanism built on top of the log would be able to show the 'history of the history' to enable folks to make better determinations on who to trust or not.
      - ulrikrasmussen 4y ago
        The CT log vendor is signing entries, so although you don't know what the "true" state of the log is, you know that you cannot trust the CT log vendor.
Nursie 4y ago
> Blockchains are great for one-thing... guarantee that data is being appended and never modified. in a distributed, trustless fashion If it's not distributed or trustless, you can do the same without the blockchain.
- namdnay 4y ago
  Yeah, a git repo covers 99% of these pseudo-blockchain usecases
  - chaxor 4y ago
    A git repo is a blockchain... Git is why people like blockchains so much - the value is clear, since it's what we interact with all day.
    - ZiiS 4y ago
      Git is a Merkle tree but to be a full blockchain it would need a consensus algorithm. Clones can add diffrent commits; nothing ensures they agree.
mnd999 4y ago
That’s an event sourcing architecture, and something like Kafka will do it much better than a blockchain. The forever problem can be, ironically, resolved with crypto. If you encrypt each employer record with an employee key then, if the employee data needs to be deleted you just delete the key and the data is gone.
- kenniskrag 4y ago
  Not really with crypto, if you use a a not forever secure crypto algo.
  - mnd999 4y ago
    The usual reason for doing this is to convince auditors or lawyers that the system is in compliance with GDPR or similar legislation, not to resist the attention of three letter agencies. If you can say you’re using industry standard / government approved crypto it should be fine.
  - newswasboring 4y ago
    This argument is equivalent to saying a data center isn't secure because a nuclear bomb can fall on it.
- tokamak-teapot 4y ago
  How about for sharing data between semi-co-operating companies? One problem with sharing data between multiple parties is that you need somewhere central to store it, somewhere that's ultimately trusted. If you decide to trust one party, they could still make mistakes, have downtime, stop supporting the project that requires the shared data, or go rogue. I'm perhaps too ignorant of blockchain, but could it help with this scenario? Does it give a better promise of availability and more trust in its consistency and integrity? edit: I'm thinking here of a blockchain whose only users are this group of companies, not a public system. I don't know if a blockchain becomes useless when it is only used by a small group.
kenniskrag 4y ago
Can be removed/rewinded if you are in a shorter chain of the fork while the block was mined.

andreareina 4y ago

That's not the full story, certificate transparency logs (and many other applications) achieve that without using a blockchain.

yokem55 4y ago
This is true as long as you trust the issuer of the transparency log to not go back and re-write the history of the log. That's a trust assumption that most folks are fine with, but it should be explicitly be understood to be there. A blockchain takes that trust assumption and spreads it out amongst the social consensus of the chain, so re-witing of history could only occur if there is a consensus to do so.
- Dylan16807 4y ago
  Who is both internal enough to get a copy of your HR database but external enough that their logs can't be changed as easily as a non-blockchain system's?
  - WrtCdEvrydy 4y ago
    Honestly, it might be possible to do this magic by having the third party issue a signing certificate based on a hash. Send me a hash as new data is added to your DB and I cut you a cert... the next cert includes hash of the last cert plus the new hash you just gave me...
    - Dylan16807 4y ago
      An external service that signs and dates [a hash of] your database is very viable! But at that point there's no longer a distributed ledger.
- ulrikrasmussen 4y ago
  Isn't the whole idea of certificate transparency to detect that situation? That's why the system also has auditors which would detect such tampering.
  - acdha 4y ago
    CT doesn’t require anonymity: the trust in CT comes from the tamper-evident design creating a risk to your reputation if you cheat. Once you have third-party trust relationships you no longer benefit from the expensive blockchain mechanism designed to work without them.
  - yokem55 4y ago
    The challenge is that if a discrepency is shown, how do you know who is lying? The whistleblowers or the CT log vendor? A consensus mechanism built on top of the log would be able to show the 'history of the history' to enable folks to make better determinations on who to trust or not.
    - ulrikrasmussen 4y ago
      The CT log vendor is signing entries, so although you don't know what the "true" state of the log is, you know that you cannot trust the CT log vendor.

Nursie 4y ago

> Blockchains are great for one-thing... guarantee that data is being appended and never modified. in a distributed, trustless fashion If it's not distributed or trustless, you can do the same without the blockchain.

namdnay 4y ago
Yeah, a git repo covers 99% of these pseudo-blockchain usecases
- chaxor 4y ago
  A git repo is a blockchain... Git is why people like blockchains so much - the value is clear, since it's what we interact with all day.
  - ZiiS 4y ago
    Git is a Merkle tree but to be a full blockchain it would need a consensus algorithm. Clones can add diffrent commits; nothing ensures they agree.

mnd999 4y ago

That’s an event sourcing architecture, and something like Kafka will do it much better than a blockchain. The forever problem can be, ironically, resolved with crypto. If you encrypt each employer record with an employee key then, if the employee data needs to be deleted you just delete the key and the data is gone.

kenniskrag 4y ago
Not really with crypto, if you use a a not forever secure crypto algo.
- mnd999 4y ago
  The usual reason for doing this is to convince auditors or lawyers that the system is in compliance with GDPR or similar legislation, not to resist the attention of three letter agencies. If you can say you’re using industry standard / government approved crypto it should be fine.
- newswasboring 4y ago
  This argument is equivalent to saying a data center isn't secure because a nuclear bomb can fall on it.
tokamak-teapot 4y ago
How about for sharing data between semi-co-operating companies? One problem with sharing data between multiple parties is that you need somewhere central to store it, somewhere that's ultimately trusted. If you decide to trust one party, they could still make mistakes, have downtime, stop supporting the project that requires the shared data, or go rogue. I'm perhaps too ignorant of blockchain, but could it help with this scenario? Does it give a better promise of availability and more trust in its consistency and integrity? edit: I'm thinking here of a blockchain whose only users are this group of companies, not a public system. I don't know if a blockchain becomes useless when it is only used by a small group.

kenniskrag 4y ago

Can be removed/rewinded if you are in a shorter chain of the fork while the block was mined.