NIST's answer to “Do you need a blockchain?”(imgur.com)
imgur.com
NIST's answer to “Do you need a blockchain?”
https://imgur.com/a/RlUj9Ed
176 comments
Don't forget the first step "Do you not really care about the technology and just want to write a webapp that gets mad investor money?" and an arrow that goes straight to "Yes"
I think the days of "mad investor money" just because you added blockchain to something may be over. The hysteria over blockchain went hand-in-hand with last year's cryptocurrency bubble, I wouldn't be surprised if smart investors are avoiding it now.
I also wonder how many projects exist now where the blockchain they decided to build their implementation upon will become technical debt.
Also, dig your username, lol.
Also, dig your username, lol.
Definitely the vast majority of them.
Bitcoin and Namecoin are the only really compelling use cases I've ever seen. Even Ethereum kind of falters because there's not much you can really accomplish with a purely digital contract.
Bitcoin and Namecoin are the only really compelling use cases I've ever seen. Even Ethereum kind of falters because there's not much you can really accomplish with a purely digital contract.
This might be seen as picking a nit, but I think the distinction is important.
Ethereum falters not because you can't do much with a purely digital contract, but because people typically want the guarantees of a digital contract except when they don't. There is so much value (if only from inertia), of being able to fall back onto negotiation, or in a more negative circumstance litigation, around an existing contract.
The digital contract is too rigid for how contracts are typically executed in the real world.
Ethereum falters not because you can't do much with a purely digital contract, but because people typically want the guarantees of a digital contract except when they don't. There is so much value (if only from inertia), of being able to fall back onto negotiation, or in a more negative circumstance litigation, around an existing contract.
The digital contract is too rigid for how contracts are typically executed in the real world.
"Smart contracts" have nothing to do with normal contracts. "Distributed script" is a much better name. Basically deterministic scripts you run on multiple computers.
It only falters because the current implementation doesn't scale and the scaling solutions are 1-2 years out. Otherwise running a VM on a block chain is a brilliant idea and has already produced thousands of projects.
"Smart contracts" aren't necessarily analagous to actual contracts. They can also be programmed with configurability.
"Smart contracts" aren't necessarily analagous to actual contracts. They can also be programmed with configurability.
I read the parent implying the opposite. The cases where the eth contracts are secure, because they only rely on actions captured in and only in the network, are very few.
What about things like games with very well defined rules?
Ethereum has proved ok at launching tradable tokens on which a lot of money has changed hands, for better or worse.
Sia is also very compelling and useful (IMO the most useful): https://www.sia.tech/
Very few. You can't have technical debt without first building something useful, and there aren't very many blockchain projects which made it that far.
I assume most pointless uses of the most holy and almighty blockchain could be fairly easily ripped out and replaced with a merkle tree (and in many cases, probably with a linked list).
Way too many of them. I expect sysadmins to be dealing with systems whose datastore is a gratuitous blockchain-derived thing for the next twenty years. And all the programs are "smart contracts", which we used to call "database triggers" and "stored procedures".
Wouldn’t the dumb investors be avoiding it now? I think the smart investors would ideally form an opinion based on fundamentals instead of which buzzword is hot right now.
Smart investors that consider fundamentals would read the flowchart in OP and "consider database" instead of blockchain.
I've reviewed startups this year that had genuinely useful uses for blockchain (I can't go into details as I'd violate confidentiality). They key being that it was "just a tech choice" based on need, on the backend of a much larger idea. They could have done it without a blockchain, but it was a good fit for what they did.
That said, I've also seen a bunch of "X, but with blockchain! Can we have money now?" startups looking for funding.
That said, I've also seen a bunch of "X, but with blockchain! Can we have money now?" startups looking for funding.
And if that opinion was 'this is a garbage fire' then we're back to 'all investors avoid it.'
I'm no investor, but I assume a whole year of the markets crashing would discourage people.
Then again, when you look at the rest of the economy it would seem that people only have a two year memory for really bad ideas, at best.
Yes, I used to think stocks were a good investment, but then that one year they all crashed and I realized stocks are all hype.
I saw a serious mention of blockchain recently as a possible solution to the problem of contaminated produce. The snake oil salesmen will always come up with creative new ideas.
Well Walmart and IBM are working on one of those https://techcrunch.com/2018/09/24/walmart-is-betting-on-the-...
I was chatting to a blockchain enthusiast friend about building something along those lines myself for recording which ingredients came from where but the whole blockchain bit seems a bit tacked on to be trendy. I mean the more obvious way to record the data would be in a regular database but I guess you could write it to a chain as well so people could be sure it hadn't been altered. Dunno.
Watching the video at the end of the techcrunch article there's an IBM guy saying a problem is people record what's gone where with all sorts of incompatible systems - paper, local computers etc which makes it slow to figure which farm did it when you get food poisoning. I guess saying they have to write to data to an open blockchain rather than a Walmart database might be an easier sell?
I was chatting to a blockchain enthusiast friend about building something along those lines myself for recording which ingredients came from where but the whole blockchain bit seems a bit tacked on to be trendy. I mean the more obvious way to record the data would be in a regular database but I guess you could write it to a chain as well so people could be sure it hadn't been altered. Dunno.
Watching the video at the end of the techcrunch article there's an IBM guy saying a problem is people record what's gone where with all sorts of incompatible systems - paper, local computers etc which makes it slow to figure which farm did it when you get food poisoning. I guess saying they have to write to data to an open blockchain rather than a Walmart database might be an easier sell?
This is the thing that no one seems to get: there are two things that make a block chain: a Merkle tree and mining. Mining is the expensive part, but the Merkle tree is the part you actually need for 99% of applications (including tracking produce).
Yes, it's the opposite now. If you say "blockchain" it's a red flag for investors. I know people pivoting away from blockchain (like they should have done to begin with) because of meeting too much resistance in VC meetings.
[deleted]
Meanwhile Overstock.com is selling their retail business and going into blockchain. There is still some hysteria going on.
The overstock guy is here on fox explaining what he's up to https://video.foxbusiness.com/v/5971657426001/?#sp=show-clip...
(Nov. 26, 2018 - 4:16 - Overstock.com CEO Patrick Byrne on the company's shift in focus to the blockchain technology.)
There doesn't seem much too much hysteria going on there. He's hoping to be a leader in STOs which are a less scammy more regulated version of ICOs.
There doesn't seem much too much hysteria going on there. He's hoping to be a leader in STOs which are a less scammy more regulated version of ICOs.
Make sure to mention how you will revolutionize the industry with AI
You can do merkle-tree-signing and other clever things with cryptography to provide auditability without needing any kind of distributed consensus via proof of work/stake/etc. so I think the flowchart could have a couple more "No" branches.
Ya this flowchart really presents a false dichotomy between a Bitcoin style block chain and a traditional database. There are many other crypto currency data structures that could be used in different ways to achieve various goals. (Directed acyclic graphs etc)
One implemtation I would like to see is a consensus algorithm applied to a multiplayer p2p game to prevent hacking.
Another implementation could be for digital assets like textures/skins, 3d models, and animations. This could take something like steam workshop and make it distributed.
One implemtation I would like to see is a consensus algorithm applied to a multiplayer p2p game to prevent hacking.
Another implementation could be for digital assets like textures/skins, 3d models, and animations. This could take something like steam workshop and make it distributed.
Doesn't that somewhat depend on how you define a blockchain? Blockchain doesn't inherently require proof of work/stake/etc, just a chain where each block contains a hash of the previous block(s). Proof of work/stake just happens to be a popular implementation detail because of cryptocurrencies.
I think at a minimum, blockchains also require some kind of byzantine consensus mechanism to manage mutations over a (potentially) hostile p2p network.
(Yes, private permissioned blockchains aren't necessarily p2p, but I'd argue that they need to use byzantine consensus too -- otherwise there's no reason not to just use a managed database instead.)
(Yes, private permissioned blockchains aren't necessarily p2p, but I'd argue that they need to use byzantine consensus too -- otherwise there's no reason not to just use a managed database instead.)
IMO any consensus mechanisms that all participants can agree on is sufficient, including where a single human approves each block. As long as everyone agrees that this is fine, it's sufficient for a blockchain.
Maybe nitpicking, but a blockchain can have a Proof of Authority, Proof of Elapsed Time or some other consensus mechanism that is not byzantine fault tolerant.
what you're describing is a Merkle tree. Blockchains are essentially Merkle trees with a distributed consensus algorithm. Take away the consensus algorithm and you're back to Merkle trees.
https://twitter.com/whitequark/status/946886702932557824
https://twitter.com/hikari_no_yume/status/933791331146784768
More seriously, some people apparently consider git a blockchain: https://medium.com/@shemnon/is-a-git-repository-a-blockchain...
https://twitter.com/hikari_no_yume/status/933791331146784768
More seriously, some people apparently consider git a blockchain: https://medium.com/@shemnon/is-a-git-repository-a-blockchain...
Git histories absolutely are something in the blockchain family of data structures, yes, but they’re not a blockchain proper: the defining chacteristic of such data structures is that they use hashes instead of pointers as references to elements. Merkle trees and blockchains are analogous to trees and singly linked lists, respectively, while git histories are DAGs.
Where things got murky was that the cryptocurrency crowd started to talk about the blockchain that backs Bitcoin in terms where the consensus layer was left implicit (our own Linux vs GNU/Linux story if you want to see it that way), then people less knowledgeable about cryptography started pouring in, they learned a bunch of new terminology, and along the way missed the nuance about the consensus layer being left implicit, so in their minds (and the world at large, eventually) blockchain means the combined data structure and consensus layer — It’s fairly obvious that git doesn’t meet the requirements for this definition of “blockchain”.
Where things got murky was that the cryptocurrency crowd started to talk about the blockchain that backs Bitcoin in terms where the consensus layer was left implicit (our own Linux vs GNU/Linux story if you want to see it that way), then people less knowledgeable about cryptography started pouring in, they learned a bunch of new terminology, and along the way missed the nuance about the consensus layer being left implicit, so in their minds (and the world at large, eventually) blockchain means the combined data structure and consensus layer — It’s fairly obvious that git doesn’t meet the requirements for this definition of “blockchain”.
Git has a great proof-of-work and consensus mechanism in its original application.
Proof-of-work is code that passes tests and consensus is "Linus said 'ok'".
Proof-of-work is code that passes tests and consensus is "Linus said 'ok'".
[deleted]
Hm when I hear "tree", i'd expect it to be at least somewhat balanced. Wikipedia also has "Hash chain" and seems to be a better fit to me, but at that point we are basically arguing semantics. But yes, "blockchain" as used today is more than what we are talking about.
That is not what a merkle tree is. In a merkle tree, only the leaf nodes contain data (or hashes of data).
[deleted]
At least for the purposes of the flowchart, it seems to be defined that way. Otherwise, the "Are you having hard time agreeing on who controls the data store?" bubble would be a bit out-of-place.
That said, if you don't have something like that, then most the rest of the bubbles don't make a whole lot of sense, either. When there's one central authority, they have the ability to unilaterally rewrite history, so you've also lost any features that flow from that not being possible, such as strong auditability.
Git seems like a decent litmus test. Is git, rebase and all, a blockchain technology, or merely a blockchain-like technology?
That said, if you don't have something like that, then most the rest of the bubbles don't make a whole lot of sense, either. When there's one central authority, they have the ability to unilaterally rewrite history, so you've also lost any features that flow from that not being possible, such as strong auditability.
Git seems like a decent litmus test. Is git, rebase and all, a blockchain technology, or merely a blockchain-like technology?
I think perhaps one effective use by a central entity is to have trust centralized but proof of work is distributed.
An example would be that I, as the central entity, know which public keys/key pairs I want to trust, and the proof of work is the owner of said key signing a given block with it. So as the central authority I can't unilaterally rewrite history, but I can unilaterally decide whether the chain is valid.
E.g. Alice wants to deliver a package to Dan by means of Bob and Carlos as couriers. So Alice signs the initial block using her public key and gives the package+signed block to Bob, who signs and gives to Carlos, who signs and gives the package to Dan. Dan can independently verify his trust in Alice, Bob, and Carlos's public keys and then be sure that the package was passed along in the manner recorded in the blockchain.
An example would be that I, as the central entity, know which public keys/key pairs I want to trust, and the proof of work is the owner of said key signing a given block with it. So as the central authority I can't unilaterally rewrite history, but I can unilaterally decide whether the chain is valid.
E.g. Alice wants to deliver a package to Dan by means of Bob and Carlos as couriers. So Alice signs the initial block using her public key and gives the package+signed block to Bob, who signs and gives to Carlos, who signs and gives the package to Dan. Dan can independently verify his trust in Alice, Bob, and Carlos's public keys and then be sure that the package was passed along in the manner recorded in the blockchain.
That reads to me as yet another scenario where blockchain is the stone in the soup.
If trusting Alice, Bob and Carlos's public keys is equivalent to trusting them, then I don't really need a blockchain to verify that they did what they said they did.
If it's not, then I don't trust the blockchain as a record of what happened, because there's no chain of trust between what they wrote in the blockchain and what they actually did.
The reason why this sort of thing works with cryptocurrency is because, with cryptocurrency, the blockchain is reality. If the blockchain says I have 1BTC, I have it. If it doesn't, I don't.
As soon as you try to apply it to something like supply chain management, though, that falls apart. The map is not the territory. So you have to add a whole bunch more stuff to the system to try and ensure that what's been recorded is accurate. Not entirely unlike how, in the story of the stone soup, people had to add a whole bunch more stuff besides the stone to the pot in order to make sure the soup was tasty and nutritious.
If trusting Alice, Bob and Carlos's public keys is equivalent to trusting them, then I don't really need a blockchain to verify that they did what they said they did.
If it's not, then I don't trust the blockchain as a record of what happened, because there's no chain of trust between what they wrote in the blockchain and what they actually did.
The reason why this sort of thing works with cryptocurrency is because, with cryptocurrency, the blockchain is reality. If the blockchain says I have 1BTC, I have it. If it doesn't, I don't.
As soon as you try to apply it to something like supply chain management, though, that falls apart. The map is not the territory. So you have to add a whole bunch more stuff to the system to try and ensure that what's been recorded is accurate. Not entirely unlike how, in the story of the stone soup, people had to add a whole bunch more stuff besides the stone to the pot in order to make sure the soup was tasty and nutritious.
What would you suggest as an alternative where each step still independently verifies all previous steps?
I guess you could just store it in a database and store the hashes and signatures as columns but again, that seems more like implementing a blockchain strategy using a traditional RDBMS.
*After your edit: It seems like the blockchain is still useful in this case as a series of signed statements where it can be (generally) verified that each signature was made by a certain entity at a certain point in the chain.
I guess you could just store it in a database and store the hashes and signatures as columns but again, that seems more like implementing a blockchain strategy using a traditional RDBMS.
*After your edit: It seems like the blockchain is still useful in this case as a series of signed statements where it can be (generally) verified that each signature was made by a certain entity at a certain point in the chain.
I'm not a logistics guy, so maybe I'm missing something here, but I think I'd just not do it at all.
Why would I need to do such a thing? What, in practical terms, does it get me?
Why would I need to do such a thing? What, in practical terms, does it get me?
So looking back at your post, I think the big difference is trusting someone's key isn't equivalent to trusting them. Trusting Alice's key just means I can trust that a statement signed by Alice's key was indeed signed/made by Alice.
The value of the system is that Bob cannot modify what Alice has said and signed. So the only place where Bob could lie is in his own block. Additionally, once Carlos signs his block, Bob and Alice can no longer change their statement either, so we're partly relying on Carlos to verify that he receives the package in the condition described by Bob's block.
One vulnerability I see is Carlos could just cut out Bob and fork the chain with his own block coming right after Alice. To counter that you could have each sender sign off on who they entrusted the package to (i.e. Alice signs her block/creates a block saying she gave the package to Bob).
So essentially the idea is to set up a system of untrusted participants whose identities can be verified/trusted. Bob might have an incentive to lie about who he received the package from or what the condition of the was package when he received it, but he doesn't have much incentive to let other people sign messages using his key.
I'm not sure as a system whether there is actual value or benefits here over other simpler solutions, it's just a fun thought experiment I've been doing to try and figure out scenarios where blockchains could provide real benefits over other systems.
The value of the system is that Bob cannot modify what Alice has said and signed. So the only place where Bob could lie is in his own block. Additionally, once Carlos signs his block, Bob and Alice can no longer change their statement either, so we're partly relying on Carlos to verify that he receives the package in the condition described by Bob's block.
One vulnerability I see is Carlos could just cut out Bob and fork the chain with his own block coming right after Alice. To counter that you could have each sender sign off on who they entrusted the package to (i.e. Alice signs her block/creates a block saying she gave the package to Bob).
So essentially the idea is to set up a system of untrusted participants whose identities can be verified/trusted. Bob might have an incentive to lie about who he received the package from or what the condition of the was package when he received it, but he doesn't have much incentive to let other people sign messages using his key.
I'm not sure as a system whether there is actual value or benefits here over other simpler solutions, it's just a fun thought experiment I've been doing to try and figure out scenarios where blockchains could provide real benefits over other systems.
So I think that, here, the 2nd-to-last question bubble in the flow chart is the key one. Because the question you're circling around is, "How do we verify that records are written by specific people?"
If you can centralize the records management, then you don't have a problem deciding who should own the record store. At that point, good old-fashioned authentication will solve your problem.
If you can't centralize records management, then things get trickier. But I think the trickiest part would still be to come up with a non-contrived logistics scenario where there isn't an obvious custodian you can put in charge of a centralized record.
If you can centralize the records management, then you don't have a problem deciding who should own the record store. At that point, good old-fashioned authentication will solve your problem.
If you can't centralize records management, then things get trickier. But I think the trickiest part would still be to come up with a non-contrived logistics scenario where there isn't an obvious custodian you can put in charge of a centralized record.
I was imagining a potentially offline scenario where the blocks are physically recorded (i.e printed) and attached to the package as some kind of barcode or QR code. I suppose you could also deal with a scenario where the digital record is primarily transported with the shipment as well.
A tamperproof log with certain commodity hardware might be easier than guaranteeing secure network access to every participant in the chain.
One example I've seen in the wild is Walmart investing in blockchain for food safety. This is me in a sense trying to reverse engineer that thought process/system to figure out what benefits it might bring.
Looks like the system I'm thinking of is roughly a Proof of Authority system (https://en.wikipedia.org/wiki/Proof-of-authority). Your point about blockchain being unnecessary here is one of the points brought up in the Wikipedia article under Comparisons.
A tamperproof log with certain commodity hardware might be easier than guaranteeing secure network access to every participant in the chain.
One example I've seen in the wild is Walmart investing in blockchain for food safety. This is me in a sense trying to reverse engineer that thought process/system to figure out what benefits it might bring.
Looks like the system I'm thinking of is roughly a Proof of Authority system (https://en.wikipedia.org/wiki/Proof-of-authority). Your point about blockchain being unnecessary here is one of the points brought up in the Wikipedia article under Comparisons.
[deleted]
In your opinion, is git source repository a blockchain if you cryptographically sign each commit?
How about ZFS filesystem?
How about ZFS filesystem?
A linked list then essentially?
Here's one library from Google, used by Certificate Transparency: https://github.com/google/trillian
In talking to a few companies who thought they wanted a blockchain, one big misconception is that blockchain will magically solve the interoperability issue where multiple parties have data in disparate formats.
Blockchain doesn't inherently do any data translation or normalization.
It's interesting to me how resilient this misconception is. I have come to the conclusion that it's just wishful thinking for a magic bullet for an age-old difficult problem.
Blockchain doesn't inherently do any data translation or normalization.
It's interesting to me how resilient this misconception is. I have come to the conclusion that it's just wishful thinking for a magic bullet for an age-old difficult problem.
Thinking, "this might solve our interoperability woes", seems to be the classic motivator behind big companies' interest in every tech trend.
It was there with Big Data ("Who cares? Just throw it in a data lake!").
It was there with NoSQL ("Who cares? Just throw it in a document store!")
It was there with XML ("XML is just one format, right?")
It was there with COM/CORBA/AppleScript/etc ("The vendor can make their own data readable!")
I wouldn't be surprised if, millennia ago, there were organizations trying to figure out how fluted spear heads might solve their communication woes.
It was there with Big Data ("Who cares? Just throw it in a data lake!").
It was there with NoSQL ("Who cares? Just throw it in a document store!")
It was there with XML ("XML is just one format, right?")
It was there with COM/CORBA/AppleScript/etc ("The vendor can make their own data readable!")
I wouldn't be surprised if, millennia ago, there were organizations trying to figure out how fluted spear heads might solve their communication woes.
> one big misconception is that blockchain will magically solve the interoperability issue where multiple parties have data in disparate formats.
That reminds me so hard of RDF/"linked data", which was (and is still in some sectors) popular for same motivation I think.
Data interoperability is a real problem, with real pain, which is why people get so excited about tech they think will solve it. But no magic technology is going to solve it, it's a human problem. (At least I can see _why_ people (wrongly) thought RDF would; no idea how they arrived at that misconception of blockchain).
That reminds me so hard of RDF/"linked data", which was (and is still in some sectors) popular for same motivation I think.
Data interoperability is a real problem, with real pain, which is why people get so excited about tech they think will solve it. But no magic technology is going to solve it, it's a human problem. (At least I can see _why_ people (wrongly) thought RDF would; no idea how they arrived at that misconception of blockchain).
> (At least I can see _why_ people (wrongly) thought RDF would; no idea how they arrived at that misconception of blockchain)
There was briefly the bad idea that "NoSQL means we don't have to care about our schemas anymore" bridging the other two bad ideas.
There was briefly the bad idea that "NoSQL means we don't have to care about our schemas anymore" bridging the other two bad ideas.
In my experience data interoperability issues are usually resolved by writing adapters, and using a datastore with strict integrity constraints. This is essentially what creating a blockchain transaction is. The chain code is responsible for running strong integrity constraints on the submitted data, and the client must adapt the data as required by the chain code before submitting a transaction. You can't get rid of the work required, but you can create a system that enforces the rules.
Matches with my experience. One guy was thinking about creating a google ads alternative, as according to his thoughts, google overreports the clicks, and blockchain will give accurate number of clicks.
I don't think that the lay-upper-middle-manager (aka the customer) cares. It's all about looking good in your yearly reviews.
The actual NIST report is here.
https://csrc.nist.gov/publications/detail/nistir/8202/final
https://csrc.nist.gov/publications/detail/nistir/8202/final
I think the key point that crypto-enthusiasts often miss here is "Are the entities with write access having a hard time deciding who should be in control of the data store". For many purported use-cases for blockchains (things having to do with traceability of goods for instance) the answer to this question is most likely "no".
For instance if you want to trace a shipment of pineapples there must be some entity somewhere who's tasked with making sure that the goods are up to code (otherwise anybody could just lie on the blockchain). This entity is clearly "in control of the data store". Of course you may want to be able to publicly audit that entity's records to detect any wrongdoings or suspicious activity, but that doesn't require a blockchain at all, simply having a signed public database/log (that anybody could archive) would do the trick nicely for instance.
For instance if you want to trace a shipment of pineapples there must be some entity somewhere who's tasked with making sure that the goods are up to code (otherwise anybody could just lie on the blockchain). This entity is clearly "in control of the data store". Of course you may want to be able to publicly audit that entity's records to detect any wrongdoings or suspicious activity, but that doesn't require a blockchain at all, simply having a signed public database/log (that anybody could archive) would do the trick nicely for instance.
I could see a situation where several rival pineapple growers supply several rival pineapple retailers where they are not sure who should control the data store but where there would be an advantage to having an auditable record. If they lie, the recipient of the iffy pineapples could go hassle the supplier.
Not sure about the virtues of signed public database/logs vs blockchains.
Not sure about the virtues of signed public database/logs vs blockchains.
I remember trying to explain this to a bank I worked for a few years ago. The trouble is, they're all so hyped up by the buzzwords they don't listen.
And before I knew it they'd hired a self-styled "blockchain consultant" at god knows what daily rate. I realised I was fighting a losing battle. Probably should have reinvented myself there and then as a blockchain consultant.
And before I knew it they'd hired a self-styled "blockchain consultant" at god knows what daily rate. I realised I was fighting a losing battle. Probably should have reinvented myself there and then as a blockchain consultant.
I was honestly expecting a picture of the word "No".
Also note the "blockchain trilemma": at the moment you can have decentralised and secure systems that don't scale (e.g. Bitcoin), or you can have scalable and secure systems which aren't decentralised (e.g. all the "private permissioned blockchain" solutions which don't actually need to use a blockchain).
Or scalable and decentralized systems that aren't secure (e.g. SMTP) :)
Yes, and as per your example this combination also doesn't need blockchain. The only combination that actually needs blockchain is decentralised and secure.
The blockchain "revolution" is very similar to AI, bots, IoT, Web 2.0, etc etc.
These were all mainstream "fads" that died down over time. As I've said before, many of these technologies are revolutionary and extremely useful - but only in their respective domain. Calling any of them, blockchain included, the end-all-be-all is foolish. There are some legitimate use cases for which this will apply greatly. But it's only a matter of time before another technology goes viral only for folks to realize it's intended use cases and then simmer down to a focuses, purpose-driven tech.
These were all mainstream "fads" that died down over time. As I've said before, many of these technologies are revolutionary and extremely useful - but only in their respective domain. Calling any of them, blockchain included, the end-all-be-all is foolish. There are some legitimate use cases for which this will apply greatly. But it's only a matter of time before another technology goes viral only for folks to realize it's intended use cases and then simmer down to a focuses, purpose-driven tech.
Seems to be very similar to this diagram from the hyperledger edX course.
https://www.jsemeraro.com/wp-content/uploads/2017/12/Blockch...
https://www.jsemeraro.com/wp-content/uploads/2017/12/Blockch...
This[1] is one of the sources provided in the NIST Report[2] appendix of references.
[1] http://doyouneedablockchain.com/ [2] https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf
[1] http://doyouneedablockchain.com/ [2] https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf
Nice to see at least one comment from someone that has actually read the document....
Could have been simplified to "no"
That's actually what I was expecting.
Except this is an actually helpful diagram that points you towards other solutions depending on what benefits you think a blockchain might give you, instead of an (unhelpful) outright dismissal.
Not really, this seems like an actionable heuristic that gives actual alternatives and a concrete, realistic case where a blockchain might help.
If you are trying to build a currency or have a timestamp system, the answer is yes.
This is why the phrase Bitcoin not Blockchain has been floating around.
This is why the phrase Bitcoin not Blockchain has been floating around.
One perfect use case is amateur radio cloud logging. Logbook of the World[0] is the defacto standard, which implements cryptographic signing, but the database is centralized, and it's consistently broken, lagging, and needs frequent updates and downtime, and due to this it probably costs a lot of money to the American Radio Relay League (ARRL) and her members. Blockchain is the perfect solution IMO.
[0]: http://www.arrl.org/logbook-of-the-world
[0]: http://www.arrl.org/logbook-of-the-world
Based on a naïve reading of your description, it's unclear whether those problems are due to some inherent properties of a centralized database, or if they're merely implementation details of the current host. Any thoughts?
LotW is just bad engineering to solve a problem that doesn't exist. I have never used it and never will.
Ultimately a QSO is something between two people. If both people believe they made a QSO, they made a QSO. If you want to have a contest over who can make the most QSOs, you need a judge to define what their definition of a QSO is. LotW is not a judge, but rather a bunch of random antique network protocols with cargo-cult cryptography thrown in to make it as difficult as possible to use. But you can still easily lie about having made a QSO. So it solves nothing.
For those that aren't hams, enjoy: http://www.arrl.org/files/file/LoTW%20Instructions/Quick%20S...
Also, a "QSO" is basically radio contact between two parties. Most people agree a QSO has been made when the remote party understands your callsign, you understand theirs, and that you have verified the understanding. (Some people are more liberal or more conservative, however.)
Ultimately a QSO is something between two people. If both people believe they made a QSO, they made a QSO. If you want to have a contest over who can make the most QSOs, you need a judge to define what their definition of a QSO is. LotW is not a judge, but rather a bunch of random antique network protocols with cargo-cult cryptography thrown in to make it as difficult as possible to use. But you can still easily lie about having made a QSO. So it solves nothing.
For those that aren't hams, enjoy: http://www.arrl.org/files/file/LoTW%20Instructions/Quick%20S...
Also, a "QSO" is basically radio contact between two parties. Most people agree a QSO has been made when the remote party understands your callsign, you understand theirs, and that you have verified the understanding. (Some people are more liberal or more conservative, however.)
I love the idea of sending data over ham radio but, outside some kind of disaster or simply making hams happy, is there a practical use?
Is there a practical use? Not really. Satellites and fibers are more reliable than hoping the ionosphere is in the right configuration for the path that you want to send messages on.
It is nice to know that you can communicate with the other side of the world using no infrastructure, but it's unlikely that it will ever be necessary.
Airplanes on oceanic routes use HF radios, which is the same idea as ham radio. I am not sure why they don't use satellites. I guess it's cheaper than buying satellites.
It is nice to know that you can communicate with the other side of the world using no infrastructure, but it's unlikely that it will ever be necessary.
Airplanes on oceanic routes use HF radios, which is the same idea as ham radio. I am not sure why they don't use satellites. I guess it's cheaper than buying satellites.
Might be useful during wartime, since it's likely that lots of infrastructure will be taken down.
Any additional communication skill would be handy to know about should it become necessary to use alternate communication methods in times of emergencies when normal communications are disrupted. Since the Internet controls practically everything we do, and enemy would want to disable our Internet access to cripple our communications. We would then need alternate ways to communicate voice, text and data. So a practical use would be to practice and gain experience ahead of time, and then hope you never have to use this as a last resort
A technology which incentivizes consuming all available resources and favors those with the most sounds like a perfect fit for amateur radio.
You wouldn't need mining for such a blockchain. It could easily work on proof of stake.
PoS doesn't actually work. The wastefulness of PoW mining is what keeps the network honest, without the waste there is no incentive to stay on "the main chain" (i.e. prevent an accidental or malicious fork) since it costs nothing to "mine" every possible chain.
It works for this use case. Radio contact logging is based on the honor system, and a contact is valid if both ends log it.
Currently it's a centralized database that anyone can input data into. In this use case you'd simply decentralize the DB.
Blockchains are needed in cryptocurrencies to prevent the double spend problem. There's no double spend problem in logging radio contacts. The incentives to attack are much less too, because there's no value to steal.
Currently it's a centralized database that anyone can input data into. In this use case you'd simply decentralize the DB.
Blockchains are needed in cryptocurrencies to prevent the double spend problem. There's no double spend problem in logging radio contacts. The incentives to attack are much less too, because there's no value to steal.
Hmm. I see your point.
I think Ethereum's plans for PoS penalizes people (on the main chain) people who have previously signed the wrong chain, so I don't think that's an insurmountable obstacle. It's all still a work in progress though with a lot of cases like that. I'm deeply suspicious of any projects that claim to have already figured out PoS.
[deleted]
Or some kind of decentralized wiki. It's not that far off from IPFS. If you want to keep history immutable, then a blockchain would do it.
i don't see how LotW requires consensus? you could have a bunch of sites which just take these signed logbook records and store them, and make them available for other sites to download. the records verify themselves by virtue of cryptographic signature.
So if you want a "tamper-proof", auditable, decentralized data store, go with block chain.
> So if you want a "tamper-proof", auditable, decentralized data store, go with git.
Yes.
Yes.
git doesn't do automated consensus, any inconsistency must be resolved manually. That doesn't work for a global system where data will often arrive in a different order to different nodes.
Git isn't decentralized, each data store has an owner.
That’s true of all decentralized algorithms.
Decentralized just means someone else can own it too.
Decentralized just means someone else can own it too.
In my view the most sane definition of what blockchain is includes Git.
Therefore, Bitcoin isn't decentralized, each node has an owner.
The owner of a node on a blockchain doesn't own the data store, the owner of a git repo does. The owner of a git repo can even rewrite the whole history of a repo. To equate the two doesn't make much sense to me.
Seems this is an exercise in how loosely we can define blockchain. In my opinion all that's being achieved is confusing blockchains, as defined by their creator, with merkle trees.
Seems this is an exercise in how loosely we can define blockchain. In my opinion all that's being achieved is confusing blockchains, as defined by their creator, with merkle trees.
> The owner of a git repo can even rewrite the whole history of a repo.
If tomorrow Linus rewrites even a part of history of [0], every single one of Debian, Canonical, Red Hat, Amazon, Gentoo, Google, AOSP and my-friend-who-always-builds-mainline are going to notice. They are all going to continue to have the choice to fork their own; only this time, better motivated. Hell, if Linus is sensible in such a scenario, he will abandon his 'history-rewritten' fork and clone one of these guys' and carry on, just so everyone can stay on the same fork with the least effort.
Yes, rewriting history would be a fork. Git is not a VCS where a remote can rewrite local branches. Only the local user can make Git do so. If someone decides to follow Linus's history-rewritten fork, they will have to voluntarily do so; and even if they don't, they can always carry the original fork on among themselves, paying no heed to Linus [1]. Does this sound similar to how forks work in Bitcoin and Ethereum?
----
0: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
1: This is because Linus is the owner of only one repo: [0]. Upon cloning a repo, the cloner becomes the owner of the clone. Ownership does not transfer. A cloner is free to go their separate way with their clone, as they are free to continue to copy changes dilligently from the source, and everything in between. Git does not concern itself with reputation or authority.
If tomorrow Linus rewrites even a part of history of [0], every single one of Debian, Canonical, Red Hat, Amazon, Gentoo, Google, AOSP and my-friend-who-always-builds-mainline are going to notice. They are all going to continue to have the choice to fork their own; only this time, better motivated. Hell, if Linus is sensible in such a scenario, he will abandon his 'history-rewritten' fork and clone one of these guys' and carry on, just so everyone can stay on the same fork with the least effort.
Yes, rewriting history would be a fork. Git is not a VCS where a remote can rewrite local branches. Only the local user can make Git do so. If someone decides to follow Linus's history-rewritten fork, they will have to voluntarily do so; and even if they don't, they can always carry the original fork on among themselves, paying no heed to Linus [1]. Does this sound similar to how forks work in Bitcoin and Ethereum?
----
0: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
1: This is because Linus is the owner of only one repo: [0]. Upon cloning a repo, the cloner becomes the owner of the clone. Ownership does not transfer. A cloner is free to go their separate way with their clone, as they are free to continue to copy changes dilligently from the source, and everything in between. Git does not concern itself with reputation or authority.
Yes, and that's part of the beauty of git, everyone can go fork it and create their own version of a data store.
In the case of something like a cryptocurrency, letting everyone create their own version of a ledger and get to decide which one is "correct", would be a complete and total failure of the system.
In my opinion, that should be part of what differentiates a merkle tree based VCS from a blockchain. The point of a blockchain is a singular, decentralized, "immutable" data store. Unlike git, version control is not what everything revolves around, version control is there so we can be sure it's a singular, decentralized, "immutable" data store.
I just don't see the point in defining blockchains so vaguely that even git counts. In practice, these are different systems that deserve different terminology.
In the case of something like a cryptocurrency, letting everyone create their own version of a ledger and get to decide which one is "correct", would be a complete and total failure of the system.
In my opinion, that should be part of what differentiates a merkle tree based VCS from a blockchain. The point of a blockchain is a singular, decentralized, "immutable" data store. Unlike git, version control is not what everything revolves around, version control is there so we can be sure it's a singular, decentralized, "immutable" data store.
I just don't see the point in defining blockchains so vaguely that even git counts. In practice, these are different systems that deserve different terminology.
> everyone can go fork it and create their own version of a data store
And with cryptocurrencies, everyone can go fork it and create their own ledger. That not many do it is unrelated to the datastructure.
> In the case of something like a cryptocurrency, letting everyone create their own version of a ledger and get to decide which one is "correct", would be a complete and total failure of the system.
Yes, as a system.
> In my opinion, that should be part of what differentiates a merkle tree based VCS from a blockchain.
A "merkle tree based VCS" is a system. A cryptocurrency is a system. A blockchain is just a datastructure.
> The point of a blockchain is a singular, decentralized, "immutable" data store.
Which git is.
> Unlike git, version control is not what everything revolves around
In git, version control is not what everything revolves around. Git was designed for version control, and a merkle-tree of objects and dirtrees and metadata and commits was chosen to implement it on, which is what everything revolves around.
Just like how Bitcoin was designed for payment, and a blockchain of transactions was chosen to implement it on.
> I just don't see the point in defining blockchains so vaguely that even git counts.
This sounds a bit like you're trying to come up with a definition of "blockchain" with an express purpose of excluding git from it.
> In practice, these are different systems [emphasis mine] that deserve different terminology.
And this, is the heart of our disagreement. You're comparing the systems git and cryptocurrencies, only you call the latter "blockchains". I'm comparing datastructures, and I distinguish between the terms "cryptocurrency" (which I consider a system) and "blockchain" (which I consider a datastructure).
And with cryptocurrencies, everyone can go fork it and create their own ledger. That not many do it is unrelated to the datastructure.
> In the case of something like a cryptocurrency, letting everyone create their own version of a ledger and get to decide which one is "correct", would be a complete and total failure of the system.
Yes, as a system.
> In my opinion, that should be part of what differentiates a merkle tree based VCS from a blockchain.
A "merkle tree based VCS" is a system. A cryptocurrency is a system. A blockchain is just a datastructure.
> The point of a blockchain is a singular, decentralized, "immutable" data store.
Which git is.
> Unlike git, version control is not what everything revolves around
In git, version control is not what everything revolves around. Git was designed for version control, and a merkle-tree of objects and dirtrees and metadata and commits was chosen to implement it on, which is what everything revolves around.
Just like how Bitcoin was designed for payment, and a blockchain of transactions was chosen to implement it on.
> I just don't see the point in defining blockchains so vaguely that even git counts.
This sounds a bit like you're trying to come up with a definition of "blockchain" with an express purpose of excluding git from it.
> In practice, these are different systems [emphasis mine] that deserve different terminology.
And this, is the heart of our disagreement. You're comparing the systems git and cryptocurrencies, only you call the latter "blockchains". I'm comparing datastructures, and I distinguish between the terms "cryptocurrency" (which I consider a system) and "blockchain" (which I consider a datastructure).
So what was the first blockchain?
I think you're just rebelling against the common definition of a blockchain as a distributed ledger, though I don't understand what's to be gained from that. Seems the community is rather split about this...
I think you're just rebelling against the common definition of a blockchain as a distributed ledger, though I don't understand what's to be gained from that. Seems the community is rather split about this...
> So what was the first blockchain?
Does it matter? What was the first linked-list?
> I think you're just rebelling against
I'm not "rebelling", I'm asserting.
> the common definition of a blockchain as a distributed ledger
That's a common application, not a definition; like blockchains and VCSes are common applications of merkle-trees, but not definition.
> though I don't understand what's to be gained from that
Nothing more that what's to be gained from asserting a linked-list is a list made of elements linking to each other. A blockchain is a chain made of blocks that depend on other blocks up the chain.
Does it matter? What was the first linked-list?
> I think you're just rebelling against
I'm not "rebelling", I'm asserting.
> the common definition of a blockchain as a distributed ledger
That's a common application, not a definition; like blockchains and VCSes are common applications of merkle-trees, but not definition.
> though I don't understand what's to be gained from that
Nothing more that what's to be gained from asserting a linked-list is a list made of elements linking to each other. A blockchain is a chain made of blocks that depend on other blocks up the chain.
>What was the first linked-list?
The initial 1955 implementation within the Information Processing Language.
Come on, the history of computer science isn't exact esoteric knowledge so if you know so much about how blockchain is "supposed" to be defined it should be easy to find where they came from.
And yes, every hash tree is a chain of blocks, nobody's arguing against that. The argument is whether or not blockchain should be defined so vaguely that it means the exact same thing as "hash tree", especially considering that blockchain is already in widespread use under a different definition.
What you're doing is arguing semantics and asserting that mekle tree, hash tree, and blockchain so all mean the exact same thing. That's just going to confuse people even more...
The initial 1955 implementation within the Information Processing Language.
Come on, the history of computer science isn't exact esoteric knowledge so if you know so much about how blockchain is "supposed" to be defined it should be easy to find where they came from.
And yes, every hash tree is a chain of blocks, nobody's arguing against that. The argument is whether or not blockchain should be defined so vaguely that it means the exact same thing as "hash tree", especially considering that blockchain is already in widespread use under a different definition.
What you're doing is arguing semantics and asserting that mekle tree, hash tree, and blockchain so all mean the exact same thing. That's just going to confuse people even more...
The owner of a Bitcoin node could rewrite the history of their chain, too. (After all, it's just a file on a hard disk.)
This would, however, make their node incompatible with everyone else's, in exactly the same way that rewriting the history of a Git repository makes that repository not able to automatically pull from or push to any other non-rewritten repos.
You seem to be thinking of 'git' as a thing which gets stored on GitHub, but it's entirely possible to run a repository with no central copy, based only on consensus. (I've actually done this--in an area without an internet connection, we spent a day coding and passing around copies on flash drives and merging until everyone had the same code. I don't recommend doing this on a regular basis, but there's no technical differences preventing it.)
This would, however, make their node incompatible with everyone else's, in exactly the same way that rewriting the history of a Git repository makes that repository not able to automatically pull from or push to any other non-rewritten repos.
You seem to be thinking of 'git' as a thing which gets stored on GitHub, but it's entirely possible to run a repository with no central copy, based only on consensus. (I've actually done this--in an area without an internet connection, we spent a day coding and passing around copies on flash drives and merging until everyone had the same code. I don't recommend doing this on a regular basis, but there's no technical differences preventing it.)
I'm well aware of how git works, and the consensus mechanism you just pointed out is one of the fundamental differences between git and what's normally referred to as a blockchain.
I think the confusion is people are equating merkle trees with blockchains.
I think the confusion is people are equating merkle trees with blockchains.
Notice that the flow chart does not mention decentralized. The "decentralization" in cryptocurrencies come from whatever mining/proof-of-something mechanism build on top and has nothing to do with blockchain itself.
It mentions decentralization, but in a rather smart-ass way:
"Are the entities with write access having a hard time deciding who should be in control of the data store."
"Are the entities with write access having a hard time deciding who should be in control of the data store."
I do not think I agree. Blockchains are decentralized consensus. If you remove the decentralized consensus algorithm from a block chain, you are left with simply a Merkle tree, a much older concept (used in git for instance where there is no global consensus).
The concept of "You" is sort of interesting. If "You" want to build something that isn't centrally owned by "You" then you should use a blockchain. Satoshi Nakamoto doesn't "own" bitcoin anymore than anyone else does. Same with most other blockchain projects. The problems come when "You" want to have your cake and eat it too.
Some of these miss the mark, e.g. depending on what you're doing with PII storing hashes or symmetric encryptions would work fine. Similarly, updates can be accomplished by writing new entries, which is how Bitcoin works; you read all blocks ever and steadily build up a (local) database of all the unspent transactions, and update those as new blocks come in. Namecoin works similarly but for DNS entries. It's no different than replaying a transaction log in a standard DB (once) to reconstruct the current state.
Where >99% of blockchain proposals fall down, though, is that they don't actually need the "anyone can commit" property. Businesses sure as hell wouldn't allow random strangers to commit to their internal blockchain, so they don't really need one at all. They would only allow some small number of vetted, authenticated external parties to do so, in which case normal account mechanisms work fine.
Where >99% of blockchain proposals fall down, though, is that they don't actually need the "anyone can commit" property. Businesses sure as hell wouldn't allow random strangers to commit to their internal blockchain, so they don't really need one at all. They would only allow some small number of vetted, authenticated external parties to do so, in which case normal account mechanisms work fine.
> Some of these miss the mark, e.g. depending on what you're doing with PII storing hashes or symmetric encryptions would work fine.
granted that "depending on what you're doing" is a big caveat, but:
i feel like there's a difference between encrypting my PII with an ephemeral session key, then sending it in some packets across the internet that are unlikely to be captured, and encrypting my PII with some not-very ephemeral key, then writing it to the disks of thousands or millions of people with a big "this is PII" sign on top of it.
granted that "depending on what you're doing" is a big caveat, but:
i feel like there's a difference between encrypting my PII with an ephemeral session key, then sending it in some packets across the internet that are unlikely to be captured, and encrypting my PII with some not-very ephemeral key, then writing it to the disks of thousands or millions of people with a big "this is PII" sign on top of it.
There wouldn't be a "this is PII" sign on top of it. By its nature you don't know what encrypted data is unless you can decrypt it, and there's many other things that people would be encrypting and putting on the blockchain that aren't PII (probably the vast majority of them wouldn't be). And that's only for the symmetric case anyway; in the hash case it's non-reversible and the majority of the blockchain data is already hashes anyway.
Also, your "ephemeral encrypted packets" are probably logged to disk in multiple three-letter agency databases.
Also, your "ephemeral encrypted packets" are probably logged to disk in multiple three-letter agency databases.
Funny how almost everyone seems to be discussing the diagram and not actually reading the NIST paper first hand.
And then nitpicking over the very definition of what block chain is. But then saying 'bitcoin' 'ethereum' 'git' and 'merkle tree' over and over and over.
Given the title of the thread, and the availability of the actual text, I suggest everyone take a quick read first, then come on back. It is only 50 pages.
https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf
And then nitpicking over the very definition of what block chain is. But then saying 'bitcoin' 'ethereum' 'git' and 'merkle tree' over and over and over.
Given the title of the thread, and the availability of the actual text, I suggest everyone take a quick read first, then come on back. It is only 50 pages.
https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf
It seems to me that a better solution for auditing in situations where you don’t need a distributed ledger is using event sourcing. Blockchains are just a data structure after all. You wouldn’t say “just use a b-tree.” Event sourcing databases solve most of the problems blockchain companies seem to think they have. (And the other problems they have probably won’t be solved with Blockchain anyway.)
I'm surprised somebody hasn't yet made an "audit log as a service". The Reddit comment editing is one place that shows why companies cannot be trusted. But, for enterprise security, you also want a log that cannot be tampered with.
Blockchains are pointless for "enterprise security" because "enterprise" already implies a trusted authority.
Being in an enterprise doesn't mean you have ultimate trust of every single individual with write access. There's a reason many orgs operate under a two-person rule for access to some data, have change controls, and so forth.
That's irrelevant. The point is that the enterprise is a centralized authority so it can trivially codify its business rules into a centralized system; nothing is gained by using a blockchain. Tracking, audits, and tamper resistance is already possible without a blockchain.
Only thing I took issue with is the overbroad statement "because "enterprise" already implies a trusted authority"
It does not necessarily.
It does not necessarily.
No. It necessarily does. The enterprise is the final authority regarding whether or not the system is behaving correctly, not a distributed consensus.
Definition of blockchain is fluid because a blockchain is a combination of many technologies.
I don't have a specific use case in mind but it seems that some subset of these, for example [0], would necessitate, or at least be aptly solved with a blockchain.
[0]: {Shared and Consistent, More than One Contributor, Distributed Control, Tamperproof Log}
[0]: {Shared and Consistent, More than One Contributor, Distributed Control, Tamperproof Log}
sometimes you don't really want a blockchain, you actually want a "Distributed Ledger".
It's similar in that a DLC also requires consensus. It's different in that a DLC need not be a "chain of blocks". i.e. a linked-list as it's core data structure.
The Difference Between Blockchains & Distributed Ledger Technology https://towardsdatascience.com/the-difference-between-blockc...
It's similar in that a DLC also requires consensus. It's different in that a DLC need not be a "chain of blocks". i.e. a linked-list as it's core data structure.
The Difference Between Blockchains & Distributed Ledger Technology https://towardsdatascience.com/the-difference-between-blockc...
The last step should be "You should use git"
Is there a source document that can be linked instead?
PDF page 53 of the document with canonical URI of [1], resolved by the doi.org resolver [2] to a pdf with a NIST URL [3].
[1] doi:10.6028/NIST.IR.8202
[2] https://doi.org/10.6028/NIST.IR.8202
[3] https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf
[1] doi:10.6028/NIST.IR.8202
[2] https://doi.org/10.6028/NIST.IR.8202
[3] https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf
You don't need a blockchain until corruption and lack of transparency forces a need for one in order to re-build trust.
Wouldn't it make sense have some sort of solution before it happens? Like Venezuela.
It is almost as though, prior to blockchain, nobody had conceived the idea of a distributed spreadsheet.
NIST would apparently have you believe that a spreadsheet & email are just as effective.
The idea definitely existed -- it's just that no one had cracked how to keep it correct and consistent until Bitcoin demonstrated how proof-of-work could be used as a practical consensus algorithm.
(Prior implementations of digital currencies always relied on some kind of centralized mechanism to prevent double-spending.)
(Prior implementations of digital currencies always relied on some kind of centralized mechanism to prevent double-spending.)
pdf of the document: https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf
I think the mods should switch the link to this one.
It's linked at the bottom of the imgur link. And scrolling down to page 42 is not exactly quick :-)
NIST nailed it :)
I think blockchain is staring us in the face as a solution to the collapse of trust in institutions. For example, if all votes were stored on a permissioned blockchain, audits would be trivial. If we layered it on top of our existing (bad) election technologies and did a post-election comparison of accuracy, I bet it would be far more accurate.
> I think blockchain is staring us in the face as a solution to the collapse of trust in institutions.
In a world where people genuinely believe Hillary Clinton received millions of votes from illegal immigrants, I don't see how a specific (and complex) technological implementation is going to solve those trust issues.
In a world where people genuinely believe Hillary Clinton received millions of votes from illegal immigrants, I don't see how a specific (and complex) technological implementation is going to solve those trust issues.
Voodoo magic hidden from view would finalize the collapse. Like the great Oz behind the curtain.
Or, stored on paper with a bunch of both independent and representative people counting the paper and ensuring the newspapers reported their riding correctly.
My mom was a returning officer for years and I find it horrifying to watch the US gum up their election systems in the name of progress (or, maybe, in the name of election fraud).
My mom was a returning officer for years and I find it horrifying to watch the US gum up their election systems in the name of progress (or, maybe, in the name of election fraud).
But paper is extremely inefficient? We can do so much better using cryptography and electronics
The inefficiency can be a feature not a bug. How the process seems to work when I last voted was the ballot papers were numbered and they wrote the number next to my name when they gave it to me which prevents then just ticking x on another 1000 ballots to fix the result. However my privacy is protected by the fact that to see which way I voted you'd have to dig through hundreds of bits of paper and compare the number to a hand written list which is slow and hard to do without observers seeing. Make it electronic and you lose that - malware could download the lists in seconds without anyone noticing.
Blockchains are literally the most inefficient way we've ever discovered to store and secure data.
Paper is by far the most distributed, understandable, efficient, and secure mechanism we have discovered for obtaining, securing, and tallying votes by humans. It can be practically tamper-proof given a modest amount of trust and scrutiny.
I don't know why, but Americans of every political leaning seem to think that elections are some incredibly hard brain surgery problem. They aren't.
Paper is by far the most distributed, understandable, efficient, and secure mechanism we have discovered for obtaining, securing, and tallying votes by humans. It can be practically tamper-proof given a modest amount of trust and scrutiny.
I don't know why, but Americans of every political leaning seem to think that elections are some incredibly hard brain surgery problem. They aren't.
Cryptocurrencies are designed to be inefficient. You can perform 'valueless' BC using far less energy than bitcoin. Bitcoin is inherently limiting by design to long tail the mining of coins as the count draws down.
> We can do so much better using cryptography and electronics
no, we can't
> But paper is extremely inefficient?
efficiency is less important than correctness.
no, we can't
> But paper is extremely inefficient?
efficiency is less important than correctness.
I would argue its about integrity from subversion, rather than correctness. You can use electronic records and cryptography to be more correct than paper, in general. Electronic voting is easier to subvert than paper ballots. Thats why voting should be on paper, hand counted. The only group wanting instant results is the media for their reporting. Everyone else is happy to wait for something so important.
Your username is what I use when I want to say 'thank you' to a smart ass. Awesome.
> no, we can't
Well, that settles it!
Well, that settles it!
If you don't care about keeping a voter's vote secret, the problem becomes a lot easier to begin with, and permits a lot of non-blockchain solutions. Like publishing votes in the newspaper.
Who allocates the credentials that each citizen needs to vote?
There's no way around the need for trusted institutions in this case.
There's no way around the need for trusted institutions in this case.
If you can't trust "institutions" there is nothing to vote on.
No. Blockchain isn't a solution to that. Why? A long answer is here (and many other answers) here: https://medium.com/@kaistinchcombe/decentralized-and-trustle... (read part one too).
tl;dr
Blockchain systems do not magically make the data in them accurate or the people entering the data trustworthy, they merely enable you to audit whether it has been tampered with. A person who sprayed pesticides on a mango can still enter onto a blockchain system that the mangoes were organic. A corrupt government can create a blockchain system to count the votes and just allocate an extra million addresses to their cronies. An investment fund whose charter is written in software can still misallocate funds.
...
Before blockchain can even get involved, you need to trust that voter registration is done fairly, that ballots are given only to eligible voters, that the votes are made anonymously rather than bought or intimidated, that the vote displayed by the balloting system is the same as the vote recorded, and that no extra votes are given to the political cronies to cast. Blockchain makes none of these problems easier and many of them harder—but more importantly, solving them in a blockchain context requires a set of awkward workarounds that undermine the core premise. So we know the entries are valid, let’s allow only trusted nonprofits to make entries—and you’re back at the good old “classic” ledger. In fact, if you look at any blockchain solution, inevitably you’ll find an awkward workaround to re-create trusted parties in a trustless world.
tl;dr
Blockchain systems do not magically make the data in them accurate or the people entering the data trustworthy, they merely enable you to audit whether it has been tampered with. A person who sprayed pesticides on a mango can still enter onto a blockchain system that the mangoes were organic. A corrupt government can create a blockchain system to count the votes and just allocate an extra million addresses to their cronies. An investment fund whose charter is written in software can still misallocate funds.
...
Before blockchain can even get involved, you need to trust that voter registration is done fairly, that ballots are given only to eligible voters, that the votes are made anonymously rather than bought or intimidated, that the vote displayed by the balloting system is the same as the vote recorded, and that no extra votes are given to the political cronies to cast. Blockchain makes none of these problems easier and many of them harder—but more importantly, solving them in a blockchain context requires a set of awkward workarounds that undermine the core premise. So we know the entries are valid, let’s allow only trusted nonprofits to make entries—and you’re back at the good old “classic” ledger. In fact, if you look at any blockchain solution, inevitably you’ll find an awkward workaround to re-create trusted parties in a trustless world.
You can audit a small percentage, verify with the original voter it was accurate, and get a statistically significant result about the accuracy.
So you need a trusted party to perform an audit, a trusted party to verify votes with original voters (so, no secret/anonymous voting, so you need a trusted party to handle personal data, a trusted party to destroy that data after elections so that the winner doesn't abuse that data) etc.
So, you mean "solving them in a blockchain context requires a set of awkward workarounds that undermine the core premise... In fact, if you look at any blockchain solution, inevitably you’ll find an awkward workaround to re-create trusted parties in a trustless world."
So what problem exactly does blockchain solve for voting that isn't already solved better and more efficiently now?
So, you mean "solving them in a blockchain context requires a set of awkward workarounds that undermine the core premise... In fact, if you look at any blockchain solution, inevitably you’ll find an awkward workaround to re-create trusted parties in a trustless world."
So what problem exactly does blockchain solve for voting that isn't already solved better and more efficiently now?
If the blockchain containing the votes is distributed to multiple entities, it cannot be tampered without them knowing. Then you can let those entities selectively audit the contents. And then you can follow up with voters, and have them agree or disagree with the accuracy of the record. Compared to messy paper ballots, and electronic voting which is centralized and easy to tamper with, a blockchain solution is much more reliable, tamper-proof, and accurate.
> If the blockchain containing the votes is distributed to multiple entities
So now you have to find multiple trusted entities. That you trust to: provide proper audits and handle sensitive personal data
> And then you can follow up with voters,
Who is this you? Another trusted entity? That you have to trust with: handling personal data, be truthful about following up with voters, protecting voter data. And that voters will give you truthful answers. And that this mysterious you doesn't just select "voters" who will tell anything.
> Compared to messy paper ballots, and electronic voting which is centralized and easy to tamper with, a blockchain solution is much more reliable, tamper-proof, and accurate.
So far you have shown that blockchain solution is:
- messy: voter data is no longer anonymised, you need to find multiple trusted agencies to handle personal data.
- entirely centralised: everything is done through centralised agencies: centralised audit, centralised "you" who will follow up with voters etc.
- extremely easy to tamper with: these "agencies" and this "you" can easily do whatever the hell they want with audits and follow ups
- not tamper-proof: the blockhain itself is tamper proof. However, you propose to add a whole host of tamper-prone processes on top of that.
- not accurate: so, distribution of voting rights is not accurate, entry of votes into the blockchain is not accurate, the resulting audit is not accurate, the voter follow up is not accurate, but just because there's blockhain in the middle of all of this, this entire process somehow magically becomes accurate? How so?
So now you have to find multiple trusted entities. That you trust to: provide proper audits and handle sensitive personal data
> And then you can follow up with voters,
Who is this you? Another trusted entity? That you have to trust with: handling personal data, be truthful about following up with voters, protecting voter data. And that voters will give you truthful answers. And that this mysterious you doesn't just select "voters" who will tell anything.
> Compared to messy paper ballots, and electronic voting which is centralized and easy to tamper with, a blockchain solution is much more reliable, tamper-proof, and accurate.
So far you have shown that blockchain solution is:
- messy: voter data is no longer anonymised, you need to find multiple trusted agencies to handle personal data.
- entirely centralised: everything is done through centralised agencies: centralised audit, centralised "you" who will follow up with voters etc.
- extremely easy to tamper with: these "agencies" and this "you" can easily do whatever the hell they want with audits and follow ups
- not tamper-proof: the blockhain itself is tamper proof. However, you propose to add a whole host of tamper-prone processes on top of that.
- not accurate: so, distribution of voting rights is not accurate, entry of votes into the blockchain is not accurate, the resulting audit is not accurate, the voter follow up is not accurate, but just because there's blockhain in the middle of all of this, this entire process somehow magically becomes accurate? How so?
I don't think you can fix the problem of lack of trust with building systems that don't require trust. The whole point of trust is to enable tremendous efficiency gains over trustless systems.