BTC violates GAAP, result a mess.

[kjj]

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.

[LvM]

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

You've gotta be kidding?

[LvM]

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!

Bitcoin != accounting system.

OK. Nobody expects or suggests a complete accounting system.
But BTC is a payment system, used to transfer money.

Or would you even deny that BTC is used to transfer money?
I was told by another "Hero" that BTC is "just money" and nothing else.
The next one just told us: "Bitcoin is in no way incompatible with GAAP."

Bitcoin can however do things (and is intended to do them!) that cannot be covered by an accounting system.

One example please, just ONE. I am almost sure, you are wrong.
Anyway. We cannot build more complex things on sand.
Might it be you have no idea how flexible and efficient GAAP really is?

In the wiki this basic notion GAAP doesn't appear at all.
https://en.bitcoin.it/w/index.php?search=GAAP&button=&title=Special%3ASearch
Conclusion: Bitcoiners know nothing about GAAP. Can be seen everywhere.

[LvM]

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.

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.

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.

See no reasoning for your daring statement, kjj.
As showed in detail using GAAP would save plenty of resources (~ 80%).
Estimated 50% just by avoiding these funny "changings", endless more using carry-overs if needed...

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.

See nothing special in Mike Hearn's so-called "contracts", namely:
Providing a deposit, Escrow, Assurance contracts, Using external state, Trading across chains, Rapidly-adjusted (micro)payments to a pre-determined party or whatever else.

All quite normal commercial transactions. Not at all hindered or restrainted by GAAP. Mike doesn't claim that himself.
On the contrary!
Mikes examples show again how difficult it might be to solve normally not at all existing "problems" with current BTC.

https://en.bitcoin.it/wiki/Contracts

[c4n10]

"Money has no earmark".  
Forgetting this old wisdom they desparately try to simulate that.

WHY

Even real cash in a real wallet is normally inseparably mixed together so that we cannot know, which bills or coins came from A or B or C. To "trace" each bill or coin would even if real cash just be nonsens.

I couldn't understand the point of your post as it seems English may not be your first language and quite a bit was incomprehensible, but I have to point out that this statement is false.

Money is earmarked. Look at the face of any denomination of dollar bill, there is a serial number which is on both the left and right side of the bill. Every dollar you earn and spend is QUITE traceable, if it weren't there would be FAR less risk involved in robbing banks and people wouldn't have to pay their taxes.

Many major criminal organizations are brought down specifically by tax evasion or the fact that the money in their possession has been traced back to a high profile robbery or they were given money by undercover agents/officers in exchange for drugs, guns, etc.. and the money with those serial numbers is found in their possession thus linking them to the illegal purchase/sale. I'm not saying these actions should be condoned, but the potential implications for governments and private entities to trace every sale, purchase and money gift are repulsive.

The idea behind bitcoin (aside from a decentralized currency which does not rely on governments or private entities like banks and the federal reserve) is that it is nobody's business but your own what you are spending your money on. Governments and private entities should not be able to track your purchases (which believe me, with cash everything you buy is tracked and recorded SOMEWHERE) nor should you be subject to taxation at every turn when buying/selling or gifting monies to another person.

In the U.S.A. we were promised no taxation without representation which essentially means that the people should not be taxed unless we have a fair say in our governmental proceedings, yet time and time again our government continues to rule against the will and desires of the masses. We are essentially living in a semi-benevolent dictatorship and we are paying out the ass (via taxes) for the luxury of living in this semi-benevolent dictatorship.

Bitcoin was created as a tool to assist in fighting back against taxation, invasion of privacy and in a way it helps to put some of the power back into the hands of the people.

[LvM]

@c4n10

I agree to your statement and esp. your political considerations.
No taxation without representation! Fine!

With Money has no earmark I remind what imho is meant with this (not?) popular saying:
the number printed on bills or where bills and coins exactly came from normally does not matter.

The Romans likewise used the slogan:
"Pecunia non olet" - Money has no smell.

In criminal and other special cases this might be different of course.
But even clearly stolen, robbed or extorted money can be acquired in good faith.
Thats the law at least since the old Romans.

BTC nevertheless tries to simulate such "earmarks" with its cash/change theatre, normally not relevant in cash and simply impossible in cashless transactions. A source of endless subsequent problems only.

[kjj]

OK. Nobody expects or suggests a complete accounting system.

Might it be you have no idea how flexible and efficient GAAP really is?

In the wiki this basic notion GAAP doesn't appear at all.
https://en.bitcoin.it/w/index.php?search=GAAP&button=&title=Special%3ASearch
Conclusion: Bitcoiners know nothing about GAAP. Can be seen everywhere.

