<p>Lower the confirmation.
The security reports are specific, 1 confirmation is not safe. 2 confirmations is considered 'safe'. More is considered 'safe'.
You can "rock'n roll" with 2 confirmation.
MtGox died the epic death because their custom made wallet was accepting coins after just 1 confirmation</p>

CC BY-SA 3.0
2014-10-28T14:34:56.803Z
2014-10-28T14:34:56.803Z
dooode
<p>I'm currently working on some Bitcoin code and whilst I'm hoping I've covered my bases, I wanted to check the implementation theory.</p>

<p>If I understand the malleable bug it's basically...
You create a transaction address for the transaction to take place on.  At this point a transaction id is created (txid)</p>

<p>The txid is changed before the transaction is complete on the network, creating a second txid, that the transaction will eventually be completed/confirmed/verified on.</p>

<p>So if that is correct (please correct me if I'm wrong)...</p>

<p>A script/program transferring coins to somebody should work something like this:</p>

<p>A transaction address is created and given to the payee to transfer the requested balance to.
That transaction address is checked periodically for number of confirmations.  When the transaction address receives 6 or more confirmations it can be considered as completed.</p>

<p>Is there a better/quicker/securer way ?</p>

<p>Thanks</p>

CC BY-SA 3.0
2014-02-14T23:34:06.447Z
You're confusing addresses with the transaction id. Addresses can't be changed. The transaction id can be. You create a transaction sending btc to an address. The problem is you can't simply use thee transaction id to track the progress of the transaction because someone can change that id and then you don't see it going into the blockchain even though it has.
Jannes
CC BY-SA 3.0
2014-02-14T23:39:50.757Z
Thanks Jannes.
So why wouldn't people try to verify against transaction addresses instead of transaction IDs ?
Mark
CC BY-SA 3.0
2014-02-15T01:16:39.870Z
Yeah that's basically what you're supposed to do. Keep an eye on your own balance and match any transaction you see to any transaction you made earlier. Just not by the id but by the addresses. Which basically means you make your own hash of the important (non-malleable) parts of the transaction that you create and then you keep an eye on the blockchain for that hash. There's a recommended best practices for such a hash. Best to follow those and not implement something yourself based on what some random lurker on  here tells you (meaning: i may have parts or all of this wrong)
Jannes
CC BY-SA 3.0
2014-02-15T01:17:20.217Z
https://github.com/bitcoin/bitcoin/pull/3656
Jannes
CC BY-SA 3.0
2014-02-15T12:26:06.760Z
I think your question would be much clearer if you edited it to reflect your new knowledge about the difference between addresses and transaction ids. ;)
Murch
CC BY-SA 3.0
2014-02-15T12:27:01.903Z
related: [How is a Transaction ID generated & when does it change? (with a new sequence ID?)](http://bitcoin.stackexchange.com/q/5887/5406)
Murch
<transaction-malleability>
Avoiding Bitcoin malleable bug with implementation
Mark
# Avoiding Bitcoin malleable bug with implementation

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

I'm currently working on some Bitcoin code and whilst I'm hoping I've covered my bases, I wanted to check the implementation theory.

If I understand the malleable bug it's basically...
You create a transaction address for the transaction to take place on. At this point a transaction id is created (txid)

The txid is changed before the transaction is complete on the network, creating a second txid, that the transaction will eventually be completed/confirmed/verified on.

So if that is correct (please correct me if I'm wrong)...

A script/program transferring coins to somebody should work something like this:

A transaction address is created and given to the payee to transfer the requested balance to.
That transaction address is checked periodically for number of confirmations. When the transaction address receives 6 or more confirmations it can be considered as completed.

Is there a better/quicker/securer way ?

Thanks

**Tags:** transaction-malleability

> **Comments:**
> **username_1**: You're confusing addresses with the transaction id. Addresses can't be changed. The transaction id can be. You create a transaction sending btc to an address. The problem is you can't simply use thee transaction id to track the progress of the transaction because someone can change that id and then you don't see it going into the blockchain even though it has.  
> **username_0**: Thanks username_1. So why wouldn't people try to verify against transaction addresses instead of transaction IDs ?  
> **username_1**: Yeah that's basically what you're supposed to do. Keep an eye on your own balance and match any transaction you see to any transaction you made earlier. Just not by the id but by the addresses. Which basically means you make your own hash of the important (non-malleable) parts of the transaction that you create and then you keep an eye on the blockchain for that hash. There's a recommended best practices for such a hash. Best to follow those and not implement something yourself based on what some random lurker on  here tells you (meaning: i may have parts or all of this wrong)  
> **username_1**: https://github.com/bitcoin/bitcoin/pull/3656  
> **username_2**: I think your question would be much clearer if you edited it to reflect your new knowledge about the difference between addresses and transaction ids. ;)  
> **username_2**: related: [How is a Transaction ID generated & when does it change? (with a new sequence ID?)](http://bitcoin.stackexchange.com/q/5887/5406)  

---

## 1 answers

### Answer by username_3 on 2014-10-28. Score: 1

Lower the confirmation.
The security reports are specific, 1 confirmation is not safe. 2 confirmations is considered 'safe'. More is considered 'safe'.
You can "rock'n roll" with 2 confirmation.
MtGox died the epic death because their custom made wallet was accepting coins after just 1 confirmation


---

