|
Title: Look at the last merges, devs are already fixing the malleability problem Post by: Sheldor333 on February 12, 2014, 10:59:21 AM Update on Transaction Malleability
https://bitcoinfoundation.org/blog/?m=201402 Quote 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. Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: murraypaul on February 12, 2014, 11:00:35 AM 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. Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: Rannasha on February 12, 2014, 11:05:34 AM 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. Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: murraypaul on February 12, 2014, 12:46:49 PM 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? Quote 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. Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: vv01f on February 12, 2014, 04:38:51 PM 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. ;)Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: murraypaul on February 12, 2014, 04:49:22 PM 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] Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: BitCoinDream on February 12, 2014, 05:03:03 PM I think malleability problem is client dependent. Those using old clients will continue to encounter this problem.
Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: cr1776 on February 12, 2014, 05:08:14 PM 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. Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: Lauda on February 12, 2014, 05:20:37 PM Obviously the fix was urgent after the current events.
Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: Nagle on February 12, 2014, 07:15:27 PM [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. Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: murraypaul on February 12, 2014, 07:23:18 PM [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. Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: BitTrade on February 12, 2014, 10:34:57 PM [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? Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: gamecenteruk on February 12, 2014, 10:42:19 PM This problem is really serious, if the money in the wallet can not be used, the whole bitcoin is useless as well.
Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: jongameson on February 12, 2014, 10:46:27 PM if your concerned about malleability
just mine steel or mercury geez Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: Holliday on February 12, 2014, 10:54:50 PM 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. Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: meanig on February 12, 2014, 10:56:19 PM [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. Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: BitTrade on February 12, 2014, 11:33:36 PM [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 Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: 12648430 on February 13, 2014, 12:05:28 AM [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. Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: BittBurger on February 13, 2014, 04:25:55 AM 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? Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: Abdussamad on February 13, 2014, 04:30:45 AM 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. Title: Re: Look at the last merges, devs are already fixing the malleability problem Post by: Holliday on February 13, 2014, 04:36:38 AM 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. Indeed. The fear would be rushing a fix and introducing a new bug that is worse than the problem they are trying to fix. As long as you are using a proper client, you won't lose any coins to the transaction malleability issue. I'm sure they are doing what they can. Of course, the project is open source, so anyone is welcome to submit their ideas. |