The Mathematics of Cryptographic Hashing
the missing part of the TNT white paper -- FILE FORMAT
The Mathematics of Cryptographic Hashing
by Joseph Mark Haykov
June 18, 2024
Abstract
The 2008 Bitcoin white paper makes an implicit false assumption by misidentifying the root problem of structuring a peer-to-peer bank as that of preventing ‘double spending’. In fact, the real problem in terms of processing cryptocurrency payments is not double spending per se, but asymmetric information about pending payments. Double spending is a type of fraud (in this case, passing counterfeit money) made possible specifically by asymmetric information about transactions and can only occur when peer-to-peer nodes are not symmetrically informed about all pending payments. However, the potential for fraud facilitated by asymmetric information exists not only ex ante, or before the transaction is permanently recorded in the blockchain, but also persists ex post, or after the fact. For example, it is possible to steal back bitcoins after they have been spent by distributing a modified copy of the entire Bitcoin blockchain, which is how the FBI is able to confiscate bitcoins from criminals engaged in blackmail (or ransomware).
Unlike Bitcoin and all competing alternative cryptocurrencies, TNT makes all such fraud impossible not only ex ante but also ex post any block update. Ex ante fraud is made impossible by using Transparent Network Technology (TNT) to maintain full information symmetry via batch processing. Ex post fraud is made impossible by requiring every single bank client (or wallet) to digitally sign every single block update, exceeding any existing blockchain security standard. This is achieved through the mandatory collection and inclusion of a full set of dual-approval digital signatures that collectively provide absolute certainty about the authenticity of any copy of the TNT (True-NO-Trust) blockchain via provable transparency, as defined by non-repudiatable proof of universal consensus immutably recorded in a TNT blockchain gold standard file format, fully verifiably trustworthy.
The dual signatures collected by TNT guarantee that each recorded transaction was not only unfettered but also symmetrically informed, as evidenced by the signature of every single counterparty to the trade. Under the rules of the TNT Bank software, each counterparty effectively becomes an independent third-party observer (witness) and is required to sign off on the fact that they independently detected no fraud at the time each and every payment was recorded. This process ensures in law, fact, and theory that no fraudulent transactions could possibly be included in the TNT blockchain.
Legal Introduction
Before we proceed with the technical discussion, we would like to point out that when we apply for an SEC Exemptive Order, we do so with the intention of using TNT to sell wBTC tokens to minimize the cost of electricity involved in processing Bitcoin payments. If such wBTC is backed by a 'dormant' (green, environmentally friendly, non-transacting) Bitcoin wallet, it is equivalent to Bitcoin and does not require any greenhouse gas emissions (i.e., mining) for transfers. This not only saves money on electricity but also allows for full AML compliance by handing over the dual approval key for incoming credits to a custodian who will not allow anyone to deposit dirty, unregulated money into a clean, AML-monitored, regulated True-NO-Trust (TNT) wallet, simply by refusing to sign the incoming credits from ‘unmonitored’ wallets.
Moreover, we seek Exemptive Order approval for all other existing use cases that currently rely on proof-of-work, as we provide the same functionality—namely, a guarantee of no fraud—but at a much lower cost, faster speed, and higher throughput, while also offering greater security. Therefore, regulating a TNT one-true money coin differently from Bitcoin would constitute granting an unfair advantage—a regulatory monopoly—to Bitcoin, thereby justifying the need for the exemption and demonstrating how it meets the statutory criteria for granting an exemption. We are asking for an Exemptive Order, as a No-Action Letter does not provide sufficient protection.
Next, we will engage the environmental lobby, supported by advocates such as Elizabeth Warren, who favor regulating cryptocurrency by imposing AML compliance. We will urge the SEC to expedite approval, emphasizing the need to phase out polluting Bitcoin and ensure that no more ransomware is facilitated by bad actors, such as Russian hackers, through our TNT one-true money—a U.S.-approved and regulated cryptocurrency.
However, the goal is not merely to obtain a license to print money—though we will benefit financially. The primary aim is to demand stricter regulation of cryptocurrencies, particularly in terms of AML, and we are the existing open-source technology capable of meeting AML requirements at a low cost.
There is no incentive for anyone to rewrite or steal our code since it is available as an open-source version. Any attempt to do so would expose the abuser to intellectual property lawsuits. Additionally, there is no benefit in re-engineering the code because it is already open source. Anyone who tries to re-engineer our code and claim it as their own will face the same legal consequences as if they used the open-source version directly. They would incur unnecessary costs for re-engineering without any added benefit, and our open-source model ensures the code remains independently verifiable and trustworthy. What we are emphasizing is that our intellectual property is open-source, so there is no additional risk of someone illegally selling it. Any illegal user would be irrational to use a re-engineered version when our True-No-Trust open-source version is guaranteed to work perfectly.
We can motivate environmental groups to encourage people to buy dormant ‘clean’ Bitcoins and contribute them to an environmentally clean Bitcoin wallet that never gets traded, using TNT-wrapped BTC (TNT-BTC) as money instead. TNT-wrapped, True-No-Trust TNT-BTC does not consume any electricity or create greenhouse gases and, instead, helps save the environment by using TNT-backed green coins as an alternative to Bitcoin. This will be the next marketing step and may require a separate license/registration from the SEC, as a No-Action Letter is too risky.
The key point here is that we do not need to take on the counterparty risk of the U.S. government potentially prosecuting individuals. We will stay offshore while awaiting explicit U.S. approval. If we do not receive explicit approval, we will not market in the U.S. This strategy highlights the issue of the U.S. government acting as a crooked rent-seeking regulatory monopoly enforcer for dirty, polluting Bitcoin, eventually pressuring them to provide full regulatory approval, akin to Bitcoin, as opposed to merely a No-Action Letter. We will not risk operating with only a No-Action Letter; we prefer to avoid any legal jeopardy. Let others take the risk of legal consequences—we will not.
Real Introduction
A checksum is a fast, basic type of cryptographic hash. However, the term "cryptographic hash" has the same exact meaning in mathematics and computer science as it does in banking and cryptocurrencies. As we focus on cryptographic hashing in the context of cryptocurrency and banking, it is important to first explain what the term "cryptographic hash" means in mathematics and computer science, where very fast forms of cryptographic hashing, such as checksums, are almost universally deployed.
Rather than spending space and time explaining exactly what a checksum is, we refer you to this Wikipedia page. As the link explains, a primitive checksum of a text message would be the sum of the ASCII values of each letter, modulo say 264, to produce a 64-bit hash value. The idea is that we take an arbitrary-length message and produce a fixed-size “checksum” or “hash value,” which has the desirable property that if two messages are different, the odds of them having the same hash value are very low. This means that if the hash values are the same, the underlying messages from which these hash values were computed are extremely unlikely to be different, making us almost certain that the two underlying messages are, in fact, the same.
This facilitates error checking and other use cases where two large blocks of data need to be compared quickly without going through the entire data set. If the checksums (or hash values) match, the probability that the underlying data sets differ must be as low as possible. To minimize the probability of a matching checksum with different messages, various sophisticated hash functions have been developed by experts. These algorithms are highly complex and beyond the scope of this discussion, but they are all structured exactly the same way in terms of code as a library function, along the following lines: unsigned long hash(const char *msg).
In essence, while there are better or worse implementations of the “hash” function, all of them return a fixed-length value. The goal is that if hash(msg1) == hash(msg2), then the probability that msg1 != msg2 is minimized, under conditions relevant to the use case of the hash function being deployed.
Having explained how cryptographic hashes work from a computer science and mathematics perspective, we can now shift focus to finance, banking, and cryptocurrencies. In these fields, cryptographic hashes, along with digital signatures, are used to mitigate fraud, such as passing counterfeit money by double spending Bitcoins. So, how exactly do cryptocurrencies utilize cryptographic hashes and digital signatures to mitigate fraud?
Fraud inevitably exists, owing to the inherent human propensity to seek to benefit from fraud when no risk of retribution is involved (as exemplified by selling rotten eggs misrepresented as fresh), in cases of fully unfettered, but asymmetrically informed exchange, as George Akerlof proves in his analysis of the market for “lemons.” The peer-to-peer network of nodes in the Bitcoin system exemplifies this type of exchange, where asymmetric information about pending payments facilitates fraud, such as double spending.
To prevent the type of fraud described by Akerlof that is facilitated by asymmetric information about the goods and services being exchanged, symmetric information must be available to all parties involved in the trade. In this case, any type of fraud becomes as impossible as passing a counterfeit gold coin to a professional jeweler who has all the necessary equipment to independently test and verify the authenticity of gold coins. The presence of symmetric information eliminates the possibility of fraud facilitated by one counterparty being less well-informed than another, as exemplified by a gullible used car buyer being sold a "lemon" by a dishonest dealer who knows much more about the car's defects. In such transactions, fraud is facilitated by the fact that the two parties are not symmetrically informed about the goods and services being exchanged.
But what does that mean in the context of cryptocurrencies? What does it mean for “symmetric information to be available to all parties involved in the trade” in this case? All parties involved in the trade are well-defined; they are simply those individuals who own one or more bank accounts or Bitcoin wallets. However, the question then becomes, how can all Bitcoin wallet owners be symmetrically informed about any fraud?
For everyone to be sure there is no fraud, each peer-to-peer node must be able to independently verify that there is indeed no fraud and that everyone else is fully honest. Here, the absence of fraud is guaranteed by three conditions:
All debits must have equal matching credits. In other words, money can’t just disappear; it must move from one account (or wallet) to another. The exact amount debited from the spending account must also be credited to the recipient’s account to the penny (or the minimum fraction of Bitcoin), barring well-defined exceptions such as fees paid to miners for processing payments or miner rewards collected in the form of newly minted Bitcoins. Except for these well-defined and inviolable exceptions, all debits must have exact and equal matching credits.
Passing counterfeit money must not be possible. This is ensured if no account balance ever falls below zero. No fraudulent payment that would result in a negative account balance must ever be processed.
Spending other people’s funds must be impossible. This is guaranteed in the case of Bitcoin by the requirement that the owner of the spending wallet authorizes all debits to their account by digitally signing them with their private key, which matches the public key of the wallet. This segues nicely into our next topic: digital signatures.
Now that we have explained how cryptographic hashes work, digital signatures, a mathematically related topic, become much easier to explain, and it is a combination of cryptographic hashes and digital signatures that mitigates fraud, as exemplified by double spending Bitcoin. However, let us get back to the subject at hand, digital signatures. What are they, and how exactly do they work? It is actually easier to outline the API first:
#include <iostream>
#include <cstring>
typedef unsigned long long Hash; // 64-bit unsigned integer
typedef char Key[255]; // fixed-length key
// Function prototypes
void makeKeyPair(Key &publicKey, Key &privateKey);
Hash encrypt(Hash decrypted, const Key &privateKey);
Hash decrypt(Hash encrypted, const Key &publicKey);
Hash hash(const char *msg);
Hash sign(const char *msg, const Key &privateKey) {
return encrypt(hash(msg), privateKey);
}
bool matches(const char *msg, Hash signature, const Key &publicKey) {
return decrypt(signature, publicKey) == hash(msg);
}
Type Definitions:
Hash is a 64-bit unsigned integer.
Key is a fixed-length array of 255 characters, used for keys.
Function Prototypes:
makeKeyPair generates a pair of keys (one public and one private).
encrypt encrypts a hash value using the private key.
decrypt decrypts a hash value using the public key.
hash computes the hash of a message (discussed previously).
Signing Function:
sign takes a message and a private key, computes the hash of the message, and encrypts that hash using the private key. This creates a digital signature.
Verification Function:
matches verifies that a given message corresponds to a given signature using the public key. It decrypts the signature with the public key and compares it to the hash of the message. If they match, the signature is valid.
Using digital signatures and cryptographic hashes, we can now explain exactly how all three conditions outlined above regarding the lack of fraud are guaranteed in the context of Bitcoin's proof-of-work system, as outlined by Satoshi Nakamoto in the 2008 Bitcoin white paper and as currently implemented in the real world using the open-source Bitcoin software.
Before we even discuss how fraud in payment processing is mitigated by various consensus algorithms, such as proof of work, proof of stake, proof of history, and many other "proof of" consensus algorithms, each individual peer-to-peer node must be certain of its current account balances when it first joins the Bitcoin peer-to-peer network. That peer-to-peer node must be able to independently determine which versions of the existing "blockchains" published by current peer-to-peer nodes are honest and which are fraudulent. In other words, given two copies of the Bitcoin blockchain, A and B, any given peer-to-peer node must be able to independently compare them and, if they are different, determine whether A or B is the correct and fraud-free "one true, immutable Bitcoin blockchain" that all honest wallets use.
So, how is this accomplished, in fact, as such verification is unrelated to how the proof-of-work consensus algorithm works and is based purely on the contents of the blockchain file? In this sense, what is it that the Bitcoin blockchain file records (or contains), specifically, that proves to an independent third-party observer that it contains no fraud?
From an individual wallet owner’s perspective, fraud is defined as making false claims about financial transactions, such as double-spending Bitcoins. This would be considered equivalent to knowingly and purposefully (not accidentally) bouncing a bank check, which is illegal and akin to passing counterfeit money. The security of a blockchain is established by a set of collected digital signatures, where a witness effectively attests to the truth of a claim by digitally signing it with their private key, matching the public key that uniquely identifies the signatory.
So, what digital signatures are collected by the Bitcoin blockchain?
Two sets of digital signatures are collected, collectively ensuring the security and authenticity of a blockchain. First, the debits to spending accounts are authorized by having the owners of spending wallets sign the spending requests with their private key, matching the public key of their wallet. This first set of digital signatures ensures that no unauthorized funds are spent, ensuring condition 3: Spending other people’s funds must be impossible.
The second set of digital signatures is collected as the miners digitally sign the hash value of the update blocks they generate, using the private key matching the public key of the miner’s wallet. Miners are responsible for ensuring that both conditions 1 and 2 hold (debits match credits and no double spending that results in negative account balances occurs). However, the miners not only ensure that conditions 1 and 2 hold, but also help certify the immutability of the blockchain, as their digital signatures of the cryptographic hashes mean one cannot go back and modify transactions in old blocks and re-compute the subsequent hashes without knowing the private keys of all Bitcoin miners who added the subsequent blocks to the blockchain.
The key nuance is that what ensures immutability is digital signatures of cryptographic hashes, not cryptographic hashes of digital signatures. This key distinction – typically overlooked in any blockchain discussion – is what, in fact, makes any blockchain truly immutable, as defined by being independently verifiable for authenticity by any peer-to-peer node. For example, if you simply have clients digitally sign spending requests and then add cryptographic hashes, this does not make the blockchain immutable. The reason is simple enough – anyone can go back and double spend in the past using the following technique:
The perpetrator of fraud has two wallets, A and C, with 100 coins in A and none (0) in C.
The perpetrator sends money to B as follows: pay 100 to B, signed by A.
The perpetrator then, ex post, after the fact, replaces in the blockchain “pay 100 to B, signed by A” with “pay 100 to C, signed by A” and recalculates and replaces all the subsequent checksums (hashes), leaving no one the wiser that they have a fraudulent blockchain.
What precludes this from happening is that the miner signs the update block with their private key, and this is what, in fact, makes the blockchain immutable—the fact that the perpetrator needs to also have the miner’s private key in order to modify the historical blockchain in such a way as to make it appear authentic. In this sense, if the FBI knows who the miner is and asks, legally, firmly, and politely, for temporary access to their private key, then they have no problems “stealing” any Bitcoins from anyone they wish.
Here, TNT is provably more secure than Bitcoin, simply by virtue of the fact that we collect the same set of digital signatures as Bitcoin, and then many additional ones. The additional signatures fall into two separate categories:
In addition to digital signatures authorizing the debits, we at TNT also collect separate digital signatures authorizing the incoming credits.
In the case of Bitcoin, only the miner’s wallet digitally signs the hash value of the entire block update. However, in TNT, every single wallet must digitally sign the hash value of the block update for it to be considered valid and accepted into the TNT blockchain.
On account of the fact that the TNT blockchain collects additional digital signatures and stores them in the TNT True-NO-Trust blockchain log file format, valid block updates are defined as those that contain all the mandated additional signatures, as specified above. In a TNT blockchain, just as in the Bitcoin blockchain, only the block updates that have collected all the necessary mandated digital signatures are considered valid and appended to the TNT blockchain, making it provably more secure than Bitcoin or any other competing alternative with fewer gathered witness signatures.
In summary, whereas a Bitcoin blockchain update is considered valid if each transaction has collected the digital signature authorizing the debit, and the block hash value is signed by the miner, in TNT, in addition to a digital signature authorizing the debit, we also collect the digital signature authorizing the credit. Furthermore, in addition to having the miner sign the cryptographic hash of each update block (which in the TNT blockchain, just as in the Bitcoin blockchain, also references the previous block, including its cryptographic hash), TNT also mandates that all other wallets, bar none, sign the cryptographic hash of the update block. This mathematically proves and guarantees that the TNT True-NO-Trust blockchain file format is inherently more secure than any format used by competing blockchains.