open-source specifications
working on a meeting agenda
TNT Open Source Software Specifications – Version 1.00
By Joseph Mark Haykov
June 6, 2024
Blockchain was invented in the 1970s, decades before anyone ever heard of cryptocurrencies. It was simply a way to facilitate independent auditing of relational databases during the heyday of batch processing.
A relational database is a collection of several related tables. For example, a car dealership might have three tables: one describing vehicles in the inventory, one with customer information, and a third table relating the first two, maintaining records of who bought which car and when.
In the past, such databases were updated using batch processing, where all transactions, like car sales to new clients and new inventory deliveries, occurred during the day. The database would then be updated once at night with a collection of all the day's transactions. Here, the important thing is that it doesn’t matter how frequently you process the updates—once a day, once a week, or once a month—the end result after the update will be exactly the same each time. In this sense, all the updates applied to the empty table from the time of its creation, barring errors, will always result in the current table.
This list of database updates, when recursively linked via cryptographic hashes, effectively becomes "immutable"—not because the database cannot be altered (it can), but because any alterations of historical data become immediately detectable, as the hash values of update blocks will not match their recorded historical hash values. This recursively linked list of updates via their cryptographic hashes is a blockchain. In this context, a blockchain is simply a log file containing the entire history of all database transactions (referred to as a general ledger in the context of cryptocurrencies and bank money). It is recorded in such a way that any subsequent modifications become immediately detectable, facilitating independent verification of the immutability of any relational database, regardless of its contents.
In this sense, a general ledger for a cryptocurrency like Bitcoin stored in the blockchain format, or a general ledger for a bank like JP Morgan, in whatever relational database format it is stored, both contain the exact same set of transactions that, once applied to an empty set of tables in a relational database, will inevitably result, each time, in the same set of account balances in each JP Morgan bank account, or Bitcoin or Ethereum wallet – for the general ledger is always a log file that results in the current account balances.
The Unix operating system is structured so that there are multiple users, each with permissions to perform specific tasks. While the root user has full access to all available functionality, other users have restricted access to the operating system. This is the same ‘permissioning’ concept used in TNT, with the only difference being that instead of passwords, we use private-public key pairs. In other words, to issue a Linux command, the user has to authenticate themselves by typing in their password. In TNT, the same thing is accomplished by sending instructions to the core node ring digitally signed by the private key matching the proper public key – the primary key for debiting an account, and the dual approval key for accepting credits into one.
For example, in the case of TNT, the root is the owner of TNT's one-true-coin wallet; whoever has the root coin has administrative privileges to do things like sign off on voting, perform coin splits, appoint new hot spare nodes, create wallets, and so on. In this sense, a valid blockchain is one where all such instructions are signed by the one-true-coin wallet’s dual approval key.
However, for extra security, each wallet has two public keys with which it can sign transactions, with the dual approval (password key) exactly mirroring the situation when a Linux user logs in and provides their password. In effect, all commands are then "digitally signed" by the user's dual approval key, including accepting incoming credits, except for spending requests (or debits). Debits must be signed by the primary key, the “debit” key – the spending key – where the corresponding private key is never revealed to anyone. This is distinct from the dual approval key, which can be handed over to an AML enforcing custodian bank, or even directly to the US Government, to make absolutely sure no dirty funds ever flow into a TNT-bank account!
Next, using our patented technology, we collect all pending updates into universally agreed-upon blocks and then collect the appropriate digital signature from the users. So our database updates might look like this:
In crossing session 34:
DEBIT A 100 GREENCOIN98 for further credit to B, signed by A-primary key
CREDIT 100 GREENCOIN98 to B, signed by B-dual-approval-key, must match crossing session 34’s hash!
We accumulate these updates in blocks (one block per crossing session) that are recursively linked by cryptographic hashes, making them immutable, and accumulate these update blocks in a set of tables, such as account balances of different coins. That's it. That's what we need to implement. That way, we can query the database to see what the coin balances were ex-ante and ex-post any given crossing session, and what the current balances are. Also, all payments in a block in a given crossing session are visible to everyone, making fraud absolutely impossible, period. That's it. That's TNT.
Blockchain Balance Algorithm
Base Case:
For the initial session (Session 1):
pre[1]=NULL
post[1]=pre[1]+updates[1]
post[1]=NULL+updates[1]
Inductive Step:
Assume the pre and post balances are correct for session n:
pre[n]=post[n−1]
post[n]=pre[n]+updates[n]
Then for session n+1:
pre[n+1]=post[n]
post[n+1]=pre[n+1]+updates[n+1]
So, using our assumption:
pre[n+1]=post[n]=pre[n]+updates[n]
post[n+1]=(pre[n]+updates[n])+updates[n+1]
This proves that each session's balances build correctly from the previous session.
Recursive Blockchain Representation:
Here’s how we record the blockchain step by step:
Session 1:
pre[1]=NULL
post[1]=NULL+updates[1]Session 2:
pre[2]=post[1]
post[2]=pre[2]+updates[2]
post[2]=(NULL+updates[1])+updates[2]Session 3:
pre[3]=post[2]
post[3]=pre[3]+updates[3]
post[3]=((NULL+updates[1])+updates[2])+updates[3]Session 4:
pre[4]=post[3]
post[4]=pre[4]+updates[4]
post[4]=(((NULL+updates[1])+updates[2])+updates[3])+updates[4]
And so on...
Summary:
Session 1: NULL+updates[1]
Session 2: previous balance+updates[2]
Session 3: previous balance+updates[3]
Session 4: previous balance+updates[4]
…
Session n: previous balance+updates[n]
Each session’s starting balance is the ending balance of the previous session, and each session’s ending balance is the starting balance plus the session’s updates. This creates a linked chain of balances, ensuring everything is tracked correctly.
This is simply a double-entry accounting system where every debit and credit is signed, making all transactions non-repudiable. Cryptographic hashes provide immutability. Everything else sits on top of this foundation, but no other functionality is requested or allowed in the release. All other commands within the update blocks, such as creating wallets, are signed by the authorized root user, namely the wallet that holds the one true money coin.
What makes all this possible is good old 1970s technology: batch processing. This allows for a fraud-free, symmetrically informed environment by allocating specific future time slots for signing debits and different, adjacent, real-time future time slots for signing matching credits. For example, in the first test version of TNT-bank money, debits are signed during the odd-numbered minutes, and matching credits, as well as any other administrative transactions such as new wallet creation, smart contract execution, etc., that require the dual approval signatures from the prior odd minute, are processed during the following even-numbered minutes by all peer-to-peer nodes.
Peer-to-peer nodes pause all activity during the first 3 seconds of each minute, allowing for up to a one-second real-time clock drift. Achieving real-time clock accuracy of one second is a trivial requirement, automatically fulfilled by periodic NTP synchronization. Yes, we sacrifice ad-hoc payment processing, necessitating a wait period that matches the crossing session cycle frequency (each minute, each second, every 6 seconds, etc.) before confirming receipt of payment. However, in return, by separating debit signatures from all other transactions, including credit signatures, through batch processing, we facilitate a symmetrically informed, fraud-free environment.
As for the SEC no action letter, see here: https://haykov.substack.com/p/legal-notes
