<p>I've been trying to get my head around the process that stops transactions from being malleable on a system built using Bitcoind. I'm pretty sure, that out of the box, right now, I'm not doing anything to solve this problem. </p>

<p>So I thought I would look it up, but could not find any tutorials, or even a good explanation of the technical steps you need to take in order to stop or prevent transaction mailability.</p>

<p>Are there any protocol level tutorials on the subject?
Or, do you have any personal experience with this that you could share with me?</p>

<p>Thanks in advance for your help.</p>

CC BY-SA 3.0
2014-03-03T19:19:04.153Z
You'll have to be more specific as to what you mean by "transaction malleability". Changing the meat of a transaction is essentially impossible. Changing things like the transaction id, which is really a checksum (it's not even guaranteed to be unique, though it's *highly* unlikely to be repeated) is possible, though practically difficult. Or perhaps you could be more specific as to what you're worried about?
Chris S
CC BY-SA 3.0
2014-03-03T19:26:11.320Z
I apologize for being vague.
Yitzhak
CC BY-SA 3.0
2014-03-03T19:27:57.193Z
Here's what I'm doing. I'm putting up an instance of bitcoind that users can drop money into, and make transactions with other users, who also put money in the system. 

What I want to make sure of is that there's no way to game bitcoind into putting money into the system where it gets logged and spent, and then taken out retroactively by the same user that put it in (if that's even possible). I'm not clear on this.
Yitzhak
CC BY-SA 3.0
2014-03-03T19:35:37.643Z
There's no take-backs in BitCoin. The amount and who it's coming from and to can't be changed once the transaction is broadcast. The transaction malleability problems being talked about, like MtGox is where people modified something else in the transaction, calculated a new TxID - MtGox problem was keeping track of account balances *only* by the individual transactions; they'd never recalculate the balance of an address (eg lookup all transactions to/from an address).
Chris S
CC BY-SA 3.0
2014-03-03T20:08:58.877Z
So as long as you keep a running total, by auditing accounts and all transactions in your system, you're okay?
Yitzhak
CC BY-SA 3.0
2014-03-03T21:50:23.643Z
What's more important than your method of keeping accounts, is that you have a different method available for verifying accounts. The source and destination addresses in a Bitcoin transaction are immutable (without invaliding the transaction), so either your primary or secondary accounting methods should rely on that information.
Chris S
CC BY-SA 3.0
2014-05-08T10:30:46.307Z
possible duplicate of [How is the transaction malleability issue being fixed?](http://bitcoin.stackexchange.com/questions/22918/how-is-the-transaction-malleability-issue-being-fixed)
Murch
<bitcoind><protocol><transaction-malleability>
Transaction malleability and Bitcoind
Yitzhak
# Transaction malleability and Bitcoind

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

I've been trying to get my head around the process that stops transactions from being malleable on a system built using Bitcoind. I'm pretty sure, that out of the box, right now, I'm not doing anything to solve this problem.

So I thought I would look it up, but could not find any tutorials, or even a good explanation of the technical steps you need to take in order to stop or prevent transaction mailability.

Are there any protocol level tutorials on the subject?
Or, do you have any personal experience with this that you could share with me?

Thanks in advance for your help.

**Tags:** bitcoind, protocol, transaction-malleability

> **Comments:**
> **username_1**: You'll have to be more specific as to what you mean by "transaction malleability". Changing the meat of a transaction is essentially impossible. Changing things like the transaction id, which is really a checksum (it's not even guaranteed to be unique, though it's *highly* unlikely to be repeated) is possible, though practically difficult. Or perhaps you could be more specific as to what you're worried about?  
> **username_0**: I apologize for being vague.  
> **username_0**: Here's what I'm doing. I'm putting up an instance of bitcoind that users can drop money into, and make transactions with other users, who also put money in the system.   What I want to make sure of is that there's no way to game bitcoind into putting money into the system where it gets logged and spent, and then taken out retroactively by the same user that put it in (if that's even possible). I'm not clear on this.  
> **username_1**: There's no take-backs in BitCoin. The amount and who it's coming from and to can't be changed once the transaction is broadcast. The transaction malleability problems being talked about, like MtGox is where people modified something else in the transaction, calculated a new TxID - MtGox problem was keeping track of account balances *only* by the individual transactions; they'd never recalculate the balance of an address (eg lookup all transactions to/from an address).  
> **username_0**: So as long as you keep a running total, by auditing accounts and all transactions in your system, you're okay?  
> **username_1**: What's more important than your method of keeping accounts, is that you have a different method available for verifying accounts. The source and destination addresses in a Bitcoin transaction are immutable (without invaliding the transaction), so either your primary or secondary accounting methods should rely on that information.  
> **username_2**: possible duplicate of [How is the transaction malleability issue being fixed?](http://bitcoin.stackexchange.com/questions/22918/how-is-the-transaction-malleability-issue-being-fixed)  

---

## 0 answers

