📅 Original date posted:2014-02-03
📝 Original message:It's not limited to HTTP. I was pointing out that unsolicited
merchant-to-consumer messages don't work on HTTP (and a lot of other
situations), and so you can't add a need for it to the payment
protocol (since it wouldn't be usable in the majority of cases).
On Mon, Feb 3, 2014 at 3:30 PM, Tim Tuxworth Founder Go-taxi.biz
<tim at go-taxi.biz> wrote:
> Is BIP70 limited to http only?
>
> What about face to face scenarios, or realtime like ticket sales or
> gambling, and socket and/or bluetooth type connections?
>
> Tim Tuxworth
> Founder Go-Taxi.biz
>
>
> -------- Original message --------
> From: Christophe Biocca
> Date:2014/02/03 10:49 AM (GMT-08:00)
> To: Tim Tuxworth
> Cc: bitcoin-development at lists.sourceforge.net
> Subject: Re: [Bitcoin-development] BIP70: Canceling Payments
>
> Over http, the merchant doesn't have the ability to reach out to the
> consumer's bitcoin wallet on their own. So sending "Cancel Payment
> Request" to the user is impossible.
>
> If the customer doesn't want to send, nothing ever needs to happen. So
> sending a "Reject Payment Request" to the merchant is useless.
>
> The unhappy path scenario with Payment Requests (customer paid, but
> for whatever reason that payment is no longer valid) can be simply
> solved in 1 of 2 ways:
>
> If the merchant realizes the mistake, they can refund the money.
> If the customer realizes the problem, they can contact the merchant,
> provide the signed request, and ask the merchant to return the funds.
>
> What isn't covered?
>
> On Mon, Feb 3, 2014 at 1:08 PM, Tim Tuxworth <tim at go-taxi.biz> wrote:
>> The process described in BIP70 might be ok for a simple "happy path"
>> scenario, but what if things don't work so smoothly. I'm not talking
>> here about technical issues, but _very common_ business scenarios such as:
>>
>> e.g. Merchant cancels request before payment is sent, such as when:-
>> - the merchant realizes that they charged the wrong amount
>> - the merchant realizes that they send the payment request to the wrong
>> customer
>> ...
>>
>> e.g. the Merchant or Customer decides to cancel the transaction after
>> the payment request is sent because:-
>> - the customer decides to pay by some other mechanism like cash or
>> credit/debit
>> - the customer doesn't have sufficient funds and decides not to purchase
>> - the customer changes their mind and decides not to purchase
>> ...
>>
>> It strikes me that a "Cancel Payment Request" message is required
>> and a "Reject Payment Request" may also be required (or maybe use the
>> same message for both).
>>
>> Tim Tuxworth
>>
>>
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Christophe Biocca [ARCHIVE] /
npub1mt…9g5zm
2023-06-07 15:12:57
in reply to nevent1q…4uu7
Author Public Key
npub1mtxs7jztn027d9cylej99hltqq9vq84uxm80zl4naxafd9hpxqwsj9g5zmPublished at
2023-06-07 15:12:57Event JSON
{
"id": "31bade828d85d2198567b4b580b4fef427e67d91e234cd92d24a4c48700a283c",
"pubkey": "dacd0f484b9bd5e69704fe6452dfeb000ac01ebc36cef17eb3e9ba9696e1301d",
"created_at": 1686150777,
"kind": 1,
"tags": [
[
"e",
"581e40456bf142b1bf0aa41af407881bb0efaad61a52ade99b9d2789a9147eec",
"",
"root"
],
[
"e",
"507a44ec4450d16b6482e2c875790f9422414e3206536e224e2bab2fdc5ea3dc",
"",
"reply"
],
[
"p",
"3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc"
]
],
"content": "📅 Original date posted:2014-02-03\n📝 Original message:It's not limited to HTTP. I was pointing out that unsolicited\nmerchant-to-consumer messages don't work on HTTP (and a lot of other\nsituations), and so you can't add a need for it to the payment\nprotocol (since it wouldn't be usable in the majority of cases).\n\nOn Mon, Feb 3, 2014 at 3:30 PM, Tim Tuxworth Founder Go-taxi.biz\n\u003ctim at go-taxi.biz\u003e wrote:\n\u003e Is BIP70 limited to http only?\n\u003e\n\u003e What about face to face scenarios, or realtime like ticket sales or\n\u003e gambling, and socket and/or bluetooth type connections?\n\u003e\n\u003e Tim Tuxworth\n\u003e Founder Go-Taxi.biz\n\u003e\n\u003e\n\u003e -------- Original message --------\n\u003e From: Christophe Biocca\n\u003e Date:2014/02/03 10:49 AM (GMT-08:00)\n\u003e To: Tim Tuxworth\n\u003e Cc: bitcoin-development at lists.sourceforge.net\n\u003e Subject: Re: [Bitcoin-development] BIP70: Canceling Payments\n\u003e\n\u003e Over http, the merchant doesn't have the ability to reach out to the\n\u003e consumer's bitcoin wallet on their own. So sending \"Cancel Payment\n\u003e Request\" to the user is impossible.\n\u003e\n\u003e If the customer doesn't want to send, nothing ever needs to happen. So\n\u003e sending a \"Reject Payment Request\" to the merchant is useless.\n\u003e\n\u003e The unhappy path scenario with Payment Requests (customer paid, but\n\u003e for whatever reason that payment is no longer valid) can be simply\n\u003e solved in 1 of 2 ways:\n\u003e\n\u003e If the merchant realizes the mistake, they can refund the money.\n\u003e If the customer realizes the problem, they can contact the merchant,\n\u003e provide the signed request, and ask the merchant to return the funds.\n\u003e\n\u003e What isn't covered?\n\u003e\n\u003e On Mon, Feb 3, 2014 at 1:08 PM, Tim Tuxworth \u003ctim at go-taxi.biz\u003e wrote:\n\u003e\u003e The process described in BIP70 might be ok for a simple \"happy path\"\n\u003e\u003e scenario, but what if things don't work so smoothly. I'm not talking\n\u003e\u003e here about technical issues, but _very common_ business scenarios such as:\n\u003e\u003e\n\u003e\u003e e.g. Merchant cancels request before payment is sent, such as when:-\n\u003e\u003e - the merchant realizes that they charged the wrong amount\n\u003e\u003e - the merchant realizes that they send the payment request to the wrong\n\u003e\u003e customer\n\u003e\u003e ...\n\u003e\u003e\n\u003e\u003e e.g. the Merchant or Customer decides to cancel the transaction after\n\u003e\u003e the payment request is sent because:-\n\u003e\u003e - the customer decides to pay by some other mechanism like cash or\n\u003e\u003e credit/debit\n\u003e\u003e - the customer doesn't have sufficient funds and decides not to purchase\n\u003e\u003e - the customer changes their mind and decides not to purchase\n\u003e\u003e ...\n\u003e\u003e\n\u003e\u003e It strikes me that a \"Cancel Payment Request\" message is required\n\u003e\u003e and a \"Reject Payment Request\" may also be required (or maybe use the\n\u003e\u003e same message for both).\n\u003e\u003e\n\u003e\u003e Tim Tuxworth\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e Managing the Performance of Cloud-Based Applications\n\u003e\u003e Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.\n\u003e\u003e Read the Whitepaper.\n\u003e\u003e\n\u003e\u003e http://pubads.g.doubleclick.net/gampad/clk?id=121051231\u0026iu=/4140/ostg.clktrk\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development",
"sig": "8d0b71b52865e89fc064a164903284d3bacf5b18e16fa7a73e57f342198e211b478653faae9e2e61fc8652127254e07e136d92358e6fae6a1c959a456d81fecc"
}