<p>If I understand the scenario you're describing, you are effectively constructing an independent, second transaction that also pays the receiver, but using your own funds rather than the original sender's, for a smaller amount.</p>
<p>The two transactions will not conflict, and both will go through. So not only will you have done nothing to prevent the original transaction, you'll have donated some of your own money to the recipient in addition to it.</p>

CC BY-SA 4.0
2021-10-15T21:54:47.467Z
what about change existing transactions? just alter the amount and sign with the hacker's key-pair? not possible? how a miner can recognize it invalid transaction ? my target is to decrease the amount of the receiver's wallet.
aze2201
CC BY-SA 4.0
2021-10-15T22:20:53.763Z
You can't just make every node in the network forget the old transaction. All you can do is broadcast transactions of your own. From the network's perspective, there is no distinction between "transaction A, but with key/amount changed" or "transaction B, which always had your key/amount in the first place". Transactions have no identity, apart from their hash, and when you change their behavior, the hash changes - and the result is that it'll be treated as an independent transaction from the original.
Pieter Wuille
CC BY-SA 4.0
2021-10-15T22:47:28.693Z
I Understood it. So, it is avoiding by democracy. Means, single hash of changed block will be rejected by others.
aze2201
CC BY-SA 4.0
2021-10-15T23:02:16.213Z
I don't understand what democracy has to do with it. You simply don't invalidate a transaction by broadcasting another one.
Pieter Wuille
CC BY-SA 4.0
2021-10-16T06:57:29.480Z
Let's put in this way:
Amount:20 from: Alice to: Bob
Signature: AliceSign.

hacker miner block and alter some transaction to:
Amount:5 from: Fariz to: Bob
Signature: FarizSign.

(Suppose cryptographic algos are matching for a signing.)

How to avoid this? Because altered transaction also is valid. 
My question is in a cryptographic way how the receiver is a safe zone?  

Because from your answer I understand single block can be altered, but other nodes will reject it. Because hash will not match with other nodes. 
But I want to know how to avoid this in crytographc way.
aze2201
CC BY-SA 4.0
2021-10-16T12:27:24.780Z
As I told you: both the original and the modified transaction will go through. The original transaction does not conflict with the modified one, so the original one will still also be mined, possibly by some other miner in a later block. So what you describe you can't be prevented but it is also harmless: it's just the attacker creating an independent additional transaction from them to the recipient. The only effect is the attacker losing money, and the receiver getting a gift.
Pieter Wuille
CC BY-SA 4.0
2021-10-16T12:50:07.523Z
Also, the block cannot be altered in any way after creation without invalidating it, but the miner who creates it has full authority to choose whatever they want to include in it. So I'm assuming you're asking about a _miner_ who chooses to not include the original transaction, but instead includes an alternative transaction paying the same person, but using their own (the miner's) funds instead. What will happen is that the next miner will likely include the original transaction instead.
Pieter Wuille
CC BY-SA 4.0
2021-10-16T13:06:49.347Z
Understand it. Now it is clear. So, end of the story, transaction content is just signing by senders private key, and not encrypting with receivers public key (to open by receiver's private key only). So, transaction can be read by everyone and avoiding from altering only is distribute transactions/blocks.
aze2201
CC BY-SA 4.0
2021-10-15T21:38:57.937Z
2021-10-15T21:38:57.937Z
Pieter Wuille
<p>What about if I (as a hacker) change the amount from 5 to 1 for any transaction and put signature with my (as a hacker) Private Key and mine that block again. Yes, I lose  1 coin, At the same time isn't it an attack to target the public key (target walled address)? Because target walled address lost coin from 5 to 1.
How is bitcoin preventing this? Democracy?</p>

<private-key><signature><cryptography>
how target walled address is secure to save received amount?
aze2201
# how target walled address is secure to save received amount?

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

What about if I (as a hacker) change the amount from 5 to 1 for any transaction and put signature with my (as a hacker) Private Key and mine that block again. Yes, I lose 1 coin, At the same time isn't it an attack to target the public key (target walled address)? Because target walled address lost coin from 5 to 1.
How is bitcoin preventing this? Democracy?

**Tags:** private-key, signature, cryptography


---

## 1 answers

### Answer by username_1 on 2021-10-15. Score: 2

If I understand the scenario you're describing, you are effectively constructing an independent, second transaction that also pays the receiver, but using your own funds rather than the original sender's, for a smaller amount.

The two transactions will not conflict, and both will go through. So not only will you have done nothing to prevent the original transaction, you'll have donated some of your own money to the recipient in addition to it.

> **Comments:**
> **username_0**: what about change existing transactions? just alter the amount and sign with the hacker's key-pair? not possible? how a miner can recognize it invalid transaction ? my target is to decrease the amount of the receiver's wallet.  
> **username_1**: You can't just make every node in the network forget the old transaction. All you can do is broadcast transactions of your own. From the network's perspective, there is no distinction between "transaction A, but with key/amount changed" or "transaction B, which always had your key/amount in the first place". Transactions have no identity, apart from their hash, and when you change their behavior, the hash changes - and the result is that it'll be treated as an independent transaction from the original.  
> **username_0**: I Understood it. So, it is avoiding by democracy. Means, single hash of changed block will be rejected by others.  
> **username_1**: I don't understand what democracy has to do with it. You simply don't invalidate a transaction by broadcasting another one.  
> **username_0**: Let's put in this way: Amount:20 from: Alice to: Bob Signature: AliceSign.  hacker miner block and alter some transaction to: Amount:5 from: Fariz to: Bob Signature: FarizSign.  (Suppose cryptographic algos are matching for a signing.)  How to avoid this? Because altered transaction also is valid.  My question is in a cryptographic way how the receiver is a safe zone?    Because from your answer I understand single block can be altered, but other nodes will reject it. Because hash will not match with other nodes.  But I want to know how to avoid this in crytographc way.  
> **username_1**: As I told you: both the original and the modified transaction will go through. The original transaction does not conflict with the modified one, so the original one will still also be mined, possibly by some other miner in a later block. So what you describe you can't be prevented but it is also harmless: it's just the attacker creating an independent additional transaction from them to the recipient. The only effect is the attacker losing money, and the receiver getting a gift.  
> **username_1**: Also, the block cannot be altered in any way after creation without invalidating it, but the miner who creates it has full authority to choose whatever they want to include in it. So I'm assuming you're asking about a _miner_ who chooses to not include the original transaction, but instead includes an alternative transaction paying the same person, but using their own (the miner's) funds instead. What will happen is that the next miner will likely include the original transaction instead.  
> **username_0**: Understand it. Now it is clear. So, end of the story, transaction content is just signing by senders private key, and not encrypting with receivers public key (to open by receiver's private key only). So, transaction can be read by everyone and avoiding from altering only is distribute transactions/blocks.  

---

