January 22, 2014
Who invented the shared repository idea: Bitcoin, Boyle, and history
I had previously claimed that Todd Boyle had invented the idea of a shared transaction repository (or STR):
"BitCoin achieves the issuer part by creating a distributed and published database over clients that conspire to record the transactions reliably. The idea of publishing the repository to make it honest was initially explored in Todd Boyle's netledger design."
It was a point of some discord between us, and almost brought us to academic blows, but with the advent of Bitcoin and it's published, out-there, in-your-face ledger, now aka the blockchain, Todd's ideas have been cast in a new light.
This is a historical curiosity, and as I was challenged on this question by Luuk, a student of this history, I finally got around to researching it. Now, sadly, Todd has left the net scene for other things. But the wayback machine preserves his writings (GLT-GLR, STR and death to CDEA), and I found the following snippet concerning the GLT or General-Ledger-for-Transactions, his idea of a webserver that handled transactions for the world:
Triple entry accounting is this: You form a transaction in your [General-Ledger-for-Transactions]. Every GLT transaction requires naming an external party. ... [which names a] real customer or supplier ID which is publicly agreed, just as domain names or email addresses are part of public namespaces.When you POST, the entry is stored in your internal [GLT] just like in the past. But it is also submitted to the triple-entry table in whatever [Shared-Transaction-Repository] system you choose. Perhaps your own STR server, such as the STR module of your GL. Or perhaps it is a big STR server out at Exodus or your ISP or a BSP. The same information you stored in your GLT entry suffices to complete the shared entry in the STR, and your private Stub.
...
3. the GLT is something that is almost becoming a community asset. You just cannot get the kind of integrated economy we need, without some real consensus among practitioners, to move certain parts of the transaction to a shared place. I am not saying public; I am saying shared. The amount, date and description of a deal are inherently shared between two parties and should be stored visible to those two parties alone, i.e. either protected by private system permissions or, encrypted visible to those two parties alone.
For me, these paragraphs dating back to 2003 stake a tiny claim. I certainly don't claim the idea because I remain horrified at the privacy implications of a published general ledger, as expressed by Bitcoin, but that's something that the market has decided it's not so fussed about. What is interesting is that, rarely amongst contemporary writings, Marc Andreeson came out and said:
... Bitcoin at its most fundamental level is a breakthrough in computer science – one that builds on 20 years of research into cryptographic currency, and 40 years of research in cryptography, by thousands of researchers around the world.
Having been someone who started working in cryptographic currency in 1995, I'm very aware of the way this history unfolded. Satoshi Nakamoto stands on the shoulders of giants, his design is the very clever assembling of components that were tried beforehand, and found wanting for various reasons.
The notion of a public, and/or shared ledger is one of those components employed in Bitcoin, and for that, I think Todd deserves a small byline in history.
Todd Boyle! We who died in the entrepreneurial pursuit of digital currency, we salute you!
Posted by iang at January 22, 2014 02:34 PM | TrackBackHi Ian, thanks for the post... there is a lot of interesting discussion on open lists, such as this post,
https://groups.yahoo.com/neo/groups/decentralization/conversations/topics/697
I was very much influenced by Bob Haugen, a guy in the ebXML standards working on Core Components. He was a software implementer in the Auto industry in the 1990s, you know, EDI and ERP software stuff, and those people had been tearing their hair out for years and wishing they had a "Public Transaction Repository" i.e. a general iedger type thing, flat rows where independent companies could post their resource transfers and related double entry, the AR/ AP amount. Bob even helped me by reviewing my STR papers, back in 2000.
I was considered an idiot and a nuisance on the Decentralization list by all these luminaries like Clay Shirkey, Lucas Gonze, Dave Winer, etc. It was a great list.
Todd
Posted by: Todd Boyle at January 5, 2015 01:43 AMTodd, it's great to see you're still alive! Been looking for you for years.
See my post from last year at: http://www.sleeter.com/blog/2014/02/digital-currency-are-bitcoins-here-to-stay/
I believe you are the real inventor of Bitcoin.
Posted by: Doug Sleeter at January 10, 2015 02:29 PMSomething that was highly influential to Bitcoin's design is Wei Dai's b-money:
http://www.weidai.com/bmoney.txt
"In the first protocol, every participant maintains a (seperate) database of how much money belongs to each pseudonym. These accounts collectively define the ownership of money, and how these accounts are updated is the subject of this protocol."
....
"2. The transfer of money. If Alice (owner of pseudonym K_A) wishes to transfer X units of money to Bob (owner of pseudonym K_B), she broadcasts the message "I give X units of money to K_B" signed by K_A. Upon the broadcast of this message, everyone debits K_A's account by X units and credits K_B's account by X units, unless this would create a negative balance in K_A's account in which case the message is ignored."
List: cypherpunks
Subject: PROTOCOL: Encrypted open books
From: Eric Hughes
Date: 1993-08-26 18:28:14
[Download message RAW]
Note: I started this reply last week; I've decided to post what I know, since I don't have a solution and I've run out of simple ideas for now.
Hal' criticism that (real) money could leak out of the system is correct. The problem is that while the books would still balance, i.e. sum to zero, some fake depositor would have a negative balance, the net result of taking out more money than you put in. Negative numbers just aren't allowed in double-entry bookkeeping, but they were allowed in the first protocol set.
The first part of the solution is to allow no private accounts on the left hand (asset) side of the ledger, in other words, no anonymous loans. A protocol for doing anonymous loans could be invented, but since the first problem is merely to run a money exchange and not more complicated financial services, this is acceptable. Most of the money that left the S&L's was by corrupt loan practices, so I don't consider this omission a particularly glaring one right now.
Therefore all the private accounts must be on the right hand side, that is, they are all liabilities. In layman's terms, the bank owes you; should you ask for your money, they have to give it to you. If we can verify that each of these accounts never goes negative, then we can be certain that if the books balance, that the amounts of money in each account are accurate.
Consider this. If money was transferred from your account to another one, that transaction shows up in the public encrypted transaction record. If you have due diligence over this record, you can assertain that no transaction was performed against your will. This case corresponds to a debit and credit against two customer accounts, decreasing one and increasing the other.
Another way that money might end up in a fake account if it were credited with assets. A debit to an asset increase its value and the credit to the account increases that value. This is the case of a deposit; the bank gets cash (+asset) and credits someone's account (+account). Now if they want to give someone money this way, they have to do so by increasing the assets somehow; in other words, they money has to come from somewhere. It didn't come from any of the customers because they've already verified that. It didn't magically appear from one of the other asset accounts because these are all publically audited.
In summary, we need to ensure that all accounts have positive balance. Public accounts can be revealed and seen to be positive. Private accounts need a cryptographic assurance.
A private account starts off at zero. This can be publically revealed. Then to the encrypted transaction log and the public cyclic balances we add publication of the private balances in encrypted form that allows us to verify to the blinded balance is positive. This balance is verifiably linked to previous cyclic balances via the transaction log. It is therefore linked all the way back to the beginning balance which was zero.
Consider all the transaction triples for which the first element is equal to the private account in question, since the account was opened. Take a product of all of the second elements and a product of all the third elements. It is clear that these products can be calculated inductively from the previous cyclic products and the activity in this cycle.
The products on second and third elements are equal to
g^( Sum x_i,j,t + Sum r_i,j,t ), h^( Sum r_i,j,t )
where I've added a time index by cycle which was implicit before. The notation for the inductive calculation is different, of course, and also obscures the underlying invariant.
What we want is a certificate that Sum x_i,j,t is positive. Here it gets a bit hairy. There are likely other solutions to this technical requirement; here is the one I thought up yesterday and today.
I thought I had an idea with promise on how to create such certificates using quadratic residuosity, but it doesn't work. I'm still thinking about it; this certificate doesn't seem impossible to create, but the standard ideas that I know about in algebraic protocol design don't seem to work.
If anybody wants to work on this technical point off-line with me, send me mail. The math involved is advanced enough that I'd prefer to post summaries of work rather than all the detailed discussion.
Another non-technical attack on the problem is to require periodic bank holidays, where all private balances will be revealed to be zero (preferably), or whatever is actually in the account. This doesn't prevent owner fraud, but does put an upper bound on the time in which to perpetrate it.
Eric
Posted by: PROTOCOL: Encrypted open books by Eric Hughes at July 2, 2015 05:28 PMTodd Boyle! How long has it been?
I give Todd all props, precedence and credit for the idea of a shared transaction repository.
I thank him for even mentioning my name, but I deserve no credit. All Todd, all the time!
Posted by: Bob Haugen at July 8, 2016 06:48 PM