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

Quote from: LvM on May 21, 2013, 10:46:36 AM

At first glance you cannot really believe it, BUT:
BTC indeed tries to simulate CASH for CASHLESS transactions.
Result is a mess at the lowest level.

Bitcoiners relentlessly struggle to simulate CASH of pure and genuine CASHLESS transactions, not hesitating a second to ask themselves, why this not at all understandable or even realizable intent should make ANY sense at all.

...

Instead of adding/substracting transferred amounts quite simply to/from the balance of the accounts involved...
they insinuate indeed, that they cannot but "destroy" all the money in the paying account and indeed create "new" BTC for payers and receivers assigning the "change" even to new so called "outputs". Armory does its best and provides the option to assign these "changings" to the "first input" address (whatever this exactly might be).

Obviously this "cash/change" idea also has nothing todo with technicalities like hashes, signatures, encryption, P2P db/network....
There is just NO explanation, why these confusing, time and space consuming pseudo-cash simulations exist at all.

Going to try to explain you once more with several SIMPLE ARGUMENTS why bitcoin has some of these properties you cannot seem or willing to understand.

As I already pointed out to you in another thread, the main idea behind bitcoin is that is it decentralized (= no central authority decides what is correct) and there is no trust between the nodes (a node not sticking to the rules cannot bring the system down). And this in comparison to the normal centralized banking system.

You don't seem to have a problem with what you call the technicalities of hashes, signatures and the block chain: this is indeed the first part of the bitcoin solution to the decentralized/no trust problem. It solves the problems related to deciding what is correct (= blockchain), and the prove you actually hold some coins (the signatures & hashes).

So now we come to the part where you don't understand why:

transactions are made up the way they are ("destroying" coins, "create" new coins and the "change" thingy);
there is no simple balance with adding/subtracting;
there is no "reason of payment" or "comment" field with each transaction;
bitcoin "struggles to simulate cash".

Let me start with the last point: bitcoin does not struggle to simulate cash, but it is rather the opposite: because of the solution Satoshi developed to the second part of the problems related to the decentralized/no trust problem (see below), bitcoins behave more or less like cash we know today. I think Satoshi made only the analogy to cash to help to understand this totally new form of "money".

So now the "other" problems that need to be solved when doing something decentralized with no trust.

First of all, all transactions are publicly know to everybody.
In analogy to your bank account: LvM, do you want everybody in the world to know the exact balance of your bank account, and each and every detail of every transaction you do ?
I don't think so. So that is why there is no "reason of payment" field, and there are no "accounts". Instead, there are bitcoin "addresses" that hold an amount of bitcoins.

Secondly, concurrent transactions can occur.
This is why in bitcoin there isn't a "simple" balance.
A simple example used in many programming tutorials on concurrency involves keeping track of a balance. And these examples show it is very easy to get improper balances when doing concurrent updates. In fact, you need to "lock" the balance before you start the transaction: after you get a lock on the balance, you can read it, update it and release the lock again.
Translated to bitcoin and the block chain: something is considered "correct" and "safe" when at least X blocks (X about 6) have passed since including the transaction into a block, what would mean you can only do 1 transaction every hour (on average 10 minutes between blocks). Balances are clearly not suitable.
Instead, bitcoin uses another kind of transactions: Starting point: X coins are transferred to an address A. When you want to transfer Y (Y<=X) coins from A to B, there is a transaction:

that moves all X coins (because a partial move would mean you introduce balances which are not practical, see above)
that sends Y coins to address B
if Y

This transaction scheme allows for much more concurrency (somebody can own several bitcoin addresses and/or a bitcoin address can have multiple unspent "coins"), and allows easy verification of "double spending attempts" (an output is either used/spent or unused/available).

Because of this implementation, there is some analogy with "cash": If you need to pay 30 euro and you have a 50 euro bill, you spent the 50 euro bill and get a 20 euro bill as "change".

@bfever:

Quote

Let me start with the last point: bitcoin does not struggle to simulate cash, but it is rather the opposite: because of the solution Satoshi developed to the second part of the problems related to the decentralized/no trust problem (see below),
bitcoins behave more or less like cash we know today.

OK. BTC behaves more or less like cash. But it can't since cashless.

The field "reason of payment" should be encrypted, readable by sender/receiver only.
For commercial use the sender of money (not the receiver) has to decide for what he pays.

Quote

Instead, there are bitcoin "addresses" that hold an amount of bitcoins.

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.

The enforced "changings" make things even WORSE.
Each silly hackers (like me) see at a glance: which amount was there and where it's all gone.
Enlarging the transaction sizes almost twice the "change" is nothing but eyewash.

Better to use a reliable marketplace/escrow deposit where your BTC are mixed with all others they keep for others.
Trustees seem to use their "own" addresses to send "my" (legally their) BTC to anyone else.
Public tracing of transfers from there seems impossible.

The trustee would function almost exactly like any bank
(except that fiduciary money of a trustee is not endangered by bankruptcy).

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.

Very important always to check the legal implications (place of jurisdiction etc.).
Thousands(!) lost their money trusting obscure BTC providers.

Quote

"Secondly, concurrent transactions can occur."

Yes, this is a normal problem with all banking, esp. if clients have their own networks using the same bank account for transactions.
The bank in all such cases simply refuses to accept transfers which exceed the disposable limit (balance).

Don't see why this should be very different in BTC.
Sure. In case of BTC the bank management is decentralized (P2P).
But logically its the same bank (blockchain).

Might happen, that different servers involved not yet know about transactions via other servers and the resulting balances.
But where is the problem, to ignore/delete all transactions exceeding the limit?
Seems easier to check that by the resulting balances instead of "earmarking" millions of BTC and even Satoshis as used/unused and create them "new" by simulated "changings".

In my view the main difference between BTC and normal banking is the public P2P database.
The rest (something else than transactions?) would and should allow quite normal banking procedures, making things much easier for developers and users. In the moment I cannot even try to include BTC into my applications.