Blog > Bitcoin & Blockchain Tech

Private blockchains are a matter of economic forces

By Craig Wright | 18 Dec 2018 | Bitcoin & Blockchain Tech

The issue of “private blockchains” comes to a purely economic outcome. The issue of public vs private is, and has always been one of setting the correct controls. An encrypted session is more secure than one that is merely “hidden” or “air-gapped.”


To securely encrypt a session, we have techniques that have already been developed. The use of symmetric-key encryption and one-time pads provide the ability for an organisation to set access policies and controls that maintain confidentiality and allow the data to be maintained privately, whether inside a firewall or on the web.

One use of a “private blockchain” is the means to keep proof and attestation of a transaction. One thing many do not understand is that such a thing is rather simple in Bitcoin.

OP_HASH256 5b093a8f05ed915e63f4799ebe143c1776279048ca2fd470512d399bcea259ae OP_EQUAL

In this script, we have the hash of the abstract in the Bitcoin white paper.


The typical means of explaining the scenario is shown below:


It is also said to be insecure, as a “miner could take the output.” Well, the other way to think about it is that it is a way to pay miners for a service. Bitcoin is a commodity ledger. It is for use in storing data and for transactions.

Fees should be low.


The fees on the Bitcoin SV network to send and save a hash puzzle can be in the order of $0.02 today, as long as you do not care that the puzzle is saved that minute (for example, if 3 blocks or 30 mins are OK).

The Bitcoin wiki says the following about hash puzzles:

they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.

The (false) assumption here is that it matters. A business can use the blockchain to save hash values and data.

It can do something as simple as a Data Push to save a name (in the script or in OP_Return) and then save the hash as a part of an on-chain record.

With the ability to have a transaction sent to multiple outputs, we can also use the process to link to accounts. For example, we can have Input 1 linked to Output 1 in a transaction, paying the same business wanting to store a record.

We can use a system that links the record values and allows these to be constructed into a ledger of values that we seek to prove (as shown in the link).

Now, we have another input for a small value (in fact, we could have a smaller transaction with only this input and output value as a hash puzzle, but this is more difficult to compile into a complete ledger of many records), and the second input links to the output as a hash puzzle this time.

So, we now have a file identifier (such as the description or file name) and the record hash. This is a forensic proof of a file’s existence. Signed and encoded, it can be a record of a contract between parties that can stand on its own in court.

It can act as a proof of the first existence of a file. A media company can demonstrate the existence of values. It is also not using OP_Return, it is the hash puzzle itself.

Bitcoin also supports SHA256d. This is a hash of the hash. It can be used to allow other uses of puzzles. We can (in script or otherwise) create a hash puzzle that uses the hash of the file hash and not the file. In this, we have created a means to allow evidence and proof without ever leaking the file.

Some of the many uses of a hash include:

  • saving the hash of a log file to ensure that it has not been tampered with;
  • software-version hashes — so clients can be assured that they are downloading a valid version of the software (Microsoft host hashes, but all websites are vulnerable to hacking, the Bitcoin blockchain is not.);
  • contract hashes.

In saving the puzzle as a Hash < Hash (file) > > variation, we now need to provide the 256-bit hash and not the file itself as a pre-image. If the security of RipeMD160 is good enough, then we can even save more space.

Cisco use an IOS verification as a means to validate software. The validation could be made far more secure using Bitcoin. Simple tools to check functions for customers can be created today. The addresses in Bitcoin could be used as a means to mark the source (in the example, Cisco) and validate the image or software.


These are all uses that can be easily implemented today.

This is why we are scaling Bitcoin to allow millions of transactions a second. Bitcoin has value as cash, when it is money, and to be money, it needs to be a commodity. The commodity value of Bitcoin comes through use.

So, why is the puzzle secure…

Very simply, the output goes to the miners.

We could even have a very-low-fee or no-fee transaction that miners would accept, knowing that they could have a payment later. If we need the record for 7 years, set up an nLocktime value for a spend in 7 years, allowing the transaction to be spent and to be prunable. Alternatively, if it does not matter that the transaction is in the UTXO set, spend it now. The puzzle is then available to be grabbed by miners.

Let the miners have it. It is the fee for storing the data and adding value.

So, the real question is…

If you can make a public blockchain more secure, more easily accessible, and also less expensive (no servers to run, no staff to maintain it)…

When the public system is faster.

When it is cheaper and more secure.

When it is run without the need to hire your own staff to maintain it.

Why would you even start thinking about a private Internet or a private blockchain…?

That is the real puzzle.