The Bitcoin Paper – A Black Review
Bitcoin BLACK paper
The Bitcoin Paper – A Black Review
by Joseph Mark Haykov
June 11, 2024
Satoshi Nakamoto did one thing right – not put his real name on that 2008 Bitcoin white paper – what a turd! To mess up so many things in one essay takes a real genius. Let's start from the beginning. There is no double spending problem, at least not ex ante – which means before the fact – before the update block gets recorded, in a properly structured batch processing payment system. Here, the signing of debits during odd minutes is separated from the signing of credits during subsequent even minutes in real time.
The double spending problem still persists, however, even with batch processing, ex post, or after the transaction is recorded. Unless the auditor possesses additional information about how any specific TNT system processes payments in such a way as to preclude the possibility of fraud, the log file, or the blockchain itself, must serve as proof of its own authenticity.
In other words, just like you can independently tell if a gold coin is real or not if you possess the right testing equipment, so too, given the right testing equipment, as exemplified by the open-source Bitcoin software, anyone can independently compare two copies of the Bitcoin blockchain, A and B, and tell which of the two copies, A or B, is authentic, and which copy is fraudulent. This way, given the list of known peer-to-peer nodes that maintain copies of the current Bitcoin blockchain, to which wallet applications connect when verifying coin balances, anyone can independently tell which one of such “known and trusted peer-to-peer nodes that wallet applications connect to” is using a fraudulent and non-authentic version of the Bitcoin blockchain, and stop pointing their wallets to it. This is how the Bitcoin blockchain maintains its authenticity, in fact, leaving aside any silly theoretical claims about it.
Now, here, the key nuance is that what ensures immutability is digital signatures of cryptographic hashes, not cryptographic hashes of digital signatures. This key difference – 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 perp sends money to B as follows: pay 100 to B, signed by A.
The perp 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 are looking at 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 perp 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.
In this sense, in order to make a blockchain log file prove its own authenticity absolutely, one would have to have each and every single wallet that had any coins in it either before or after each crossing session (batch update) sign the hash value of: “ex-ante balances + all updates = ex-post balances.” This would generally necessitate n signatures from each of the wallets. However, given that most wallets will outsource the signing of the incoming credits to the dual-approval custodian node, the total number of unique credit signatures necessary to collect to certify the authenticity of the entire blockchain will be reduced substantially and may even be constrained to six (one true money wallet and five core node rings owners’ wallets). But in any event, none of this matters. If multiple wallets share the same dual-approval credit private-public key pair, then only that number of unique signatures are required to prove the authenticity of any particular TNT blockchain absolutely.
Formally, a TNT (True No Trust) file is simply a log file where each update, as defined by the cryptographic hash of “ex-ante balances + update = ex-post balances,” is digitally signed by each and every unique dual-approval private key in the database affiliated with each and every single one of the wallets with any coins in it either in the ex-ante or ex-post balances – that’s all.
On account of this being a black paper, we don’t want to mess around with theories any more than we have to. All we can say is that a TNT (True No Trust) file is at least as immutable as the Bitcoin blockchain and costs a lot less money to generate using the Transparent Network Technology (TNT) batch processing payment system than using any competing alternative approach, including, but not limited to, proof of work, proof of stake, proof of history, and any and all other ‘proof’ mechanisms. TNT necessitates no proof of anything, due to the fact that symmetric information about all pending and past payments is maintained across all peer-to-peer nodes in the TNT network.
In summary, the following feature comparison between BTC and TNT explains clearly why TNT is more secure than Bitcoin.
Debit Authorization:
BTC and TNT: Both use the digital signature of all spending requests by the private key matching the debit (spending) public key of each wallet issuing payment.
Credit Authorization:
BTC: Does not support this feature at all.
TNT: Only considers as valid those debits where the matching credits are digitally signed by the receiving wallet’s dual-approval private key matching the public key used to accept credits.
Cryptographic Hashes of All Update Blocks:
BTC and TNT: Both compute the cryptographic hash of each update block and include the cryptographic hash of the previous update block as one of the fields in the new block. In this sense, the approach is exactly identical, though TNT hashes not merely the update itself but also all account balances before (ex ante) and after (ex post) each TNT blockchain log file update.
Digital Signature of Cryptographic Hashes:
BTC: Only has one signature from the miner that processed the block, "sealing" the cryptographic hash value of the update block.
TNT: Requires every single wallet to sign each and every single update block’s hash value, making it truly immutable.
As you can see, TNT is provably more secure than BTC. One last thing that must be clarified: the dual-approval signatures for incoming credits are collected and encompassed within the update block. These signatures are completely unrelated to the signature that each wallet must provide for the hash value of “prior + update = next,” which every single wallet must always digitally sign during every crossing session, regardless of any incoming funds.