5 ms·

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

82 points by brucemacd 8y ago

cwyers 8y ago
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?
- aplummer 8y ago
  Yep I hit the same bug, if you answer “yes” the next question has the same bug.
- brucemacd 8y ago
  Just fixed the wording to match the actual NIST flowchart. Thanks.
  - davidy123 8y ago
    I realize this isn't a life's work, but can you support the back button? Some of the questions are double-negative-ish, or maybe I'm just not a morning person, either way the back button to revise answers without having to go through the whole thing again would be useful.
- pmontra 8y ago
  The problem are the double negative questions. They should be reworded into positives to remove ambiguity.
nootropicat 8y ago
>Data records, once written, are never updated or deleted? >Blockchains do not allow for modification of historical data. Consider a database. If that was true it wouldn't even be possible to send any tokens. Log of all past actions can't be deleted or updated, which is a quite different thing.
- village-idiot 8y ago
  The log entries in a blockchain are supposed to be immutable. You can add new entries, but not change old ones.
  - nootropicat 8y ago
    It depends on how you define what a 'data record' is. State of a specific address can be changed and deleted if the contract is designed to allow it. It's directly equivalent to a normal database that keeps logs of all historical commands entered.
  - decentralised 8y ago
    We often talk about "blockchain as a database" but don't clarify what type of data we are discussing. In second generation blockchains like Ethereum there's a difference between world state and ledger data. Only the Ledger data (record of state transitions) is immutable by design.
  - browsercoin 8y ago
    so what's wrong with Datomic? why do people insist on using blockchain?
    - quellobiondo 8y ago
      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 original trustless timestamping service proposal [1]. [0] https://bitcoin.org/bitcoin.pdf https://bitcoin.org/bitcoin.pdf [1] H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal trust requirements," In 20th Symposium on Information Theory in the Benelux, May 1999.
      - 8y ago
deleted 8y ago
[deleted]
yodude 8y ago
This toy is BS. Please include a justification for the decision. What do you think you are? The mysterious oracle telling earthly idiots what they need? How arrogant!
- brucemacd 8y ago
  Don't take it too seriously. I was trying for a similar vibe to "howfuckedismydatabase.com".
  - yodude 8y ago
    No worries about being taken seriously.
randaouser 8y ago
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 storing the encrypted data on ipfs. In future audits, one can reveal the unencrypted data and ensure the hashes match.
- aeijdenberg 8y ago
  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#redactability https://github.com/benlaurie/objecthash#redactability
  - randaouser 8y ago
    yes precisely, you must include a random value that remains secret until the appropriate reveal time.
- ketzu 8y ago
  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.
  - randaouser 8y ago
    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
Theodores 8y ago
Brilliant. I have found a use case for blockchain thanks to this tool. Who wants to go co-founder on my YC application for... "Blockchain for nuclear weapons" Any fan of Dr Strangelove should know that there is a problem with the system, it is not just the president's nuclear football that can bring on the omnicide that the people in CND are so scared of. Blockchain for nuclear weapons - where could it go wrong? It is an obvious use case, not a solution in search of a problem. I stand corrected with all my scepticism regarding blockchain. We don't need pesky INF treaties, we can just go with smart contracts and have only the president able to launch that decapitation strike rather than some rogue general.
mistrial9 8y ago
is this NISTIR 8202 -- Blockchain Technology Overview ? https://doi.org/10.6028/NIST.IR.8202 https://doi.org/10.6028/NIST.IR.8202
- klenwell 8y ago
  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.

82 points by brucemacd 8y ago

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?

aplummer 8y ago
Yep I hit the same bug, if you answer “yes” the next question has the same bug.
brucemacd 8y ago
Just fixed the wording to match the actual NIST flowchart. Thanks.
- davidy123 8y ago
  I realize this isn't a life's work, but can you support the back button? Some of the questions are double-negative-ish, or maybe I'm just not a morning person, either way the back button to revise answers without having to go through the whole thing again would be useful.
pmontra 8y ago
The problem are the double negative questions. They should be reworded into positives to remove ambiguity.

nootropicat 8y ago

>Data records, once written, are never updated or deleted? >Blockchains do not allow for modification of historical data. Consider a database. If that was true it wouldn't even be possible to send any tokens. Log of all past actions can't be deleted or updated, which is a quite different thing.

village-idiot 8y ago
The log entries in a blockchain are supposed to be immutable. You can add new entries, but not change old ones.
- nootropicat 8y ago
  It depends on how you define what a 'data record' is. State of a specific address can be changed and deleted if the contract is designed to allow it. It's directly equivalent to a normal database that keeps logs of all historical commands entered.
- decentralised 8y ago
  We often talk about "blockchain as a database" but don't clarify what type of data we are discussing. In second generation blockchains like Ethereum there's a difference between world state and ledger data. Only the Ledger data (record of state transitions) is immutable by design.
- browsercoin 8y ago
  so what's wrong with Datomic? why do people insist on using blockchain?
  - quellobiondo 8y ago
    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 original trustless timestamping service proposal [1]. [0] https://bitcoin.org/bitcoin.pdf https://bitcoin.org/bitcoin.pdf [1] H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal trust requirements," In 20th Symposium on Information Theory in the Benelux, May 1999.
    - 8y ago

deleted 8y ago

[deleted]

yodude 8y ago

This toy is BS. Please include a justification for the decision. What do you think you are? The mysterious oracle telling earthly idiots what they need? How arrogant!

brucemacd 8y ago
Don't take it too seriously. I was trying for a similar vibe to "howfuckedismydatabase.com".
- yodude 8y ago
  No worries about being taken seriously.

randaouser 8y ago

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 storing the encrypted data on ipfs. In future audits, one can reveal the unencrypted data and ensure the hashes match.

aeijdenberg 8y ago
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#redactability https://github.com/benlaurie/objecthash#redactability
- randaouser 8y ago
  yes precisely, you must include a random value that remains secret until the appropriate reveal time.
ketzu 8y ago
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.
- randaouser 8y ago
  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

Theodores 8y ago

Brilliant. I have found a use case for blockchain thanks to this tool. Who wants to go co-founder on my YC application for... "Blockchain for nuclear weapons" Any fan of Dr Strangelove should know that there is a problem with the system, it is not just the president's nuclear football that can bring on the omnicide that the people in CND are so scared of. Blockchain for nuclear weapons - where could it go wrong? It is an obvious use case, not a solution in search of a problem. I stand corrected with all my scepticism regarding blockchain. We don't need pesky INF treaties, we can just go with smart contracts and have only the president able to launch that decapitation strike rather than some rogue general.

mistrial9 8y ago

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

klenwell 8y ago
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.