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,:
Why would people trust this?
It's been quite the task in trying to understand how the public blockchain, specifically bitcoin, works in disintermediating centralized authorities, such as banks, to settle transactions between two parties that don't know each other. In a sense, a retailer, like Overstock.com, only needs to receive a string of digits, such as:
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.
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.
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.
Process:
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.
Process: In this example, Alice is sending the bitcoins to Bob's public key "1Cdid9KFAaatwczBwBttQcw XYCpvK8h7FK", which is also known as his bitcoin address.
If you want to wade into the details as to how the transaction is set-up and transmitted check out these two posts (here and here) by Google engineer, Ken Shirrif.
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.
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.
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).
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:
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.
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.
Risk: Any node can verify the integrity of the blockchain by downloading the full blockchain ledger and ensuring that one block is linked to the previous block. However, to do this you need about 100 GB and a few days to download the blockchain. Consequently, there is a potential risk that mobile devices - which are used by most to execute bitcoin transactions - is unable to do this verification because it lacks the storage capacity and processing power to verify the blockchain.
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 flow
Before 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 Transaction
I 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.
Process:
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.
If you want to wade into the details as to how the transaction is set-up and transmitted check out these two posts (here and here) by Google engineer, Ken Shirrif.
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.
Process: As you can see from this list of transactions, transaction ID "7957a35fe64f80d..." is just one of the many transactions that are pooled together to be mined (i.e. checked) and then added to the blockchain ledger. You can try to find the transaction by going to the link, hitting ctrl-F and pasting in the first few digits of the transaction.
Risk and Controls: NA
Step 8: Protocol uses Merkel-Tree structure to hash transactions
Process: What I found challenging was to understand how the header hash (i.e. this) links to the actual transaction (i.e. this). And that’s where my journey took me to Merkle Tree structures. What Merkle trees allow you to do is recursive hashing that combines transactions recursively into the root hash as follows:
(Taken from: here)
Control: The use of Merkle Roots enables the verification of bitcoin transactions on small devices such as smartphones. Unlike a computer that has sufficient storage, these devices can simply use merkle paths to verify the transactions instead. Using Simplified Payment Verification, the bitcoin protocol, enables you to verify that the transaction is part of this root in order to get comfort that it is part of the block that has been checked and added to the blockchain. This structure also protects the pseudonymity of the other transactions as it doesn't require decrypting the other transaction in the tree structure. This control, however, relies ultimately the overall blockchain is being verified by network and does not standalone.
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.
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.
Control: This is what effectively puts the "chain" in blockchain. It’s ultimately this structure that prevents transactions that have been added to the ledger from being modified. So let’s say you want to alter transactions that were added 1 hour ago (remember: it takes 10 minutes to add a block of transactions) you have to change the following:
- 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.
Why?
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.
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."
- 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.
Why?
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
Process: The miners "brute force" (rapidly guess) what the right value of the nonce is to get the hash. The miners keep iterating the nonce, producing the hash, and checking if it matches the desired header hash. The series flows above is meant to illustrate the iterative process the miner goes through. If the miner guesses the right hash, they will be awarded the Block Award of 12.5 bitcoins. This reward halves every 4 years and there will only be 21 million bitcoins issued. The last bitcoin will be mined in 2140.
Risks:
Process: Timestamps are embedded in every calculation involved in generating the block. This makes the blockchain “immutable” as malicious actors can’t change previous blocks, especially after 6 blocks have been added to that block (i.e. which is why online retailers wait 60 minutes before accepting payment)
- 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.
Controls:
Mitigating Risk 1: As noted in the process above, the miners have to brute-force the nonce and therefore expend energy. In fact, "electricity makes up between 90 and 95 percent of bitcoin mining costs". That means miners have to invest capital, effort and energy to actually mine the bitcoin. As noted earlier, this investment ties the miner to the success of bitcoin. That is, they won't want to hack bitcoin as it would drive the value down. On the capital side, miners buy specialized equipment called "rigs" to mine bitcoin:
Mitigating Risks 2 & 3: The bitcoin reward provides the incentives to the miners to create the header hash that has the necessary elements. While the 21 million cap on bitcoins, actually makes the currency deflationary. As bitcoins get deleted or become inaccessible because some can't remember the password to their digital wallet - those bitcoins are gone forever. Consequently, the total amount of bitcoin in circulation will be less than 21 million.
Step 12: The block is time stamped
Risk & Control: As noted in Step 9, the blockchain concept of linking one blockchain to another is a sequence is one of the key controls to ensure that transactions will be modified in an unauthorized manner. Such a control is dependent on the timestamp as noted in the process section.
Process: Other nodes check the hash by running it through the SHA-256 hash function and confirm that the miner has properly checked the transaction. If more the 51% agree, then it is accepted as valid and added to shared blockchain ledger and it will become part of the immutable record.
Author: Malik Datardina, CPA, CA, CISA. Malik works at Auvenir as a GRC Strategist that is working to transform the engagement experience for accounting firms and their clients. The opinions expressed here do not necessarily represent UWCISA, UW, Auvenir (or its affiliates), CPA Canada or anyone else.
Step 13: Block is propagated across the network.
Risk: If miners added the block to themselves, they would have both access to gaining the asset (i.e. the bitcoin) and access to the ledger itself.
Control: The bitcoin network effectively segregates incompatible functions by requiring 51% of the network to agree that the work performed was valid. That is, a block cannot become part of the blockchain ledger until the majority of the network reviews the work performed by the miners.
Conclusion:
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.
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 engagement experience for accounting firms and their clients. The opinions expressed here do not necessarily represent UWCISA, UW, Auvenir (or its affiliates), CPA Canada or anyone else.