You seem to be living under the peculiar delusion that accounting is primary, and that money exists to facilitate accounting.  However popular that delusion may be among accountants, around here, it just makes you sound silly.

I assure you that a business that wants both accounting and bitcoin can have both easily.

I'm not really sure what your argument is.  Either GAAP is flexible and can work with bitcoin, or bitcoin is incompatible with GAAP.  You can't seem to make up your mind.

Personally, I think that the profession of accounting will adapt to bitcoin just fine.  They may need to throw out some of their generally accepted principles*, the ones that make no sense in a bitcoin world, but new ones will take their place.

P.S.  In no way have you "shown" anything in your incoherent posts, far less "in detail".  If someone else has "showed in detail" your mythical ~80% savings, please feel free to point me to it.  Note also that my posts were about the technical problems with ledger-summary cryptocurrencies as compared to ledger-journal systems (like bitcoin).    If you feel that I'm wrong about them, you are free to make your own GAAPcoin and we'll see how the two systems fare in the arena.

*  Note that I make a clear division between accounting, and a body of standards that accountants use when dealing with the fiat world (GAAP).  This is not an accidental division, but an intentional one.  To argue that bitcoin is incompatible with accounting would be silly.  To argue that bitcoin must conform to present systems for accounting is just as silly.

[LvM]

I'm not really sure what your argument is.  

Yes I know that. Its always the same with you. Cannot help it. Not my fault if you cannot understand my English.

Your imputations are rigth from the beginning as clearly as possible answered.
Anyway: I am not inclined to write esp. for you the same things twice, in the end again and again.

If you have exact counter-arguments lets hear them.
Good night.

[aaaxn]

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.

This is not true. Ledger system done right provide big savings in memory, because you don't even have to store old past transactions. You can discard it after they are buried under enough blocks. See this for details https://bitcointalk.org/index.php?topic=195275.0
Furthermore there is always only single entry for each address while bitcoin can hold any amount of unspent outputs for single address.
Transactions in such system are much smaller, because you don't even have to include pubkey hashes but just offsets of account in db. I made some calculations and tx could be as small as 24 bytes + signature.

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.

Well bitcoin is more flexible only in theory. Most functionality of scripts is turned off until developers decide such scripts are nessesary and won't bloat blockchain, network etc. It's effectively not more flexible than account ledger.
Bitcoin scripts are constrained while with ledger you can make more powerful concepts because you have access to turing complete programming language and current network state. You can make complex constructs for example to make secure atomic laundry (https://bitcointalk.org/index.php?topic=195275.msg2289285#msg2289285) and much more.

[Sukrim]

It is easily possible and actually recommended to use addresses as "transaction identifiers" instead of Tx hashes - so addresses are only used once, ever. That way the UTXO set would be equal to the "addresses with balance" set.

Something that might be hard to emulate with ledger systems would be different colored coins in one single address for example:
1 cCoin Satoshi representing 1 share of ASICMINER, 1 cCoin Satoshi representing 1 share of TradeFortessBTC.
If 1 Satoshi gets transferred off now, which one was it? Currently one can loot at the outputs used, with a ledger not so much.

My understanding of accounting is that you take finalized transactions and store them in a certain format.
Bitcoin however can deal with transactions that are not finalized, might never be finalized, depend on external events to be finalized, stay in limbo until one of the participants moves, depend on several parties to collude... and that's just the current functionality that is considered standard (there's much more possible with nonstandard scripts).

It seems to me (using a maybe bad analogy) similar to complain about web sites because they are breaking typography rules developed over the centuries when typesetting books and anything else to read - there are no chapter markings, "quotes" are a misused term all over the place and a title page often is done in a way that would make Mr. Gutenberg cringe!

[aaaxn]

It is easily possible and actually recommended to use addresses as "transaction identifiers" instead of Tx hashes - so addresses are only used once, ever. That way the UTXO set would be equal to the "addresses with balance" set.

It would just cause UTXO to be spread over many addresses instead of one. It wouldn't affect number of outputs. With account ledger one person gets payment to same address and they are merged. This is source of savings.

Something that might be hard to emulate with ledger systems would be different colored coins in one single address for example:
1 cCoin Satoshi representing 1 share of ASICMINER, 1 cCoin Satoshi representing 1 share of TradeFortessBTC.
If 1 Satoshi gets transferred off now, which one was it? Currently one can loot at the outputs used, with a ledger not so much.

You just shouldn't mix different colored coins under one address. Such coins need to be separated anyway, so you wouldn't accidentally spend it. Such rule could be even enforced by network if colors are public.

[LvM]

