Published on: 2014-01-31T16:21:59+00:00
The discussion revolves around the issues faced by merchants using the refund or memo feature in Bitcoin Core. Merchants need to provide an alternate route for delivering this information before the transaction is made, rendering these fields useless and removing the ability to rely on the payment protocol being bidirectional.Various solutions are suggested, such as sending refund/memo fields as part of the initial request or response to PaymentRequest/PaymentDetails. However, these options require significant changes to the protocol.In an email thread, Jeremy Spilman suggests separating the issues of obtaining refund/memo fields and determining how transactions are broadcasted, retried, locked, and double-spent. He believes that the first issue can be solved without fully specifying behavior for the second.Chuck proposes a solution where customers send unsigned transactions and only the hashes of the fully signed transactions until the merchant acknowledges the unsigned versions. This ensures that the merchant can monitor the network for delivery of the signed transaction.Gavin Andresen and Jeff Garzik discuss the intent of Bitcoin's payment protocol, which is to give customers a great experience. However, there is a concern about the refund or memo feature, where merchants need an alternative route for delivering that information before the transaction is made.Pieter suggests measures to prevent a transaction from being broadcast without the payment delivered, such as attempting to send the payment to a specified payment_uri and making a reasonable attempt to deliver the payment when a transaction is broadcast. Once a paymentACK has been received, the client is no longer responsible for broadcasting the transaction.The conversation also covers the topic of broadcasting transactions in CoinJoin. It is agreed that broadcasting should only be necessary if the payment fails due to the imperfect fungibility of bitcoins. Delaying the broadcast of a transaction after inputs are signed can add complexity to implementation. Some wallets may not broadcast at all and instead try to submit via the payment URL. The goal is to achieve payment atomicity, where the customer losing control of funds is atomic with respect to the payment going through.Overall, the discussions focus on ensuring that merchants cannot act maliciously, finding ways to reliably obtain refund/memo fields, and determining responsibility for broadcasting transactions. The participants suggest various solutions and propose changes to the protocol to enhance the user experience and prevent fraudulent activities.In January 2014, Mike Hearn raised a question regarding whether the wallet should broadcast a transaction to the bitcoin network when it receives an ACK or if it should assume that the merchant server will handle it. He also suggested the inclusion of an error code field in future versions of Bitcoin to differentiate between failed/rejected submissions and successful ones beyond the freeform memo field. Hearn included a link to CenturyLink Cloud, emphasizing its role as a leader in enterprise cloud services.Currently, there is no way to distinguish between a failed or rejected submission and a successful one beyond the freeform memo field. Having an error code field in future versions would be beneficial for troubleshooting and identifying the cause of failed submissions. This addition could potentially save time and resources by enabling more efficient issue resolution.Gavin Andresen discussed the purpose of PaymentACK in payment processing. Its main function is to reassure customers that their payment request has been received and will be processed accordingly. If the payment request is found to be incorrect or invalid, a PaymentACK with a message indicating the problem should be sent as a response.One participant questioned whether it was necessary to always respond with an ack, even in problematic cases, to which Andresen clarified that an ack should always be sent. However, the participant suggested that the specification should explicitly state that sending a nack would result in connection closure without an ack. Additionally, they proposed renaming PaymentACK to PaymentResponse for greater clarity.Andreas Schildbach and Gavin Andresen discussed the purpose of PaymentACK in an email exchange. The BIP70 specification briefly explains that it is sent from the merchant's server to the bitcoin wallet in response to a Payment message. Its purpose is to provide reassurance to customers that their payment request has been received and will be processed (or not). If the payment is invalid or syntactically incorrect, a PaymentACK with a message indicating the problem should be sent.It is not recommended to wait for payment confirmation before sending an ACK, but waiting a few seconds to detect a potential double-spend attempt is acceptable. The BIP intentionally does not specify how long it may take to receive an ACK, but the goal is to provide customers with reassurance that their payment is being processed.The BIP70 specification provides limited information about what a PaymentACK signifies in response to a Payment message. It is unclear whether it indicates receipt of a syntactically correct payment, validity of the payment, or both. There is also uncertainty about how long an Acknowledgement can be delayed until all payment conditions are met. However, it is advised against keeping an HTTP or Bluetooth connection open for an extended period while awaiting blockchain confirmation.
Updated on: 2023-08-01T07:21:51.614337+00:00