Author: Timo Hanke 2013-04-28 18:03:04
Published on: 2013-04-28T18:03:04+00:00
In an email dated April 25th, 2013, Gavin Andresen discussed the bottleneck in code review and testing for v0.9, which needed to be done before work on a v2 could begin. In another email thread, the issue of how the current protocol protects the refund address was discussed. While protecting the payee against a compromised web server may be out of scope, signing the refund address is a more immediate concern that can be solved with marginal changes to the protocol. Payees can create PaymentDetails messages with an explicit pubkey in output.script, not an address, and if payment_url is specified, the payer hashes their Payment message and pays to h*pubkey, where h is the computed hash. Upon receiving the Payment message, the payee computes the same hash and can pick up their funds from h*pubkey. However, the drawback is that the payer has to backup the Payment message before submitting it or broadcasting the transaction in order to keep a proof. Refund address signing should probably be an option that the payer can choose after reading a backup warning.
Updated on: 2023-06-06T15:36:43.731106+00:00