Topic: What the "average user" needs to know about Transaction Mutability - page 4. (Read 38935 times)

The situation isn't helped by the fact that the blockchain data structure is founded on the assumption of unique txids (each transaction references its inputs by their transaction hash), whereas the wire protocol cannot assume unique txids.

By the way, this is the second time bitcoin has gotten burned by this.  The first time was when a miner managed to get more than one identical coinbase transaction into the chain, breaking this assumption.

Why does Gavin keep denying that the reference implementation can't handle duplicated TXs.
This is a bold lie (see Duplicated Transaction Visibility explained by DaT).

Well, then someone who has been here longer then yesterday.
I have a payment of 0.10btc pending since yesterday.
I cannot find it in the blockchain so i hope it will correct itself.

It's just another newbie poster spreading FUD about Bitcoin.

Name:    gamecenteruk
Posts:    5
Activity:    4
Position:    Newbie

How did you lose money? Please elaborate.

I am a normal user, affected by this issue and lost money, now all bitcoin transactions should be stopped to prevent this happening, or the dead of bitcoin.

This post should be stickied, at least until the transaction malleability issue is solved.

Good job D&T, the clearest and most complete explanation of the issue I've read so far.

Thanks for this OP.  
I tried reading it, but to be honest, I don't understand all the computer lingo and code.

Thanks D&T for comprehensive explanation.
I  tried my best to read it.  To be honest, I can't say get it, but at least understand something.
In the example TX.A the user spends 0.6 and not 0.4?

That assumes the user only has a single unspent output available to spend. If a user had multiple unspent outputs they could make multiple txs each involving one or more of them while the new unconfirmed change confirms.  My current wallet has 118 unspent outputs so I wouldn't be affected as much by the more conservative version than someone who literally has received Bitcoins once ever.

The patch isn't ideal but it is better than a situation where txs "unexplainably" simply never confirm.  The long term goal should be immutable transaction ids however this is a significant challenge and it is going to take a long time.  The "fix" proposed would be temporary because doing nothing until the long term goal is reached is not viable.  Make no mistake, it isn't ideal, but it is better than what we have right now.  I also suggested that it be optional so if users want to risk broken transactions they can spend unconfirmed change outputs.  Another optional change would be to have the client create two or more change outputs when the number of discrete unspent outputs (we are talking unique outputs not necessarily value) is "low".  This would give the coin selection algorithm more options and (once confirmed) allowed the user to make multiple back to back transactions before needing to wait for a confirmation.  You can manually do this yourself (i.e. in your 1 BTC example the user could right now send 0.1 BTC to 10 different addresses in his wallet).

The original post is well written. There's another problem with the fix, though. If you can't spend unconfirmed change arising from confirmed inputs, once you've spent some money, you sometimes can't spend again until a few confirmations have been processed. There's now an option in the official QT client to enforce that rule. 

This creates operational problems for Bitcoin use. Once you've spent some Bitcoins, you may not be able to spend any more Bitcoins for tens of minutes. Whether or not you can spend depends on the denominations of Bitcoins currently in your wallet. You don't have an "account balance", you have a collection of Bitcoin items with varying denominations, and this now matters.  Explaining this to end users is going to be a problem, especially since the current user interface doesn't expose that level of detail to the user. With the "no spending unconfirmed change" rule enforced, it's going to look like this, I think:

User has 1 BTC, 0 unconfirmed, 1.0 available for spending. The 1 BTC is from a single transaction.
User spends 0.5 BTC.
User now has 0.5 BTC, 0.5 unconfirmed, 0 available for spending.
Half an hour later....
User now has 0.5 BTC, 0 unconfirmed, 0.5 available for spending.

This is not going to play well at the mall.

For a big operation with a lot of outgoing transactions, like an exchange, wallet systems may have to have something like active currency management. (This is the "we have too many twenties, and not enough fives right now" problem a retailer sometimes faces).

Anybody thinking about this?

Great posts and structured informations in this thread. Thank you DeathAndTaxes!

Thanks for this OP.  I tried reading it, but to be honest, I don't understand all the computer lingo and code    I wish I did, because I really wanted to understand what was going on today...

Reminds me of the satoshi spam issue. Thanks for clarification.

You are incorrect.  

The node will not RELAY it to other nodes but it records and shows all transactions related to your inputs or outputs that it becomes aware of.

Doesn't Bitcoin-QT reject a duplicate TX that inputs are already used by another TX the node knows about? I think getting the duplicated TX in a block is the only way to create a duplicated transaction visibility. Correct me if I am wrong.

The more permanent fix is to identify transactions by inputs and outputs, and (correctly) treat the relationship between transactions and txids as one-to-many.

That way a client could do the right thing if multiple txids appear for the same transactions: display the duplicates seen on the network at least until the transaction is unconfirmed, and optionally discard the ones that don't make it into the blockchain.

Yeah, and whoever finds the next block gets the fee, instead of you.

It simply isn't in the interest of any particular miner (or pool).  The decision about transaction inclusion is made by each miner (or pool) individually; it's not some sort of thing that the miners collectively vote on "for the common good".

Thanks. Or maybe they are counting Satoshi's. 

Still, delaying a non canonical transaction to a later block wouldn't be a problem for miners, or would it? The original transaction should be there to mine also, unless it is a transaction which actually uses the capabilities of the script format and has a good fee. But then it wouldn't be a problem to mine it.  And in the end it is in the interest of the miners when bitcoin functions well and is valued, because it increases the value of their reward.

Also the stick could be applied to keep miners that apparently prefer non canonical transactions for no valid reason and keep them from spending matured coins unless they mine them theirselves.

That's what I suggested:


I think the point is that this wasn't done when transaction mutability was first noticed, and at the moment it can't be done quickly enough to solve the problem.

PS, like your username.  And, yes, they do -- of electric sheep.  At least the androids.

The duplicates appear whenever you node learns of them.  Either when a peer relays the duplicate to your node, or when a peer relays a block containing the duplicate to your node.

It is important to understand you don't actually "pay twice".  The balance *reported* by the client may be reduced but this is a reporting issue.  It would be like if you have 100 gold bars in a vault and the auditor miscounts it as 99 or 101.  The reported balance will be incorrect, but your wealth really hasn't changed but .  The incorrect report can't change the amount of actual gold in the vault.

If the duplicates were "hidden" from display and counting (and the balance is simply counting the value of all unspent outputs) it would display correctly.