Something that might be hard to emulate with ledger systems would be different colored coins in one single address for example:
1 cCoin Satoshi representing 1 share of ASICMINER, 1 cCoin Satoshi representing 1 share of TradeFortessBTC.
If 1 Satoshi gets transferred off now, which one was it? Currently one can loot at the outputs used, with a ledger not so much.

Foreign currency accounts

Based on GAAP foreign currency accounts could quite easily be provided by BTC if there is just one little additional field in the GAAP-conform transaction records defining the currency used in the specific transactions (USD, EUR, BTC, XRP, JPC.... whatever)

And software beeing aware not mixing different currencies.

This very, very easily implemented feature would be a GREAT advancement in a worldwide used system like BTC.
Neil Armstrong would say: "One small step for BTC, one giant leap for mankind."

[kjj]

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.

This is not true. Ledger system done right provide big savings in memory, because you don't even have to store old past transactions. You can discard it after they are buried under enough blocks. See this for details https://bitcointalk.org/index.php?topic=195275.0
Furthermore there is always only single entry for each address while bitcoin can hold any amount of unspent outputs for single address.
Transactions in such system are much smaller, because you don't even have to include pubkey hashes but just offsets of account in db. I made some calculations and tx could be as small as 24 bytes + signature.

This doesn't save as much (of anything in particular) as you'd hope.  The problem is that you are comparing the pathologically bad case of bitcoin to the pathologically good case of the alternative.

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.

