I've saved a couple of potential clients months of development time and probably tens of thousand of dollars just by convincing them not to use a blockchain.
So we have this great world changing idea which will transform, reinvent and disrupt ... and it uses a blockchain to keep track of ....
Why the blockchain ?
Because ... distributed ... anonymous ...
But you have user accounts on your servers.. your project is centralized by design.
Why not save yourself the trouble and use a mysql database ?
People like being involved in things which sound cool and they try to bend reality so that they can find a use for a cool sounding technology.
Most 'blockchain' proposals I've seen, particularly in civic technology, would be satisfied with a public git repository containing a .csv file, and also generally ignore the social issues around data ownership and quality.
This is a tremendous issue in civic tech. We have spoken with many people in the space (being in govtech, naturally run into each other) and the level of "because it sounds cool" is above the Silicon Valley mean.
There are so many problems in government. A vast majority are not sexy, but if you care about impact the roll up your sleeves.
Programmers, hackers, mathematician, often tend to fall into this trap. It was pretty well illustrated by Swift, in Gulliver's travel. When the protagonist arrive in Laputa, the city of mathematician, they take his measurements to make him a suit. But they only take one measure! Because we can compute all other measures through fancy equations... and that's how everyone in Laputa ends up with suits that are not well-adjusted.
Opportunity cost is a huge problem but it seems like an even more basic issue is just the suitability for the underlying problem. The hype around blockchains lead a lot of people to suggest them as alternatives for relational databases or digital signatures, and even if a high-quality, tested, easy to use, well-secured system magically appeared it'd still be an inferior choice for any problem which can be solved with those tools: transactions take orders of magnitude longer to clear and the capacity limit is orders of magnitude smaller, customer service and fraud are hard problems rather than routine operations, etc.
Even if the opportunity cost was zero, the choice wouldn't make sense unless you had a problem which cannot be solved well with mature tools.
They're definitely related problems — I just find it fascinating how often enthusiasm leads people to completely downplay this category of problem, often while spending non-trivial amounts of energy trying to deal with them
After much exposure in big data processing and running an Ethereum meetup since it wasn't yet cool, I think the main promise of this technology is more conceptual than strictly determined by a dominant protocol. These are:
- Fully user owned identities
- Eradicating information asymmetry in mutually beneficial ways
- Transparent update rules, i.e. an evolving but never deprecated API
Thus different roads will lead to those economic gains. Essentially you take mongodb, encapsulate any write access into UDFs (=smart contracts) with permission to execute based on a public/private key, a second set of keyholders able to read and validate the log and et voila, all promises of blockchain tech fulfilled.
The identity part is what's really going to surprise people. We now have the tools to build IDs that are more reliable and resilient than state-issued IDs, but can be used in any application without permission.
Can you expand on that? As I understand it blockchains allow you to use a private key as your master identity, but don't inherently provide tools for connecting that key to a real-world identity.
Are you envisioning a system like Keybase, but completely distributed?
Blockchains are decentralized cloud computers that enforce rules on a historical record. Bitcoin's rules are about managing a currency: how coins are issued, how to transfer them, etc. You can build a blockchain that enforces any rules, though, and Ethereum lets you define new rules without having to spin up your own blockchain.
Your identity will no longer be a key. It will be a pointer to a program and its associated storage on a blockchain. To identify yourself, give someone a proof that you control that identity. To add a new key to the identity, use the rules you put in place to add new keys. To change the rules that control the identity, use the rules you put in place to change the rules. You can build any rules for an identity management process into a program that runs on a blockchain. Through trial and error, we will discover the most resilient patterns with the least trust required.
Any recovery method can be built. Maybe your bank's key can authorize a new key for you. Maybe your government can. Maybe three out of five friends you picked can.
It's better to start from the other side of the problem: how do you want to recover your identity?
We could also say that blockchains can be useful in principle when people are afraid of retroactive modification of history (for example because they get hacked, or because of governmental pressure to falsify their records). This is sort of an instance of this article's mutually-untrusting writers issue, but it's an interesting one because the writers are saying that they don't want to be trusted.
I think this is the case now for software distributors and certificate authorities, among others (I gave a talk related to this at CCC); they are saying "it's bad for us and you if you just believe whatever we say, without at least a way to know if a larger audience has heard it and whether we're denying what we said before".
So we can also say that blockchains (or perhaps another kind of distributed consensus mechanism; clearly Ben Laurie and others are claiming that blockchains are too heavyweight some or all of the time) can be useful when people are afraid that they're going to be made to emit writes that they didn't want to, or to deny writes that they previously emitted.
For a CA they could structure their data as a log where each entry (new cert) contains the checksum of the previous entry. That way it's not possible to change the chain without unwinding it. Each person getting a new signed cert now has the new HEAD of the log and unwinding means revoking all these certificates.
Now if you put multiple CAs in the game it start to become interesting to use a distributed ledger like the blockchain. If all the signed certs are distributed as part of the ledger it becomes easier to track who issues certs for what domain. Something we cannot do with the current SSL CA system.
Sorry I didn't mention it explicitly -- I was trying to draw an analogy to show why blockchain-esque mechanisms are relevant here, and I thought readers would already be aware of this system.
As much as I am fascinated by the Blockchain, Bitcoin and all related matters the Blockchain shows how random projects are created around some tech just for the sake to do something with this new tech.
People fell in love with the Blockchain and desperately try to find a use case. Bitcoin was and I still think is a killer use case for the Blockchain. But in the last 24 months I met so many founders of blockchainy startups—exceptional smart guys, after 15 minutes of listening to them I felt so stupid like I missed the past five years of tech. But once you ask them what is the use case of their new shiny blockchainy tech they don't give a proper answer. Instead they shotgun more words with even higher confidence.
Again, absolutely nothing against the Blockchain and I am highly impressed by Ethereum. And I understand that people often need to play around with new tech some while to find proper use cases. But especially with the Blockchain I feel that people do not find many more killer use cases beyond currency.
Question - does the incentive (or lack thereof) of the miners to create the blocks also need to be considered? There's an obvious incentive with bitcoin - you make money. What would be the incentive for me to create a block of (using one of this article's examples) entries on a shared calendar? It seems like part of the reason that this works for bitcoin is precisely because the "thing" being recorded (money) is something I also want as a miner. Why would I want to put in the computational work to create a block of calendar entries?
Good question. The way this works right now is you can submit a non-payment tx into the bitcoin network and attach tx fees to it just like you would with a normal payment tx. Miner collects the fees when they mine the block with your tx in it.
So from the miner's perspective the incentive is there. There's the "wasted bandwidth" angle there as well but that's a different story...
I get how it works with bitcoin - that's why I was saying the incentive is obvious there. The miner makes money.
I was asking what the incentive would be to go through the computational effort of creating a block in a system that doesn't involve money. The author gave the example of using blockchain to maintain a shared calendar. What incentive would I have to go through all the computational effort to create a block of calendar entries?
I understood you correctly you're asking what is miner's incentive to process a tx if the tx does not involve transfer of funds.
There's nothing preventing the same tx fee system bitcoin is using from being implemented even if the blockchain itself is not used to transfer value. So now it is a can of worms, no doubt, as the system would have to have a way of attaching the fee to a "real world" value - along the lines of how Ether/Gas relationship works in Ethereum, but it can be done.
Another thing to keep in mind is blockchains the author is talking about in the article aren't necessarily public - with a private blockchain the nodes are paid for by the organization using it in some way shape or form.
Thanks for the reply. I'll check out Ethereum; I'm not at all familiar with it. Seems like you'd then be losing some of the - for lack of a better word - purity of the system. If I understand correctly, part of the point with bitcoin is that there really are no central entities, gatekeepers, etc. It's completely decentralized - of the people, for the people, by the people. But if you need a way to "pay" miners outside of what the system deals in, seems like you'd be bringing in some sort of central entity. Not that that's a bad thing, I just understood it to be part of what bitcoin was avoiding. And maybe it will make more sense when I learn a bit more. Thanks again.
That's why those systems shouldn't use mining. They should use something like PBFT. And the incentive to run a node is that you can catch other people cheating.
If you also sold a robot that could put the toast in the toaster, I'd love a toaster with a wireless connection. I could start breakfast from my smartwatch while I'm still in bed upstairs and only go downstairs when it's ready.
This is almost always the wrong way to solve the problem. Trying to automate a human-friendly interface is far more trouble than it's worth, when you can easily use a machine-friendly interface to begin with.
For example, dishwashers aren't robots which stand in front of a sink, squeezing bottles of detergent on to a cloth and rubbing it over a stack of dishes. Instead, they're self-contained beige boxes with a well-defined input/output mechanism (racks to hold the dishes; standard plug for electricity; standard plumbing connections).
It's like screen-scraping your own application. Or writing a CLI's main loop with `expect`. Or when sci-fi films show robots typing on computer keyboards.
Let's take your example. Unless you're living in a backwards universe I'll assume that you want to put bread in the toaster. There are existing solutions to this, e.g. many hotels have toasters with a conveyor belt; rather than having to line anything up, there's a large catchment area to plonk the bread on to. A harder problem would be separating the slices of the loaf; this can be entirely avoided if the user "loads" a whole loaf at once, like a cartridge. E.g. by inserting paddles between the slices, they won't be exposed enough to go bad, but are easily separated as needed.
With everything roughly lined up there's not really anything to control other than turning it on. Plugs with timers are easy to get hold of (I use them for switching on lights in the evening). You could use something smarter like a clapper. Even if you use a "smart plug", there's no need for the toaster itself to be any different.
Yes, traditional future-gazing has always had a problem failing to de-antropomorphise, a failure of imagination IMO.
One of Asimov's stories has a robot piloting a spaceship as a literal humanoid robot in a seat. The ship won't go because the robot is pushing down on the control bar too hard or something, something the designers hadn't factored in. Not to overly diss one of the giants of the genre, but even as a kid I found this setup kind of silly.
As I recall -- and I don't have the book in front of me -- the Robot's presence was explained as being a reasonable proxy for having a person present. The in-story thinking was that if the robot survived with no positronic damage, a person would likely survive too as the positronic and biological brains were of equivalent complexity and sensitivity.
Well, yes. Like I said in a reply to a sibling comment, I really want breakfast. I don't care how it gets made as long as I can decide whether it'll be cereal or waffles or bagels or bacon from upstairs, and it's ready as soon as I get downstairs.
In my entrepreneurial dreams (apparently shared by one of the sibling commenters here), I'd actually imagined a fully-automated kitchen. Stick a grocery bag on a shelf (extra points if it integrates with Instacart etc, so that someone else can stick a grocery bag on a shelf), and a robot arm unloads it, reads all the UPC bar codes, and stocks it in a refrigerator. This refrigerator isn't a standard issue one, with a door and shelves, but something with individual bins for items. That way, a robot arm would know exactly what product was in which bin, it could retrieve it, open the package, and measure out whatever quantity is needed for the recipe. Then it goes to the appropriate heating chamber for cooking - it may not even have pots/pans/toasters, just heating elements and containers. Food comes out on clean plates, dirty dishes go in, and the cycle repeats. My interface to it is a smartphone or smartwatch app where I can select a favorite recipe and have it made.
I figured this is beyond my hardware capacity to build (unless I exited in some other startup first and had unlimited time to tinker), but if someone else wants to make a go at it...there's the product request. ;-)
The problem with this approach is that you would need a brand new kitchen along with everything in it. Plus, after spending vast amounts of money doing so, you might find that the new kitchen, appliances, utensils etc. are no longer suitable for use by humans for those times you want to do a bit of old fashioned manual cooking (or are forced into doing so during system upgrades etc.).
What I'd like to see is a general purpose domestic robot which could learn to use all your existing things. It could start by learning to vacuum using your existing vacuum cleaner (a lot cheaper, and a lot better at cleaning, than the dedicated vacuuming robots you get now), and over time upgrade itself to do additional things, like emptying the vacuum cleaner, dusting, washing dishes and so on.
Would love to develop something like that, but coming from the software side I'd probably have to work with some pre-existing hardware, e.g. something from Willow Garage.
I think there is a case for a domestic robot. It doesn't need to have a human form. But it would clean the dishes, clean the house, cook your meals, receive parcels when you are out, iron clothes, repaint the flat while you are on holidays, yell at kids when they trespass on your lawn, change bulbs, walk the dog, and chase with a broom anyone who is trying to dump junk mail in your mail box!
I wasn't being sarcastic...I actually would love a toaster that could make breakfast while I was still in bed upstairs.
Although one key point that I'm sure IoT entrepreneurs will forget: I want breakfast, not a toaster with an Internet connection. If it doesn't make me breakfast, I'm not interested.
I really don't want a connected kitchen because I know someone will hack the damn thing to disable the eject function of the toast and I will have to deal with something worse than not being able to turn off an alarm. I can even see the virus's name "Toaster of Flame".
I want a "black box" kitchen load the groceries in one side get food on clean plates on the other side. Then, put dishes in a pile that goes in for next time. and it probably needs to be less than $1 per meal since I'm cheap.
It'll need to be updated and patched at least once a day, which will result in reliable breakfast delays. I mean, that's how me TV and Playstation work; if I want to use them, I have to wait 30 minutes for an update to happen.
The Internet of Things's main barrier seems to be cost. Do I want a toaster with a wireless connection? Sure. Am I going to pay more than ~$30 for that toaster? No. Do I want that toaster phoning home to Google about my toast-making habits? No way in hell.
What most IoT business fail to understand is that the whole point of IoT is to let devices talk to each other, this scenario will never happen if everyone has their own walled garden with incompatible products. What most people want is something like going home and opening your IoT lock will power on your IoT lightbulbs when it's dark. I don't need a fancy GUI to control my lightbulbs. I can already do that with a regular light switch.
This is a great article, but I disagree on one point. Blockchains aren't overhyped. Sure, people promote them for strange use cases sometimes. But I'm pretty confident that we'll look back on blockchains as underhyped. Blockchains will reshape entire industries, and some of the largest corporations on the planet will find themselves competing on a level playing field with a few kids in a garage.
Has disintermediation ever been overhyped? Currency disintermediated trusted community members who you knew would do you a favor in return. The printing press disintermediated the Catholic Church, one of the most powerful entities of its day. The internet disintermediated... lots of people. Blockchains disintermediate everyone else.
Blockchains are a horrible solution for the problem domain. Oh, you need decentralized consensus? Let's limit throughput to n / w / 0.5n. Hence bitcoin's multi-hour resolution times which are increasing geometrically. Sorry, I don't see it.
I hope your right, but I'm concerned that blockchains still rely on the core developers. Very few people really understand the protocols, and even they don't audit their nodes' code. You don't have to trust a central database, but you DO need to trust the code that runs the distributed database.
This need for trust demands politics, and that's why we have Bitcoin's crisis de jur.
A solution for this problem will be general libraries which you can build blockchains with. But I agree on that maintaining a blockchain needs governance as well.
We'll find out, won't we? In the meantime, my audience is those who are willing to suspend disbelief and start learning about the technology to see if I'm right.
I recently talk with a stock exchange team who wanted to start a blockchain project, so we asked naively: approximately, how many nodes are part of the system? Only one was their answer.
I'd also point out that there are a couple of projects out there aiming to add "blockchainish" behavior to a "regular" database without sacrificing the functionality we're all used to (try finding a tx with a specific value of the op_return on the bitcoin blockchain for example).
Any chance you can provide names or links to those projects? I've been expecting this, have even heard rumor IBM is building Paxos into DB2, but would love to see real projects.
Yeah, decentralized social. Who is doing this? What are the obvious problems? Spam? Other nefarious content? Who is going to delete all that crap...? So many questions...
seems like an encryption escrow service could meet 90% of use cases for a lot less costs. I digitally sign and timestamp then encrypt data upload it to web service and make it available to others.
So we have this great world changing idea which will transform, reinvent and disrupt ... and it uses a blockchain to keep track of ....
Why the blockchain ? Because ... distributed ... anonymous ...
But you have user accounts on your servers.. your project is centralized by design. Why not save yourself the trouble and use a mysql database ?
People like being involved in things which sound cool and they try to bend reality so that they can find a use for a cool sounding technology.