It was widely recognised since David Chaum's designs first appeared that the new 'digital certificate' model of money was not aligned or symmetrical with accounting techniques such as double entry book keeping. Many people expected the two to compete and indeed many money systems avoided combining them; this is I believe one of the few efforts to integrate the two and show them as better in combination than apart.
The digitally signed receipt, an innovation from financial cryptography, presents a challenge to classical double entry bookkeeping. Rather than compete, the two melded together form a stronger system. Expanding the usage of accounting into the wider domain of digital cash gives 3 local entries for each of 3 roles, the result of which we call triple entry accounting.This system creates bullet proof accounting systems for aggressive uses and users. It not only lowers costs by delivering reliable and supported accounting, it makes much stronger governance possible in a way that positively impacts on the future needs of corporate and public accounting.
Comments below as always!
Those that are deep into transactional database work, as everyone in payment systems and the like is, know there is a deep dim and ghostly place that we all fear. I've just walked that through that place, and as soon as I saw it, I know I was staring at the Twilight Zone.
The Twilight Zone is a special nightmare for database engineers. It is when your transactional set forks into two; both are correct because they are transactions, after all, but both places are wrong because of the other place. Worse, the further time passes, the more chance of more forks, more and more places, all in the same zone. It is when the time-space continuum of your data fractures and spreads out in an infinite tree of possibilities.
I've always known it existed. When you've travelled so many databases, so many scenarios, you realise that the perfect database doesn't exist. Software is meant to fail, and getting it right today just means it will really go wrong tomorrow. For nine years, tomorrow never came, until one day in Vienna, I discovered a whole issuance of newly minted gold, Euro and sterling had just ... vanished into another space. It took me over two days of isolating and isolation before I realised where I was. And where I was.
(A brief digression for the non-digerati: database software does transactions, which are like records or receipts or sales or somethings that have special characteristics: they happen once and once only, if they happen at all, and if they happen, they happen forever. We call them atomic, because they either do or they don't happen, we can't divide them into half-happens. We do this because when we move money from one place to another, we want to make darn sure it either moves or it doesn't. No halfway house. And no going back, once we got there. We actually care so much about this that we don't really care which it is - happens or not happens!)
So when my fresh gold decided it had happened and not happened, I was sucked into the Twilight Zone. The reason it exists is quite fundamental: transactional software is perfect in theory, but implementations are flawed. No matter how much care you take, changes occur, features get added, bugs need to be fixed; step by small baby step, the logical beauty of your original design flits and dances towards the forking point. With all software, everywhere, no matter the manufacturer's guarantee, there will always be the possibility of so many bugs and so many patches and so many engineers who didn't understand, all one day coming together to split your state into the twilight zone.
This is why space shuttles blow up. Why Titanics sink, dams collapse, power grids shut down, and stock exchanges melt down. It's not because of a lack in the quality of the people or the software, it's because of the complexity of the system. Fundamentally, if you got it right, someone will build a better system on yours that is 99% right, and reliant on yours 101%. And the next person will layer their opus magnum over that great work and get that 98% right... and so it goes on until the mother of all meltdowns occur.
Specifically, what happened was an event notification - a new feature added in so as to enable chat broadcasts via payments - had a dodgy forwarding address. Which would have been fine, but the change to fix that broke. Which wasn't picked up in testing, because it didn't break in quite that way, but was picked up by a recovered transaction which did look it in exactly that way, which in turn failed and then went on to block another transaction in recovery. (Long time hackers will see a chain of bugs here, one tripping another in a cascade.)
This last transaction was a minting transaction. That means, it created value, which was the sterling I mentioned earlier (or gold, or Euro, I forget). Which, by a series of other unfortunate events caused yet another whole chain of transactions to fail in weird ways and Shazam! We entered the twilight zone where half the world thought they had a bucket of dosh, and the other half did not.
Fixing the bugs is obvious, boring, and won't be discussed further. The real issues are more systemic: it is going to happen and happen again. So infrequently that its very rarity makes it much more traumatic for its lack of precedent. It is very hard to create procedures and policies to deal with something that hasn't happened in living memory, would be fixed immediately if we knew how it was going to happen, and is so not-going-to-happen that the guarantee doesn't permit it. Nor its solution, nor even the admittance of the failure.
So how do we deal with the twilight zone? Well, like quantum physics, the notion is to look at the uncertain states and attempt to collapse them into one place. With luck this is possible, simply by re-running all the transactions and hoping that it all works out. With bad luck however, there would be a clash between transactions that resulted in leaving the twilight zone the wrong way, and being splintered forever: Simply put if I had given money to you in one place, and to your sister in another place, when the two places collapsed into one then the time-space of accounting would rip asunder and swallow us all, because money can't exist in two states at once. It would be light and day together for evermore. At the least, permanent migraines.
Which leads me to our special benefit and our own fatal curse: the signed receipt. In our transactions, the evidence is a receipt, digitally signed that is distributed to all the accounts' users. This means we as issuers of contractual value are locked into each and every transaction. Even if we wanted to fiddle with the database and back out a few tranasctions to pretend your sister doesn't exist, it won't work because the software knows about the signed transactions. This trick is that which I'd suggest to other databases, and that's why we signed the receipts in the first place; We never wanted that to work, and now it doesn't. Stuck, we are.
It does however mean that the simple tactical phase is a good starting point: re-run all the transactions, and live with the potentially broken accounts, the accounting time-space rent asunder if so discovered. How we'd deal with that is a nice little question for our final exam in post-graduate governance.
My walk through the twilight zone was then guided by a strategy: find all the signed receipts, and re-run them. Every one, and hope it worked out! Luck was indeed on my side this time, as it was a minting that had failed, so the two places were cleanly separated in the zone. I had to fix countless interlocking bugs, make yet more significant feature changes, and conduct days worth of testing. Even after I had done all this, and had watched the thrilling sight of 10 transactions reborn in my preferred space, I still had only the beginnings of a systemic solution to the problem of walking the twilight zone.
How to do that is definately a tricky problem. Here are my requirements so far: even though it should never happen, it must be a regular occurrence. Even though the receipts are scattered far and wide, and are unobtainable to the server, we must acquire the receipts back. And, even though we cannot collapse the states back when they have forked too far, we must re-engineer the states for collapse.
I have the essence of a solution. But it will have to remain on the drawing board, awaiting the next dim opportunity; as no-one willingly walks into the Twilight Zone.
Adam's blog pointed me to this description of the switcherooo in US government accounting. In brief, the USG has been using cash accounting, which means they count up the cash coming in, and going out, and that's their profit & loss. Yet, the SEC mandates accrual accounting for all companies of any note. The difference is pretty substantial. In accrual accounting, you also include all your *future* income and liabilities. This of course means that on paper at least you can't play games with this year's numbers at the cost of next year's numbers.
Now, it seems that some rebels in Congress got the US treasury to at least present some rough accrual numbers this year. So we can see the difference. Well, it ain't good. Actually, it's unbelievable. So sit down, and prepare to expire.
On a cash basis the USG has incurred an extra debt of about $412 bullion, for the fiscal year of 2004. But, on an accruals basis, the number is $11.087 trillion dollars.
That's twenty seven times bigger than the popular, published number, if these numbers are to be believed. Can you say Enron on a global economic scale?
See the post, and the UST's hopefully authoritive report for the details. I can't cope, but luckily I don't need to. All you American Accountants out there.... It's over to you: Tell Mr Scrivener he's wrong! You owe it to your country.
DSR is a historical pre-commercial (circa 1994) shared accounting architecture that was proposed to compensate router owners for passing the packets of other entities.
Cooperating router nodes would count packets passed between them, and occasionally, they would send "number" money packets back and forth to reset the counters. These paid-for resets would cause charges to trickle across to big users, and money towards working routers. Defences against cheating/fraud were limited to signed notifications of balances and a simple payment system.
DSR is like LETS for routers. As a thought experiment in multi-agent accounting, it is interesting for its influence on later micropayment systems (Mojo Nation?), but it assumes pre-commercial net-style honest behaviour and the absence of competition. It also suffers somewhat from the cool engineering approach ("the silk road was so cool, let's rebuild it") that always gets steamrollered by markets and marketing.
E.g., FedEx beats the original silk road, as does a host of other transport innovations such as trains, bulk container ships and blind men with canes. In today's Internet world, large corporations achieve internal Coasian efficiencies by owning thousands of routers and not doing internal charging, but collecting flat fees from customers.
Convergence of accounting standards by 2005 is anything but a sure thing, thanks to opposition by Europe's banking sector.
Ed Zwirn, CFO.com February 20, 2004
Will opposition from Europe's banking sector leave the world's two biggest markets operating by different rules?
The International Accounting Standards Board (IASB) is apparently digging in its heels on marking derivatives to market. But the European Union may refuse to go along. Companies needing to access capital markets in both the United States and Europe, as a result, might have to continue to account for their business by using both U.S. GAAP and International Financial Reporting Standards beyond the Jan. 1, 2005 deadline for convergence.
On Wednesday, the IASB rejected calls from bankers that IAS39 either be scrapped or substantially revised. IAS39 is Europe's answer to FAS133, the U.S. accounting standard, which requires derivatives be marked to market. EU officials have cast doubt on whether they will make the standard mandatory when it makes IFRS mandatory on Jan. 1.
IASB has issued a standard on another controversial issue, ruling that EU companies must expense stock options. Another apparent sticking point for convergence is how to best record tax benefits for employee stock-based compensation.
Earlier this month, Fritz Bolkestein, internal market commissioner of the EU, warned that the EU might have to shelve mandatory compliance of IAS39 when IFRS becomes mandatory at the beginning of 2005 if the IASB does not reach some kind of agreement with the EU.
Donald Nicolaisen, the SEC chief accountant, said the IASB proposals already on the table were of "high standard" and that he would withdraw his support for accepting the IASB filings of companies listing in the United States if they were not adopted. "Derivatives are widely used today and you need a way to account for them," he said after Bolkestein's comments. "Without that, the [accounting] standards are not complete and I wouldn't be in support of accepting filings where they don't have it."
Despite heavy lobbying from European banks and the EU's European Commission on derivatives, the board refuses to change its position. As a result, sources cited by EUPolitix.com say, banks will still manage their risk portfolios as they always have. But they will be forced to make figures fit IASB requirements ? a development that will be more costly and will reduce the reliability of accounting figures.
A new Group of Thirty (G30) report, Enhancing Public Confidence in Financial Reporting, commissioned after the last few years' spate of corporate failures has stated that it is Governance that has failed, not Accounting.
It is true that governance was the core failure in these cases. But, accounting is sleeping at the wheel, and asking to be not woken up right now is hardly useful.
Accounting, according to the G30 team, has integrity. Which, they drill down to mean these five criteria (see the doc for their definitions):
These things can be done better. Consistency and Neutrality are achieved by more and deeper automation - this is widely known.
Building on the former two, Reliability is then created by liberal dashes of crypto - sign and hash everything in site.
Once these three things are in place, Relevance and Understandability follows with public disclosure: not the sort that the accountants are thinking about - regulated, limited, formally filed reports - rather the new, open and dynamic engagement with the scrutinising public. Detail that is *outside* the regulatory environment, records that are in excess of requirements, but contribute to making a fair and open picture of a corporation.
Not, as the accountants think, by reducing the amount and simplicity of information so that the public can understand it, but, the total reverse: More quantity and more quality, so the public can ascertain for themselves what is important.
Why don't accountants think in these terms? I'd stab at this: they can't move because of the momentum of current practice and regulations. Which explains why the new trends appear in unregulated sectors such as DGCs, or previously unlisted companies such as eBay which reveals detailed statistics of its auction business.
Jeroen found this definition:
"Securities that are recorded in electronic records called book entries rather than as paper certificates."
and this one:
"a method of registering securities. There is no physical certificate. Ownership is solely reflected by an entry in the books of the issuer."
Which doesn't say much really. Still, it's their term and they get to define it. Question is, what do we call Ricardo, in contrast to "book entry securities."
In essence, Ricardo uses book entries. So do all systems of any sophistication, as book entries have gathered popularity since the 13th century invention of double entry book keeping.
Token money people - blinded bearer coins - were fond of pointing out that book entry was the problem. In a way, it was, but it wasn't that it was using books, but the inefficiencies brought in by its vague pencil & abacus approach to the whole situation. As the books were quite brief in their information, and as they were mostly updated manually, with frequent error corrections, the system can't really maintain any reliable accuracy.
RIcardo does book entry without the errors. All the information is there, and each entry only needs to be made once. Once made, it stays made. How hard is that?
However hard it was, it might not be as hard as creating a metaphor to show the difference between Ricardo and book entry securities!
At the Fed's Payment Systems conference this October, Roger W. Ferguson provided this summary to save us the trip.
Nothing much on security, but these remarks caught my attentions:
"Information integration and standards. A key point made at the conference was that large businesses, in particular, want payments system providers to understand that information about transactions (such as invoice numbers and shipping information) is critical to their use of electronic payments, for both domestic and global commerce. Many speakers identified a need for common standards to enable significant operational improvements in integrating payment and related transaction information in order to enable greater straight-through processing of electronic payments and automated reconciliation procedures."
What does this mean, in detail? Here's what I can guess at:
We have always provided an open memo field in Ricardo transactions, which could be used for any purpose, and we duplicated that in XML-X. Open XML is a possibility. And, it's within the realm of possibilities to add order numbers and other identifiers, either into the Memo, or in the actual packets.
Question is, what could be done here to make a difference? Any clues?
"A particularly important topic is how electronic payments systems can better meet the needs of business users. Business people frequently report that, from their perspective, a payment is only one part of an overall transaction or relationship with a counterparty. Other parts include orders, confirmations, shipping documents, invoices, and a variety of accounting and other information that supports a transaction or relationship. The complexity of this situation has created challenges for businesses as they integrate corporate information systems with electronic payment capabilities, and this complexity has likely slowed the adoption of electronic payments for a wide range of business purposes. I hope this conference will help underscore the need for businesses, financial institutions, technology vendors, and payments system operators to find common approaches and standards for addressing this issue."
OK, so AG is worried about "orders, confirmations, shipping documents, invoices, and a variety of accounting and other information that supports a transaction or relationship..." So there's nothing wrong with the payment, it's just everything else that is wrong?
DigiCash's eCash introduced a set of coins denominated in powers of 2. That is 1,2,4,8... This allowed the most efficient arrangement of arbitrary values, and it also means that the denomination of a coin can fit in only a byte sized integer. Quite elegant, really.
(Think about the old parable of the Chinese peasant, the chessboard and the grain of rice to see how big you can go with one just one byte. In my code I limit it to 64.)
The method I have used slightly extends the eCash method by including zero, which I believe that eCash ignored. The inclusion of zero is essential for testing purposes, as it removes the need for care and concern about the coins and the need for issuances of special currencies.
Recently, someone asked for more normal denominations as are apparent in normal national monies. There are two common sequences to my knowledge:
1, 2, 5, 10, ...
1, 2.5, 5, 10, ...
Question number 1: are there any more common sequences in use by people today?
I'm not that keen to duplicate for example the sequence of pre-decimal Sterling but it is amusing to list:
1/2, 1, 3, 6, 12
for ha'penny, penny, thrupenny bit, sixpence, shilling, and then
1, 2.5, 5, 10, 20, 21
shilling, half-crown, crown, 10-shilling, pound and finally, the guinea.
Now, once we introduce the notion of non-trivial coin sets, it is also possible to experiment. One consideration is that if one were doing an untraceable bearer token scheme, then traffic analysis occurs at the coin unit. That is, for the one person who can afford a $1,048,576 coin, he has no protection.
And, at any given coin size, there is only as much protection as the size of the pool would permit. So the obvious thing is to increase the size of the pool, by, for example, reducing the denominations. For example,
1, 5, 10, 50
Or even
1, 10, 100, 1000
The disadvantage is the larger payments and the extra signing burden, but, hey, none of my computers are doing anything right now. I'll bet your's aren't either. Why not load them up a bit?