Well bitcoin is more flexible only in theory. Most functionality of scripts is turned off until developers decide such scripts are nessesary and won't bloat blockchain, network etc. It's effectively not more flexible than account ledger.
Bitcoin scripts are constrained while with ledger you can make more powerful concepts because you have access to turing complete programming language and current network state. You can make complex constructs for example to make secure atomic laundry (https://bitcointalk.org/index.php?topic=195275.msg2289285#msg2289285) and much more.

This is perverse logic.  You are again comparing the worst case in one system to the best case in another.

[aaaxn]

This doesn't save as much (of anything in particular) as you'd hope.  The problem is that you are comparing the pathologically bad case of bitcoin to the pathologically good case of the alternative.

Enlighten me. Bitcoin smallest transactions are ~250 bytes. Tx signature takes ~70 bytes. With account ledger smallest transaction would take 24 + 70 = 94 bytes while tx to address not currently in db would take ~22 bytes more and be still 2x smaller than bitcoin. Average tx would probably beat bitcoin even more (no need to combine inputs)

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.

Well bitcoin is more flexible only in theory. Most functionality of scripts is turned off until developers decide such scripts are nessesary and won't bloat blockchain, network etc. It's effectively not more flexible than account ledger.
Bitcoin scripts are constrained while with ledger you can make more powerful concepts because you have access to turing complete programming language and current network state. You can make complex constructs for example to make secure atomic laundry (https://bitcointalk.org/index.php?topic=195275.msg2289285#msg2289285) and much more.

This is perverse logic.  You are again comparing the worst case in one system to the best case in another.

These were description of capabilities. No logic behind it. Programming language is more capable than scripts simple as that. Scripts are more flexible in theory but in reality they must be artificially limited to prevent abuse.

EDIT: Nice recent example of how scripts degenerated in 'convince developers your script use-case is important'
https://bitcointalk.org/index.php?topic=220273.msg2320603#msg2320603).

[LvM]

Ledger system done right provide big savings in memory, because you don't even have to store old past transactions. You can discard it after they are buried under enough blocks. See this for details https://bitcointalk.org/index.php?topic=195275.0

Carry-overs

Using balances is a very good idea, much better than current BTC.
But deleting old transfers is not GAAP-conform, therefore a bad idea.

See above about closing books and carry-overs: We start a small new database, but keep all previous transfers available in archives.

https://bitcointalk.org/index.php?topic=211835.msg2307474#msg2307474

Any BTC user should be able to read and download the archives.

Legally financial books must be kept available for at least 10 years.

[aaaxn]

Ledger system done right provide big savings in memory, because you don't even have to store old past transactions. You can discard it after they are buried under enough blocks. See this for details https://bitcointalk.org/index.php?topic=195275.0

Carry-overs

Using balances is a very good idea, much better than current BTC.
But deleting old transfers is not GAAP-conform, therefore a bad idea.

See above about closing books and carry-overs: We start a small new database, but keep all previous transfers available in archives.

https://bitcointalk.org/index.php?topic=211835.msg2307474#msg2307474

Any BTC user should be able to read and download the archives.

Legally financial books must be kept available for at least 10 years.

Anyone can keep archived transactions for how long he want (and it's validity can be checked by anyone). I think especially node should keep all history of its own addresses. Full history is just not necessary for payment processing so standard nodes would just drop it and save history logging for specialized nodes.

[kjj]

This doesn't save as much (of anything in particular) as you'd hope.  The problem is that you are comparing the pathologically bad case of bitcoin to the pathologically good case of the alternative.

Enlighten me. Bitcoin smallest transactions are ~250 bytes. Tx signature takes ~70 bytes. With account ledger smallest transaction would take 24 + 70 = 94 bytes while tx to address not currently in db would take ~22 bytes more and be still 2x smaller than bitcoin. Average tx would probably beat bitcoin even more (no need to combine inputs)

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.

Well bitcoin is more flexible only in theory. Most functionality of scripts is turned off until developers decide such scripts are nessesary and won't bloat blockchain, network etc. It's effectively not more flexible than account ledger.
Bitcoin scripts are constrained while with ledger you can make more powerful concepts because you have access to turing complete programming language and current network state. You can make complex constructs for example to make secure atomic laundry (https://bitcointalk.org/index.php?topic=195275.msg2289285#msg2289285) and much more.

This is perverse logic.  You are again comparing the worst case in one system to the best case in another.

These were description of capabilities. No logic behind it. Programming language is more capable than scripts simple as that. Scripts are more flexible in theory but in reality they must be artificially limited to prevent abuse.

EDIT: Nice recent example of how scripts degenerated in 'convince developers your script use-case is important'
https://bitcointalk.org/index.php?topic=220273.msg2320603#msg2320603).

Give me a list of your 24 bytes, and I'll give you a partial list of capabilities you've thrown away.  Without knowing your scheme, I'd guess that some subset of "secure", "useful", "decentralized" is not possible with the information you are keeping.  Most likely, you've lost at least two of those.

If we've had the scripting debate before, I'll just refer you back to that.  I'm not sure how many people there are out there that think it wise to upgrade every node in the network all at once for every new transaction type.  I thought that one was too many.

A scripting system lets everyone figure out what they need without needing any (new) help from the rest of the network.  Writing new software for each transaction does in theory, allow more transaction types, and in that sense can be more "powerful", but it just isn't going to happen in a decentralized system.  Do you also argue that no one should own a horse because a pegasus would be much better?  In this case, the horse is just a pony, but the pegasus is still not real.

[aaaxn]

Give me a list of your 24 bytes, and I'll give you a partial list of capabilities you've thrown away.  Without knowing your scheme, I'd guess that some subset of "secure", "useful", "decentralized" is not possible with the information you are keeping.  Most likely, you've lost at least two of those.

<tx type, offsetSender, offsetReceiver, senderLastMod, amount>
1 + 5 + 5 + 5 + 8 = 24
This is simple pay to address transaction. I could probable make amount field even smaller and account offsets to until there are more than 2^32 simultaneous non-zero accounts.

If we've had the scripting debate before, I'll just refer you back to that.  I'm not sure how many people there are out there that think it wise to upgrade every node in the network all at once for every new transaction type.  I thought that one was too many.

A scripting system lets everyone figure out what they need without needing any (new) help from the rest of the network.  Writing new software for each transaction does in theory, allow more transaction types, and in that sense can be more "powerful", but it just isn't going to happen in a decentralized system.  Do you also argue that no one should own a horse because a pegasus would be much better?  In this case, the horse is just a pony, but the pegasus is still not real.

Reality check:

Security, yes (including potential for denial-of-service attacks of various sorts).

But demonstrate a spiffy, compelling use of new opcodes on testnet and we'll talk about making them standard.

[TalkingAntColony]

I love when people post ways to improve BTC without trying to make it into something tangible... I'll believe an account-tracking cryptocurrency is better when I see one that is better.

[LvM]

<tx type, offsetSender, offsetReceiver, senderLastMod, amount>
1 + 5 + 5 + 5 + 8 = 24
This is simple pay to address transaction. I could probable make amount field even smaller and account offsets to until there are more than 2^32 simultaneous non-zero accounts.

aaaxn:
Please explain the transaction records you propose more detailed.

Do you agree to my proposal?

https://bitcointalk.org/index.php?topic=211835.msg2221423#msg2221423

A field for the used currency could be added
(see foreign currencies account https://bitcointalk.org/index.php?topic=211835.msg2328815#msg2328815).
A numbering is possible but not needed (due to the timestamp, which could be date+milliseconds).

Or where a distinctions?
Please do not forget. Each transaction has 2 sides: payer and receiver.

So we need for each transaction 2 records, one for the payer, one for the receiver.
The entries in the corresponding fields are just mirror-inverted.
The amounts could and should simply be: - (minus) for the payer, + (plus) for the receiver

And please forget and ignore all the stuff and nonsens kjj is writing.
Insultings are no arguments, prove only that their author does not have them .