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

Posts

Merits