Topic: Armory and transaction malleability (Read 3358 times)
How does Armory try to solve the problem of transaction malleability? I've heard that Bitcoin-qt have solved it (I may be wrong)
Any plans to add an option so that unconfirmed change is not spent? There are pulls in github to add similar functionality to the QT client. The fact that Armory favors spent over unspent means it is less of an issue unless the wallet has no/few confirmed outputs. Do you agree users should have the option of disabling this potentially undesirable behavior?
My understanding of manual coin selection in Armory (in expert mode) is that only spendable (unspent Tx outputs with confirmations) can be selected. In general, coin selection in your average wallet prioritizes lower fees, so any confirmed UTXO will take priority over a zero conf. The only real use case where a client may output a zero conf txn chain is when the wallet only holds very few (usually 1) UTXOs.
The work around to this would be to have the wallet client split change into several UTXO once in a while. A fine line can be found between blockchain bloat and usability. Under these circumstances ZC chaining can be turned off by default with little disruption. We are considering adding this to Armory, although it still needs in depth discussion and reviewing.
As for services accepting ZC txn, they need to check the transaction isn't being chained off of another ZC, instead of trying to cut corners. Maleability isnt the only vector to abuse chained ZC txn.
A short term solution would be to increase fees for txns with deliberately oversized unsigned components. As long as the mining pools update to that, all mutated transactions would become invalid and reduce this vector to attackers with mining power, until the core devs figure if they want to use a hard fork solution.
The fact that Armory favors spent over unspent means it is less of an issue unless the wallet has no/few confirmed outputs.
If you mean Armory favours confirmed over unconfirmed, then so does the reference client, I believe.
roy
Any plans to add an option for users to elect to require confirmation of change before spending.
This would be lovely.
I wonder though, wouldn't this option be a bit useless as an opt-in for experts? Anyone who is aware of the issue and understands the solution would be smart enough to just avoid using unconfirmed change outputs in outgoing transactions. It seems like beginners would benefit more if you restrict their ability to make transactions that could become invalidated for reasons they do not understand, while experts should have the ability to opt-out if they know what they're doing...
As a side note, it regales me to see headlines exploding, exchanges crumbling, and core-devs bickering over commits to QT, while Alan nonchalantly mentions that Armory has been mostly resistant to malleability troubles for a year and a half. Kudos again.
Keep in mind that this makes the wallet really weird, since now you spend 0.1 BTC, and 53.87 become unspendable temporarily. That would confuse the hell out of people... thus probably should be an experts-only option.
Yes, that would be weird and confuse people, but might be less weird and less confusing than transactions with unconfirmed change inputs becoming invalid (which I assume means they would simply disappear from the wallet altogether) after a mutated transaction is accepted.
Like I said earlier on, perhaps showing the balance but giving a pop-up warning informing the user that these coins are still unconfirmed should the user attempt to spend them.
It's unfortunate to have to worry about these things, but apparently this bot which mutates transactions is going to be a regular thing on the network now, so...
I mean, I hear that the core devs are working on a fix (workaround) and I assume Armory will just piggy-back on that as usual.
Any plans to add an option for users to elect to require confirmation of change before spending.
This would be lovely.
Obviously an advanced/expert option, but I think it may relatively easy. The C++ backend supplies the UTXOs to the GUI which does the balance calculations, etc, and it currently passes all confirmed and all unconfirmed-sent-to-self UTXOs. It would be almost trivial to implement with a CLI flag, so that the app can reject all unconfirmed regardless of source. Keep in mind that this makes the wallet really weird, since now you spend 0.1 BTC, and 53.87 become unspendable temporarily. That would confuse the hell out of people... thus probably should be an experts-only option.
I'll spend a little time today looking at how easy that would be. I think it may as simple as toggling a flag in the UTXO-collection code so that isSpendable() returns false for all unconfirmed UTXOs.
Any plans to add an option for users to elect to require confirmation of change before spending.
This would be lovely.
Any plans to add an option so that unconfirmed change is not spent? There are pulls in github to add similar functionality to the QT client. The fact that Armory favors spent over unspent means it is less of an issue unless the wallet has no/few confirmed outputs. Do you agree users should have the option of disabling this potentially undesirable behavior?
That means it is immune to one of the two problems facing most clients listed here. A well earned kudo on that.
https://bitcointalksearch.org/topic/what-the-average-user-needs-to-know-about-transaction-mutability-460944
However what about the issue of breaking transactions which rely on unconfirmed change output.
Does Armory not spend unconfirmed change outputs?
Does it provide an option to require a certain number of confirmations before change outputs are unlocked for spending?
https://bitcointalksearch.org/topic/what-the-average-user-needs-to-know-about-transaction-mutability-460944
However what about the issue of breaking transactions which rely on unconfirmed change output.
Does Armory not spend unconfirmed change outputs?
Does it provide an option to require a certain number of confirmations before change outputs are unlocked for spending?
Armory follows Bitcoin-Qt on that one, in that it allows spending of unconfirmed change outputs (but not regular unconfirmed outputs), but only if there are no other coins to spend. Armory favors not spending zero-conf tx over all other criteria, and therefore will not use those change outputs if it doesn't need to. But you are correct it's possible for a subsequent transaction to spend such change.
Sorry guys, I haven't been seeing notifications on these threads, and I've been on travel so I hadn't noticed it..
Armory does not have any problems with transaction malleability.
There are no security issues with this. Armory does not rely on transaction IDs for anything except transaction comments. If the transaction ID changes out from under you, Armory will silently replace the transaction in the list, and the only thing that will be different will be TxID you see when you double-click on it.
The one problem someone might have is that if it's an outgoing transaction and you created a comment/label for it, that label will not show up on the mutated transaction. Note, that this already happens with offline transactions, because Armory doesn't know what the final comment/label will be until the signatures are added. I had actually thought about using the pre-broadcast ID to store comments to solve this problem for offline transactions. It would also solve it for mutated transactions.
When I first learned about malleability 1.5 years ago I did a review of the code and determined there was nothing to be done. When Armory sees a new transaction in the blockchain that conflicts with a zero-confirmation transaction in the memory pool, the blockchain tx wins and the conflicting mempool tx is removed. It all comes down to the fact that Armory only pays attention to TxIns and TxOuts for computing balances, etc, not TxID.
Armory does not have any problems with transaction malleability.
There are no security issues with this. Armory does not rely on transaction IDs for anything except transaction comments. If the transaction ID changes out from under you, Armory will silently replace the transaction in the list, and the only thing that will be different will be TxID you see when you double-click on it.
The one problem someone might have is that if it's an outgoing transaction and you created a comment/label for it, that label will not show up on the mutated transaction. Note, that this already happens with offline transactions, because Armory doesn't know what the final comment/label will be until the signatures are added. I had actually thought about using the pre-broadcast ID to store comments to solve this problem for offline transactions. It would also solve it for mutated transactions.
When I first learned about malleability 1.5 years ago I did a review of the code and determined there was nothing to be done. When Armory sees a new transaction in the blockchain that conflicts with a zero-confirmation transaction in the memory pool, the blockchain tx wins and the conflicting mempool tx is removed. It all comes down to the fact that Armory only pays attention to TxIns and TxOuts for computing balances, etc, not TxID.
That means it is immune to one of the two problems facing most clients listed here. A well earned kudo on that.
https://bitcointalksearch.org/topic/what-the-average-user-needs-to-know-about-transaction-mutability-460944
However what about the issue of breaking transactions which rely on unconfirmed change output.
Does Armory not spend unconfirmed change outputs?
Does it provide an option to require a certain number of confirmations before change outputs are unlocked for spending?
Sorry guys, I haven't been seeing notifications on these threads, and I've been on travel so I hadn't noticed it..
Armory does not have any problems with transaction malleability.
There are no security issues with this. Armory does not rely on transaction IDs for anything except transaction comments. If the transaction ID changes out from under you, Armory will silently replace the transaction in the list, and the only thing that will be different will be TxID you see when you double-click on it.
The one problem someone might have is that if it's an outgoing transaction and you created a comment/label for it, that label will not show up on the mutated transaction. Note, that this already happens with offline transactions, because Armory doesn't know what the final comment/label will be until the signatures are added. I had actually thought about using the pre-broadcast ID to store comments to solve this problem for offline transactions. It would also solve it for mutated transactions.
When I first learned about malleability 1.5 years ago I did a review of the code and determined there was nothing to be done. When Armory sees a new transaction in the blockchain that conflicts with a zero-confirmation transaction in the memory pool, the blockchain tx wins and the conflicting mempool tx is removed. It all comes down to the fact that Armory only pays attention to TxIns and TxOuts for computing balances, etc, not TxID.
Armory does not have any problems with transaction malleability.
There are no security issues with this. Armory does not rely on transaction IDs for anything except transaction comments. If the transaction ID changes out from under you, Armory will silently replace the transaction in the list, and the only thing that will be different will be TxID you see when you double-click on it.
The one problem someone might have is that if it's an outgoing transaction and you created a comment/label for it, that label will not show up on the mutated transaction. Note, that this already happens with offline transactions, because Armory doesn't know what the final comment/label will be until the signatures are added. I had actually thought about using the pre-broadcast ID to store comments to solve this problem for offline transactions. It would also solve it for mutated transactions.
When I first learned about malleability 1.5 years ago I did a review of the code and determined there was nothing to be done. When Armory sees a new transaction in the blockchain that conflicts with a zero-confirmation transaction in the memory pool, the blockchain tx wins and the conflicting mempool tx is removed. It all comes down to the fact that Armory only pays attention to TxIns and TxOuts for computing balances, etc, not TxID.
Well, that just means that Armory manages "mutated" transactions much better than Bitcoin-QT.
Good job, Alan!
Sorry guys, I haven't been seeing notifications on these threads, and I've been on travel so I hadn't noticed it..
Armory does not have any problems with transaction malleability.
There are no security issues with this. Armory does not rely on transaction IDs for anything except transaction comments. If the transaction ID changes out from under you, Armory will silently replace the transaction in the list, and the only thing that will be different will be TxID you see when you double-click on it.
The one problem someone might have is that if it's an outgoing transaction and you created a comment/label for it, that label will not show up on the mutated transaction. Note, that this already happens with offline transactions, because Armory doesn't know what the final comment/label will be until the signatures are added. I had actually thought about using the pre-broadcast ID to store comments to solve this problem for offline transactions. It would also solve it for mutated transactions.
When I first learned about malleability 1.5 years ago I did a review of the code and determined there was nothing to be done. When Armory sees a new transaction in the blockchain that conflicts with a zero-confirmation transaction in the memory pool, the blockchain tx wins and the conflicting mempool tx is removed. It all comes down to the fact that Armory only pays attention to TxIns and TxOuts for computing balances, etc, not TxID.
Armory does not have any problems with transaction malleability.
There are no security issues with this. Armory does not rely on transaction IDs for anything except transaction comments. If the transaction ID changes out from under you, Armory will silently replace the transaction in the list, and the only thing that will be different will be TxID you see when you double-click on it.
The one problem someone might have is that if it's an outgoing transaction and you created a comment/label for it, that label will not show up on the mutated transaction. Note, that this already happens with offline transactions, because Armory doesn't know what the final comment/label will be until the signatures are added. I had actually thought about using the pre-broadcast ID to store comments to solve this problem for offline transactions. It would also solve it for mutated transactions.
When I first learned about malleability 1.5 years ago I did a review of the code and determined there was nothing to be done. When Armory sees a new transaction in the blockchain that conflicts with a zero-confirmation transaction in the memory pool, the blockchain tx wins and the conflicting mempool tx is removed. It all comes down to the fact that Armory only pays attention to TxIns and TxOuts for computing balances, etc, not TxID.
I understand this would only be an issue if your spend transactions are close to each other (i.e. 20 minutes or so, a block or two) but still, seems like something that needs to be solved.
Not necessarily. Your wallet *might* actually get confused by the transaction that you issued having a "wrong" tx-id once it gets into the blockchain. It should not be, since even without transaction malleability you could have made a transaction using the same inputs on another computer (with a copy of the wallet), so the wallet software should (and probably does) recognize this altered transaction once it makes it into the block chain, then discard the original transaction and update the balances. I would expect that all wallets do this correctly, but my question was really if we are sure that Armory does this correctly (MtGox's wallet apparently does not).
One reason for suspect that Armory might *not* do this correctly is that there has been a bug in recent versions of Armory where a transaction vanishes once it is confirmed. A rescan fixes it. But it could potentially be a corner case triggered by the altered transactions we are now seeing in the wild.
The problem here (even with armory) is that if you send something to yourself (change, for example) armory will not lock those funds and they can be spent immediately. Since transaction references previous outputs by the tx id those transactions can become invalid. That should be fixed asap, imho - maybe the same way bitcoin-qt did it, just locking every unconfirmed output for now.
Holliday / DeathAndTaxes, thanks for the replies
Yeah I can see now how that's gonna confuse a lot of people using wallet software, even if (like me) you understand the advice to wait a handful of confirmations before 'accepting a payment'. It is hard to see (without getting into the issue of 'change') how the second transaction is kind of dependent on the first.
I understand this would only be an issue if your spend transactions are close to each other (i.e. 20 minutes or so, a block or two) but still, seems like something that needs to be solved.
Will have a read of the article you pointed at.
Yeah I can see now how that's gonna confuse a lot of people using wallet software, even if (like me) you understand the advice to wait a handful of confirmations before 'accepting a payment'. It is hard to see (without getting into the issue of 'change') how the second transaction is kind of dependent on the first.
I understand this would only be an issue if your spend transactions are close to each other (i.e. 20 minutes or so, a block or two) but still, seems like something that needs to be solved.
Will have a read of the article you pointed at.
I think I've grasped this malleability issue, but is it just me or is it really a non issue with reference to the core Bitcoin protocol?, i.e. current advise is to wait for 6 confirmations to safely assume your transaction is 'bedded in' to the block chain. The transaction IDs are different due to the 'relayer' created a second one but each input and output is identical (addresses, TXID, amounts etc), therefore only one will be accepted anyway !!
so I kinda agree with those saying this is more about the way the exchanges are working as opposed to a 'bug'.
so I kinda agree with those saying this is more about the way the exchanges are working as opposed to a 'bug'.
Let's say you have a new wallet. You've funded your wallet by sending some coins to an address using a single transaction. Now that you have a balance, you want to spend/send some coins. You send a few coins to vendor A. A little while later, you find something you want to buy at vendor B. So, you go ahead and send some coins to vendor B. Let's say there were no blocks found in the time period between your two purchases.
The coins you've sent to A were already confirmed and your wallet software allows you to send them.
The coins you've sent to B were not confirmed (they were change from the first transaction and there has been no block), yet your wallet allows you to send them anyway.
If the transaction you sent to A was changed by the bot currently attacking the network and the changed transaction is accepted in the next block, the transaction to vendor B will be invalid (never included in a block).
You won't lose any coins in the process, but some users might not understand why their second transaction was invalid.
Having unexpected things occur is not acceptable when dealing with wallet software. This is how the current version of Bitcoin-Qt works.
If you don't understand my post, here is someone with far more technical knowledge than me explaining it: https://bitcointalksearch.org/topic/what-the-average-user-needs-to-know-about-transaction-mutability-460944
I think I've grasped this malleability issue, but is it just me or is it really a non issue with reference to the core Bitcoin protocol?, i.e. current advise is to wait for 6 confirmations to safely assume your transaction is 'bedded in' to the block chain. The transaction IDs are different due to the 'relayer' created a second one but each input and output is identical (addresses, TXID, amounts etc), therefore only one will be accepted anyway !!
so I kinda agree with those saying this is more about the way the exchanges are working as opposed to a 'bug'.
so I kinda agree with those saying this is more about the way the exchanges are working as opposed to a 'bug'.
It isn't as dire as some (Gox cough cough) make it seem but it does have the potential to cause issues even for those using the reference client "as-is". Under normal conditions it might not cause a problem but one or more entity is intentionally mutating all the transactions it can and rebroadcasting the duplicates. This can cause unexpected behavior so even normal users.
More info:
https://bitcointalksearch.org/topic/what-the-average-user-needs-to-know-about-transaction-mutability-460944
I think I've grasped this malleability issue, but is it just me or is it really a non issue with reference to the core Bitcoin protocol?, i.e. current advise is to wait for 6 confirmations to safely assume your transaction is 'bedded in' to the block chain. The transaction IDs are different due to the 'relayer' created a second one but each input and output is identical (addresses, TXID, amounts etc), therefore only one will be accepted anyway !!
so I kinda agree with those saying this is more about the way the exchanges are working as opposed to a 'bug'.
so I kinda agree with those saying this is more about the way the exchanges are working as opposed to a 'bug'.
I workaround would be that Armory disallows 0-confirmation inputs even in the case when it has just created them itself. That would of cause have a negative usage impact as well. Hmmm....
I think this negative impact would be less of a negative impact than having transactions go invalid.
Saying "No" from the start is preferable to saying "Yes" then "Sorry, I was wrong".
Edit: Perhaps an error message along with "No" would be prudent, something like, "No confirmed inputs currently available, please wait for the next block before sending."
Can Armory fall victim to the problem with spending 0-confirmation change coins due to transaction malleability? It is apparently a problem i Bitcoin-Qt see http://www.reddit.com/r/Bitcoin/comments/1xj3rq/gavin_andresen_and_jeff_garzik_mt_gox_is_wrong/cfc9elc
It is the problem that has not just caused MtGox to fail, but Bitstamp has also had to suspend withdrawals due to this.
The problem is simple: You send some bitcoins and receive some change. An evil relayer modifies your transaction and relays quickly. The modified transaction still spend the same inputs and generates the same outputs, but it has a different transaction ID. You and the nodes you are connected to see the original TX id, and so does some miners. But some see the TX id of the changed transaction. Now if you wait until the transaction is confirmed, nothing bad happens - either your original tx confirms or Armory presumably sees a confirmed transaction doing exactly the same thing as you original one, and discards the original as a double spend. But if you have already spend the change from the first transaction in a second transaction, then if the modified first transaction confirms, then the second transaction is invalid since it is based on the output from an invalid transaction (the TX id is apparently used to identify the inputs).
My point is: Will Armory end up being totally confused by this (inconsistent database or something), or is this a non-issue (a part from the risk of issuing invalid transactions?).
I workaround would be that Armory disallows 0-confirmation inputs even in the case when it has just created them itself. That would of cause have a negative usage impact as well. Hmmm....
It is the problem that has not just caused MtGox to fail, but Bitstamp has also had to suspend withdrawals due to this.
The problem is simple: You send some bitcoins and receive some change. An evil relayer modifies your transaction and relays quickly. The modified transaction still spend the same inputs and generates the same outputs, but it has a different transaction ID. You and the nodes you are connected to see the original TX id, and so does some miners. But some see the TX id of the changed transaction. Now if you wait until the transaction is confirmed, nothing bad happens - either your original tx confirms or Armory presumably sees a confirmed transaction doing exactly the same thing as you original one, and discards the original as a double spend. But if you have already spend the change from the first transaction in a second transaction, then if the modified first transaction confirms, then the second transaction is invalid since it is based on the output from an invalid transaction (the TX id is apparently used to identify the inputs).
My point is: Will Armory end up being totally confused by this (inconsistent database or something), or is this a non-issue (a part from the risk of issuing invalid transactions?).
I workaround would be that Armory disallows 0-confirmation inputs even in the case when it has just created them itself. That would of cause have a negative usage impact as well. Hmmm....
Jump to: