<p>In order for the transaction to be valid it has to have valid signatures from the public keys associated with the funds being transferred. It is regarded to be computationally unfeasible for a middleman to forge a signature if he does not possess the private key.</p>

<p>These signatures are specific to the transaction and ensure its integrity, i.e., if the transaction is modified (by replacing recipient, amount, ...) then the signature becomes invalid.</p>

<p>There is a small exception to the last point: a signature cannot ensure the integrity of the signature itself, hence we have some minor problems with transaction malleability in which the transaction signature can be modified, but not its effects.</p>

CC BY-SA 3.0
2016-05-03T05:45:49.713Z
Cant i sign the funds with my own private key instead of the original?
ArielB
CC BY-SA 3.0
2016-05-03T10:11:31.380Z
The funds are associated with the owner's public key, not yours so any signature you provide does not authorized the Transfer.
cdecker
CC BY-SA 3.0
2016-05-03T12:53:37.280Z
how? i understand that by spending the funds, you supply your unlocking script with the locking script (usually hash with the private key) - is this what makes it unchangable?
also, besides the scripts, the transaction is signed by whole?
ArielB
CC BY-SA 3.0
2016-05-03T14:00:28.530Z
Yes, the script attached to the output dictates which public keys are allowed to spend the funds, signatures by other private keys are invalid. Usually the signature signs the entire transaction, but that behavior can be fine tuned using the SIGHASH flags.
cdecker
CC BY-SA 3.0
2016-05-05T14:12:47.180Z
uhm. i still didnt understand something.
let's say i'm eavesdropping the network, grabbing the transaction that Bob sent to Alice, he supplied his unlocking script, and added Alice's locking script. why can't i just take that transaction, change the output to me, change the locking script to my keys, and then it's like Bob sent the money to me?
ArielB
CC BY-SA 3.0
2016-05-07T18:16:57.007Z
Because the keys that are required to unlock the funds were specified in the previous transaction, the one that transferred the funds to Bob.
cdecker
CC BY-SA 3.0
2016-05-08T07:40:42.307Z
i know, they were specified in the previous transaction, but the transaction wasn't broadcasted yet to any node, so, i'm still using Bob's unlock scripts, i'm just faking the part that he supposed to send the funds to alice - transferring them to me - isn't it similar to a malware that for example changes the address while user pastes it in his wallet? just instead of making the wallet software create the transaction with the new address, i'll "re-create" it with a created transaction?
ArielB
CC BY-SA 3.0
2016-05-08T13:02:02.470Z
See this: http://stripcoin.com/security/mitm/ - "In the same context, any time you transmit a Bitcoin address over a non cryptographic connection like HTTP or Email, every service provider who can see that transfer has the ability to change your Bitcoin address to theirs. " - that's what i meant.
ArielB
CC BY-SA 3.0
2016-05-08T14:12:23.857Z
That MITM attack targets a communication channel that is external to the Bitcoin protocol. Bitcoin is only concerned with securing the transaction once the payee address has been securely communicated to the payer. Once that is done and the payer has correctly created a transaction it is no longer vulnerable to MITM attacks.
cdecker
CC BY-SA 3.0
2016-05-08T14:22:05.080Z
yep, u described it well. so before broadcast - you are in risk, after confirmations - all good.
thanks!
ArielB
CC BY-SA 3.0
2016-05-08T15:07:25.263Z
Well even during the broadcast it is safe, it's just safely communicating the payee's address which is in danger of incurring a MITM attack :-)
cdecker
CC BY-SA 3.0
2016-05-02T21:13:14.383Z
2016-05-02T21:13:14.383Z
cdecker
<p>This would not work because the man in the middle's public key would not hash to the bitcoin address that owns the coins.</p>

<p>What a man in the middle can do is perform a padding attack which has largely been compensated for, but caused a lot of problems when it first came out. See more <a href="https://bitcoin.stackexchange.com/a/21995/2630">here</a></p>

CC BY-SA 3.0
2016-05-02T20:04:14.150Z
Can you explain that in more details?
ArielB
CC BY-SA 3.0
2016-05-02T18:17:40.280Z
2016-05-02T18:17:40.280Z
2017-04-13T12:47:36.647Z
placeybordeaux
<p>i'm very new to bitcoins (started learning it today). i hope i get the question right:</p>

<p>i understand when a transaction is created, using my private key i sign the transaction, but i also provide the public key with it right?</p>

<p>if so, what denies a man in the middle to take it, re-sign using his own private key, and provide his own public key?</p>

