BTC violates GAAP, result a mess.

[jgarzik]

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.

Because it makes good engineering sense.

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

[aaaxn]

Because it makes good engineering sense.

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

It certainly does not make engineering sense for payment system to keep track of non-necessary information about UXTO when all user care about is account balance. So please elaborate.

[Sukrim]

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?

On the contrary, forcing me to write "I, [name here], used this bill to pay for a beer in the evening of the 8th of June 2013 in the pub named [insert name]" on each and every bill I use would be a PITA.
The bar will either just have an internal receipt system where the barkeeper enters my purchase + note or even just do a total "We had xxx EUR before opening, we have XXXXX EUR after closing" calculation. Why should I as customer be exposed to their accounting practices? It's in my best interest to consume alcohol an NOT fill out forms or attach messages to my payments!

Also the payment of the change money (coins...) I received back should have come with a "message" - again, I didn't need or want that, as it was and still is simply not possible and also not necessary to follow GAAP in these kind of cash transactions.

If one simply follows recommended usage patterns in Bitcoin and uses each address exactly once, these addresses itself become the "messages" or identifiers for each and every transaction. Also it is not necessary to know where money actually came from (outside of KYC territory) to do proper accounting of it. I still don't see the issue where you cannot do proper accounting with Bitcoins. Just because the internal lingo is a bit off (imagine "account" as a bunch of addresses instead of a single one and you're golden) does not mean that this system is doomed, badly engineered or completely impossible to use in accounting.

[aaaxn]

On the contrary, forcing me to write "I, [name here], used this bill to pay for a beer in the evening of the 8th of June 2013 in the pub named [insert name]" on each and every bill I use would be a PITA.
The bar will either just have an internal receipt system where the barkeeper enters my purchase + note or even just do a total "We had xxx EUR before opening, we have XXXXX EUR after closing" calculation. Why should I as customer be exposed to their accounting practices? It's in my best interest to consume alcohol an NOT fill out forms or attach messages to my payments!

Also the payment of the change money (coins...) I received back should have come with a "message" - again, I didn't need or want that, as it was and still is simply not possible and also not necessary to follow GAAP in these kind of cash transactions.

If one simply follows recommended usage patterns in Bitcoin and uses each address exactly once, these addresses itself become the "messages" or identifiers for each and every transaction. Also it is not necessary to know where money actually came from (outside of KYC territory) to do proper accounting of it. I still don't see the issue where you cannot do proper accounting with Bitcoins. Just because the internal lingo is a bit off (imagine "account" as a bunch of addresses instead of a single one and you're golden) does not mean that this system is doomed, badly engineered or completely impossible to use in accounting.

You are totally missing the point. Your money and change comes with message. You don't need to write it down of course. You can say it. YOu can point your finger to beer, whatever. Person to person contact is inherent feature of cash and that is why you don't need to write message on notes. You always see person you trade with. It is part of 'cash protocol'. Bitcoin is different and without ability to attach message it is similiar to making cash transaction without ability to see or communicate with other side

[bluemeanie1]

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.

Because it makes good engineering sense.

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

Jeff, thanks for the response.

Was there some kind of recorded discussion about why it was done this way?

yes we have the set of UTXOs, but the entire chain must be traversed in order to compute this set!  Thus computation issues are built into the system.  If you were to have a tx format like OP suggests, you could eliminate much of the computation(to find a balance, you just find the last tx with account X as destination).

Of course I really don't know how you could implement the scripting system with this.

[bluemeanie1]

On the contrary, forcing me to write "I, [name here], used this bill to pay for a beer in the evening of the 8th of June 2013 in the pub named [insert name]" on each and every bill I use would be a PITA.
The bar will either just have an internal receipt system where the barkeeper enters my purchase + note or even just do a total "We had xxx EUR before opening, we have XXXXX EUR after closing" calculation. Why should I as customer be exposed to their accounting practices? It's in my best interest to consume alcohol an NOT fill out forms or attach messages to my payments!

