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.
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.
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.
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.
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”.
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.
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.)
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
> 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?
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.
> 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).
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...
> 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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
"Smart contracts" have nothing to do with normal contracts. "Distributed script" is a much better name. Basically deterministic scripts you run on multiple computers.
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".
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.
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.
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.
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).
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.
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.
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).
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.
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.
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.
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.
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.
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?
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?
> 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.
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.
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.
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.)
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.
> 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).
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.
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.
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.
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.
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?
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.
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.
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.)
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.
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
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.
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.
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}
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.
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.
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.
> 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.
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.
176 comments
[ 2.9 ms ] story [ 223 ms ] threadThis is why the phrase Bitcoin not Blockchain has been floating around.
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...
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”.
Proof-of-work is code that passes tests and consensus is "Linus said 'ok'".
(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.)
How about ZFS filesystem?
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?
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.
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.
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.
Why would I need to do such a thing? What, in practical terms, does it get me?
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.
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.
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.
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.
https://www.jsemeraro.com/wp-content/uploads/2017/12/Blockch...
[1] http://doyouneedablockchain.com/ [2] https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf
"Are the entities with write access having a hard time deciding who should be in control of the data store."
Yes.
Decentralized just means someone else can own it too.
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.
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.
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.
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).
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...
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.
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...
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 think the confusion is people are equating merkle trees with blockchains.
That said, I've also seen a bunch of "X, but with blockchain! Can we have money now?" startups looking for funding.
Also, dig your username, lol.
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.
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" aren't necessarily analagous to actual contracts. They can also be programmed with configurability.
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.
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?
[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
There's no way around the need for trusted institutions in this case.
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).
no, we can't
> But paper is extremely inefficient?
efficiency is less important than correctness.
Well, that settles it!
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.
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.
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 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?
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.
https://csrc.nist.gov/publications/detail/nistir/8202/final
(Prior implementations of digital currencies always relied on some kind of centralized mechanism to prevent double-spending.)
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.
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).
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.
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.
[0]: http://www.arrl.org/logbook-of-the-world
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.
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.)
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 does not necessarily.
[0]: {Shared and Consistent, More than One Contributor, Distributed Control, Tamperproof Log}
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 while we're at it another for serverless architectures?
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...
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.
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.
Also, your "ephemeral encrypted packets" are probably logged to disk in multiple three-letter agency databases.