<ul>
<li>regular https handles this issue using a root CA, which i understand doesn't exist in bitcoins concept</li>
<li>encryption is usually used using the public keys, to avoid someone else changing the transaction and re-encrypt it (as it doesn't have the private key to open the data)</li>
</ul>

<p>so, i don't quite understand what makes it secure as the bitcoin wallet creates a data that is not encrypted, and anyone else can take this data, and alter whatever it wants before it leaves the network</p>

<p>thanks!</p>

<transactions><security>
can man in the middle change transaction before its broadcast?
ArielB
# can man in the middle change transaction before its broadcast?

(Asked by: username_0 on 2016-05-02)

i'm very new to bitcoins (started learning it today). i hope i get the question right:

i understand when a transaction is created, using my private key i sign the transaction, but i also provide the public key with it right?

if so, what denies a man in the middle to take it, re-sign using his own private key, and provide his own public key?

* regular https handles this issue using a root CA, which i understand doesn't exist in bitcoins concept
* encryption is usually used using the public keys, to avoid someone else changing the transaction and re-encrypt it (as it doesn't have the private key to open the data)

so, i don't quite understand what makes it secure as the bitcoin wallet creates a data that is not encrypted, and anyone else can take this data, and alter whatever it wants before it leaves the network

thanks!

**Tags:** transactions, security


---

## 2 answers

### Answer by username_1 on 2016-05-02. Score: 2 | Accepted answer

In order for the transaction to be valid it has to have valid signatures from the public keys associated with the funds being transferred. It is regarded to be computationally unfeasible for a middleman to forge a signature if he does not possess the private key.

These signatures are specific to the transaction and ensure its integrity, i.e., if the transaction is modified (by replacing recipient, amount, ...) then the signature becomes invalid.

There is a small exception to the last point: a signature cannot ensure the integrity of the signature itself, hence we have some minor problems with transaction malleability in which the transaction signature can be modified, but not its effects.

> **Comments:**
> **username_0**: Cant i sign the funds with my own private key instead of the original?  
> **username_1**: The funds are associated with the owner's public key, not yours so any signature you provide does not authorized the Transfer.  
> **username_0**: how? i understand that by spending the funds, you supply your unlocking script with the locking script (usually hash with the private key) - is this what makes it unchangable? also, besides the scripts, the transaction is signed by whole?  
> **username_1**: Yes, the script attached to the output dictates which public keys are allowed to spend the funds, signatures by other private keys are invalid. Usually the signature signs the entire transaction, but that behavior can be fine tuned using the SIGHASH flags.  
> **username_0**: uhm. i still didnt understand something. let's say i'm eavesdropping the network, grabbing the transaction that Bob sent to Alice, he supplied his unlocking script, and added Alice's locking script. why can't i just take that transaction, change the output to me, change the locking script to my keys, and then it's like Bob sent the money to me?  
> **username_1**: Because the keys that are required to unlock the funds were specified in the previous transaction, the one that transferred the funds to Bob.  
> **username_0**: i know, they were specified in the previous transaction, but the transaction wasn't broadcasted yet to any node, so, i'm still using Bob's unlock scripts, i'm just faking the part that he supposed to send the funds to alice - transferring them to me - isn't it similar to a malware that for example changes the address while user pastes it in his wallet? just instead of making the wallet software create the transaction with the new address, i'll "re-create" it with a created transaction?  
> **username_0**: See this: http://stripcoin.com/security/mitm/ - "In the same context, any time you transmit a Bitcoin address over a non cryptographic connection like HTTP or Email, every service provider who can see that transfer has the ability to change your Bitcoin address to theirs. " - that's what i meant.  
> **username_1**: That MITM attack targets a communication channel that is external to the Bitcoin protocol. Bitcoin is only concerned with securing the transaction once the payee address has been securely communicated to the payer. Once that is done and the payer has correctly created a transaction it is no longer vulnerable to MITM attacks.  
> **username_0**: yep, u described it well. so before broadcast - you are in risk, after confirmations - all good. thanks!  
> **username_1**: Well even during the broadcast it is safe, it's just safely communicating the payee's address which is in danger of incurring a MITM attack :-)  

---

### Answer by username_2 on 2016-05-02. Score: 0

This would not work because the man in the middle's public key would not hash to the bitcoin address that owns the coins.

What a man in the middle can do is perform a padding attack which has largely been compensated for, but caused a lot of problems when it first came out. See more [here](https://bitcoin.stackexchange.com/a/21995/2630)

> **Comments:**
> **username_0**: Can you explain that in more details?  

---