Also the payment of the change money (coins...) I received back should have come with a "message" - again, I didn't need or want that, as it was and still is simply not possible and also not necessary to follow GAAP in these kind of cash transactions.

If one simply follows recommended usage patterns in Bitcoin and uses each address exactly once, these addresses itself become the "messages" or identifiers for each and every transaction. Also it is not necessary to know where money actually came from (outside of KYC territory) to do proper accounting of it. I still don't see the issue where you cannot do proper accounting with Bitcoins. Just because the internal lingo is a bit off (imagine "account" as a bunch of addresses instead of a single one and you're golden) does not mean that this system is doomed, badly engineered or completely impossible to use in accounting.

You are totally missing the point. Your money and change comes with message. You don't need to write it down of course. You can say it. YOu can point your finger to beer, whatever. Person to person contact is inherent feature of cash and that is why you don't need to write message on notes. You always see person you trade with. It is part of 'cash protocol'

you can do something like this with Bitcoin, simply by embedding a hash of your message(or the message itself if brief enough) in the script field.

[NewLiberty]

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?

On the contrary, forcing me to write "I, [name here], used this bill to pay for a beer in the evening of the 8th of June 2013 in the pub named [insert name]" on each and every bill I use would be a PITA.
The bar will either just have an internal receipt system where the barkeeper enters my purchase + note or even just do a total "We had xxx EUR before opening, we have XXXXX EUR after closing" calculation. Why should I as customer be exposed to their accounting practices? It's in my best interest to consume alcohol an NOT fill out forms or attach messages to my payments!

Also the payment of the change money (coins...) I received back should have come with a "message" - again, I didn't need or want that, as it was and still is simply not possible and also not necessary to follow GAAP in these kind of cash transactions.

If one simply follows recommended usage patterns in Bitcoin and uses each address exactly once, these addresses itself become the "messages" or identifiers for each and every transaction. Also it is not necessary to know where money actually came from (outside of KYC territory) to do proper accounting of it. I still don't see the issue where you cannot do proper accounting with Bitcoins. Just because the internal lingo is a bit off (imagine "account" as a bunch of addresses instead of a single one and you're golden) does not mean that this system is doomed, badly engineered or completely impossible to use in accounting.

Right!
And then the wallet software or cash register or accounting package can be used to assign whichever variables the particular regulatory regime requires at the time.

[jgarzik]

yes we have the set of UTXOs, but the entire chain must be traversed in order to compute this set!  Thus computation issues are built into the system.  If you were to have a tx format like OP suggests, you could eliminate much of the computation(to find a balance, you just find the last tx with account X as destination).

Without the current design, you cannot have a zero trust system.

Most efficient designs are of course possible, but decrease trust.  SPV is an example.

[aaaxn]

If one simply follows recommended usage patterns in Bitcoin and uses each address exactly once, these addresses itself become the "messages" or identifiers for each and every transaction. Also it is not necessary to know where money actually came from (outside of KYC territory) to do proper accounting of it. I still don't see the issue where you cannot do proper accounting with Bitcoins. Just because the internal lingo is a bit off (imagine "account" as a bunch of addresses instead of a single one and you're golden) does not mean that this system is doomed, badly engineered or completely impossible to use in accounting.

And who says system is doomed or makes accounting impossible? It is just inconvenient and require a lot of work to do simplest thing. I don't understand why one have to defend every little bitcoin feature. Even one that are just byproducts of system design (attaching messages to txns is disabled because it would overload network and bloat blockchain)

[NewLiberty]

On the contrary, forcing me to write "I, [name here], used this bill to pay for a beer in the evening of the 8th of June 2013 in the pub named [insert name]" on each and every bill I use would be a PITA.
The bar will either just have an internal receipt system where the barkeeper enters my purchase + note or even just do a total "We had xxx EUR before opening, we have XXXXX EUR after closing" calculation. Why should I as customer be exposed to their accounting practices? It's in my best interest to consume alcohol an NOT fill out forms or attach messages to my payments!

