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

No bitcoin balances are required. Powerful computer not required either, but lots of attack machines with good internet connections would make it more effective. Locating those machines physically closeby to the servers for Mt Gox, Bitstamp, Coinbase, BTC-e and other targeted sites would also make it more effective.

And you do need to use a copy of the bitcoin software, to send the mutated transactions out with. To make the spamming more effective, the attacker might modify the source code of the bitcoin software so that the original transaction with the original id number isn't sent to the rest of the network. Almost certainly, that was done in the case of this attack.

It affects more than just point-of-sales at brick-and-mortar stores too.  My wife purchases Gyft cards for Amazon, BR, Sephore, etc., all the time.  (I bet she's their best customer  )  Basically, she opens up gyft.com on her Mac, clicks "buy $200 Amazon gift card", then scans the QR code and pays.  She might buy a few cards in a row and then she wants to use them NOW.  The fact that Gyft transfers these cards to her instantly upon receipt of the zero-confirmation transaction is exactly what makes using bitcoin more pleasant than a credit card.  If she had to wait 10 minutes before seeing the Amazon card credited to her account, I bet she would not use Gyft (and thus bitcoin) at all.  

If we make bitcoin more annoying and slower to use, it will greatly detract from adoption.  

We need reliable zero-confirm transactions between honest participants. 

Quite true - but it doesn't change the fact this will be quite a hit for some people that assumed that 0-conf could work in certain - and useful - circumstances.

I sense that a clone of Bitcoin that just fixes the malleability issue by not allowing txid to be mutated could get a lot of publicity ATM.

My concern with this is that the customer turns off their phone or turns off their computer, and the replacement tx never gets sent.  Yet, they saw the "This invoice has been paid" message and didn't realize that it wasn't guaranteed.  I'd rather they see nothing positive until the tx is done.

But that also assumes that all tx will be mutated.  Thus there's no point to doing the first tx.  If the standard case is no mutations, it might work.

But I am deeply concerned that people will find themselves accidentally reversing paying for their doughnut, and then refusing to allow the replacement tx to go through.   i.e. They pay, turn off their device, turn it back on later, and it tells them the payment never went through, please re-type your password to re-send... "hmm, if I just don't type my password, that was a free doughnut!"

It's one of those things, that makes me feel like the empirical reliability of zero-conf tx allowed too many businesses to build services around them, which can't be supported now.  Technically, you could do an ETF from your bank to pay for your doughnut, or pay with gold flakes, but we don't because the timelines and convenience make it infeasible.  I would argue that Bitcoin should be treated somewhat the same way, and it was only a matter of time before the illusion fell apart.

Bitcoin is fantastic for a whole lot of things, but Point-of-Sale doesn't seem to be one of them.

I think either one would be fine and far superior to the wallet without warning creating a tx which it "knows" may be broken in the future.  Personally I prefer the first one only because I am "security paranoid".  The second option is more user friendly but the jump to creating and broadcasting tx automatically shouldn't be taken lightly.  Either way advanced users if they have a specific need could always disable this warning via an option in the menus (i.e. [ ] Do not warn on creating transaction with unconfirmed input).

This limitation is most likely to affect users with a small number of confirmed unspent outputs.  A way to improve the user experience would be for the client to be a little proactive about "output management".

A user who has 100 BTC as a single unspent output spends 1 BTC.  Most clients today would make that In: 100BTC, Out: 1 BTC & 99 BTC.  However if the client seeing this tx will reduce the "unspent output pool" below some safety margin would instead make it Out: 1 BTC, 49 BTC, 50 BTC.   Now once this tx confirms the user could potentially two more txs before, even being presented with the warning.

Just an idea.  It is far less critical than what I put in the OP but sometimes solving a problem means making the problem less likely to occur in the first place.

I'm not very technical, maybe this isn't the right thread to ask but the attack that is happening this week.


Could somebody tell me whether the person/group doing it need a lot of Bitcoins to pull it off or just computing power?

Interesting.  In my example (https://bitcointalksearch.org/topic/m.5113081) where the customer's donut purchase is invalidated because his coffee purchase was malled, the wallet would realize this and then send out a new transaction to remedy the situation [which may occur after the customer has left the store and without his knowledge].

So, the customer could still pay instantly, even if he has no confirmed outputs.  Provided the customer is honest (which we already need to assume), the merchant will still get paid even if the parent transaction gets malled by an attacker: the wallet just checks for malling and, if so, sends a replacement TX to fix the problem.  

It sounds to me like the way for wallets to handle this (like Armory), is to popup a warning if a user sends one transaction, and then later attempts to send a second transaction that requires unconfirmed change. 

-- If they are not spending unconfirmed change, nothing needs to be done.  User is not inconvenienced.
-- If they are, pop up a message to the effect of:


I suppose a better alternative would be to hold the key data in RAM until your tx is confirmed, and sign a new transaction with the new txid, if the first one is mutated.  Perhaps even broadcast the first one, but immediately sign and broadcast the replacement if the first one is invalidated.  I prefer the first one though (where the software just waits before doing anything), which is a bit cleaner.

In my opinion, the reliability of zero-confirm transactions has been significantly degraded.  This affects brick-and-mortar stores that are required to accept zero-confirm transactions in order to be viable (e.g., selling coffee).

Before the malleability attack, I believed that zero-confirm transactions were reliable provided the person sending them was honest, they included an appropriate fee, and that the transcation was accepted by the network [I thought that only a dishonest customer in cahoots with a nefarious miner could cheat on a zero-confirm tx].  When the network is under malleability attack, this is no longer the case if the transaction in question uses any unconfirmed outputs.  

I described a practical example of a problem that could arise at Wave Coffee here in Vancouver (they accept bitcoin via BitPay): https://bitcointalksearch.org/topic/m.5113081

I agree that we must dis-allow spending of unconfirmed change outputs by default, in order for zero-confirm transactions to be reasonably trustworthy again.

Until malleability can be eliminated, wallets will need to become smarter, ensuring that you have a good supply of confirmed coins at your disposal, by breaking up large coins when necessary.  

Where we are differing is the fact that the alternative is also quite confusing to the user.  They spend 0.3 BTC and suddently 54.3228 of their Bitcoins are unspendable.  Perhaps it's a better alternative, than the confusion you mention.  But I was also responding to people requesting the ability to optionally make unconf change unspendable, i.e. through an option in the menu or CLI argument.  That doesn't solve either problem, it just allows knowledgeable users to avoid accidentally double-spending when doing a chain of transactions, but regular users have the same problem.

At least with Armory, it already scores CoinSelection solutions spending unconfirmed-change lower than any other solutions.  Meaning, it would rather pay a fee and/or bundle extra inputs, rather than include any zero-conf UTXOs (though it will count the ZC UTXOs in your spendable balance, and it will use them if there are no other options).  Even though it may not have been necessary, I didn't care much for ZC outputs, which is why I deprioritized them so heavily.  It appears to have made Armory as resistant as possible to this problem, without inconveniencing the user (though I admit, it was kind of coincidental that I the criteria I chose happened to be the correct one to minimize the malleability issues).

It isn't a security issue it is a usability issue.  Traditional double spends require the SENDER to be malicious.  That is a rather narrow security scope.  For a duplicate tx to break a subsequent tx which uses unconfirmed change output only requires that a single third party on an anonymous global decentralized network is malicious.   That is a rather asininely large security scope.  It becomes "Are there any bad/mean people in the world right now?  If no then you are fine nobody can break your tx. If yes then your tx might break randomly".

Example
I create a tx with a hash of "A".  It send 1 BTC somewhere and 4 BTC back to me as change. A malicious user looking to just create chaos mutates it so that it has a hash of "B". For this tx there is no possibility of the payment being broken.  Either A or B will be confirmed and the receiver will get their 1 BTC. 

The problem is created when I create a second payment (tx "C") before "A" or "B" confirms and my wallet uses the change output from "A".  As far as it knows (due to relay rules) tx "B" doesn't even exist so of course it is ok to use "A" we aren't going to double spend ourselves.  This makes tx "C" dependent on tx "A" being confirmed.  If "B" confirms then "A" never will and as a result "C" never will either.

The user is honest, he is following the rules, creating a valid tx (proper fee, no spam, etc), the merchant is being safe and waiting for a confirmation, essentially both parties are doing the "right thing".  However the payment just breaks due to the actions of a third party.  Can it be resolved?  Sure delete Tx "C", create a new Tx "D" which is identical to C except it uses the change output from "B" not "A" and send again.  Now try to explain why you "randomly" need to do that sometimes to a non-technical user.

To a non-technical user it simply looks like the Bitcoin network "breaks" randomly and then you need to pay again, sometimes.  Not exactly confidence building huh.  Sometimes after you pay it will just break and then you need to pay again.  On top of that imagine you believe you paid a merchant and then they ask you to pay them again because Bitcoin broke.  It seems suspicious right?   I just makes the tx flow counter intuitive.  

Until transaction ids are immutable, allowing users to spend unconfirmed change outputs is just going to cause chaos.

Excellent definition of the real scope of the problem. I was waiting for someone to admit the problem was not only affecting custom wallets, but in fact troubled the reference implementation as well.

Cheers, Paul.

Can someone please elaborate why the unconfirmed-change-spending issue is a real problem? To me, it sounds like it may cause some users to accidentally reverse subsequent zero-confirmation transactions, and that's it.  But the community has been pretty darn vocal about telling people/merchants not to accept zero-conf tx, and there's plenty of ways to intentionally double-spend them without this bug/quirk.  It seems that this particular part of the problem is simply making it (more) painfully obvious why they shouldn't be accepting zero-conf tx.

What am I missing? 

(Of course I know there's bigger problems with transaction mutability than just spending unconf change, but that seems to be the only issue Armory currently has ... if it's a real issue)

I had no doubts that it would get done.  Reading the comments though shows it is a challenge.  Looks like a bug already exists where if you have sufficient confirmed outputs to cover the amount sent but not the amount of the fee, the fee will be paid using unconfirmed output which breaks the "fix".

Hopefully the OP helps "non programmers" to understand the issue and what to expect.

And here, for the other issue (duplicates counted in the balance)

Not necessarily.  A compliant wallet should not generate dust outputs.  It should use proper coin selection to ensure all outputs (including change) are above the dust threshold.  Any spend consolidates outputs.  Outside of niche applications it doesn't make any sense to consolidate outputs.   If you have a large number of small outputs and need to make a large spend then the tx will be larger.   If you conolidate them to avoid that then the consolidation tx will be large.  More outputs (within reason) shouldn't significantly increase transaction size.  Imagine two hypothetical wallets with 100 BTC in confirmed unspent outputs.

Unspent outputs (100 BTC total)
-----------------------
"A" 100 BTC

vs

Unspent outputs (100 BTC total)
-----------------------
"A" 1 BTC
"B" 3 BTC
"C" 3 BTC
"D" 6 BTC
"E" 7 BTC
"F" 20 BTC
"G" 25 BTC
"H" 35 BTC

If I make a withdraw of 0.8 BTC, 6.7 BTC, or 23 BTC either wallet can handle it with a single input. The second wallet would need a second input if I wanted to withdraw 50 BTC but that will not change the transaction size significantly.  I would always prefer to have the later wallet as it can handle all four hypothetical transactions without either waiting for change output to confirm or taking a risk and spending it while unconfirmed.

For a large exchange "output management" is going to be important.  Having all your funds in a single unspent output is going to kill real time transaction processing.

Having many unspent outputs in a wallet helps speed up spends, but transactions get bigger, as they contain more inputs. This may accelerate dust generation, if there's a bias in favor of never consolidating inputs. Wallets may have to become smarter about when to divide and when to consolidate inputs. The optimal strategy depends on the wallet owner's spending pattern.

This is most likely to be a problem for a commercial wallet with high traffic, such as an exchange's hot wallet.  This could impose a limit on outgoing transaction volume. (I almost hate to suggest this, because some inept exchange may use it as an excuse for withdrawal delays.)

Nice explanation D&T!

---

NO. Malleability does NOT (directly) enable one to steal coins.

In a given transaction, the inputs, outputs and amounts ARE signed by the sender. One CANNOT change that without invalidating the transaction. However one can pad additionnal data to the transaction, which results in an equally valid transaction, but with a different txid. (because the txid is the hash of the transaction). That transaction has the SAME effect that the original transaction: The "mutator" cannot take the coins.

HOWEVER, if the sender ONLY checks for txids to know if a transaction went trough, then it the mutated transaction went trough instead of the original, then it'll falsely believe that the transaction failed, and may send a new transaction. The receiver may then have recieved the money twice.

Thus one should NEVER check for txids, to verify transaction, and instead, check for inputs, outputs and amount to acertain that. Mt.Gox's software only checked for txids, and is now confused by all this mutability issue.

That's another way of saying that only the blockchain is canonical.

like Wall Street (or other) wants to send the price to the earth and make some significant purchase?