Topic: What's the problem with getting Bitcoin compliant with GAAP??? (Read 1919 times)

In addition to this opinion (which I entirely agree with btw), is that none of these issues should be addressed by the ref.client - store the blockchain however you'd like to, mine it to calculate timestamps on transactions you're interested in. The vast majority of users don't need this functionality and probably don't even know why they don't want it.

Exactly.  GAAP is irrelevant to Bitcoin.  Unlike some currencies, Bitcoin isn't a debt-based, fractional-reserve, leveraged pseudo-money that requires fine-grained, exact time-based tracking in order to prevent fraudulent third-order effects (like that ever even worked, anyways;  high-frequency Bitcoins here we come).

You don't need to pay taxes on Bitcoin transactions.  In fact, you shouldn't.  And you shouldn't try to use Bitcoin as a means of transferring value denominated in inherently flawed, poorly-accounted-for, debt-based, fractional-reserve, fraudulently-leveraged pseudo-monies, either.

That's pretty obviously what this request is about.  And it's not even remotely in any Bitcoin users' interest to help make that possible.

This is just nuts, top down, guys-in-suits type thinking.

Shoe horning some random accounting rules into a design spec (and implementation (which will never happen anyway)) for a network protocol is just wishful thinking ... pretty misguided also imho.

NB : GAAP rules were suspended by US Treasury Secretary Timothy Geithner (Hank Paulson) for the major banks at the height of the financial markets panic in 2008 and as far as I know they haven't been re-instated (specifically look at mark-to-model rules of off-balance sheet entities of JPMorgan for example) ... perhaps there are bigger problems with GAAP than "bitcoin doesn't comply" ?

When I hear that, I hear "you should stop doing what you're doing for a year or two or three and re-implement the whole thing."

Yeah... no.  As much as that would be a fun project, I don't think that is the job of the team working on the existing reference implementation. Keeping the existing software and network running as smoothly as possible is the highest priority.

Another very high priority is working through issues that arise as alternative implementations happen (see the current thread in the development section about non-DER-encoded signatures for a good example).  An alternative implementation that has the kind of accounting that you want is a great idea-- go do it, fund it, or convince somebody else to do it.  I think genjix' libbitcoin has the "store the blockchain in a database" that you want (although last I heard he was running into performance issues with that approach).

Technically, if you want to use GAAP, Bitcoin issued 21 million coins back in 2009 and hasn't done anything since then.

I like the sound of this.  I was very surprised when I first found out that this wasn't already possible in the reference client.  

Here's the essentially the same answer as mine, but from somebody who tries to run Bitcoin business on top of Microsoft technologies:

https://bitcointalksearch.org/topic/m.1113573

Just skip to point 3).

Just clearly abstract the storage pool layers. There are two storage pools in the Satoshi client:

A) public: blockchain and peer addresses and some settings
B) private: wallet and some settings

Any, literally any well know traditional ACID database technology would be fine. Just create the free account at Oracle's OTN and download whatever suits your fancy. If you aren't a Microsoft hater then obtain access to MSDN/Bizspark/Dreamspark/Technet and use the database technologies available there.

The things that need deep and far reaching changes in the current implementation:

1) store blockchain in a database, not in a stdio/iostream file
2) blkindex is just an index, it doesn't need full transactional logging, the lightweight metadata-only logging is sufficient
3) blkindex is just an index, if there's something wrong with it,  provide a "reindex" operation, maybe as a side effect of "checkblocks/checklevel" operation
4) provide a way of obtaining sincere ledger / audit log for the transactions with multiple timestamps:
4a) true time when first seen on the p2p net
4b) true time when first seen in a block
4c) block time when seen in a block
4d) true time when some block caused a reorg and un-confirmed the transaction
4e) true time when other block reconfirmed the transaction
4f) block time when reconfirmed
4g) etc.. for each subsequent chain reorganization

The above is just a first step. The next step would be to actually integrate with any middleware:

5) get rid of "blocknotify" and support normal commit/rollback hooks supported by pretty much all distributed transactional technology, including the free Microsoft DTC.

In summary: the above isn't a "patch" or "git pull request" that can be submitted. This is a change of a mindset that would need to happen amongst the core development group. The GAAP isn't just a ruleset/certification that happens once and then you have it. It is an ongoing commitment.

What specific technology would you rather we use?

It requires extensive modification of the Satoshi client.

The upcoming v0.7 requires at least one modification less: "'blocktime' and 'timereceived' fields were added".

No matter what, the core development group is dead set against using any auditable database technology for storage, so the cost of modifications will continue to be very high.

Based on my research, bitcoins are either commodities or foreign currecy.

Companies compliant with GAAP have had both commodities & foreign currency for years....

What's the problem with getting bitcoins compliantt with GAAP???

The key there is making Bitcoin comply with GAAP (Generally Accepted Accounting Principles).

I don't see how that old thread is related.

Oooh...the hints are falling from the sky as things start to become clear.

It is in relation to this:
https://bitcointalksearch.org/topic/m.1034137