Also the payment of the change money (coins...) I received back should have come with a "message" - again, I didn't need or want that, as it was and still is simply not possible and also not necessary to follow GAAP in these kind of cash transactions.

If one simply follows recommended usage patterns in Bitcoin and uses each address exactly once, these addresses itself become the "messages" or identifiers for each and every transaction. Also it is not necessary to know where money actually came from (outside of KYC territory) to do proper accounting of it. I still don't see the issue where you cannot do proper accounting with Bitcoins. Just because the internal lingo is a bit off (imagine "account" as a bunch of addresses instead of a single one and you're golden) does not mean that this system is doomed, badly engineered or completely impossible to use in accounting.

You are totally missing the point. Your money and change comes with message. You don't need to write it down of course. You can say it. YOu can point your finger to beer, whatever. Person to person contact is inherent feature of cash and that is why you don't need to write message on notes. You always see person you trade with. It is part of 'cash protocol'. Bitcoin is different and without ability to attach message it is similiar to making cash transaction without ability to see or communicate with other side

Right.  Why confuse the money with a "payment system"?
When you send money online with your bank, you can add all sorts of information to it that are not a part of the money.  They are a part of the payment system.

It isn't the issue for Bitcoin, it is the issue for the Bitcoin payment system, which includes wallet software and accounting packages and etc

[aaaxn]

Without the current design, you cannot have a zero trust system.

Most efficient designs are of course possible, but decrease trust.  SPV is an example.

Wow, it's really powerful statement and really questionable. I hope it comes with formal proof
Blockchain system can secure almost any underlying data structure (think of namecoin) and I don't see why it cannot be account ledger.

[jgarzik]

Without the current design, you cannot have a zero trust system.

Most efficient designs are of course possible, but decrease trust.  SPV is an example.

Wow, it's really powerful statement and really questionable. I hope it comes with formal proof
Blockchain system can secure almost any underlying data structure (think of namecoin) and I don't see why it cannot be account ledger.

You snipped the relevant, quoted context for the response given.

The entire transaction history is required for a zero trust system.

[bluemeanie1]

Without the current design, you cannot have a zero trust system.

Most efficient designs are of course possible, but decrease trust.  SPV is an example.

Wow, it's really powerful statement and really questionable. I hope it comes with formal proof
Blockchain system can secure almost any underlying data structure (think of namecoin) and I don't see why it cannot be account ledger.

this is true.

however what makes Bitcoin unique is the 'mining' aspect.  So you need a way to enforce this economy of transaction processing.

I recently developed an alternative, but it's not 'zero trust', it's more 'many trust'.  In other words the block chain depends on trusting many parties not to collude.  This kind of scenario is implicit in many financial schema, ie. Digital Gold Currencies, Community Currencies, etc.

https://docs.google.com/file/d/0BwUFHE6KYsM0ZkxLVmFwbXQ3ck0/edit?usp=sharing

https://github.com/BlueMeanie/ConfidenceChainsSimulation/wiki/Features

I don't think a 'zero trust' currency actually exists.  It will appear to exist up until the time someone exploits it.  For instance Bitcoin trust model is very robust, but we must trust that someone doesn't overload the system with computing power(51% attack).

[bluemeanie1]

Without the current design, you cannot have a zero trust system.

Most efficient designs are of course possible, but decrease trust.  SPV is an example.

Wow, it's really powerful statement and really questionable. I hope it comes with formal proof
Blockchain system can secure almost any underlying data structure (think of namecoin) and I don't see why it cannot be account ledger.

You snipped the relevant, quoted context for the response given.

The entire transaction history is required for a zero trust system.

Hi Jeff,

you can have the entire transaction history while adhering to the suggestions of OP.  It would just be more efficient to compute the account balances.  You might lose something though, perhaps you know? 

-bm

[NewLiberty]

Jeff, thanks for the response.

Was there some kind of recorded discussion about why it was done this way?

I remember the discussion from about 8 years ago.  Recording was specifically prohibited during the discussion.  The reasons for that may be obvious.

