I'd still like to understand the rationale for having the merchant broadcast the transaction - it seems to add complexity and create edge cases.
How about this as an alternative proposal: The buyer's client prepares the transaction and computes its txid. It then sends a ValidatePurchase message to the merchant containing the proposed Outputs and a copy of the merchant_data along with the txid. Assuming the proposed payment is accepted as valid by the merchant, the buyer's client simply broadcasts the pre-prepared transaction in the normal way, and it is the merchant's responsibility to watch for this transaction to arrive over the p2p network/blockchain to complete the purchase. (So if the merchant rejects the purchase at the ValidatePurchase stage, they never get to see the transaction that the buyer prepared, and there's therefore no need for a send-to-self to cancel it.) An optional RequestReceipt message (perhaps containing the merchant_data and txid) can be sent by the client after the transaction has been broadcast - but by making this explicitly optional it forces the merchant to rely on seeing the bitcoin transaction to 'commit' the payment and not on the RequestReceipt message. As far as I can see this proposal has no edge cases where the buyer and merchant have differing ideas as to whether the transaction has 'comitted' - or at least, no more edge cases than the standard bitcoin protocol has. roy ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
