<p>I have a feeling you are missing the index.</p>

<p>Each input is actually a transaction output from a previous transaction. The whole previous transaction is identified by the transaction hash, however the previous transaction can be paying to one or more addresses. Usually you control at least one of those addresses and so when you make a payment your software is </p>

<ol>
<li>identifying the (hopefully already confirmed) transaction</li>
<li>identifying the index of the payment (ie <em>your</em> address) which you will use coins from</li>
</ol>

<p>Point 2 is not malleable, the index is specific to the previous transaction. However you are able to compile your payment transaction in any order you choose, before it gets signed, and becomes your output.</p>

<p>This has nothing to do with the transaction malleability issue though.</p>

CC BY-SA 3.0
2014-04-23T23:10:19.027Z
2014-04-23T23:10:19.027Z
T9b
<p>The signature associated with an input doesn't just sign that input, it signs the entire transaction payload - basically every part of the transaction except the signatures themselves. (Technically, it appears to actually sign a hash of a serialized version of the transaction.)</p>

<p>It has to be that way. Otherwise, you could take someone else's signed transaction and modify the outputs to pay it to yourself instead of the intended recipient.</p>

<p>So if you modify the order of the inputs, you modify the signed payload. The signatures will no longer verify and the modified transaction will not be accepted as valid by anyone.</p>

<p>The malleable transaction attack worked by modifying the signature itself to a different but still valid alternate version. The payload of the transaction never changed.</p>

CC BY-SA 3.0
2014-05-22T16:58:03.923Z
Do you mind elaborating on the last paragraph?
Pacerier
CC BY-SA 3.0
2014-05-22T17:50:34.213Z
@Pacerier: Unfortunately I am not familiar with the precise details as to how the modified signature works.  If I figure it out I will try to update my answer.
Nate Eldredge
CC BY-SA 3.0
2014-04-24T00:26:05.363Z
2014-04-24T00:56:14.027Z
2014-04-24T00:56:14.027Z
Nate Eldredge
<p>I'm looking to track transactions in a non-malleable way. To achieve this I've read the recommendations in this <a href="https://bitcoin.stackexchange.com/a/22170/13899">answer</a>, but I don't understand how the order of transaction inputs isn't malleable. It's my understanding that each separate input is signed by the private key it's address is associated with, and thus a malleability attack could just swap the order of inputs and a tracking hash dependent a specific order would be rendered useless. Am I missing something here?</p>

<transaction-malleability>
Is the order of transaction inputs malleable?
whoknows
# Is the order of transaction inputs malleable?

(Asked by: username_0 on 2014-04-23)

I'm looking to track transactions in a non-malleable way. To achieve this I've read the recommendations in this [answer](https://bitcoin.stackexchange.com/a/22170/13899), but I don't understand how the order of transaction inputs isn't malleable. It's my understanding that each separate input is signed by the private key it's address is associated with, and thus a malleability attack could just swap the order of inputs and a tracking hash dependent a specific order would be rendered useless. Am I missing something here?

**Tags:** transaction-malleability


---

## 2 answers

### Answer by username_2 on 2014-04-24. Score: 5 | Accepted answer

The signature associated with an input doesn't just sign that input, it signs the entire transaction payload - basically every part of the transaction except the signatures themselves. (Technically, it appears to actually sign a hash of a serialized version of the transaction.)

It has to be that way. Otherwise, you could take someone else's signed transaction and modify the outputs to pay it to yourself instead of the intended recipient.

So if you modify the order of the inputs, you modify the signed payload. The signatures will no longer verify and the modified transaction will not be accepted as valid by anyone.

The malleable transaction attack worked by modifying the signature itself to a different but still valid alternate version. The payload of the transaction never changed.

> **Comments:**
> **username_3**: Do you mind elaborating on the last paragraph?  
> **username_2**: @username_3: Unfortunately I am not familiar with the precise details as to how the modified signature works.  If I figure it out I will try to update my answer.  

---

### Answer by username_1 on 2014-04-23. Score: 0

I have a feeling you are missing the index.

Each input is actually a transaction output from a previous transaction. The whole previous transaction is identified by the transaction hash, however the previous transaction can be paying to one or more addresses. Usually you control at least one of those addresses and so when you make a payment your software is

1. identifying the (hopefully already confirmed) transaction
2. identifying the index of the payment (ie *your* address) which you will use coins from

Point 2 is not malleable, the index is specific to the previous transaction. However you are able to compile your payment transaction in any order you choose, before it gets signed, and becomes your output.

This has nothing to do with the transaction malleability issue though.


---

