Quote from: bfever on June 09, 2013, 10:34:01 PM

Quote from: LvM on June 02, 2013, 06:00:49 PM

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:

Quote

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

Yes. I do!!!! Cheesy

And I know what I am talking about. Cheesy

Quote

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

Quote

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.