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

Regular users have no particular storage requirements in either system.
Miners need either the full UTXO set or the current ledger.  These are essentially the same thing, the same information.

If someone chooses to fully validate, they will need either the full transaction list since block 0, or the full transaction list since block 0.    The trust/verification tradeoff is a bit different between the two systems, but in either case, you need essentially the same data to be able to perform similar verification.

The UTXO set is somewhat larger than the summary ledger in the degenerate case where someone is willing to operate with very little verification.  But that is a single-shot savings (per node), while the summary ledger is necessarily larger than just the delta from the previous version (which is what bitcoin really boils down to) leading to higher ongoing costs.

Thank you for the summary, kjj.
An "account" could be just an address/keypair. I think there could be some reduction in storage since the last block could include a ledger with all "account balances" removing the need for the whole merkle branch until coinbase for proof of inclusion of an output. Well, this would only serve for something like trust levels (ultimate compression algorithm), since some nodes will still want to validate the whole chain from the beginning.

Also "script per account" instead of "script per output" sounds like saving, although I guess this depends greatly on "account reuse" which is discouraged for privacy and security.

I believe that this may have been discussed to death, but a I'm not sure if in the context of "trust levels". Anyway, a link to an old thread would probably help to read the most common arguments and their refutals.

Essentially, the ledger system offers no advantages (or only fictional advantages), and has a host of disadvantages.  This really has been discussed to death.  I'm not making that up to get rid of him, I just don't want to rehash the whole topic for the 99th time.

There are two main problems, and plenty others that are more subtle.

First, a ledger system provides no meaningful resources savings (no reduction in storage space, no reduction in memory usage, no reduction in network traffic, no reduction in CPU usage) because we are already very lean, meaning that our transactions are very close to the absolute minimum amount of information necessary.

Second, a ledger system is necessarily less flexible and useful.  None of Mike's contracts would work in a ledger system without adding trusted third parties.  You could regain that functionality by emulating the current scripting system with the scripts attached to disposable accounts rather than disposable transactions, but why bother?  Bitcoin puts the complexity where it belongs, in the transaction.

As for accounting, there is nothing about bitcoin that is incompatible with it.  The problem seems to come up when you try to map accounting functions to bitcoin functions based on their names.  "Transaction" means something totally different in bitcoin than it does to an accountant.  Same with "account", "balance", etc, etc.  All of the ideas are compatible, as in, you can take an accounting-account and find an analogy in bitcoin, but that analog won't be a bitcoin-account, or a bitcoin-address, it will be something else, and that something else may not be "real" in bitcoin world.

I find the whole accounting discussion to be particularly tedious because the same thing is true in the real world, and yet, no one shows up on banking forums whining that bank-accounts are not exactly the same as accounting-accounts.

If I'm understanding well, what he proposes is for the chain to maintain a ledger with pairs (address, total balance) and transactions just saying "substract X from account Y and add them to Z" instead of "spend everything in Y, X in Z and the rest back to Y". Very similar to Ripple's ledger.
This would be a huge refactor and a hardfork, but I haven't actually heard any argument or explanation why the system isn't like that from the beginning.
Saying "you don't know what we don't use GAAP because you don't know bitcoin" doesn't help.
Please, some one explain him (and me) why GAAP is worse than cash/change in any aspect.

Bitcoin != accounting system.

If you find that the software "ledger" for example violates GAAP, please feel free to call them names and whatnot. A subset of the possibilities of Bitcoin can be made GAAP compliant and I even agree that using this as a kind of "standard" way of handling things might have made it easier in the beginning. Bitcoin can however do things (and is intended to do them!) that cannot be covered by an accounting system. This is by design and won't change without good reasons. "Because accountants can't process that using GAAP" is not a good reason imho.

Just because the most used bitcoin client exposes unspent transactions spendable by a certain private key as "account" does NOT mean that this has to be an account in the sense of accounting at all!

Repent! The GAAP is nigh!

