Author: Patrick Mead 2013-12-02 13:54:30
Published on: 2013-12-02T13:54:30+00:00
The author proposes a solution to the issue of accepting transactions in retail scenarios by adding a "fee" parameter to the payment URI specification. The idea is for the vendor to have responsibility for setting the fee, allowing them to choose the trade-off that works best for them in terms of fee size versus speed of processing. When processing the transaction, the customer's UI should only show the total price, including both the transfer amount and the fee. The vendor would only accept the transaction if the customer uses the right amount and fee. If the fee is too small, the vendor can issue a refund transaction immediately. The pros of this proposal include that it could easily be implemented immediately, old wallets would still be supported, there would be no greater risk of double spending on either side, it maintains the distributed nature of the system, it relies on humans to judge the fee, and it is flexible enough to support varying sizes of transactions and varying degrees of security. However, the cons include that it requires the vendor to have sufficient understanding of Bitcoin to make the trade-off, it doesn't solve the problem of selecting a fee for transactions between individuals/laymen, and it doesn't solve fee selection for automated transactions such as mixing/de/refragmentation.
Updated on: 2023-06-07T21:41:03.760839+00:00