Gavin Andresen [ARCHIVE] on Nostr: 📅 Original date posted:2013-12-03 📝 Original message:> > A merchant can always ...
📅 Original date posted:2013-12-03
📝 Original message:>
> A merchant can always refuse the payment and refund it if that's a
> practical problem.
>
No, they can't, at least not in bitcoin-qt: when the user pokes the SEND
button, the transaction is broadcast on the network, and then the merchant
is also told with the Payment/PaymentACK round-trip.
Allowing merchants to cancel (e.g. having a PaymentNACK) makes
implementation harder, and brings up nasty issues if we want to allow
CoinJoin or CoinJoin-like transactions as payments to merchants.
Bitcoin-Qt ALREADY allows you to pay several PaymentRequests with one
transaction; handling the case where one merchant gives you a PaymentACK
and another gives you (or wants to give you) a PaymentNACK is a nightmare.
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131203/7df4c2e4/attachment.html>;
📝 Original message:>
> A merchant can always refuse the payment and refund it if that's a
> practical problem.
>
No, they can't, at least not in bitcoin-qt: when the user pokes the SEND
button, the transaction is broadcast on the network, and then the merchant
is also told with the Payment/PaymentACK round-trip.
Allowing merchants to cancel (e.g. having a PaymentNACK) makes
implementation harder, and brings up nasty issues if we want to allow
CoinJoin or CoinJoin-like transactions as payments to merchants.
Bitcoin-Qt ALREADY allows you to pay several PaymentRequests with one
transaction; handling the case where one merchant gives you a PaymentACK
and another gives you (or wants to give you) a PaymentNACK is a nightmare.
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131203/7df4c2e4/attachment.html>;