<p>This is the new issue, the one that's causing all the trouble. You basically have two choices:</p>

<ol>
<li><p>Don't spend any of your own outputs until you're quite confident they're fully confirmed. For example, you could wait for three confirmations.</p></li>
<li><p>Be prepared to deal with this problem by monitoring your outstanding transaction chains and re-issuing any orphaned transactions with new input transaction IDs.</p></li>
</ol>

CC BY-SA 3.0
2014-02-24T01:14:49.037Z
Both solutions have their flaws. Number one implies that user will need to wait between taking actions with his wallet, which isn't the end of the world, but far from ideal. Number two is impossible to automate in my case, because I use multi signature wallets, which means user has to confirm every transaction from his wallets, so I cannot resend the tx automatically if an orphan is detected.
As I said, the best way to deal with that would be to use NTXID as an input. Any idea if that's even remotely possible in near future?
mav
CC BY-SA 3.0
2014-02-24T01:58:12.023Z
@mav Yeah, it's a real issue. Allowing NTXID to be used as an input would be a painful hard fork that would require everyone to reindex all unspent outputs. I guess another way to do it would be to have a way to specify in a transaction that this specific transaction be referenced by NTXID and still allow "legacy" transactions to be referenced by TXID. Then you could set this option in all your transactions. I don't know if the community has considered that.
David Schwartz
CC BY-SA 3.0
2014-02-25T04:02:25.960Z
@Gracchus The complexity of the transition depends on the nature of the implementation. But basically, the procedure you outlines is how you would do it.
David Schwartz
CC BY-SA 3.0
2014-05-22T14:03:07.003Z
@Gracchus, What do you mean by "abrupt"?
Pacerier
CC BY-SA 3.0
2014-05-22T14:03:42.780Z
@David, then wouldn't the whole idea of "green addresses" (accept as confirmed if coming from respected address) be rendered unusable?
Pacerier
CC BY-SA 3.0
2014-02-23T00:23:44.130Z
2014-02-23T00:23:44.130Z
David Schwartz
<p>Here is a workaround that doesn't solve the core issue but it will solve your problem.</p>

<p>Before you make the transaction check if the destination address is also an address that belongs to the same user. If so, don't create the transaction. Warn the user that the destination address belongs to him and that he cannot make this transfer.</p>

<p>This can also happen if address B belongs to another user on your site. Do the same check and make the transaction off the chain. Just update users' balances but do not create a bitcoin transaction.</p>

<p>Assuming that this scenario actually takes place in an exchange, I think you can comfortably draw the line like this.</p>

<p>Moving balances between two addresses that belong to the same user sounds like a wallet functionality. But you are running an exchange.</p>

<p>Some users might complain, but hey, better to be safe than goxed. They will understand.</p>

CC BY-SA 3.0
2014-02-26T21:59:20.653Z
I run a multi signature wallet scheme, I cannot just "update users' balances" here. It's a full-reserve, on-chain solution with much better security, but has this downside that I'll need to wait for the confirmation between every action to be safe against malleability.
mav
CC BY-SA 3.0
2014-02-27T08:10:01.377Z
I see. Sounds interesting. May I ask which site?
Emre K.
CC BY-SA 3.0
2014-02-28T09:20:02.783Z
it's called [Bitalo](https://bitalo.com). We launched last month.
mav
CC BY-SA 3.0
2014-02-25T21:27:41.633Z
2014-02-25T21:27:41.633Z
Emre K.
<p>Please note that this question is NOT a duplicate of other questions regarding <a href="/questions/tagged/transaction-malleability" class="post-tag" title="show questions tagged &#39;transaction-malleability&#39;" rel="tag">transaction-malleability</a>.</p>

<p>My question is regarding a following scenario, that could happen on an exchange that uses on-chain wallet management:</p>

<ul>
<li>user deposits funds on address A, belonging to his account on an exchange. Exchange waits <em>n</em> confirmations before it credits user account.</li>
<li>user then moves funds from address A to address B, which also belongs to his account on the same exchange. Exchange doesn't wait for any confirmations here, because the it knows it won't double-spend itself. Exchange thus notes the TXID of this transaction for future use.</li>
<li>while transaction is unconfirmed, someone exploits transaction malleability issue and pushes its tweaked version, which gets picked up by miners instead.</li>
<li>in the mean time, user wants to withdraw funds to address C, which is another exchange or external wallet. Exchange creates this transaction using TXID that it stored earlier. Unfortunately, Blockchain doesn't know this TXID because it was rejected by majority of miners. The exchange though doesn't get immediate feedback about that, because it doesn't know that a tweaked version of that transaction exists (since both are still unconfirmed)</li>
<li>in effect, funds are not withdrawn, and exchange operators are left wondering why this happened.</li>
</ul>

<p>Now the following situation has NOT happened to me (yet), but I'm wondering:</p>

<ul>
<li>is it realistic enough that it could happen, or is there something I missed?</li>
<li>how I can guard against this? For me it seems that the best fix for this would be use of the new NTXID instead of TXID in transaction inputs. But that will probably not be possible in near future, because required quite a big change in the protocol.</li>
</ul>

