I ran into something the other day that shows how different the bitcoin system of accounting really is.

 It occurred to me that if we could have a very simple CREDIT system, then we could also hedge the price of BTC.  ex.  If I think BTC is going to appreciate, then I LOAN out BTC.  If I think BTC is going to depreciate, I BORROW BTC[1].  It's that simple really.  Most instruments and market functions can be derived from this basic credit device.

 So all we need to do is have a time release TX right?  as in - make a TX going out(the loan) and make another TX going in that is time dependent.  Sounds like it would work right?  problem is that you cannot SPEND the money if the TX is already created, even if it's time dependent.  Thus, I cannot cash the BTC out for USD while I have it on loan.  Thus the Bitcoin system ISN'T a system of credits and debits as accountants would expect.  It has very different qualities.  You can derive credits and debits from the basic data.  A Bitcion TX is NOT AN ACCOUNT LEDGER.  Bitcoin devs will probably read this and say: 'no duh?' - but for those coming from the accounting worldex, who expect these features will no doubt be suprised to find they dont exist here.  Bitcoin's TX structure ensures that there can never be unsettled transactions.  You can NEVER have a TX that results in 'sorry funds are not there' - simply can't happen.

 It reminds me of the common issue of managing multithreaded bank accounts: http://msdn.microsoft.com/en-us/magazine/cc817398.aspx , something tells me the thing we're looking for is related to that.  The Bitcoin system of account protects against many kinds of corruptions such as indicated in the link.  In Bitcoin the order of TX might be rearranged so the transaction flows must be explicit.  The TX structure, historically, is not coincidental it was conceived as an integral part of the system from the start.  It's mentioned in the whitepaper.
 

[1] this is what the notion INTEREST RATES are all about.  DING!

The words are not for the troll alone.  This criticism is not altogether uncommon and truthfully, 99% of the people on the planet know less than LvM does about bitcoin.
Who knows, maybe we are writing his term paper for him (or some one else reading this).  Its not horribad to rehash this criticism every once in a while.  It won't be the last time.

G.A.A.P. is an inferior "accounting protocol" in any case. The best A.A.P. would be, to quote the Geico Commercial: "So easy, a cave man could do it." I have came up with an idea of this sort:

https://bt.irlbtc.com/view/225783.msg2375477


The model above proposes eliminating the need for a separate balance sheet, income statement, and statement of cash flows. (FYI: These are three main types of financial statements prepared by accountants.) Instead of a record of transactions, a blockchain here tracks a record of income sources and their allocation. The balance sheet, income statement, and statement of cash flows can then be compiled from the blockchain using automatic software. Transactions that might occur twice every week (such as visits to various US stores) can be condensed to a single event on the blockchain, saving valuable information storage. This is made possible by the concept which I have dubbed the "Balancome Statement":


Literally everything accounting should be simple enough to work on an interface of such simplicity as I envision. This will keep the blockchain size low while still meeting the demands of businesses to do their accounting in BitCoin without adding any significant burdens. This will also be required to encourage the general public, who do not want to constantly engage in currency conversions, to solve real day-to-day financial imbalances and manage financial risk with a few clicks or taps. If we expect BitCoin to go to something like $1,000 or more per BTC (i.e. market cap of over $10 billion), we will NEED something like this.

I'm still not sure you people understand what LvM is proposing, so I will rephrase it.

Ripple.com uses what he wants instead of inputs/outputs. It also has a scripting system.
Why would they regret to use a regular ledger instead of inputs/outputs?

I don't think they will. Personally I don't think inputs/outputs are inferior enough to change it at this point.
As said, the refactor would be big, and you would need a hard fork. But I'm still missing why Satoshi didn't make it a balances ledger from the beginning.

Why is it a mistake on the part of ripple devs to substitute inputs/outputs with GAAP?

I don't see why reorgs are a problem using sequence numbers to serialize the transactions from an address.
But that makes you remember empty addresses and their sequence numbers forever to avoid replays.
If they used the hash of the last transaction from each address, you could forget about empty addresses or "destroy accounts".

By the way, unlike the OP I don't want a memo field in the chain and I know the current setup can perfectly work with accounting systems. I'm just curious about the technical arguments in favor of inputs/outputs.

About scripts...I think in Ripple they have 2 types of transactions: regular transactions and contracts; but don't take my word for it. In any case, I don't take that as a serious argument in favor of the UTXO approach.
Anything can be done with BOTH approaches if designed properly. And I don't see why contracts should be more complicated with a ledger instead of an utxo. In fact, it seems to me that the language can be of a higher level (easier to use) if you chose the ledger.

And the transaction hash provides an index useful in adding whatever additional elements are needed for the variety of ever-changing accounting standards - to the external compliance software, and outside the block chain.

It is a balance ledger.  It's a log structured database.  The reason is because you want to trust each successful miner with only a single set of modifications to the database (the TXs).  It makes sense to use a log structured database to keep track of the ledger.  Unfortunately, its a bitch to parse and distribute, prune and whatnot.  But the underlying reason is the same that this kind of DB is used for example in SSDs. 

BTW OP, does gold violate GAAP? 

A couple of hours ago I purchased a Coke bottle from a vending machine. I inserted a 2 euro coin, pressed a button, got a Coke bottle and 20 eurocent coin in change.

There was no "reason of payment" field in either the 2 euro coin or the 20 cent coin. Trust was involved, of course. And of course the transaction ends  up in some kind of a GAAP compliant ledger eventually (likely bundled into other nameless transactions).

An analoguous scenario with Bitcoin would be a vending machine that accepts Bitcoin (this one only accepts physical coins and phone calls). It's not the currency's responsibility to do the accounting. Bitcoin does something a bit like accounting but it doesn't do it because of accounting convenience, instead it does it in order to be trustless and decentralised. Because it does things like this it's actually easier to handle Bitcoin in an accounting software than physical foreign currency.

Any answers for Jtimon?