While LvM isn't half as kooky as BenRayfield (WARNING Transactions and Addresses will soon be used as high volume data storage) he is slowly getting there. I don't think that LvM will ever match the famous Mentifex, but who can really tell?

http://www.nothingisreal.com/mentifex_faq.html

Bitcoin is in no way incompatible with GAAP.  Your incorrect understanding of bitcoin appears to be incompatible.

So I admit contritely:

In BTC we indeed have to revise >1000 years old, worldwide accepted and used basic logic,
discovered btw centuries before Columbus discovered America.

But BTC is new and hence above any "old" logic?! Its just magic?!
Isn't it? Believe it or perish!
Or is "sorcerous" a better word for this new phenomenon?

Its a pity and regrettable that nobody seems able to really explain BTCs centuries overwhelming new logic,
the howto to record money transfers,
so that the rest of the world and idiots like me could at least try to understand it.

Oh, no, no.  You don't get to pull this shit.

Your ideas are nonsense because you don't have a clue what bitcoin is.  This is clearly and extensively documented in the thread I linked.

We spent days trying to teach you about bitcoin.  The problem is not your imperfect command of English.  The problem is you.  I'm not going to waste yet more time explaining what is wrong with your alleged ideas.  Refer back to the other thread to see why.

OH, YES! Not to forget!

We see here and there very very impressive and compelling arguments against GAAP.
Even if insulting me I must admit that I can't understand them.
But quite certainly I am silly and wrong.

Sorry, sorry
that my English, German and other language abilities are'nt just as perfect as dead certainly yours.

Is somehow new for me however, that imperfect use of a foreign language might be an argument.
Anyway. That seems to be the best argument to ignore arguments.
Perhaps I will use this nice feature myself in the future.
What about their authors German or Spanish abilities?

Yep its a mess

dont feed the troll?

didnt someone tell you in german section to read about bitcoin..

As it was also suggested to you in the German forum section: Please read about the inner workings and goals of Bitcoin before coming up with criticism, especially about a certain implementation like bitcoin-qt.

You can create a GAAP bitcoin client probably, but it likely won't support all features of Bitcoin. If you want a stricter set of features to implement GAAP in a cryptocurrency you're free to fork Bitcoin and present your work as an alternative currency - if it really works out well there, it is not impossible that this might be implemented in Bitcoin itself too. I do not believe that e.g. Multisig is really considered in any GAAP.

Accounting is intended to work well WITH money, not to BE money in my opinion.

I normally try really hard to understand posts when it appears that the author isn't a native English speaker, so I read this whole thing four or five times, and I still can't...

Hey, wait a minute!  Are you the same LvM from the binary map thread that was saying that there were no logical differences between bitcoin and other currencies?


I assure you that you are not the first person to suggest a scheme of balance tracking.  Hell, you probably aren't even in the first thousand.  Feel free to augment your research into cryptocurrencies by looking into why no such proposals have gone anywhere.  Hint:  It isn't because we are all just too stupid to see your brilliance.

I like this idea

Carry-overs

We see a lot of discussions and proposals regarding the ever growing BTC blockchain (BC)....

https://bitcointalk.org/index.php?topic=88208.0;all (compressed BC by Etotheipi)
https://bitcointalk.org/index.php?topic=109467.0;all (Size BC in centuries by Nebulus)   
https://bitcointalk.org/index.php?topic=152219.0;all (Solution to Never-Ending BC by spartacusrex)
https://bitcointalk.org/index.php?topic=169204.0;all (MC2 by Tacotime
https://bitcointalk.org/index.php?topic=189239.0;all (Decrit by Etlase2)
https://bitcointalk.org/index.php?topic=195275.0;all (Mini-BC by Bitfreak! + Aaan)
etc...
[EDITED above a bit, May 31, 2013]

As far I could see, they all forget the normal way to simply avoid all size problems.
So it really must be recalled that thousand year old GAAP avoid ever growing books and now databases quite simply and naturally by
"carry-overs".

