Quote from: Rampion on February 13, 2014, 08:10:10 AM

Do you realize how confusing and frustrating can be for users to disallow spending of unconfirmed change?

Imagine you received 100 BTC and you spend 1 BTC - suddenly 99 BTC become unspendable for 5,10, 30 minutes... That's very counter intuitive and will confuse a lot many users who do not understand how the protocol works.

Wallets will need to be "smarter". A wallet knows how many unique unspent outputs it has.

So in the 100 BTC example it could spend it back to itself as 5x 20 BTC outputs. Then a user could spend 1, have 19 BTC change confirming and still have 80 BTC available to spend.

Wallets also probably need to use simpler language like: "Total balance: XXXX (available to spend: XXXX) Why is this different?" with link/popup to simple user level explanation.

A "smart wallet" can engage in output management to minimize the disruption to a user. There is no reason a tx must have 1 change output (to the protocol change is simply an output no different than the "intended" output). If anything multiple change outputs would make blockchain analysis slightlymore difficult. So when creating an outbound tx the wallet could look at its internal confirmed output pool and if it is "low" make 2 or more change outputs. How many to make would depend a lot of the amount of the change (in BTC) and the number of unspent outputs (in discrete outputs not value).

Instead of

Code:

Input[0]: Value 100 BTC

Output[0]: Value 1 BTC <- payment
Output[1]: Value 99 BTC <- change

The wallet could instead do this:

Code:

Input[0]: Value 100 BTC

Output[0]: Value 1 BTC <- payment
Output[1]: Value * BTC <- change
Output[2]: Value * BTC <- change
...
Output[n]: Value * BTC <- change

Where * is a random amount such that the sum of the change addresses is 99 BTC.

Quote

About 0-conf: for small, day by day payments they were absolutely safe. The cost to perform a double spend was simply not worth the cost of a coffee. Now, that changes, 0-conf are not safe even if the buyer is 100% honest and the cost of the product is negligible: again we cannot downplay the effect of that, it's quite serious.

It is important now with mass mutation attack going on to distinguish between:

0 confirm tx where all inputs are confirmed
vs
0 confirm tx where one or more inputs are also 0 confirm.

The former requires a race attack and malicious intent of the sender for the receiver to lose funds. So if you trust your customers, or feel only a small % of your customers would attempt an attack you are relatively safe (especially for low value, low risk purchases). The later however only requires that SOMEONE on the network mutate the prior unconfirmed transaction and that the mutated version ends up confirming. The risk profile becomes "do you trust the entire world to not mess with your money even though it is painfully easy?" In most cases that answer should be no.

In the donut shop example up thread, the customer isn't the one doing the mutating. He could be a regular customer and liked by the shopkeeper however his coffee tx gets mutated by a malicious third party. Now mutated or not the coffee tx will go through, no risk to the shop there. However if the duplicate is the one which is confirmed, then the change output used for the doughnut becomes invalid. Now through no fault of either the shopkeeper or the legit customer the donut payment will never confirm. It gets worse when you consider how confusing this will be to put the shopkeeper and the customer especially if their are "crypto-nerds".

Honestly until tx ids are immutable the use of unconfirmed change outputs is just going to cause mass chaos. The long term goal should be immutable tx ids but lets be honest that is probably a six to nine month project. It will most likely require a hard fork of the protocol and there is simply no fast and easy way to do that. So in the immediate future transactions are mutable (even by third parties) and that means unconfirmed change can be broken by a malicious third party. For the record the "DDOS attack" against exchanges involves this aspect of mutable transactions.

I would also point out how nuanced this conversation is. Now imagine someone who has a "user level" knowledge of Bitcoin. Many people have no idea that Bitcoin works on the concepts of inputs and outputs. Their knowledge is no deeper than the "abstraction" of wallet balances. Now that is fine, the job of good software is to abstract a very complex system into a simple concept. It isn't the user's fault that they don't know the inner workings, however you can't even start to explain the problem, until you explain how Bitcoin "really works". That simply isn't a viable scenario for non-enthusiasts. Case in point my need for a side note here: https://bitcointalk.org/index.php?topic=460944.0