7 ms·

Isn't blockchain just a slow database in the first place. What do you mean by blockchain meet database.

arxpoetica 9y ago
Not having read the white paper, it appears the defining difference here is data versioning.
atomical 9y ago
I would assume it means that it's a database where it's impossible to modify the version history and maintain database integrity. It would offer some protection against tampering.
prepend 9y ago
Having a multi-node database that syncs (even slowly) and handles merge conflicts is useful in many applications. Specifically, this is useful in global health situations where you have lots of data collectors with tablets entering data that all has to eventually come together. But has lots of offline/online changes and has an untrusted data entry issue where you don’t want anything deleted.
- he0001 9y ago
  How can it handle merge conflicts automatically?
  - dustingetz 9y ago
    i assume he means https://en.m.wikipedia.org/wiki/Conflict-free_replicated_data_type https://en.m.wikipedia.org/wiki/Conflict-free_replicated_dat...
  - prepend 9y ago
    I don’t need it to merge automatically, but storing them in a way that can be reconciled later is necessary. In some situations merges could be automatic if the records don’t have any conflicts.
- MichaelGG 9y ago
  You've described merging/replication which has nothing to do with blockchain.
  - prepend 9y ago
    That’s right, the blockchain part just adds in immutability of data and being able to trust different nodes. What database models have replication/merging models provide assurance of data integrity and perpetual versioning?
    - MichaelGG 9y ago
      Blockchain adds neither things you mention. Both can be accomplished with digital signatures and timestamping, which are not new. Blockchain alone doesn't prevent you from modifying data -- just rewrite the entire chain. As an example, Bitcoin only prevents this with proof of work, but only following accumulated difficulty prevents someone from thinking my privately-mined chain is true.
- manigandham 9y ago
  We have lots of distributed databases with merging/syncing abilities. You can also append-only and disable delets. No blockchain necessary. I don't get your use-case regarding data collection people, what exactly will a blockchain prevent them from doing? Are they all entering the same piece of data to then pick the version they all input the most?
  - prepend 9y ago
    It’s very likely that I’m just not aware. What databases enforce no deletes or edits in a verifiable way? I would appreciate you sharing some examples. In my use case you have say 5 people covering different territory collecting info that usually doesn’t conflict. Imagine doing a census of a few villages. You don’t want data changed or altered especially time stamps and want it to be shared across all nodes when they are in proximity so they can sync to a remote instance when back in coverage. In some situations it’s literally the group meets at a tree at noon with a coordinator that syncs up all the collectors and moves on to the next group. There are some conflicts that need to be merged, but mostly just syncing lots of nodes asynchronously and you don’t want anyone dropping records, maliciously editing them, or accidentally overwriting.
    - ilikebits 9y ago
      No deletes or edits is a really bad idea, especially for health data. In theory, it's pretty neat; in practice, it's a legal, compliance, and privacy nightmare.

Not having read the white paper, it appears the defining difference here is data versioning.

I would assume it means that it's a database where it's impossible to modify the version history and maintain database integrity. It would offer some protection against tampering.

prepend 9y ago

Having a multi-node database that syncs (even slowly) and handles merge conflicts is useful in many applications. Specifically, this is useful in global health situations where you have lots of data collectors with tablets entering data that all has to eventually come together. But has lots of offline/online changes and has an untrusted data entry issue where you don’t want anything deleted.

he0001 9y ago
How can it handle merge conflicts automatically?
- dustingetz 9y ago
  i assume he means https://en.m.wikipedia.org/wiki/Conflict-free_replicated_data_type https://en.m.wikipedia.org/wiki/Conflict-free_replicated_dat...
- prepend 9y ago
  I don’t need it to merge automatically, but storing them in a way that can be reconciled later is necessary. In some situations merges could be automatic if the records don’t have any conflicts.
MichaelGG 9y ago
You've described merging/replication which has nothing to do with blockchain.
- prepend 9y ago
  That’s right, the blockchain part just adds in immutability of data and being able to trust different nodes. What database models have replication/merging models provide assurance of data integrity and perpetual versioning?
  - MichaelGG 9y ago
    Blockchain adds neither things you mention. Both can be accomplished with digital signatures and timestamping, which are not new. Blockchain alone doesn't prevent you from modifying data -- just rewrite the entire chain. As an example, Bitcoin only prevents this with proof of work, but only following accumulated difficulty prevents someone from thinking my privately-mined chain is true.
manigandham 9y ago
We have lots of distributed databases with merging/syncing abilities. You can also append-only and disable delets. No blockchain necessary. I don't get your use-case regarding data collection people, what exactly will a blockchain prevent them from doing? Are they all entering the same piece of data to then pick the version they all input the most?
- prepend 9y ago
  It’s very likely that I’m just not aware. What databases enforce no deletes or edits in a verifiable way? I would appreciate you sharing some examples. In my use case you have say 5 people covering different territory collecting info that usually doesn’t conflict. Imagine doing a census of a few villages. You don’t want data changed or altered especially time stamps and want it to be shared across all nodes when they are in proximity so they can sync to a remote instance when back in coverage. In some situations it’s literally the group meets at a tree at noon with a coordinator that syncs up all the collectors and moves on to the next group. There are some conflicts that need to be merged, but mostly just syncing lots of nodes asynchronously and you don’t want anyone dropping records, maliciously editing them, or accidentally overwriting.
  - ilikebits 9y ago
    No deletes or edits is a really bad idea, especially for health data. In theory, it's pretty neat; in practice, it's a legal, compliance, and privacy nightmare.