1

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?

Murch
  • 75,206
  • 34
  • 186
  • 622
exaRock
  • 13
  • 2

1 Answers1

0

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.

Murch
  • 75,206
  • 34
  • 186
  • 622
  • 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 Mar 17 '23 at 14:26
  • @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 Mar 17 '23 at 14:30
  • 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? – Murch Mar 17 '23 at 14:30
  • Ok, I got it. I just mixed up the results of these two parts. Thanks for your clearly explanation. – exaRock Mar 17 '23 at 15:37