<p>Here is the list of known sources of malleability from BIP62 (which has been withdrawn, and is no longer up to date, but does give some insight):</p>

<ol>
<li><strong>DER encoded ECDSA signatures</strong> Right now, the Bitcoin reference client uses OpenSSL to validate signatures. As OpenSSL accepts more than serializations that strictly adhere to the DER standard, this is a source of malleability. Since v0.8.0, non-DER signatures are no longer relayed already.</li>
<li><strong>Non-push operations in scriptSig</strong> Any sequence of script operations in scriptSig that results in the intended data pushes, but is not just a push of that data, results in an alternative transaction with the same validity.</li>
<li><strong>Push operations in scriptSig of non-standard size type</strong> The Bitcoin scripting language has several push operators (OP_0, single-byte pushes, data pushes of up to 75 bytes, OP_PUSHDATA1, OP_PUSHDATA2, OP_PUSHDATA4). As the later ones have the same result as the former ones, they result in additional possibilities.</li>
<li><strong>Zero-padded number pushes</strong> In cases where scriptPubKey opcodes use inputs that are interpreted as numbers, they can be zero padded.</li>
<li><strong>Inherent ECDSA signature malleability</strong> ECDSA signatures themselves are already malleable: taking the negative of the number S inside (modulo the curve order) does not invalidate it.</li>
<li><strong>Superfluous scriptSig operations</strong> Adding extra data pushes at the start of scripts, which are not consumed by the corresponding scriptPubKey, is also a source of malleability.</li>
<li><strong>Inputs ignored by scripts</strong> If a scriptPubKey starts with an OP_DROP, for example, the last data push of the corresponding scriptSig will always be ignored.</li>
<li><strong>Sighash flags based masking</strong> Sighash flags can be used to ignore certain parts of a script when signing.</li>
</ol>

<p>(1) has been fixed for all transactions by BIP66, and (2)-(6) are prevented by standardness rules in recent Bitcoin Core releases. A specific case of (7) is proposed to be fixed by BIP147.</p>

<p>Segregated Witness (BIP141) proposes fix all of them, but only for transactions that spend  solely from segwit outputs. It does this by moving the scriptSig data to a new field (the witness) which does not influence the txid.</p>

CC BY-SA 3.0
2017-02-28T16:06:51.993Z
do you really think that OP understands your answer? :)
amaclin
CC BY-SA 3.0
2017-02-28T16:17:28.040Z
Maybe, maybe not. OP is free to vote or accept whatever is most informative. But I'm not just answering the question for OP, and this may give a more detailed response for other people that find this page
Pieter Wuille
CC BY-SA 3.0
2017-02-28T15:15:24.483Z
2017-02-28T15:15:24.483Z
Pieter Wuille
<p>No! The algorithms are generated by the first block created by bitcoin so if you change the hash, the transaction will not be recognized and invalid.</p>

CC BY-SA 3.0
2017-02-28T12:19:03.383Z
Transactions in mempool can be changed.
gkucmierz
CC BY-SA 3.0
2017-02-28T12:23:56.740Z
Fails quickly correct! Fortunately...
atmon3r
CC BY-SA 3.0
2017-02-28T12:14:55.493Z
2017-02-28T12:14:55.493Z
atmon3r
<p><strong>TL;DR</strong>
Today - nothing</p>

<p>In fact, there are several sources for malleability. Most of them (not all) are already fixed by changed consensus rules, others become transaction non-standard.</p>

<p>But. <strong>Are you an attacker or a defender?</strong></p>

<p>You <strong>can</strong> create transaction which can be malleated by any person without invalidating it and without knowledge of your keys. It is easy.</p>