[aaaxn]

You snipped the relevant, quoted context for the response given.

The entire transaction history is required for a zero trust system.

Bitcoin blockchain has hardcoded checkpoints, which means earlier blocks can never be changed. if bitcoin used account ledger instead of uxto list, all transactions before checkpoint could be forgotten without reducing security.

[LvM]

Thats the main problem.
Your "addresses" in my view are accounts with just one turnover only.
The question is: why only one?
To hide transfers and balances this way cannot be very successful, since all public.

But in this case an (encrypted) field "reason of tx" is definitely necessary for commercial usage.
A merchant and his computers not able to know WHO payed him for WHAT cannot use BTC.

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).

bfever:

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

Yes. I do!!!!
And I know what I am talking about.

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).

Yes, fine.
Difficult and strange enough, but might work in this very simple example
THOUGH any legal caveats, exceptions, conditions, reservations cannot be articulated by the sender (P). 

Commercially we have quite a lot of additional legal and practical problems with the (useless*) workaround of changing addresses.

Example:
If customer P has to pay -due to different contracts- more than one bill for things like T1,T2..Tx he has to get from M more than one address A,B,C,D... to be used for his 10 or 20 payments. Might be a bit difficult for a normal customer to use for each invoice another address, esp. if he does not want to pay a special bill. If P on the other hand wants to pay the sum of all bills by ONE transfer problems arise on both sides.

Our merchant M might have hundreds or thousands different customers daily. So he has to produce and transmit hundreds, thousands special addresses to his customers.... Even with perfectly integrated QR-Codes this is not just fun.

In normal life we register the bank accounts of all our customers/merchants just once in our accounting system.
Bank accounts of merchants are printed on each letter/invoice.

With current BTC you have to change thousands of these entries ("addresses") daily.
Even for the same customer buying several things in different contracts.

Result is an error-prone MESS with daily thousand probabilities of errors.
Imagine that a customer/merchant might use in any case the wrong address.
How can that be repaired?

All this hide-and-seek behind different addresses only to avoid a simple field reason of payment !?

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).

Privacy is NOT guaranteed by this not very elegant but cumbersome way since all public.
All customers even know the NAME of the receiver and can check what their merchant M is doing with the money received. All customers can (and legally may?) publish their knowledge in the internet.
Result: the whole world, esp. all competitors can check it regardless of all the addresses used.

Better we forget complicated and eyewashing ideas producing error-prone workload and problems only.

Not to speak of the other problems BTC is producing with its current concept  -
easily avoided by simplest GAAP needed and used for each payment system in the world.

[LvM]

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.

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

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

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.

=====================================

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

As already said:
That's impossible with current BTC since there is no such record/field to use.

But very interesting indeed to see how you or anybody else can produce a software, able to write into a not existing BTC field.
lol
If the field is provided any software could do that, of course.

Not the responsibility of the currency.

Also already said:
A "currency" is "responsible" for nothing.

BTC is a payment system not just a currency.

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

Money which cannot be transferred is useless.

Compliance regimes vary with geography, jurisdiction, and time.

Nope.

[LvM]

One simple Example: There is not even a "Reason of payment" field usable by the SENDER of money.

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?!

Paying your beer or anything else with cash is ALWAYS accompanied by an explicit or implicit reason of payment.

You just said it yourself (YOU payed "for a beer").

BTC molesting the complete net with its clumsy, useless, really infantile "Cash/Change" simulations
simply forgot this simple, obvious and most important FACT.

btw: Asked you a few questions you did not answer.
https://bitcointalk.org/index.php?topic=211835.msg2321400#msg2321400

[LvM]

BTC indeed tries to simulate CASH for CASHLESS transactions.

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!

Call it as you like. The "cash/change" simulation is not my idea.

btw:
Debts and claims as juridical things have nothing todo with the relative items claimed or debted.
Apples and a claim or debt of apples are quite different things.

With money and anything else its exactly the same.
Money is money and an apple an apple. Not a "debt" as sometimes insinuated.