<p>When person A &quot;Sends&quot; their transaction, they must first sign it, and then broadcast it to the mempool. The signing ensures that the transaction is not valid if any of the signed portions are changed. Thus, if you change a scriptPubKey, the signature they added to the transaction will be rendered invalid, and when you attempt to broadcast your updated version of the transaction, it will be rejected by all nodes.</p>
<p>One possible exception is if person A uses SIGHASH_NONE. If this flag is set, the signature does not sign the scriptPubKeys of the outputs, and thus they are mutable without invalidating the signature. AFAIK, no one uses SIGHASH_NONE due to this insecurity.</p>
<p>More on Sighash flags: <a href="https://river.com/learn/terms/s/sighash-flag/" rel="nofollow noreferrer">https://river.com/learn/terms/s/sighash-flag/</a></p>

CC BY-SA 4.0
2021-10-05T21:03:01.090Z
2021-10-05T21:03:01.090Z
Sachin Meier
<p>To ensure that the transaction is not tampered with, the owner will SIGN the transaction and then broadcast to the network. Changing any part of the transaction WILL change the transaction's signature and other nodes will <strong>DROP</strong> that corrupted transactions as message(transaction) has changed.</p>
<p>But still the possibility of tampering exists,</p>
<p>Because the transaction contains signatures themselves, a signature can't sign itself and hence signatures are not included in the transaction string during signing. So while a transaction is in the mempool(staging area waiting to be mined) and has been computed/assigned a TxnID(a hash of transaction), a node can slightly change your signature(in a way not making transaction invalid) and because the signature is now changed(in turn transaction string is modified)..a new hash will be created.</p>
<p>While the integrity of transaction remains well and bitcoins will be sent to intended receiver, the software/wallet waiting for confirmation of the previously known TxnID will still be waiting for confirmations.</p>
<p>Even this has been fixed with the introduction of SegWit to bitcoin network after the BIP-141.</p>

CC BY-SA 4.0
2021-10-11T14:02:34.233Z
2021-10-11T14:02:34.233Z
Pranay Reddy
<p>Suppose a person A makes a transaction to person B and sends it to bitcoin network. Suppose I changed PubKeyHash in scriptPubKey of a transaction to my PubKeyHash and send it to bitcoin network. The transactions sent by me will be a valid transaction, right ??
Thanks.</p>

<transactions><script><public-key><p2sh>
What if I change PubKeyHash in scriptPubKey of a transaction to my PubKeyHash?
inder128
# What if I change PubKeyHash in scriptPubKey of a transaction to my PubKeyHash?

(Asked by: username_0 on 2021-10-05)

Suppose a person A makes a transaction to person B and sends it to bitcoin network. Suppose I changed PubKeyHash in scriptPubKey of a transaction to my PubKeyHash and send it to bitcoin network. The transactions sent by me will be a valid transaction, right ??
Thanks.

**Tags:** transactions, script, public-key, p2sh


---

## 2 answers

### Answer by username_1 on 2021-10-05. Score: 1

When person A "Sends" their transaction, they must first sign it, and then broadcast it to the mempool. The signing ensures that the transaction is not valid if any of the signed portions are changed. Thus, if you change a scriptPubKey, the signature they added to the transaction will be rendered invalid, and when you attempt to broadcast your updated version of the transaction, it will be rejected by all nodes.

One possible exception is if person A uses SIGHASH\_NONE. If this flag is set, the signature does not sign the scriptPubKeys of the outputs, and thus they are mutable without invalidating the signature. AFAIK, no one uses SIGHASH\_NONE due to this insecurity.

More on Sighash flags: <https://river.com/learn/terms/s/sighash-flag/>


---

### Answer by username_2 on 2021-10-11. Score: 1

To ensure that the transaction is not tampered with, the owner will SIGN the transaction and then broadcast to the network. Changing any part of the transaction WILL change the transaction's signature and other nodes will **DROP** that corrupted transactions as message(transaction) has changed.

But still the possibility of tampering exists,

Because the transaction contains signatures themselves, a signature can't sign itself and hence signatures are not included in the transaction string during signing. So while a transaction is in the mempool(staging area waiting to be mined) and has been computed/assigned a TxnID(a hash of transaction), a node can slightly change your signature(in a way not making transaction invalid) and because the signature is now changed(in turn transaction string is modified)..a new hash will be created.

While the integrity of transaction remains well and bitcoins will be sent to intended receiver, the software/wallet waiting for confirmation of the previously known TxnID will still be waiting for confirmations.

Even this has been fixed with the introduction of SegWit to bitcoin network after the BIP-141.


---

