Blockchain study finds zero success rate and vendors don't call back

> We need an easier way to automatically distribute payments based on certain rules to open source developers.

Has almost nothing to do with Blockchain. This is just called "micropayments"- and blockchains suck for them. At best, you end up doing little payments outside the blockchain, and then settling them occasionally on the blockchain.

You may notice this same approach works quite well for "do little payments outside the existing financial system, and settle them periodically."

> Code and modules need to be multi-signed and certificates should be inexpensive to get and easy to validate.

Code signing is unrelated to blockchain.

Certificates are already easy to get. GPG is free. Certificates signed by a CA sometimes cost money- code signing certs, at least in theory (in practice? hah, not really), cost because they need to be able to verify your actual identity.

Certificates being easy to validate... this is a PKI problem. Blockchain provides nothing of value here.

You might be able to do something like what Keybase does- having some centralized "identity" and making changes to same auditable- with a degenerate Merkle tree. You know what else does this? A HSM from like 2006, which, in each audit log entry, includes the hash of the previous one, to establish exactly this property- changes and edits can be detected.

> One of our dependencies could become a malicious package in the same way we saw it with event-stream. But instead of giving full maintenance or full publishing rights to new collaborators, the original developer would give new maintainers or a CI system only signing rights. So they would sign their releases and after a careful review the original author would countersign stating that he checked and approves these changes.

Not only has this got nothing to do with Blockchain, the proposal here is just "a new maintainer needs to ask the old maintainer for permission to publish for a while", which is quite silly- if the old maintainer is tired of bothering with the maintenance bit, the LAST thing they want to do is careful code audits.

> Later, if our fictional project received an in-app payment there could be some logic within the runtime environment that based on the impact or contribution of this open source module to our project would automatically distribute a couple of cents of each payment to the author who can be determined based on the certificate.

Well, no, the author can't be determined based on the certificate on your binary. The person (or persons) who signed it can be. Asking every contributor to sign every release in perpetuity is silly, of course. Incentivize them to do it with a cut of the profits? Great, now they just rubber stamp everything.

Now, if you mean the maintainer of the module, sure. You know what else works quite nicely for this? Just having a payment address in your Git repo in some file with a well-known name. There's no point in the certificate, here!

"Aha- a payment address! PayPal won't work, not much else that exists will, either. For those smaller payments, only a Blockchain-based approach would work." Well, that's true- for now. Similarly, "free, rapid person-to-person transfers" was largely just Venmo for a while. Then the sleeping giants that are the financial industry woke up, threw some pocket change at the problem, and created Zelle / Early Warning, which does the exact same thing.

There isn't a good way to do microtransactions today because there isn't that much demand for microtransactions. If there is, it'll pop up quite quickly.

This entire article is just... clown shoes. The parts that might work aren't novel and don't require anything besides a degenerate Merkle tree, and the parts that are novel or require a Real Blockchain(TM) are useless.

Why is this? Because the article itself was written backwards! The author started out with "I like and know Blockchain. (more cynically, 'I benefit when $ETH goes up'.) Here is a problem. How can we apply Blockchain to it, and make the world more secure (and more cynically, 'make me richer and my skills more in demand')?"

In so far as this article attempts to solve any problem, the problem is "Blockchain isn't used as much as I'd like it to be."

Nah, git retains its commit history, so it's actually closer to a blockchain approach than what I'm describing. Plus, with git, the syncs [with git-push and git-fetch] are async, such that a "cluster" of git-using nodes is never "in consensus" as a whole.

Picture instead, something more like a document synced in realtime using Operational Transformations (via SubEthaEdit, Etherpad, Google Docs, etc.), purely peer-to-peer (so specifically like SubEthaEdit) and without any peer expected to retain any history of the OT sync process itself (so you can't "wind back" the document like you can on Google Docs.) Except, now, also picture that if you try to broadcast any OT events other than an insert OT, the other nodes will just ignore those OT events, causing your document to fall out of sync with everyone else's. So the document itself can only ever grow, and nothing can be redacted or changed once it has been inserted.

So now you've got this single document that everyone can "write" to (but never change anything that's already been "written.") Now just make everyone always put their new writes at the end, so they're not breaking up anyone else's message. Now you've got a durable, distributed message bus.

(If you've ever used a wiki Talk page—or the old original C2 wiki where every page was a Talk page—the rule there for posting a new "chat message" to a page, is that you should append them onto the end of the existing "chat messages" of everyone else. If you put it anywhere else, another editor will revert your edit. This rule by itself is enough to allow for a functional chat system/forum with a complete logical "conversation" history! Same idea here—just that it's the database-node software that's automatically "reverting" bad edits. In all other senses, it's just a regular distributed file.)

They make sense when the primary vulnerability isn't the person doing the recording but the possibility that the data might be tampered with or misrepresented before it gets to the consumer.

Consider, for example, the problem of restaurant reviews. We know that one person's review of a restaurant isn't going to be 100% accurate, because it's subjective. Socially, we've figured out ways of getting around that, like soliciting reviews from many different people, looking for reviews from people with tastes like ours, looking at the specific details they post, etc. They're also not generally incentivized to lie, because they've already eaten there and their review isn't likely to influence their service in the future.

All this falls apart if, say, the platform responsible for collecting these reviews has a business model where they are incentivized to bury negative reviews and manipulate scores upwards, but only for restaurants that have given them money. It'd be a much more trustworthy system if the reviewers could receive currency directly for the information they provide, provided by the potential customers who benefit directly from that information. Alas, basically nothing on the web works that way.

If only current blockchain implementations had acceptable performance to handle terabytes of data on mobile phones...

Sure, so each party in the supply chain registers their private key with a PKI by going to the PKI's website (e.g. GoDaddy) and sticking their USB fob into their computer. The PKI associates the private key with an identity, and allows private keys to be voided and replaced if they get lost or whatever.

Then as each head of lettuce is picked, it goes into a crate that's securely sealed and then signed with the farmer's private key in a way that originates that crate of produce on the ledger. When the farmer sells their produce to the middleman that transaction is also recorded, and so on, all the way to the end consumer who buys the produce in a grocery store or in a restaurant. (And consumers would just use their phones or credit cards for this, rather than using any sort of external fob.)

Then when the first person gets sick they report their illness as per usual. Nothing happens at this stage, because there's no way to narrow down what made the person sick. By by the time the second person gets sick (with E. coli of the same genetic signature), now you can find the furthest place back in the supply chain where both people's purchases intercept. So you can now see if e.g. the contamination came from a single farm, and if so only recall lettuce from that farm rather than all romaine lettuce produced worldwide.

Because the database is open anyone can download a copy, and there is no risk of a single entity imposing a 30% Apple tax on each head of lettuce or whatever. And each person benefits from participating, because it's a pareto improvement in terms of their profitability. (Now their products only get recalled when they are at fault, rather than their products getting recalled when anyone is at fault.)

Suppliers at every step of the chain enter data into a blockchain. Every organization runs a node. Therefore they can’t lie later and tamper with records when something goes wrong. Investigators can trace provenance easier. That’s it really. An append-only cryptographically secure database would do that same thing, but that’s just another name for a blockchain, which is a rebranding of a specific type of distributed database that has enhanced trust properties.