<p>Point (6) does not eliminate this source of malleability. Rather, point (2) of BIP62 disallows all three modifications you suggested. BIP62 describes the problem:</p>

<blockquote>
  <p><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.</p>
</blockquote>

<p>And the proposed solution:</p>

<blockquote>
  <p><strong>Non-push operations in scriptSig</strong> Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: Push operators.</p>
</blockquote>

CC BY-SA 3.0
2015-06-16T00:05:29.953Z
one last one - how about a doubling the scriptsig content:`OP_PUSHDATA <sig> OP_PUSHDATA <pubkey> OP_PUSHDATA <sig> OP_PUSHDATA <pubkey>` - i think this would still evaluate to true, right?
mulllhausen
CC BY-SA 3.0
2015-06-16T00:43:58.520Z
@mulllhausen Point (6) prevents against that. It would evaluate to true with a typical transaction, but it would be a non-standard and not relayed. For transactions in which bip62 goes into effect, it would evaluate to false, though.
morsecoder
CC BY-SA 3.0
2015-06-15T15:15:22.533Z
2015-06-17T13:53:43.337Z
2015-06-17T13:53:43.337Z
morsecoder
<p>are any of the following transaction malleability "attack" vectors currently feasible?</p>

<p>alter scriptsig from:</p>

<pre><code>OP_PUSHDATA &lt;sig&gt; OP_PUSHDATA &lt;pubkey&gt;
</code></pre>

<p>to one of:</p>

<pre><code>1) OP_1 OP_SHA1 OP_DROP OP_PUSHDATA &lt;sig&gt; OP_PUSHDATA &lt;pubkey&gt;
2) OP_PUSHDATA &lt;sig&gt; OP_PUSHDATA &lt;pubkey&gt; OP_1 OP_SHA1 OP_DROP
3) OP_PUSHDATA &lt;sig&gt; OP_PUSHDATA &lt;pubkey&gt; OP_NOP
</code></pre>

<p>so that the corresponding scriptpubkey still evaluates to true:</p>

<pre><code>OP_DUP OP_HASH160 OP_PUSHDATA &lt;address&gt; OP_EQUALVERIFY OP_CHECKSIG
</code></pre>

<p>i can't tell if this is handled by point 6 in <a href="https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki" rel="nofollow">bip 62</a> or not:</p>

<blockquote>
  <ol start="6">
  <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>
  </ol>
</blockquote>

<p><a href="https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L693-L701" rel="nofollow">judging by the code</a> it looks like it has been taken care of, but my c++ knowledge is not great...</p>

<transaction-malleability>
transaction malleability "attack" vectors
mulllhausen
# transaction malleability "attack" vectors

(Asked by: username_0 on 2015-06-15)

are any of the following transaction malleability "attack" vectors currently feasible?

alter scriptsig from:

```
OP_PUSHDATA <sig> OP_PUSHDATA <pubkey>

```

to one of:

```
1) OP_1 OP_SHA1 OP_DROP OP_PUSHDATA <sig> OP_PUSHDATA <pubkey>
2) OP_PUSHDATA <sig> OP_PUSHDATA <pubkey> OP_1 OP_SHA1 OP_DROP
3) OP_PUSHDATA <sig> OP_PUSHDATA <pubkey> OP_NOP

```

so that the corresponding scriptpubkey still evaluates to true:

```
OP_DUP OP_HASH160 OP_PUSHDATA <address> OP_EQUALVERIFY OP_CHECKSIG

```

i can't tell if this is handled by point 6 in [bip 62](https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki) or not:

> 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.

[judging by the code](https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L693-L701) it looks like it has been taken care of, but my c++ knowledge is not great...

**Tags:** transaction-malleability


---

## 1 answers

### Answer by username_1 on 2015-06-15. Score: 1 | Accepted answer

Point (6) does not eliminate this source of malleability. Rather, point (2) of BIP62 disallows all three modifications you suggested. BIP62 describes the problem:

> **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.

And the proposed solution:

> **Non-push operations in scriptSig** Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: Push operators.

> **Comments:**
> **username_0**: one last one - how about a doubling the scriptsig content:`OP_PUSHDATA <sig> OP_PUSHDATA <pubkey> OP_PUSHDATA <sig> OP_PUSHDATA <pubkey>` - i think this would still evaluate to true, right?  
> **username_1**: @username_0 Point (6) prevents against that. It would evaluate to true with a typical transaction, but it would be a non-standard and not relayed. For transactions in which bip62 goes into effect, it would evaluate to false, though.  

---

