Published on: 2014-01-30T12:38:10+00:00
The conversation revolves around the handling of transactions and payments in Bitcoinj. Mike Hearn explains that transactions are only committed to the wallet if the server accepts the Payment message and acknowledges it. However, Pieter Wuille states that this is not what is suggested or required by the specification, nor is it currently implemented in Bitcoin core master.Chuck expresses concerns about failure situations and emphasizes the importance of addressing these issues now rather than trying to patch solutions later. He suggests invalidating all transactions in the Payment message by broadcasting a send-to-self transaction as soon as possible to prevent an indeterminate wallet balance. Chuck also discusses the potential for merchants to force transactions into the user's wallet without an acknowledgement, resulting in the user paying without receiving an ACK.The conversation highlights the need for careful consideration of the current implementation's weaknesses and addressing them before evolving the protocol further. They discuss the use of arbitrators in Bitcoin transactions and potential trust issues with third parties. Suggestions are made to add signing to PaymentACK and other measures to address this issue in the future.Chuck and another party discuss the importance of addressing failure situations in the Bitcoin Core and bitcoinj protocols. They propose making minor changes now to prevent potential problems from arising later. Chuck identifies the delivery of the Payment message as a major hole in the implementation, suggesting that the protocol should do everything possible to prevent transactions from confirming without the payment message being delivered.In a conversation between Chuck and Mike Hearn, they discuss the Bitcoin Payment Protocol (PP) and the need for backwards compatibility in any changes made. Chuck emphasizes the importance of discussing failure situations now to avoid having to patch solutions later. He raises concerns about the current PP description and proposes making changes to address potential issues with the delivery of the Payment message. The conversation also touches on the use of arbitrators in payment transactions and the potential for merchants to lie or manipulate transactions.The conversation between Chuck and an unnamed individual centers around the implementation of Bitcoin Core and bitcoinj protocols. They discuss the importance of backwards compatibility in any changes made. They propose using a receipt including PaymentRequest and transactions as proof of payment, and suggest adding features such as ECDH key agreements and refunding addresses. They also emphasize the importance of the customer signing the message with the private key of the refund address. The conversation concludes with plans to evolve the PaymentRequest/Payment/PaymentACK protocol with backwards compatible upgrades.Peter (sipa) recommends forwarding a post to the mailing list for further discussion. The author of the post raises questions about BIP70 message delivery and the value of the PaymentACK message. The author suggests that if PaymentACK is never delivered, a receipt including PaymentRequest and transactions would suffice as proof of payment. The author proposes a slightly improved protocol, outlining required steps and optional steps. The proposed protocol includes measures to provide redundancy and verify transactions. The author seeks thoughts on the proposed protocol.
Updated on: 2023-08-01T07:33:42.801502+00:00