Carry-overs need just ONE entry to transfer the last balance of each account into a new database,
leaving and keeping(!) all previous (thousands or millions!) transactions in an (unchangeable but readable) "archiv"
(where there can be found if really needed - normally almost never again).

These so-called "year-end closings" and "carry-overs" are done annually (and are legally prescribed).

In BTC this could be done more or less often, i.e. always if there are "too many" transactions in the database making it too large for effective usage by clients and the P2P network.

Using this everywhere -indeed worldwide!- quite normal way of all bookkeeping the actual "blockchain" could be kept
small and handy and would not be bloated ad infinitum.

In BTC we just have todo with a very small part of GAAP: with payments only.

Impossible, complete nonsens, to keep all transactions over say 5, 10, 100, 200... years in ONE always to be transferred and checked database.
But till now I saw in BTC nowhere any usable solution for this
from the very inception foreseeable issue.

For a correct and efficient GAAP-conform payment system only the (slightly changed) TRANSACTION records are needed
Details decribed above: https://bitcointalksearch.org/topic/btc-violates-gaap-result-a-mess-211835

"Blocks"

Another, but smaller problem are the "blocks" and their "miners" wanting more and more undefined (illegal?) amounts of money for transactions also.
First designed to produce new BTC the creation of blocks indeed is thought to continue forever!!
Even if all 21 Mio BTC are created.
Might be due to the present but in the long run unusable database structure,
not easy, but unavoidable to change!!

"Double spending"
btw a misleading "cash" orientated notion, praised as "The primary innovation behind bitcoin"
https://en.bitcoin.it/wiki/Introduction

better:
Spending more money you have
is simply avoided
1. by checking the balance of the account before any payment is really processed,
2. by an early reduction of the balance, i.e. before a payment is further promoted, confirmed etc.

Compared with the current logic and structure of transactions
see the TxBinaryMap, kindly provided by etotheipi in
https://en.bitcoin.it/wiki/File:TxBinaryMap.png
the time and space needed to check, execute and save transactions could be reduced by lets say 80%
Quite a lot of software and fields needed only to somehow workaround a false basic assumption could also be abandoned.

Having abolished not more or less than the "cash" simulation Bitcoin could become a well usable and understandable, quite normal money system
with the extraordinary advantage that there is no Helicopter-Bernanke and no other state governed central bank unscrupulously inflating the money expropriating its owners.

So LvM proudly declares his not at all revolutionary but basic idea to
Bitcoin Improvement Proposal BIP #1.


At Pentecost the Holy Ghost hopefully has not forgotten the bitcoiners and their "Heroes" again.

While experienced in GAAP, electronic banking/bookkeeping I understand almost nothing about the details of ECDSA pp.

But nobody can tell me, that the "cash" idea has anything todo with technical things, with security, P2P or whatever else.

Instead of all simulated "changes" we need (also due to legal reasons)
two or three additional fields within the transfer records.

Within each tx record should be the field: "Reason of transaction" or "Posting text"
and if really not yet there - a field for the balance resulting from transfers belonging to this account.

If user A has an account, a so called "address" or "public key" (pbkA)
a GAAP conform transfer record could simply look like:

Transfer FROM A:
pbkA,  to,   time, reason of Tx, amount payed,    new balance
Transfer TO A:
pbkA,  from, time, reason of Tx, amount received, new balance

The field "to/from" contains the account ("address") of the other part.
The field "time" is needed for each transfer to update the balance accordingly.

For user B sending/receiving BTC to/from A we have the same (mirror-inverted).
Same if A has another account and transfers BTC between them.

Indexed by public key and transaction time all accounts can be quickly and easily found, checked and if needed, reconstructed/recomputed within milliseconds.

That's the core and basically all we need for each user aka public key or address.
Additional technical fields might be needed for ECDSA, encryption, P2P database/network problems...
Security and anonymity remain untouched. Real privacy doesn't exist anyway.