Roy Badami [ARCHIVE] on Nostr: 📅 Original date posted:2012-11-29 📝 Original message:I'd still like to ...

📅 Original date posted:2012-11-29
📝 Original message: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