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

this system of inputs and outputs was indicated in the Satoshi whitepaper.

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.

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://bitcointalksearch.org/topic/m.2321400

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


Nope.

bfever:

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


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


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.

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.

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

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

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

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

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

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.

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

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)

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.

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.

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.

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.

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

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.

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.