CC BY-SA 3.0
2014-04-23T09:03:34.857Z
For what I understand about the normalized transaction ID (NTXID), you can use it as a "helpdesk identifier" for transactions you created yourself. In your example you should also detect the changed TXID of B, to be able to use its outputs in the C transaction. The answer to how to do that: http://bitcoin.stackexchange.com/questions/24048/anti-transaction-malleability-patterns
Robert-Reinder Nederhoed
<transactions><multi-signature><transaction-malleability><transaction-id>
How can I avoid transaction malleability consequences?
mav
# How can I avoid transaction malleability consequences?

(Asked by: username_0 on 2014-02-22)

Please note that this question is NOT a duplicate of other questions regarding [transaction-malleability](/questions/tagged/transaction-malleability "show questions tagged 'transaction-malleability'").

My question is regarding a following scenario, that could happen on an exchange that uses on-chain wallet management:

* user deposits funds on address A, belonging to his account on an exchange. Exchange waits *n* confirmations before it credits user account.
* user then moves funds from address A to address B, which also belongs to his account on the same exchange. Exchange doesn't wait for any confirmations here, because the it knows it won't double-spend itself. Exchange thus notes the TXID of this transaction for future use.
* while transaction is unconfirmed, someone exploits transaction malleability issue and pushes its tweaked version, which gets picked up by miners instead.
* in the mean time, user wants to withdraw funds to address C, which is another exchange or external wallet. Exchange creates this transaction using TXID that it stored earlier. Unfortunately, Blockchain doesn't know this TXID because it was rejected by majority of miners. The exchange though doesn't get immediate feedback about that, because it doesn't know that a tweaked version of that transaction exists (since both are still unconfirmed)
* in effect, funds are not withdrawn, and exchange operators are left wondering why this happened.

Now the following situation has NOT happened to me (yet), but I'm wondering:

* is it realistic enough that it could happen, or is there something I missed?
* how I can guard against this? For me it seems that the best fix for this would be use of the new NTXID instead of TXID in transaction inputs. But that will probably not be possible in near future, because required quite a big change in the protocol.

**Tags:** transactions, multi-signature, transaction-malleability, transaction-id

> **Comments:**
> **username_1**: For what I understand about the normalized transaction ID (NTXID), you can use it as a "helpdesk identifier" for transactions you created yourself. In your example you should also detect the changed TXID of B, to be able to use its outputs in the C transaction. The answer to how to do that: http://bitcoin.stackexchange.com/questions/24048/anti-transaction-malleability-patterns  

---

## 2 answers

### Answer by username_2 on 2014-02-23. Score: 5

This is the new issue, the one that's causing all the trouble. You basically have two choices:

1. Don't spend any of your own outputs until you're quite confident they're fully confirmed. For example, you could wait for three confirmations.
2. Be prepared to deal with this problem by monitoring your outstanding transaction chains and re-issuing any orphaned transactions with new input transaction IDs.

> **Comments:**
> **username_0**: Both solutions have their flaws. Number one implies that user will need to wait between taking actions with his wallet, which isn't the end of the world, but far from ideal. Number two is impossible to automate in my case, because I use multi signature wallets, which means user has to confirm every transaction from his wallets, so I cannot resend the tx automatically if an orphan is detected. As I said, the best way to deal with that would be to use NTXID as an input. Any idea if that's even remotely possible in near future?  
> **username_2**: @username_0 Yeah, it's a real issue. Allowing NTXID to be used as an input would be a painful hard fork that would require everyone to reindex all unspent outputs. I guess another way to do it would be to have a way to specify in a transaction that this specific transaction be referenced by NTXID and still allow "legacy" transactions to be referenced by TXID. Then you could set this option in all your transactions. I don't know if the community has considered that.  
> **username_2**: @Gracchus The complexity of the transition depends on the nature of the implementation. But basically, the procedure you outlines is how you would do it.  
> **username_3**: @Gracchus, What do you mean by "abrupt"?  
> **username_3**: @username_2, then wouldn't the whole idea of "green addresses" (accept as confirmed if coming from respected address) be rendered unusable?  

---

### Answer by username_4 on 2014-02-25. Score: 1

Here is a workaround that doesn't solve the core issue but it will solve your problem.

Before you make the transaction check if the destination address is also an address that belongs to the same user. If so, don't create the transaction. Warn the user that the destination address belongs to him and that he cannot make this transfer.

This can also happen if address B belongs to another user on your site. Do the same check and make the transaction off the chain. Just update users' balances but do not create a bitcoin transaction.

Assuming that this scenario actually takes place in an exchange, I think you can comfortably draw the line like this.

Moving balances between two addresses that belong to the same user sounds like a wallet functionality. But you are running an exchange.

Some users might complain, but hey, better to be safe than goxed. They will understand.

> **Comments:**
> **username_0**: I run a multi signature wallet scheme, I cannot just "update users' balances" here. It's a full-reserve, on-chain solution with much better security, but has this downside that I'll need to wait for the confirmation between every action to be safe against malleability.  
> **username_4**: I see. Sounds interesting. May I ask which site?  
> **username_0**: it's called [Bitalo](https://bitalo.com). We launched last month.  

---

