Published on: 2014-01-14T13:18:38+00:00
One potential flaw in the payment system involving contract hash is that it assumes the merchant will cash the funds or reimburse via the refund address. However, a rational yet abusive move for the merchant would be to let the buyer's funds sit in limbo and force the buyer to initiate a dispute. Dispute resolution may not be worth the cost, especially if the seller is anonymous or located in another country. To address this issue, it may be beneficial for the buyer to have time-stamped evidence of sending the funds to the merchant and proof that the merchant did not collect the funds. This evidence could include omission from the blockchain.The discussion revolves around fair advertising rules, particularly in the context of dynamic pricing and revocable bids in trading. The concern is that merchants may use aggressive tactics such as retracting offers after partial commitment from customers or systematic abuse of pricing mistakes. One approach is to send a payment message to the merchant who then broadcasts the transaction to claim funds, with the user relying on the merchant for retraction. Another approach is for the user to broadcast the transaction and payment message to the merchant. To prevent retraction, the transaction can be bound to the payment message using a hash function. It is noted that if a merchant systematically retracts advertised offers, it could be evidence of unfair trading leading to censure.In an email conversation on January 14, 2014, Mike Hearn posed a hypothetical question about payment requests and merchants changing their minds. The email thread discusses the legal binding of a payment request for a specified amount of time, where if the merchant changes his mind after receiving payment from the customer, it is considered problematic. The email also talks about how a payment request is legally binding, and the contract becomes valid if the customer accepts the offer by paying. It mentions that there are extreme cases covered by law that can override this process. The email concludes with questions about the relevance of an expiry time in the message and the purpose of a payment request if it's not binding.As a prospective buyer, imagine receiving an offer from a merchant that you would like to accept, but the merchant changes their mind. In most cases, if the merchant has not delivered the product or service yet, they are allowed to change their mind without any issues. The problem arises only when the merchant changes their mind after you have made the payment.In an email exchange, Pieter Wuille expressed his concerns about the possibility of a transaction being confirmed while the associated payment is not delivered. He stated that if this happens, it means that the payment transmission cannot be relied upon. However, he later acknowledged that there may be certain situations where broadcasting the transaction to the peer-to-peer network would be necessary even if the payment messages are lost. Specifically, in cases where merchants change their minds about accepting payments after a good offer has been made, broadcasting the transaction to the blockchain would allow for the presentation of confirmed payment requests in legal proceedings.The context of the conversation involves a proposal by an individual named Pieter Wuille regarding the use of a payment protocol for face-to-face payments. The proposal entails using payment requests via NFC or QR, payment messages and payment confirmations through Bluetooth. Wuille suggests that this can be done by incorporating a Bluetooth MAC address into the payment URL. The person responding to the proposal acknowledges this suggestion and expresses no issues with it.In an email exchange between Andreas Schildbach and Pieter Wuille, the two discussed the issue of ensuring that a payment is delivered with a Bitcoin transaction. Wuille proposed that if a payment URL is present, it should be encouraged to only send the payment there instead of broadcasting the transaction on the P2P network, which would minimize the risk of confirming a transaction without receiving payment. Schildbach agreed with this proposal but also noted that wallets must still be able to deal with scenarios where the payment fails even if the transaction succeeds. Wuille expressed his desire to use the payment protocol for face-to-face payments as well, using NFC or QR for payment requests and Bluetooth for payment confirmations. Schildbach was aware of this and asked what issues Wuille saw. The two also discussed the potential for HTTP failures in payments over the internet.In an email dated January 13, 2014, Pieter Wuille suggested optimizing BitcoinJ's payment URL feature by only sending payments through the URL and not broadcasting transactions on the P2P network. This would minimize the risk of a transaction confirming without the payment being received, though it cannot be guaranteed. However, another individual questioned the effectiveness of this approach, arguing that relying solely on HTTP connections could result in more failed payments due to potential issues with proxies or Bluetooth endpoints. They suggested having fallback payment URLs in case of such failures.
Updated on: 2023-08-01T07:15:42.657911+00:00