<p>Payment requests in Bitcoin are completely out of band. They have no binding effect for what happens on-chain. An address merely communicates what locking script the receiver would like the sender to pay into. While a payment request might specify an amount, a sender could send any other amount as well. Once an address has been communicated, receiving is completely passive: the receiver does not have to sign off, nor do they get a chance to veto a payment.</p>

CC BY-SA 4.0
2023-03-17T14:26:41.617Z
I see. I have clarified concept now. But in this case isn't it a totally useless function to let the receiver set an amount? Adding the amount will generate a different address, which makes me confused.
exaRock
CC BY-SA 4.0
2023-03-17T14:30:06.193Z
@exaRock *Every* time you ask your wallet for an address it will generate a new one, whether the amount is the same or not (for privacy reasons, addresses shouldn't be reused). And it isn't useless; it avoids mistakes where the sender types the amount incorrectly.
Pieter Wuille
CC BY-SA 4.0
2023-03-17T14:30:43.733Z
If the payment request is consumed by another app, setting an amount will permit the other app to present its user with a transaction draft that already pays the requested amount to the receiver. I don’t see why it would be useless. Generating a new address every time you create a new payment request seems reasonable (addresses are used to identify payment context, akin to an invoice identifier, and should only be used once). Generating a new address when the user is just changing the amount while customizing a payment request sounds like an odd UX choice. Which app is this?
Murch
CC BY-SA 4.0
2023-03-17T15:37:37.900Z
Ok, I got it. I just mixed up the results of these two parts. Thanks for your clearly explanation.
exaRock
CC BY-SA 4.0
2023-03-17T13:17:58.683Z
2023-03-17T13:17:58.683Z
Murch
<p>Can I assume that someone can still send any amount to a receiving address with a blank amount?</p>
<p>And, what will be the result of sending more or less to a receiving address which has set a specific amount?</p>

<receiving>
Is setting an amount for a new receiving address purely optional?
exaRock
# Is setting an amount for a new receiving address purely optional?

(Asked by: username_0 on 2023-03-17)

Can I assume that someone can still send any amount to a receiving address with a blank amount?

And, what will be the result of sending more or less to a receiving address which has set a specific amount?

**Tags:** receiving


---

## 1 answers

### Answer by username_1 on 2023-03-17. Score: 0 | Accepted answer

Payment requests in Bitcoin are completely out of band. They have no binding effect for what happens on-chain. An address merely communicates what locking script the receiver would like the sender to pay into. While a payment request might specify an amount, a sender could send any other amount as well. Once an address has been communicated, receiving is completely passive: the receiver does not have to sign off, nor do they get a chance to veto a payment.

> **Comments:**
> **username_0**: I see. I have clarified concept now. But in this case isn't it a totally useless function to let the receiver set an amount? Adding the amount will generate a different address, which makes me confused.  
> **username_2**: @username_0 *Every* time you ask your wallet for an address it will generate a new one, whether the amount is the same or not (for privacy reasons, addresses shouldn't be reused). And it isn't useless; it avoids mistakes where the sender types the amount incorrectly.  
> **username_1**: If the payment request is consumed by another app, setting an amount will permit the other app to present its user with a transaction draft that already pays the requested amount to the receiver. I don’t see why it would be useless. Generating a new address every time you create a new payment request seems reasonable (addresses are used to identify payment context, akin to an invoice identifier, and should only be used once). Generating a new address when the user is just changing the amount while customizing a payment request sounds like an odd UX choice. Which app is this?  
> **username_0**: Ok, I got it. I just mixed up the results of these two parts. Thanks for your clearly explanation.  

---

