Live data from Hacker News

Show HN: Interactive implementation of the NIST Blockchain use case flow chart

brucemacd.github.io

21–30 of 30 posts

Re: Show HN: Interactive implementation of the NIST Blockchain use case flow chart

#21

Earlier quoted context omitted.

so what's wrong with Datomic? why do people insist on using blockchain?

To be fair, you can modify datomic, there’s a mutable delete operation so that you can comply with legal requirements to delete data.

[deleted]

Re: Show HN: Interactive implementation of the NIST Blockchain use case flow chart

#22

Earlier quoted context omitted.

The log entries in a blockchain are supposed to be immutable. You can add new entries, but not change old ones.

so what's wrong with Datomic? why do people insist on using blockchain?

CDIXON: Complement effects are one of the main reasons that technology adoption is non-linear. There are other reasons, including network effects, viral product features, and plain old faddishness.

http://cdixon.org/2009/09/10/non-linearity-of-technology-ado...

Blockchain is 3 for 3!

Re: Show HN: Interactive implementation of the NIST Blockchain use case flow chart

#24

is this NISTIR 8202 -- Blockchain Technology Overview ? https://doi.org/10.6028/NIST.IR.8202

That's what I found, too. It looks like the flowchart in question is on p. 42.

This is really helpful by the way. My sister is completing her MBA and I think IBM is a program sponsor or something and has really been pushing their blockchain product. Whatever the case, she's drank the Blockchain Kool-Aid. I'm going to point her to this (this site and the NIST doc) the next time she brings it up.

Re: Show HN: Interactive implementation of the NIST Blockchain use case flow chart

#25
post #2

I think there's a bug in this. If I answer "Will data records ever need to be updated or deleted once they are written?" with "No" it says "You Don't Need a Blockchain Blockchains do not allow for modification of historical data. Consider a database." It seems like blockchains actually meet that requirement per my entry?

The problem are the double negative questions. They should be reworded into positives to remove ambiguity.

Re: Show HN: Interactive implementation of the NIST Blockchain use case flow chart

#26

Earlier quoted context omitted.

so what's wrong with Datomic? why do people insist on using blockchain?

To be fair, you can modify datomic, there’s a mutable delete operation so that you can comply with legal requirements to delete data.

can't you technically modify block chain in the same way, rollback and fork or something? i feel like this was done for bitcoin at one point

Re: Show HN: Interactive implementation of the NIST Blockchain use case flow chart

#27

Earlier quoted context omitted.

To be fair, you can modify datomic, there’s a mutable delete operation so that you can comply with legal requirements to delete data.

can't you technically modify block chain in the same way, rollback and fork or something? i feel like this was done for bitcoin at one point

yes. but obviously common sense goes out the window as soon as blockchain and crypto comes into play.

Re: Show HN: Interactive implementation of the NIST Blockchain use case flow chart

#28

Earlier quoted context omitted.

so what's wrong with Datomic? why do people insist on using blockchain?

The point is on the ownership of the database and the trust among participants. In Datomic there is a single owner that has full control on the data (probably you, or a company that you fully trust). In the blockchain use-cases there are multiple parties that depend on the data, and no one of them is trusted enough to have full control on the database. (trust-less scenarios) Apart from Bitcoin[0] check out the origin…

In Datomic, you are responsible for the contents on it, but this is the exactly the same for people writing to the blockchain. The notion that by organizing a group of profit motivated to validate transactions is really the same thing as a centralized organization. Look at the Chinese bitcoin miners. How many times have we forked? Now the forked bitcoin is forking!

Say you took out a mortgage on an open ledger (a PoW based blockchain ledger), BYOB. What happens when you get scammed? How do you reverse the transaction? What legal enforcement is there? Remember, you've said it yourself, the blockchain's supposed value comes from that nobody has full control of the database, but this is flawed thinking-the absence of authority does not make a ledger more trustable just because it's not in the control of anyone, which is false, bitcoin being a clear example of centralized ownership, or a perfect model of "rich miners getting richer".

Trust is not a simple matter of storing information, it's much more than that. It's based on human to human level trust, which blockchain industry has pretty much failed spectacularly with the vast majority of ICO pump-dump schemes.

Re: Show HN: Interactive implementation of the NIST Blockchain use case flow chart

#29

although sensitive data should never be written to a public ledger, that does not automatically disregard the need for a blockchain technology. Take a supply chain scenario where multiple control points would input data, however, none of the contributors trust any single touchpoint to maintain the datastore. The senstivity issue can be overcome by submitting a cryptographic hash of the information (say sha256) and st…

Not quite as simple as a cryptographic hash alone - remember that if the set of possible inputs can be easily enumerated, then it's trivial to find the input data by brute force. There are ways to work around this, for example objecthash[0] describes a small modification that prepends the input data with 32 bytes of random data before hashing in order to prevent this. [0] https://github.com/benlaurie/objecthash#redac…

yes precisely, you must include a random value that remains secret until the appropriate reveal time.

Re: Show HN: Interactive implementation of the NIST Blockchain use case flow chart

#30
post #17

although sensitive data should never be written to a public ledger, that does not automatically disregard the need for a blockchain technology. Take a supply chain scenario where multiple control points would input data, however, none of the contributors trust any single touchpoint to maintain the datastore. The senstivity issue can be overcome by submitting a cryptographic hash of the information (say sha256) and st…

One problem of this solution is you can not verify the write in the first place, as the encrypted data is no longer publicly verifiable.

you can share the encrypted data and allow anyone to perform the block hash of the file. As the data is encrypted it should be publicly accessible. EDIT

yes the data itself becomes difficult to verify. Then you must move towards are for more complicated ZKSnark or Homomorphic scheme

Post reply on HN