Look at the last merges, devs are already fixing the malleability problem

[Sheldor333]

Update on Transaction Malleability
https://bitcoinfoundation.org/blog/?m=201402

Gavin Andresen Feb 11 2014
You may have noticed that some exchanges have temporarily suspended withdrawals and wondering what’s going on or more importantly, what’s being done about it. You can be rest assured that we have identified the issue and are collectively and collaboratively working on a solution.
Somebody (or several somebodies) is taking advantage of the transaction malleability issue and relaying mutated versions of transactions. This is exposing bugs in both the reference implementation and some exchange’s software.
We (core dev team, developers at the exchanges, and even big mining pools) are creating workarounds and fixes right now. This is a denial-of-service attack; whoever is doing this is not stealing coins, but is succeeding in preventing some transactions from confirming. It’s important to note that DoS attacks do not affect people’s bitcoin wallets or funds.
Users of the reference implementation who are bitten by this bug may see their bitcoins “tied up” in unconfirmed transactions; we need to update the software to fix that bug, so when they upgrade those coins are returned to the wallet and are available to spend again. Only users who make multiple transactions in a short period of time will be affected.
As a result, exchanges are temporarily suspending withdrawals to protect customer funds and prevent funds from being misdirected.
Thanks for your patience. Follow us @BTCFoundation for updates as we learn more and make progress.

[murraypaul]

No, they are reducing the impact of it, not fixing it.
Nothing in that quote said anything about fixing the fact that 3rd parties can modify and rebroadcast someone else's transaction.

[Rannasha]

Nothing in that quote said anything about fixing the fact that 3rd parties can modify and rebroadcast someone else's transaction.

This also isn't a real problem, since the essential elements of the transaction (inputs, outputs, amounts) can't be changed in this way.

We just need to let go of the tx-id as a bookkeeping tool.

[murraypaul]

This also isn't a real problem, since the essential elements of the transaction (inputs, outputs, amounts) can't be changed in this way.

If you were designing a system from scratch, is there any reason you would think the current behaviour of Bitcoin is desirable?

We just need to let go of the tx-id as a bookkeeping tool.

The standard response from pools and exchanges if someone complains that their payment hasn't gone through is for them to search for the transaction in the blockchain.
Up to now, people (including the reference software) have relied on the transaction id being meaningful.

[vv01f]

Up to now, people (including the reference software) have relied on the transaction id being meaningful.

There is a difference between a txid of a x-times verified transaction (in blockchain already, x>=y where y>0 (usually 6) is the security block count of the receiver) and a txid in an unverified transaction.

[murraypaul]

Up to now, people (including the reference software) have relied on the transaction id being meaningful.

There is a difference between a txid of a x-times verified transaction (in blockchain already, x>=y where y>0 (usually 6) is the security block count of the receiver) and a txid in an unverified transaction.

And people and software, including the standard client, have relied on the latter.
[Change from an unconfirmed transaction is available for immediate spend]

[BitCoinDream]

I think malleability problem is client dependent. Those using old clients will continue to encounter this problem.

[cr1776]

Up to now, people (including the reference software) have relied on the transaction id being meaningful.

There is a difference between a txid of a x-times verified transaction (in blockchain already, x>=y where y>0 (usually 6) is the security block count of the receiver) and a txid in an unverified transaction.

100% correct. Until there are sufficient confirmations, you cannot depend on it.  Even a transaction can be replaced prior to confirmation which is why confirmations matter. The reference client displays unconfirmed transactions as a user convenience since they can be altered but does not rely on transaction IDs for refunding money.

[Lauda]

Obviously the fix was urgent after the current events.

[Nagle]

[Change from an unconfirmed transaction is available for immediate spend]

Not any more.  That just changed in the QT client.

It looks like it's going to be necessary to wait for confirmations on your own change from now on.

[murraypaul]

[Change from an unconfirmed transaction is available for immediate spend]

Not any more.  That just changed in the QT client.

Yes, that is part of the change mentioned in the OP.

[BitTrade]

[Change from an unconfirmed transaction is available for immediate spend]

It looks like it's going to be necessary to wait for confirmations on your own change from now on.

This is a big deal.  If I understand correctly, an entire wallet balance will be unusable until a small outgoing transaction is confirmed?

[gamecenteruk]

This problem is really serious, if the money in the wallet can not be used, the whole bitcoin is useless as well.

[jongameson]

if your concerned about malleability
just mine steel
or mercury
geez

[Holliday]

This problem is really serious, if the money in the wallet can not be used, the whole bitcoin is useless as well.

Change will behave exactly the same way newly received coins behave now. They will be spendable after the next block is found.

Until the transaction malleability problem is fixed, this is prudent behavior.

[meanig]

[Change from an unconfirmed transaction is available for immediate spend]

It looks like it's going to be necessary to wait for confirmations on your own change from now on.

This is a big deal.  If I understand correctly, an entire wallet balance will be unusable until a small outgoing transaction is confirmed?

No it means the entire balance of the change address is unusable until confirmed. The whole wallet balance would only be unusable until confirmed if you only had a coin balance in one address (the change address). Multibit has always been like this because change was always sent back to the sending address. It hasn't done Multibit's popularity any harm.

[BitTrade]

[Change from an unconfirmed transaction is available for immediate spend]

It looks like it's going to be necessary to wait for confirmations on your own change from now on.

This is a big deal.  If I understand correctly, an entire wallet balance will be unusable until a small outgoing transaction is confirmed?

No it means the entire balance of the change address is unusable until confirmed. The whole wallet balance would only be unusable until confirmed if you only had a coin balance in one address (the change address).

I'd venture to guess most people don't have multiple addresses per wallet.. Like blockchain users who haven't generated multiple addresses

[12648430]

[Change from an unconfirmed transaction is available for immediate spend]

It looks like it's going to be necessary to wait for confirmations on your own change from now on.

This is a big deal.  If I understand correctly, an entire wallet balance will be unusable until a small outgoing transaction is confirmed?

No it means the entire balance of the change address is unusable until confirmed. The whole wallet balance would only be unusable until confirmed if you only had a coin balance in one address (the change address). Multibit has always been like this because change was always sent back to the sending address. It hasn't done Multibit's popularity any harm.

Actually, it's not the balance of the address that would be locked up, but of the specific UTXOs draw from to build the transaction. The addresses the change outputs are sent to have no bearing on what UTXOs are available.

[BittBurger]

And after all this,

can someone tell me why .... the dev team hasn't fixed it immediately?

If for no other reason than fixing the bad press?

It astounds me how slow the bitcoin dev team seems to be.  I could wrong about this, but a lot of uninformed people considered this weeks events a sign that BTC needs some fixing.

Dontcha think it might behoove us to fix the problem, just so someone can publish that it was fixed, and show how flexible and resilient Bitcoin is when something is found wrong?

Are they seriously going to do absolutely nothing to actually fix the problem?

[Abdussamad]

And after all this,

can someone tell me why .... the dev team hasn't fixed it immediately?

If for no other reason than fixing the bad press?

It astounds me how slow the bitcoin dev team seems to be.  I could wrong about this, but a lot of uninformed people considered this weeks events a sign that BTC needs some fixing.

Dontcha think it might behoove us to fix the problem, just so someone can publish that it was fixed, and show how flexible and resilient Bitcoin is when something is found wrong?

Are they seriously going to do absolutely nothing to actually fix the problem?

Probably testing the fix. A lot of money is at stake so they can't roll out a half arsed piece of software.