Topic: BTC violates GAAP, result a mess. - page 3. (Read 13728 times)

Because it makes good engineering sense.

Technically we have a balance sheet anyway:  the set of unspent transaction outputs (UTXO).

I'd be interested to know that as well.

Traditionally, currency systems were designed the way OP suggests.  Not sure what was the rationale for designing the transactions this way.  It's certainly irregular, but perhaps there was some kind of articulated reason somewhere.

It's certainly possible to have a TX format as OP suggests.  Not sure how you could implement complex transaction types ie. Contracts though.  It is true that it would far more efficient as far as computing balances go.

No, but it might depend on ignoring them on occasion.
The currency remains the wrong place to put this convenience.
Bitcoin AND ALL CURRENCIES are not the place to solve this problem.

The right places could be in a bitcoin wallet, the accounting software, or in the financial service provider, or in any of the volatile entities that rise and fall with the constantly changing regulatory environments in the thousands of jurisdictions worldwide.

This is not an example of a design flaw, but one of design success.  By not attempting to resolve problems outside the domain of the currency, the currency is more resilient and stable.

It also provides for the industrious Bitcoin Wallet programmers to localize wallet software that can accommodate the peculiar regulatory issues of the different constituencies.  The competitive software market can decide how to send these additional messages to each other through bitmessage, or through some other channel that satisfies the standards.

Another issue which can get complicated is the "unit of account" field.  Again it is a complicated issue for a multi-jurisdictional currency.  And it is best solved in the accounting software, not in the currency.

To make the point a more clear, GAAP may not be the prevailing standard for much longer even in the US as there is an increasing tendency to adopt the "principle-based" system of IFRS over the "rule-based" GAAP.  If compliance needed to be incorporated into the money, such a change would be less feasible.  If the US had to burn and reprint all the dollars to comply with a different standard, that would be a mess indeed.

There are many pieces to an economic ecosystem, resolving issues in the proper places helps to keep it tidy, what the OP is suggesting is a way to make it messier rather than cleaner, but it IS a problem to be addressed, just needs to be done in the right places.

Attaching message to payment is about convenience, not about GAAP compliance. Is bitcoin success depending on NOT FOLLOWING any of GAAP rules?

The simple reason is that you don't fix accounting compliance matters in the currency, you put those fixes in accounting software.
The accounting software stores all the additional fields that are important to it as a part of the transactions.
Then the small business quickbooks software, can send a payment to the larger company SAP software (which has to contend with multi-jurisdictional compliance issues) which further issues payroll in 11 different countries.

The fact that there isn't a currency that does GAAP compliance on its own may be because GAAP rules change, and currency is not meant to change, it is meant to be stable.

The surest way to get a project to fail, is to try to make that project do things that it ought not be doing.

So you simply agree that you attached message to your payment and not being able to do so would be real PITA. You could probably workaround this issue but hey, why don't just fix it?

"Another one"...
I didn't sign anything, I didn't write a reason for payment and I also didn't receive a receipt (though if I really wanted to piss off the staff I could have requested one).

The thing is not that I just handed out money randomly, what I want to highlight is that also "traditional" money does NOT in all of it's forms (especially not in it's physical, most basic incarnation!) carry all the fields and features that the OP wants Bitcoin to include.

For Ripple, which is designed much more like a transfer of value (or rather trading) system, this might be a more valid concern - Bitcoin however does not try to be a replacement for SEPA transfers but for cash. I agree that Bitcoin transfers are paperless, they are not designed to be printed on paper though. Having them "in hand" is equal to having private key(s) + internet + client to sign&broadcast transactions + UTXOs for that private key(s).

I don't see the point of forcing the payment initiator to attach a certain unique statement to a payment that helps you find this entry in your ledger that it refers to when you can make him pay to a certain unique address instead that helps you find this entry in your ledger. If it would be possible to not just get 1 bank account but a few billion bank account numbers for the price of one, I guess this would be also employed in the traditional banking payments, as you can remove a source of potential error from the user.

You are not aware what CASH is. Cash is not only bills or banknotes. Cash is every form of money (in paper, metal, wood, digital or whatever form) that you can instantaneously spend without increasing anyone's debt!

Come on, so you just silently put this bill on the bar or did you attach message to it?

Where is the "Reason of payment" field on my 10 EUR bill that I used in the bar last night to pay for a beer? How can they even do accounting if they don't know that?!

This reason for payment record is the responsibility of the compliance software.  Not the responsibility of the currency.

