Triple Signed Receipts

The idea to use balance agreement combined with transaction numbers in order to eliminate the storage (or need) of any account history (so-called destruction of account history) is inspired by Truledger by Bill St Clair. He has mentioned discussions with Patrick Chkeroff of Loom as his muse in this area. The receipt itself becomes the “account”.

Mr. St. Clair describes his protocol in this document: Truledger in Plain English.

---

The receipts on Open Transactions also take inspiration from the work of Ian Grigg.

Here is a great article on signed receipts by Ian Grigg himself, with diagrams: Triple Entry Accounting.

Grigg’s work, especially on Ricardian Contracts, is foundational to financial cryptography. (History will show…)

---

What is interesting about Triple-Signed Receipts?

Consider: If I sign cheque #45 and give it to someone who then cashes it, the money will come out of my account, and I’ll get a receipt. And if that person tries to cash it again? No problem… the server can see that it already processed cheque #45, so it refuses to process it twice. I am protected. But only because the server, in this example, maintains a list of cleared cheque numbers (it had to store “45” somewhere on a list in order to handle this situation.) I am also relying on the server to “play nice” and only process cheques once. But what if the server itself is malicious? (Perhaps the cheque is made out to them, and they want to run it through multiple times, keeping the money each time.)

In such a dispute, I’d say, “Where is all my money?” If they said, “We don’t know,” but meanwhile my last receipt—with the server’s signature on it—shows a balance of a thousand clams, yet the server has nothing else with my signature on it (to prove why the balance should have suddenly changed), then they are clearly liable for whatever money is missing.

To avoid that situation, they’d have to say, “The money went out from these 10 cheque payments.” Of course they cannot prove such a claim without producing the signed cheque receipts. And when they do that, it will become instantly clear that the same cheque, number 45, was run through multiple times, and thus the transactions are all invalid. There is no escaping this discovery, since the server cannot forge my signature and therefore it cannot just put whatever transaction number it wants onto a cheque receipt.

The point? Whether the server has to defend against malicious users running the cheque through twice, or whether I have to defend myself against a malicious server doing the same thing, either way, both sides are thus forced to store the transaction history forever, in order to cover their ass in the case of any dispute. (You can set cheques aside, and examine any other instrument, and end up having to deal with similar conundrums.)

IT’S TIME FOR A BETTER WAY: “Destruction of Account History”

As Ian Grigg said, “The receipt is the transaction.”

More: as Bill St. Clair has accomplished, the receipt is also the “account” itself. The receipt is proof of balance, and proof of which transactions are still outstanding (all others being closed.) The receipt is the account!

Double-entry bookkeeping was a huge leap forward in the economic progress of the West, as it made it possible for balances to be proven and for fraudulent activity to be rooted out and pinned onto specific people. Unfortunately, as explained above, the storage of transaction history is a necessity for double-entry bookkeeping. If you do not have all of the transactions recorded, then you are no longer able to “balance the books”.

Yet today we live in the age of strong crypto, where it is easy for the server to include a complete copy of my signed transaction request inside its own server-signed reply. I cannot prove anything later without producing that server reply, and if I do that, I will have thus also produced my original signed request, since a copy of it is included within.

==> If each of these receipts also includes a new, signed, balance agreement, then it is no longer necessary for the server to store any previous transactions at all, since it already has my (unforgeable) signature on the current balance!

===> Furthermore, we can also prove which instruments are still valid, and which transactions are still open, by simply including a list of those transaction numbers on the same signed receipt!

Even when a cheque has a valid signature on it, it’s no longer valid after it’s been cashed, right? The signature, by itself, is not enough. There must be something beyond the signature which helps us to prove whether or not the cheque is currently authorized — not just for cheques, mind you, but for all financial instruments.

Here’s how OT solves this problem: All transactions must be accompanied by a valid transaction number. Meaning, if you want to be able to write cheques, withdraw cash, and so on, then you need to have a pile of transaction numbers in your wallet. (That you already loaded up some time in the past.)

So by the time I wrote cheque #45, that means #45 was already signed out to me. I am now responsible for #45 until I sign off on its final receipt to close out the transaction (that receipt will appear, fyi, in my inbox whenever the cheque eventually gets cashed by the endorsee.)

This means that #45 will be on every balance agreement I sign, for every transaction, and will continue to appear on every “last signed receipt” that I get, until whenever #45 is finally closed out. Until that happens, all of my receipts will show that I am still responsible for cheque #45. Furthermore, when the cheque is cashed, a receipt will pop into my inbox, showing for example “Cheque #45 in the amount of 100 clams” — and this data will ALSO be on every balance agreement that I sign (until I close it out of my inbox by signing a new balance agreement.)

This is how the server covers its ass: If your balance has dropped by 100 clams, then until you have signed a new balance agreement, then the server still needs that cheque receipt to stay in the inbox, along with the old balance agreement, in order to prove the current balance! (Remember, the server cannot “set” a balance, only a user can! The server must have your signature for every clam.)

This is also how instruments are proven good or bad: If I really did authorize cheque #45, then not only will the server have my signature on the cheque, but it’ll also have my signature on the last receipt, which includes a list of transaction numbers assigned to me—and #45 appears on that list! That’s how the server proves that the instrument is valid.

The server cannot clear the same cheque twice without either (a) failing to give me a receipt the second time around or (b) giving me a bad receipt. Either way, I’ll just refuse to sign the balance agreement. (Since I don’t agree with it.) My last receipt already proves my actual balance and shows which instruments I’m actually responsible for. Any other transactions are fraudulent or already closed, and all I need to prove that is the last signed receipt.

