Positive and negative proofs in blockchain audits

As the old logical fallacy goes - you can't prove a negative, and absence of evidence is not evidence of absence. While for a long time this might've been true in various financial audits - you could only prove that some invoice existed, not that there were no invoices you missed - thanks to the blockchain technology things might change in the near future.

Positive vs negative proof

In general, we use positive proofs a lot in our everyday lives and in business. To create a positive proof, we only need to show that something exist - show an invoice of a transaction, a recording of a conversation, etc. Even in the Bitcoin Genesis Block Satoshi used a positive proof - a quote from The Times to prove that the Block could not have been created before 2009-01-03.

Negative proofs, while applicable in mathematics and some other cases, are often used in logical fallacies. If your goal is to prove for example, that there are no mice in the attic. You can easily disprove that theory with a positive proof if you find a single mouse there. However, searching the attic and not finding anything only proved that you have no evidence there are mice there, not that you had a proof there were no mice there. A subtle, but important difference.

Proofs on the blockchain

As in most cases, it is easy to create a positive proof on a blockchain. Point to a transaction paying for a particular invoice, if it is included in a block with 6+ confirmations, it's all you need.

Now, what if instead we are being audited and we have to produce an exhaustive list of all transactions we sent and received? It is possible, but we would have to do some preparations beforehand.

Cryptographic audit on the blockchain

First of all, we need to establish some way of uniquely declaring some data, saying "I am X and this is a message coming from me: ...". If we had something like government-issued unique digital signatures, that would be good enough. Alternatively, we could rely on some less infallible methods - notarized letters, tweets from some official handles, posting information on our website for everyone to see, perhaps sending the information to our competitors (if we try to lie about something, they would benefit from calling us out). Once we can prove that we as the person or a corporation were the authors of any given message, we can use cryptographic digests to prove any piece of data is coming from us, and coupled with embedding messages into the Bitcoin blockchain for timestamping (directly, or through Factom for example), we can create tight time bounds on when the data was created.

Why do we need all of this? Well, depending on how we use the blockchain, we will need to be able to create timestamped commits / anchors that we have to prove came from us.

If we only use one address on a public blockchain for all of our transactions, we have to commit to that address early on through the above scheme - "I am X, and I will be using the address 1PiachuEVn6sh52Ez7o6Fymvw54qvQ4RBm".

If we use multiple addresses on a public blockchain, it would be best if all of those addresses were derived from a single address in some predictable fashion. For example, we could use split-key address generation, multiplying the base private key by a sequential list of integers. This way, we can easily disclose the public key of the seed and allow any auditor to derive all of the other public keys, while still keeping our private keys safe. This way we only need to declare one address early on to create a full proof for the audit.

If the blockchain we are using is private, whether it is used only by us internally or by multiple parties, it would need to be anchored into the Bitcoin blockchain periodically to prove it wasn't altered in any way (Factom does this for example). Once we have that, we would also need a complete copy of the blockchain (or at least the relevant slice between two anchors) as part of the audit. If it is our internal blockchain, it would be analysed in whole, if it is shared - we would need to indicate which parts we used just like in the public blockchain scenarios.

Having gone through all of that effort, we can finally create our final data compilation for our audit, consisting of:

• The entire block history in the slice of time we are analysing (say, all of 2010)
• Whatever else is needed to prove the block history was unaltered. This can come in block header chain up to the newest Bitcoin block, simplified-payment-verification-esque branches of anchor transactions included in blocks, etc
• Our original commits to the addresses we would use (if applicable), along with the necessary proofs that we committed to them at the appropriate time
• Any relevant metadata we wish to submit (descriptions of which transaction was for what, etc.)

Finally, we would have not only a cryptographically verifiable proof that all of the transactions took place, but also have irrefutable proof of the time frame they took place in (we couldn't forge a few extra transactions from last year after the fact) and be able to prove that we didn't omit any piece of data - creating a negative proof.

The last one is possible because the records we are dealing with are cryptographically sealed (we can't alter the blockchain without invalidating its future, which would be evident), but also public and finite (we CAN iterate over every block and every transaction and check whether it is relevant to the audit or not). This way we not only provide every relevant transaction, but prove there are no relevant transactions we didn't provide.

Conclusions

Thanks to the advent of cryptography and blockchain technology with atomic, countable transactions, it is now possible to create an undeniable cryptographic provable complete audits. Hopefully this will help us avoid more audit fraud cases in the future...