I've worked with blockchain and dozens of other means of encrypting and authenticating information and transactions. With all due respect to Marc Andreessen, who is quite adept at programming in communication environments while maintaining information integrity, he is nevertheless not an expert on information and transaction security.
For example, "Andreessen is a proponent of Bitcoin and cryptocurrency[ and has described the technology as "innovative and radical"."
I do not agree.
Wikipedia states the issue clearly: "Once recorded, the data in any given block cannot be altered retroactively without alteration of all subsequent blocks, which requires consensus of the network majority. Although blockchain records are not unalterable, blockchains may be considered secure by design and exemplify a distributed computing system with high Byzantine fault tolerance. Decentralized consensus has therefore been claimed with a blockchain."
The key here is the term "resistant." Blockchain requires a lot of computing power to verify each transaction. But that doesn't make it hack-proof, and the computing power required is a serious if not severe impediment to its use in commercial endeavors, particularly when infinitely less power-hungry means of providing both information and transaction security are available. In fact, there are a number of hacks out there right now.
The most widely known such method uses TLS (transport layer security) by employing third-party certificate authorities whose number and credentials are tightly controlled. You experience this every time you visit a website beginning with https, including hhplace and your bank. Although some people claim "TLS can be hacked," the reality is that it securely handles billions of dollars of transactions each day. See the comment here for TLS 1.2 details. While TLS provides browser to server security, however, you're trusting your bank, Amazon, and others to perform transactions properly. Nothing beats a printed statement and meticulous check/transaction records. I stopped using credit cards altogether because there's no third-party verification of the bank's records except my own records. I use a debt card and manually transfer funds as required. But I haven't trusted any financial institution with any line of credit since 2011, when my credit card account at my now former bank jumped from a balance of $0 to more than $3,500 in three days and my bank refused to acknowledge the security breach, much less return my illegally obtained i.e. stolen funds. Throughout the lawsuit, the bank routinely sent bad credit information to the credit bureaus. I won the lawsuit in 2013 and they returned the funds, but they refused to lift a finger to help me repair my credit. That took another four years.
So you see, in addition to my background in information/computer/networking security, I have just a *bit* of a personal perspective.
Back to transactional security...
Providing security for transactions, financial or otherwise, requires both parties have access to a second and secure avenue of communication, and for really important transactions, a third means, as well. It also requires the ability to record and store all steps of the transaction with a trusted third party, one beyond influence by either party.
Consider the following hypothetical:
You're buying a used car. Eight months ago you signed up with Consortium IV, a fictional third-party transaction security group comprised of 56 members. Your bank also uses Consortium IV, but the seller and his bank use e-Verify IX, another fictional third-party transaction security group.
After all the legal paperwork is done, you need to pay for the car. The seller posts the car for sale on Amazon but with a private buyer, you, as identified by your Amazon username. You log in, verify the VIN matches the one on the car and the paperwork, as well as the negotiated sales price. You hit buy, then confirm.
Because the price of $15,000 is more than the maximum $2,000 limit you set months ago, the system kicks it over to Consortium IV for authentication/verification/validation. You receive an e-mail, click the link, and type in the 12-digit alphanumeric code that was sent in a second e-mail.
But you're REALLY careful, so you signed up for additional authentication on any purchases over $5,000... You receive a phone call and the robocaller describes the item and the price, then asks you to press 1 to confirm the transaction and 9 to cancel it. You press 1 and the transaction is primed to go.
Meanwhile, the seller goes through the same process through his e-Verify IX, and when he completes his phone call, his side of the transaction is primed, as well.
Since both e-Verify IX and Consortium IV are members of a larger, world-wide group of such services, they "trust" each other, but no further than they can spit. Since both sides have provided the necessary information and multiple confirmations of the order, it goes through. Both companies record the transaction, to which both parties have access and to both companies, but the transaction is encrypted and also stored with all companies party to this group for "distributed safe-keeping." Only the two parties and their respective companies can unlock the encrypted copy, which is kept on everyone's servers, along with various transaction verification codes.
This sounds like a long process, but both users completed it in less than 60 seconds and the computers involved completed it in a microsecond, using less than one-millionth the electrical power of blockchain, which is WHY blockchain will never become any sort of widespread hit in the corporate world.
It's the same concept -- decentralized consensus -- with the same if not greater security, but without all the hype.