Published on: 2014-03-31T09:23:09+00:00
On March 28th, 2014, Mike Hearn proposed adding a refund field to BIP 70 for easier implementation of refunds on phones. The discussion revolved around establishing an appropriate time frame for refunds. Two months or three months were considered, with concerns about RAM usage and EU DSD compliance. A fixed expiry time of 2.5 years was suggested to comply with EU regulations, but the consensus was to adopt a couple of months for refunds.The conversation also touched upon the use of stealth addresses with a per-order UUID to improve scalability. Privacy concerns were raised due to a reduction in OP_RETURN size. The PaymentRequest specification was discussed regarding refunds and the absence of a specified time limit. The EU Distance Selling Directive and varying refund time frames across countries were also mentioned.There was a discussion about implementing BIP70 by BitPay, BopShop, and Trezor. It was seen as an easy process with no reason to be enthusiastic until further specification enhancements. The need for a fixed warranty expiry time to allow for shipping was debated, considering RAM usage. The current payment protocol's inability to handle salaries was noted, and emphasis was placed on solving existing problems before creating new ones.The potential limitations of the Bitcoin payment protocol were discussed, including symmetrical payment options, aggregating and netting for multiple installments, and enhanced security for payment and refund addresses. Incremental development was favored, but caution was advised against adding too many features at once. The need for a payment channel for businesses to handle salaries was proposed.Tags in a contact list to represent different payment types were suggested. The address itself could serve as the tag for blockchain-based payments, allowing for better UI display. The benefits of creating a clean protocol for repeated payments in both directions were highlighted, along with the importance of the refund field for intelligent wallet UIs.Mike Hearn expressed reluctance to manage a business relationship with every shop and suggested focusing on the buyer-to-seller relationship for now. The need for a protocol that deals with the concept of business relationships was mentioned.Overall, the discussions revolved around refund time frames, implementation of BIP70, warranty expiration, payment protocol limitations, and the importance of incremental development to address existing problems.The discussion revolves around the limitations of BIP70, a payment protocol, and the need for it to expand its scope beyond basic buyer-to-seller relationships. The protocol is criticized for not addressing the concept of business relationships and lacking provisions for communication between merchants and buyers in cases where refunds are required after a long period of time. The suggestion is made to create a new protocol that allows parties to terminate the relationship at their own discretion, rather than being controlled by algorithms and timeouts.Andreas Schildbach questions the use of PaymentDetails as a solution to a problem, noting that most of the fields cannot be known in advance at the time of initial payment. However, the other person suggests that only a few specific fields would be needed for refunds. Andreas raises concerns about the lack of protection for the refund address and proposes signing it with a key that is also signing the Bitcoin transaction. The other person agrees that tampering should not be possible over secure channels like HTTPS or Bluetooth but also suggests the idea of a full-blown PaymentRequest with optional PKI signing for refunds, although normally a seller wouldn't need to know the identity of a buyer for refunds.Mike Hearn discusses the impact of modern devices lacking swap files, which creates issues for storing keys or transactions in memory. He suggests adding a new refund field that embeds a PaymentDetails structure instead of just a list of outputs to address the lack of an equivalent for refund addresses. Alternatively, a wallet-specific swapping process could be used to create "infinite" wallets, but this may result in huge Bloom filters that hurt efficiency. Key expiry is considered fundamental to scalability.In conclusion, the limitations of BIP70 are highlighted, specifically regarding the narrow scope of the current payment protocol and the lack of provisions for refunds. Suggestions are made to either incorporate a refund field that embeds a PaymentDetails structure or implement a wallet-specific swapping process. The importance of key expiry and the impact of modern devices lacking swap files on storing keys or transactions in memory are also discussed. Overall, adding a refund feature with a time limit is seen as necessary to avoid wallets having to search for refunds for payments made years ago.
Updated on: 2023-08-01T08:14:12.745877+00:00