Spending own generated unconfirmed change in the v.0.9.0 era

[DougPeters]

Reading about spending own generated unconfirmed change some time ago I stumbled upon this reddit thread that convinced me that doing so is a really bad idea and could prove catastrophic for any business that allows it.

Now in the bitcoin core 0.9.0 release notes there are some fixes regarding the infamous malleability issue (search for text: "Transaction malleability-related fixes").

My question is:

Is it now safe to spend unconfirmed change generated by my own txs, after the 0.9.0 upgrades?
If not, what is considered to be a safe number of confirmations for this change before I can use it as an input for another tx?

[DougPeters]

It is a bit weird that nobody has replied to this very critical question, could somebody please shed some light on this one?

[TierNolan]

They didn't fix malleability, it is still possible for transactions to be modified.

They reduced the odds of modified transactions being accepted into the block chain.

Transactions have to "canonical" to be accepted by the reference client.

If you produce a canonical transaction, then (in theory) there is no way to modify it without making it non-canonical or invalidating the signature.

The problem is that miners don't have to use the reference client.  If they wish they can accept non-canonical transactions.

Most pools run the reference client, so they will reject non-canonical transactions.  Eligius accepts non-standard transactions, but I think they reject non-canonical ones (maybe).

There is a BIP proposing a soft fork that will fix the problem (subject to certain assumptions about ECDSA).

https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki

They also changed how the wallet works.  Previously, they would spend unconfirmed change outputs.  They wait until the transactions have been confirmed before spending the change.

This could mean that you can't send money even if you have funds, since all the coins are waiting for 1 confirm.

[gmaxwell]

They didn't fix malleability, it is still possible for transactions to be modified.
They reduced the odds of modified transactions being accepted into the block chain.

Most of the changes in 0.9 related to malleability, and 100% of the changes in responses to the attacksattacks, were changes to the wallet behavior.  The wallet will not become confused now if change is mutated.  There is now a switch to disable spending unconfirmed change, but by default it still does. But, for example, it will notice as soon as change is conflicted in the chain and not try to spend it, greatly decreasing the potential disruption.

(0.9 also included the fix from last September that expanded the definition of non-canoical, but thats not really important to changing the behavior here)

could prove catastrophic for any business that allows it.

Thats pure hyperbole. The worst case consequence there was that you get transactions stuck which require technical intervention to unstick in your wallet. An annoying DOS attack but hardly "catastrophic to business".

It is a bit weird that nobody has replied to this very critical question, could somebody please shed some light on this one?

It's not weird, you asked in the wrong subform and no one who cared to answer it noticed. This should have been posted in technical support.

If you'd prefer transactions to fail when you run out of confirmed inputs instead of creating a risk of getting stuck you should set spendzeroconfchange=0 in your configuration.

[cp1]

Is it now safe to spend unconfirmed change generated by my own txs, after the 0.9.0 upgrades?
If not, what is considered to be a safe number of confirmations for this change before I can use it as an input for another tx?

It's not really a question of being safe or dangerous.  The worst that will happen is your transaction will never get confirmed.  I think the only dangerous aspect is accepting those transactions.