<p>Use two tables for deposits basically.</p>

<p>insert deposits into one table with a unique hash. store sighash and txid with a unique hash and timestamp in the other. when the txid changes, you update the second table, preventing the duplicate deposit.</p>

CC BY-SA 3.0
2014-04-04T18:06:11.403Z
@DougPeters no problem. its all about spreading awareness in the community. the stronger the developers, the stronger the economy. i've nver had a problem with it because i don't rely on wallet notify to store transactions, instead i dump an array of the last 100 transactions every 30 seconds iterate through it checking against the db(type receive), only crediting once the confirm > 6. this has performance drawbacks of course, and requires an extra script to periodically check already paid deposits(for changes in txhash and # of confirmations.
r3wt
CC BY-SA 3.0
2014-04-04T18:07:59.647Z
i will opensource this solution soon, which is written in php/mysql, and it should be easily ported to other languages/configurations.
r3wt
CC BY-SA 3.0
2014-04-23T08:42:38.290Z
Will you handle deposits per address or per transaction? When a transaction pays to multiple addresses in your wallet for example.
Robert-Reinder Nederhoed
CC BY-SA 3.0
2014-03-27T17:28:25.573Z
2014-03-27T17:28:25.573Z
r3wt
<p>What are the main principles and/or patterns programmers must apply to their code in order to make their programs bulletproof towards transaction malleability attacks?</p>

<transaction-malleability>
Anti-Transaction malleability patterns
Doug Peters
# Anti-Transaction malleability patterns

(Asked by: username_0 on 2014-03-27)

What are the main principles and/or patterns programmers must apply to their code in order to make their programs bulletproof towards transaction malleability attacks?

**Tags:** transaction-malleability


---

## 1 answers

### Answer by username_1 on 2014-03-27. Score: 2 | Accepted answer

Use two tables for deposits basically.

insert deposits into one table with a unique hash. store sighash and txid with a unique hash and timestamp in the other. when the txid changes, you update the second table, preventing the duplicate deposit.

> **Comments:**
> **username_1**: @username_0 no problem. its all about spreading awareness in the community. the stronger the developers, the stronger the economy. i've nver had a problem with it because i don't rely on wallet notify to store transactions, instead i dump an array of the last 100 transactions every 30 seconds iterate through it checking against the db(type receive), only crediting once the confirm > 6. this has performance drawbacks of course, and requires an extra script to periodically check already paid deposits(for changes in txhash and # of confirmations.  
> **username_1**: i will opensource this solution soon, which is written in php/mysql, and it should be easily ported to other languages/configurations.  
> **username_2**: Will you handle deposits per address or per transaction? When a transaction pays to multiple addresses in your wallet for example.  

---

