📅 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
Roy Badami [ARCHIVE] /
npub1tr…0f95j
2023-06-07 10:42:01
in reply to nevent1q…0eq2
Author Public Key
npub1trckpcxmceskq4cykxgwxm63n8ugrjrpu5mk83c90e4upsf7d9gqf0f95jPublished at
2023-06-07 10:42:01Event JSON
{
"id": "42ab733bcbc1f1cbf93bd8a8b59858dc2cd593e10da3238322918125cb064ba7",
"pubkey": "58f160e0dbc661605704b190e36f5199f881c861e53763c7057e6bc0c13e6950",
"created_at": 1686134521,
"kind": 1,
"tags": [
[
"e",
"f5f2400f8aa8a7067be3d080f096fd7cbfeecdd6e589c178b85b63a9338150a5",
"",
"root"
],
[
"e",
"9facb1d6fb181501743457c9c4f831a31da29cbd66801f5177a14b98e8ae9c1f",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "📅 Original date posted:2012-11-29\n📝 Original message:I'd still like to understand the rationale for having the merchant\nbroadcast the transaction - it seems to add complexity and create edge\ncases.\n\nHow about this as an alternative proposal:\n\nThe buyer's client prepares the transaction and computes its txid. It\nthen sends a ValidatePurchase message to the merchant containing the\nproposed Outputs and a copy of the merchant_data along with the txid.\n\nAssuming the proposed payment is accepted as valid by the merchant,\nthe buyer's client simply broadcasts the pre-prepared transaction in\nthe normal way, and it is the merchant's responsibility to watch for\nthis transaction to arrive over the p2p network/blockchain to complete\nthe purchase. (So if the merchant rejects the purchase at the\nValidatePurchase stage, they never get to see the transaction that the\nbuyer prepared, and there's therefore no need for a send-to-self to\ncancel it.)\n\nAn optional RequestReceipt message (perhaps containing the\nmerchant_data and txid) can be sent by the client after the\ntransaction has been broadcast - but by making this explicitly\noptional it forces the merchant to rely on seeing the bitcoin\ntransaction to 'commit' the payment and not on the RequestReceipt\nmessage.\n\nAs far as I can see this proposal has no edge cases where the buyer\nand merchant have differing ideas as to whether the transaction has\n'comitted' - or at least, no more edge cases than the standard bitcoin\nprotocol has.\n\nroy",
"sig": "1c0e8c722ea3478b3d5d398e6b1b1a623c6e4c93a701a47e258759ca0b2ebffcc4a9da07cfcff387e6e78e09f29b1ea4ae323f2b825d5e3493093d3c133053a2"
}