CC BY-SA 3.0
2017-02-28T15:06:39.597Z
I am attacked by someone, I see in network many copies of my transactions. Which are not mine of course and I am wondering why someone is doing that and how is that working?
gkucmierz
CC BY-SA 3.0
2017-02-28T15:21:06.087Z
can you provide txid(s)?
amaclin
CC BY-SA 3.0
2017-02-28T12:55:07.173Z
2017-02-28T12:55:07.173Z
amaclin
<p>What can be changed in signed bitcoin transaction?
I mean how is possible to modify transaction to change its hash, but keep transaction valid, without need to have sign private keys?</p>

<address><hash><change>
What can be changed in signed bitcoin transaction?
gkucmierz
# What can be changed in signed bitcoin transaction?

(Asked by: username_0 on 2017-02-28)

What can be changed in signed bitcoin transaction?
I mean how is possible to modify transaction to change its hash, but keep transaction valid, without need to have sign private keys?

**Tags:** address, hash, change


---

## 3 answers

### Answer by username_1 on 2017-02-28. Score: 9

Here is the list of known sources of malleability from BIP62 (which has been withdrawn, and is no longer up to date, but does give some insight):

1. **DER encoded ECDSA signatures** Right now, the Bitcoin reference client uses OpenSSL to validate signatures. As OpenSSL accepts more than serializations that strictly adhere to the DER standard, this is a source of malleability. Since v0.8.0, non-DER signatures are no longer relayed already.
2. **Non-push operations in scriptSig** Any sequence of script operations in scriptSig that results in the intended data pushes, but is not just a push of that data, results in an alternative transaction with the same validity.
3. **Push operations in scriptSig of non-standard size type** The Bitcoin scripting language has several push operators (OP\_0, single-byte pushes, data pushes of up to 75 bytes, OP\_PUSHDATA1, OP\_PUSHDATA2, OP\_PUSHDATA4). As the later ones have the same result as the former ones, they result in additional possibilities.
4. **Zero-padded number pushes** In cases where scriptPubKey opcodes use inputs that are interpreted as numbers, they can be zero padded.
5. **Inherent ECDSA signature malleability** ECDSA signatures themselves are already malleable: taking the negative of the number S inside (modulo the curve order) does not invalidate it.
6. **Superfluous scriptSig operations** Adding extra data pushes at the start of scripts, which are not consumed by the corresponding scriptPubKey, is also a source of malleability.
7. **Inputs ignored by scripts** If a scriptPubKey starts with an OP\_DROP, for example, the last data push of the corresponding scriptSig will always be ignored.
8. **Sighash flags based masking** Sighash flags can be used to ignore certain parts of a script when signing.

(1) has been fixed for all transactions by BIP66, and (2)-(6) are prevented by standardness rules in recent Bitcoin Core releases. A specific case of (7) is proposed to be fixed by BIP147.

Segregated Witness (BIP141) proposes fix all of them, but only for transactions that spend solely from segwit outputs. It does this by moving the scriptSig data to a new field (the witness) which does not influence the txid.

> **Comments:**
> **username_2**: do you really think that OP understands your answer? :)  
> **username_1**: Maybe, maybe not. OP is free to vote or accept whatever is most informative. But I'm not just answering the question for OP, and this may give a more detailed response for other people that find this page  

---

### Answer by username_3 on 2017-02-28. Score: -2

No! The algorithms are generated by the first block created by bitcoin so if you change the hash, the transaction will not be recognized and invalid.

> **Comments:**
> **username_0**: Transactions in mempool can be changed.  
> **username_3**: Fails quickly correct! Fortunately...  

---

### Answer by username_2 on 2017-02-28. Score: -2

**TL;DR**
Today - nothing

In fact, there are several sources for malleability. Most of them (not all) are already fixed by changed consensus rules, others become transaction non-standard.

But. **Are you an attacker or a defender?**

You **can** create transaction which can be malleated by any person without invalidating it and without knowledge of your keys. It is easy.

> **Comments:**
> **username_0**: I am attacked by someone, I see in network many copies of my transactions. Which are not mine of course and I am wondering why someone is doing that and how is that working?  
> **username_2**: can you provide txid(s)?  

---

