For the past year, I have been following blockchain to assess how this exponential technology will impact financial auditing.
Unlike artificial intelligence, quantum computing, or virtual reality, this technology addresses the heart of accounting profession: it is an innovation in the process of recording and accounting for transactions. Furthermore, it captures "proof of interaction" by leveraging digital signatures as the basis for executing exchanges. Both these features speaks to the core of what we do as accountants and auditors.
But before we get ahead of ourselves, it is important to look at blockchain in a nuanced way. On the one hand, technologists should be careful about how the blockchain will impact the audit. However, at the same time, the audit profession can't afford to ignore it. To do so would invite the profession to repeat the mistakes of Kodak who, despite inventing the digital camera in 1975, were ultimately disrupted by that very same technology.
Part of the problem was understanding that digital technology was changing at a linear pace instead of an exponential pace. In this post, Peter Diamandis talks about how "30 exponential steps" compares to "30 exponential steps" (and talks more broadly about linear vs exponential thinking). Ray Kurzweil, the infamous Googler, talks about the infamous story of how the inventor of chess requested an exponential amount of rice (and is rumored to have lost his head).
Going back to looking at this as an auditor, I think a useful starting point to understand the topic of blockchain is one of "professional skepticism". Specifically,:
https://blockchain.info/block/0000000000000002f7de2a020d4934431bf1dc4b75ef11eed2eede55249f0472 and be satisfied that the purchaser has bitcoins required to buy the merchandise and hasn't already spent them. That is, they have "assurance" from the above string of digits and characters that the sender has not already spent the bitcoin or has simultaneously sent the bitcoins to someone else.
Part 1: Background on the process flowBefore going through the walk through, it is important to watch these videos first to get some background on how Bitcoin works.
The following video illustrates the peer-to-peer nature of the ledger:
This video gives a good 5-minute summary delving more into the technical details of bitcoin. If you need more, check out this 22-minute video by the same author.
The following video by Andreas Antonpolous, is especially helpful in understanding how the blockchain works at a deeper level. Encourage watching the whole video, but if you want to get to the meat of how the Proof of Work, SHA hash function works, skip to this point in the video .
As noted in these videos, when you send or receive bitcoins there's no exchange of actual digital code. Rather, it merely updates on the ledgers across the bitcoin network. It's quite ironic for us accountants - the way to bitcoin holdings are really just the sum of the person's bitcoin transactions.
Part 2: Walk-through of a Bitcoin TransactionI originally mapped out this "walk-through" of a bitcoin transaction in PowerPoint. The transaction is largely based on the book, Mastering Bitcoin, by Andreas Antonopolous (same individual in the video above). He has been nice enough to make a number of the chapters online, including chapter 2, 5 and 8 that I used to develop this flow.
The bitcoin transaction that I used to perform the walk-through is the same one used in the book and it belongs to block #277298. As per the book, Alice sends 0.015 bitcoins to Bob's cafe to buy a coffee.
Step 1: Get a bitcoin wallet and some bitcoin.
For those bold enough to transact in bitcoin, they need to set-up a bitcoin wallet on their computer or mobile phone. Most important of all this needs to be secured as it holds your private key that is used to sign the transactions and send over to others. If this key is compromised, lost, etc. - you will lose all your bitcoins! And unlike credit cards, there is no central authority to complain to if this happens.
If you live in Toronto, you can actually buy the bitcoins at Deloitte at Bay and Adelaide (but you will need to set-up your digital wallet before doing this).
It cannot be overstated enough that this is where the bulk of security issues occur and makes bitcoin prone to hacking. As noted in this article, the August 2016 hack of Bitfinex had to do with the way that the actual wallets are secured using multi-signature wallets where multiple parties (user, Bitfinex, and Bitgo) held the keys. It should be clear, however, that it's not the actual ledger that is being hacked or more accurately being modified. Instead, it's the encryption keys that are being stolen by the attackers.
How did the thieves access the funds given that the ledger is reporting all transactions publicly?
This article from the Verge gives some insights on how bitcoins can be effectively laundered out of the blockchain.
Step 2: Send bitcoins to the recipient.
Process: In this example, Alice is sending the bitcoins to Bob's public key "1Cdid9KFAaatwczBwBttQcw XYCpvK8h7FK", which is also known as his bitcoin address.
Risks: Unauthorized recipient is sent the bitcoin. Unauthorized user modifies the payments.
Controls: Public key-cryptography: As noted in the process, Alice must send the bitcoin to Bob's bitcoin address or his public key. As long as she is 100% sure that it is actually Bob's address then only Bob will be able to access those bitcoins. In this scenario, Alice will likely scan Bob's QR since she is buying the coffee from him. However, if this were an online transaction then she would need to use an alternative method to verify that she is sending her bitcoins to the right address. PKI also ensures that the message can't be altered.
Step 3: Generate the transaction ID
Process:After the bitcoins are sent to the recipient a transaction identification number is generated, which in this case is “7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18”.
Risks: Transaction will not be properly identified.
Control: Each bitcoin transaction is uniquely identified by transaction identification.
Step 4: Perform checks at the node
Process: Transaction is captured by the initial node. Risk:Transaction will be invalid, incomplete, incorrectly formatted, or violate other rules within the bitcoin protocol. See below for how these controls would be classified as “input edit controls” or data validation routine.
Risks: Inaccurate, invalid or incomplete transaction or transaction details will be posted to the blockchain.
Controls: The following list of controls are taken verbatim from chapter 8 Antonopolous's book mentioned earlier (or click here to see "Independent Verification of Transactions" in chapter 8)
Validity checks.The real genius of bitcoin is that it ensures that the person sending you the bitcoin already has them. In other words, it’s provide comfort on the existence assertion – to potential vendor or other person that will receive those bitcoins. With respect to data validations, it provides the following checks:· None of the inputs have hash=0, N=–1 (coinbase transactions should not be relayed).
- A matching transaction in the pool, or in a block in the main branch, must exist.
- For each input, if the referenced output exists in any other transaction in the pool, the transaction must be rejected.
- For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions pool, if a matching transaction is not already in the pool.
- For each input, if the referenced output transaction is a coinbase output, it must have at least COINBASE_MATURITY (100) confirmations.
- For each input, the referenced output must exist and cannot already be spent.
- Reject if transaction fee would be too low to get into an empty block.
- The unlocking scripts for each input must validate against the corresponding output locking scripts.
- The transaction’s syntax and data structure must be correct.
- Neither lists of inputs or outputs are empty.
- The transaction size in bytes is less than MAX_BLOCK_SIZE.
- The transaction size in bytes is greater than or equal to 100.
- The number of signature operations contained in the transaction is less than the signature operation limit
- The unlocking script (scriptSig) can only push numbers on the stack, and the locking script (scriptPubkey) must match isStandard forms (this rejects "nonstandard" transactions)
- Reject if the sum of input values is less than sum of output values.
Range checks. The following controls ensure that the values submitted are within an acceptable range. The last one is what prohibits the mining of coins beyond the 21 million limit set by the protocol:
- nLockTime is less than or equal to INT_MAX.
- Each output value, as well as the total, must be within the allowed range of values (less than 21m coins, more than 0).
- Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in the allowed range of values (less than 21m coins, more than 0).
Step 5: Accept or reject the transaction
Process: If the transaction meets the criteria then it is passed on to the miners to be mined in a block. Otherwise the transaction is rejected.
Risk/Control: this is a flow through from the previous step.
Step 6: Send transaction to be mined
Process: The transaction is then sent to a pool to be mined. The protocol looks to have the transaction mined within 10 minutes. When the sender submits the transaction to the recipient, they can add fees to be paid to the miners. However, those do not give fees are of a lower priority than the people that actually paying to have their transactions processed. Right now this is not critical as the main reward is getting awarded 12.5 bitcoins for mining (i.e. guessing the correct nonce which is discussed below). When bitcoins run out in 2040, however, it is these transaction fees that will become the main “remuneration” for the miners.
Risk: Miners incentives will not be aligned with verifying transactions.
Control: The economic incentives give the miners a reason not to counterfeit. It is less work to actually mine the coin then try to counterfeit the coin by amassing the necessary computer power. Also, the problem for profit-seeking criminals is that once they counterfeit the coins (e.g. through the 51% attack) then the community would lose faith in the bitcoin making it worthless. However, this does not stop non-profit seeking parties who are looking for a challenge or to destroy the bitcoin platform.
Step 7: Pool the transaction with other transactions to be mined.
Step 8: Protocol uses Merkel-Tree structure to hash transactions
Step 9: Combining the hash transactions with previous block
Process: Miners need to generate the header of the blockhash, which consists of the previous hash, the merkle root of the current set of transactions, as well as the nonce (see step 10 and 11)
Risk: Transactions will be modified in an unauthorized manner.
- Merkle root of the hash of that transaction that was added 60 minutes ago.
- The header hash of the transaction of the block that was added 50 minutes ago.
- The header hash of the transaction of the block that was added 40 minutes ago.
- The header hash of the transaction of the block that was added 30 minutes ago.
- The header hash of the transaction of the block that was added 20 minutes ago.
- The header hash of the transaction of the block that was added 10 minutes ago.
Because each hash is based on the hash of that transaction that was added an hour ago. Any modification of that hash alters each of the 5 blocks that comes after that. Each block of the 5 block’s data structure depends on that hash-value of that transaction you want to modify.
Step 10: Setting the Difficulty/Target to identify the nonce
Process: The difficulty is actually set by the peer-to-peer system itself reviewing that the average time for the last 2016 blocks was 10 minutes on average. If not, then the difficulty will be adjusted up or down to get to the 10 minute average.
Risk: Transactions will be mined in an untimely manner; i.e. more or less than 10 minutes.
Control: The difficulty/target effectively as a throttle to ensure that the blocks mined takes 10 minutes regardless the number the miners or the computers involved(i.e. which will continually fluctuate). What the target determines is the level of guessing that the miners have to do find the "nonce" (see next step). The lower the target the more difficult it is to guess that number because there are possibilities of the answer being correct.
Antonopoulos, in Mastering Bitcoin, gives the following analogy:
"To give a simple analogy, imagine a game where players throw a pair of dice repeatedly, trying to throw less than a specified target. In the first round, the target is 12. Unless you throw double-six, you win. In the next round the target is 11. Players must throw 10 or less to win, again an easy task. Let’s say a few rounds later the target is down to 5. Now, more than half the dice throws will add up to more than 5 and therefore be invalid. It takes exponentially more dice throws to win, the lower the target gets. Eventually, when the target is 2 (the minimum possible), only one throw out of every 36, or 2% of them, will produce a winning result."
Step 11: Produce the header hash, i.e. the proof of work
- Malicious actor controlling 51% of the network could authorize fraudulent transactions.
- People will not sign up to be miner without sufficient reward for their effort
- Infinite supply of bitcoins would expose the currency to inflation risks, i.e. if a bitcoins are mined endlessly the exiting bitcoins would decrease in value.
Step 12: The block is time stamped
Step 13: Block is propagated across the network.
Hopefully, this has clarified some of the nagging questions you've had about how the bitcoin blockchain enables trust through a decentralized peer-to-peer network. That being said, the above flowchart has been quite the labour of love for the past few months. So there will be quite a few gaps! Special thanks to Andreas Antonopoulos, who although I have never met, has made this journey a lot easier by making his work available online.
Please email me at malik [at] auvenir.com if you have any comments, questions, or notice any gaps.
Author: Malik Datardina, CPA, CA, CISA. Malik works at Auvenir as a GRC Strategist that is working to transform the way we do financial audits. The opinions expressed here do not necessarily represent UWCISA, UW, Auvenir, Deloitte's or anyone else.