Easy or not, it is the wrong place to solve that problem.  Compliance regimes vary with geography, jurisdiction, and time.
The burden of them must be tied to those compliance regimes, not to the currency, even when the currency is software.
The fact that bitcoin goes further toward making compliance easy than any other currency existing, does not change where the responsibility rests.
GAAP compliance software is the place for it. 
The same is true for PCI compliance software, FINcen compliance software, and the plethora of other local and regional regulation authorities.
Not all compliance regimes are even compatible with each other.  If currencies were responsible for all compliance, a global currency would be forever impossible.

Aren't we using IFRS?

Again you stick to the classic way of bank accounts, and only accepting this strict convention.

Let me try to rephrase:

The "problem" we face is: person P buys a thing "T" from merchant M, and P initiates the payment to M.
Now M needs to know that P paid for T when the payment arrives.

Traditional solution: M has a known bank account B, P can transfer the money to this account B. But because everybody else buying from M pays to this same account, M needs additional data. As the bank account of P is not known to M, something like a "reason of tx" field is necessary to relay the information "I'm P buying T".

Bitcoin solution: When M and P make the deal, M gives P a bitcoin address A. P pays the necessary bitcoins to this address A.
DONE. No further information is needed, as this bitcoin address is unique (only used once, exactly for the reason of P buying T).
An elegant solution that covers your problem of "merchant needs to be able to know WHO payed for WHAT", and at the same time keeping some privacy (nobody can link address A to M, except P).

GAAP compliant necessities cannot be achieved by "quickbooks" or any other higher software using BTC in its present condition.
Via BTC, for example, the always needed reason of payment cannot be written and transmitted from sender to receiver.

BTC as a (normally quite simple) payment system should and easily could provide the (simple) basics needed for professional money transfers.

Instead of taking care of the primaries first, all BTC discussion is filled with and buried behind the jargon and lingo of cryptologists, i.e. logically secondary questions and other self inflicted problems. The exploding size of the blockchain could be reduced by avoiding those obviously ridiculous "changings". And completely avoided by GAAP conform carry-overs.... etc.

Is your claim that quickbooks can never be used to make payments with BTC because if quickbooks puts a reason of payment in its ledger it will somehow break bitcoin?
Or are you completely misunderstanding my proposal as being one where bitcoin is changed to accommodate GAAP rather than accounting software be expanded to accommodate bitcoin?

No, there neither is nor will ever be any GAAP compliant software for current BTC.
One simple Example: There is not even a "Reason of payment" field usable by the SENDER of money.

It's simply impossible to remedy all the deficiencies of the lowest level at higher levels.

Very, very bad that there are no financial experts explaining basics
to bloody laymen worshipping BTC with its cash/change and other nonsens like a golden calf.

It seems we agree.  There are many GAAP compliant software packages. 
These deal with the unit-of-account issues which are always needed in multi-currency systems.
There are losses in currency translations which can be similar to how it deals with bitcoin.
The "missing fields" are not the problem of bitcoin, but of the GAAP software, these fields are also missing on dollar bills.
So the GAAP software package rewrites which include bitcoin and other alternatives are going to be available sooner or later.
It is not an impossible challenge, and needs nothing added to the protocol.

I stopped reading after the first page.
Leave Bitcoin, as the protocol, as it is.
Write a new client software which implements GAAP.
Solve the trust issue in not having a full copy of the blockchain.
Profit.

Alternatively:
Create a fork which is lightweight and GAAP compatible.

I would suggest to try #1.

Ente

The GAAP criticisms are tiresome, but every problem someone has (especially if 99 different folks have it) is an opportunity.  This one is pretty big from the first-mover advantage point of view.

Programmers who make a BTC client which has exportable GAAP compliant translations in XML for quickbooks and other small and medium business software applications are going to make some fast cash.  This will also remove some barriers to adoption and make your own bitcoins worth more as more folks will want them.

The pieces of GAAP that aren't in bitcoin already can be left for the accountant to fill in in the XML or in the destination application.  Since it fills a need, it could even be a non-free client wallet addon to one of the other software packages.

Continuation from this thread: https://bitcointalksearch.org/topic/armory-discussion-thread-56424


*resisting the urge to answer something stupid*

Just a question: Would you care to explain, where the difference between the UTXO-Set, the Account-Tree (of the last proposal by bitfreak) and your "carry-overs" is?
And a polite request: Could we try to not further derail the Armory-thread, and carry on discussion about blockchain-scalability issues in the corresponding threads?