What about the case where I accept the receipt (to remove it from my inbox) and then a malicious server runs the cheque through, a second time? This is not possible, because by then it’s already too late: my latest balance agreement (that I signed when I cleared the cheque receipt out of the inbox) includes a list of transaction numbers that I’m currently responsible for, and cheque #45 no longer appears on that list. I already have the server’s signature on the lastest receipt showing the updated list of numbers. Thus I’m not responsible for #45, or for any other transactions besides the legitimate ones listed on that receipt, that I previously signed for.

Unless the malicious server can somehow come up with a newer receipt showing differently, with my signature on it, then I’d win the dispute.

To me the amazing part of all this isn’t that the balances are proved, or that signed instruments can be authorized and de-authorized. The amazing part, rather, is that it is done while simultaneously eliminating any need to store the account history, or even an “account” at all, other than the receipt itself! Wallet software only needs to store the latest receipt, and the winner in any dispute is the one with the newest receipt.

Because all parties must sign off on any transaction, and because receipts are provided in all directions, the layers of proof are pretty comprehensive. For example, take a look at the receipts received by all parties during an account-to-account transfer:

ALICE
– Alice gets the server’s signature on her transfer request (whether it is accepted or rejected, she still
gets a signed receipt.)
– She gets Bob’s signature (in her inbox) accepting her transfer when he processes his own inbox.
– She also gets the server’s signature on that when it happens.
– She’ll also get the server’s signature on an agreement of balance at the same time.

BOB
– Bob gets Alice’s signature sending the original transfer, which appears in his inbox.
– He also has the server’s signature on that
– Then, when he accepts her transfer, he will get a signed receipt from the server when his balance is updated.
– He will also have a signed balance agreement from the server at this time.

THE SERVER
– The server gets Alice’s signature on the transfer request.
– The server gets Bob’s signature accepting Alice’s transfer.
– The server gets Alice’s signature acknowledging Bob’s acceptance (when she removes his accept notice from her inbox.)
– Tthe server will also have Alice AND Bob’s agreement on both of their balances, (and doesn’t need to store anything else.)

Not to complicate things, but on each of the above (on each balance agreement), there is also:
– a list of transaction numbers still outstanding (signed out by the Nym).
– a list of pending transactions, and signed receipts, awaiting approval in the inbox.
– …and a similar list of pending outgoings (in the outbox.)

Once a transaction is closed, it will be removed from the next signed receipt and the old receipt can be discarded.
The user no longer has sign off on that transaction number on any future balance agreements.

That’s important: If Cheque #45 hits my inbox in the form of a cheque receipt, my wallet only needs to verify against
the last signed receipt. If #45 wasn’t signed out to me, then I’m not responsible for that cheque! The signature, by
itself, is not enough.

This makes it possible to define the terms of an instrument, to exercise it, to revoke it, or expire it, or determine the
manner or the number of times by which it shall be negotiated. Nevertheless, parties only need store the last signed receipt.

---

How does Open Transactions compare to Truledger?

• Because Truledger guarantees that transfers will happen in order, Mr. St. Clair was able to rely on a simple assumption: That all transactions prior to a specific balance agreement have been cleared, and are therefore no longer pending.

• However, Open Transactions features transactions that may occur out of order. You might use transaction numbers 5, 6, and 7 on a set of three cheques. But the recipients might redeem those cheques in the order 7, 5, 6. Just because cheque 7 has cleared, does not mean that 5 and 6 have cleared! OT thus does not have the same guarantee of sequential processing that Truledger does.

• This means that Open Transactions must include a list of all uncleared transaction numbers with each balance agreement, so that when the receipt is presented later, clear proof may be obtained as to which transactions were cleared and which had not yet been processed. (Whereas on Truledger, the balance agreement itself proves the current transaction number, and all previous numbers are considered cleared.)

• In both cases (Truledger and Open Transactions) the same basic effect is achieved: server and client can prove balances and validity of instruments simply by presenting the most recent receipt, with no need to store any other transaction history. In order to accomplish this, OT has to include all currently outstanding transaction numbers on the receipt, but this enables OT to support offline instruments (such as cheques) that may be presented later in a different order than they were originally issued.

• The other big difference is that Open Transactions assigns the transaction numbers to a user account, where they might end up being used for any of that users’s asset accounts, meaning that OT has inboxes for the user accounts (for receiving transactions and messages) AND for the asset accounts (for receiving pending transfers and cheque receipts) whereas in Truledger, the user account IS the asset account (you just create as many as you need, and each has its own inbox.)

• The other big difference, right now, is that Truledger uses chronological timestamps for its transaction numbers, whereas OT uses sequential long integers. However, OT will soon most likely also change to using timestamps—but not for the same reason. On Truledger, the timestamp (for a given transaction) inherently proves the prior clearance of all previous transaction numbers, and thus eliminates the need for any “uncleared” numbers to be explicitly declared on the receipt. Whereas on Open Transactions, the current transaction number wouldn’t prove the sequence even if it WAS a timestamp, since instruments can be presented out of order! This is why OT explicitly must declare all uncleared numbers on the receipt.

So then, why is OT bothering to convert to use timestamps as transaction numbers? Because it’s the only way to expire them. The server would otherwise be forced to store uncleared numbers forever, in case they came floating back in some day. To fix this, OT will soon switch to timestamp-based transaction numbers, to make it easy for the server operator to expire any uncleared transactions that are older than N days.

Much gratitude and respect for Bill St. Clair, whose work on Truledger was truly inspirational and who has been available for discussions on this topic.

Click here to read more about cheques.
Click here to read about other financial instruments on Open Transactions.