📅 Original date posted:2014-04-26
📝 Original message:>
> The main area of concern is handling unexpected problems while sending
> the Payment message, or receiving the corresponding PaymentACK message.
> For example, in case of a transport layer failure or non-200 HTTP status
> code while sending the Payment message, what should the wallet software
> do next? Is it safe to re-send the Payment message? I'd propose that for
> any transport failure or 500 status code, the client retries after a
> delay (suggested at 30-60 seconds). For 400 status codes, the request
> should not be repeated, and as such the user should be alerted and a
> copy of the Payment message saved to be resent later.
>
Why does error handling have to be standardized?
I generally think that wallet software should be free to do whatever gives
the user the best experience, so I'm in favor of restricting BIPs to things
that must be standardized so that different implementations inter-operate.
> For 300 (redirect and similar) status codes, is it considered safe to
> follow redirects? I think we have to, but good to make it clear in the
> specification.
>
Referencing whatever RFCs defines how to fetch URLs would be the best way
to do this. Submit a pull request.
>
> On the merchant's side; I think it would be useful for there to be
> guidance for handling of errors processing Payment messages. I'd suggest
> that Payment messages should have a fixed maximum size to avoid merchant
> systems theoretically having to accept files of any size; 10MB would
> seem far larger than in any way practical, and therefore a good maximum
> size?
PaymentRequests are limited to 50,000 bytes. I can't think of a reason why
Payment messages would need to be any bigger than that. Submit a pull
request to the existing BIP.
> A defined maximum time to wait (to avoid DDoS via connection
> holding) might be useful too, although I'd need to do measurements to
> find what values are tolerable.
>
Implementation detail that doesn't belong in the spec, in my humble opinion.
> I would like to have the protocol state that merchant systems should
> handle repeatedly receiving the same Payment message, and return an
> equivalent (if not identical) PaymentACK to each. This is important in
> case of a network failure while the client is sending the Payment
> message, as outlined above.
>
I think this should be left to implementations to work out.
> Lastly, I'm wondering about potential timing issues with transactions;
> if a merchant system wants to see confirmation of a transaction before
> sending a PaymentACK...
.... not a good idea. The user should get feedback right away. Poking a
"pay now" button and then waiting more than a second or three to get "your
payment has been received and is being processed" is terrible UI.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140426/612df373/attachment.html>;
Gavin Andresen [ARCHIVE] /
npub1s4…d44kw
2023-06-07 15:20:15
in reply to nevent1q…uhzp
Author Public Key
npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwPublished at
2023-06-07 15:20:15Event JSON
{
"id": "517c1ba4dcb221dcb3aadb4ce53222d78c79c197f6c45a67670de710d3894875",
"pubkey": "857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4",
"created_at": 1686151215,
"kind": 1,
"tags": [
[
"e",
"943033598b3a5b6f707aaca5dd69e4ac8ea6602b877b930b1fb35d7cc72d4f16",
"",
"root"
],
[
"e",
"0db28f184e807671cec2653ecf81aae1e9a472caad1e26aa23bbe0cc2b35b638",
"",
"reply"
],
[
"p",
"3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc"
]
],
"content": "📅 Original date posted:2014-04-26\n📝 Original message:\u003e\n\u003e The main area of concern is handling unexpected problems while sending\n\u003e the Payment message, or receiving the corresponding PaymentACK message.\n\u003e For example, in case of a transport layer failure or non-200 HTTP status\n\u003e code while sending the Payment message, what should the wallet software\n\u003e do next? Is it safe to re-send the Payment message? I'd propose that for\n\u003e any transport failure or 500 status code, the client retries after a\n\u003e delay (suggested at 30-60 seconds). For 400 status codes, the request\n\u003e should not be repeated, and as such the user should be alerted and a\n\u003e copy of the Payment message saved to be resent later.\n\u003e\n\nWhy does error handling have to be standardized?\n\nI generally think that wallet software should be free to do whatever gives\nthe user the best experience, so I'm in favor of restricting BIPs to things\nthat must be standardized so that different implementations inter-operate.\n\n\n\u003e For 300 (redirect and similar) status codes, is it considered safe to\n\u003e follow redirects? I think we have to, but good to make it clear in the\n\u003e specification.\n\u003e\n\nReferencing whatever RFCs defines how to fetch URLs would be the best way\nto do this. Submit a pull request.\n\n\n\u003e\n\u003e On the merchant's side; I think it would be useful for there to be\n\u003e guidance for handling of errors processing Payment messages. I'd suggest\n\u003e that Payment messages should have a fixed maximum size to avoid merchant\n\u003e systems theoretically having to accept files of any size; 10MB would\n\u003e seem far larger than in any way practical, and therefore a good maximum\n\u003e size?\n\n\nPaymentRequests are limited to 50,000 bytes. I can't think of a reason why\nPayment messages would need to be any bigger than that. Submit a pull\nrequest to the existing BIP.\n\n\n\u003e A defined maximum time to wait (to avoid DDoS via connection\n\u003e holding) might be useful too, although I'd need to do measurements to\n\u003e find what values are tolerable.\n\u003e\n\nImplementation detail that doesn't belong in the spec, in my humble opinion.\n\n\n\u003e I would like to have the protocol state that merchant systems should\n\u003e handle repeatedly receiving the same Payment message, and return an\n\u003e equivalent (if not identical) PaymentACK to each. This is important in\n\u003e case of a network failure while the client is sending the Payment\n\u003e message, as outlined above.\n\u003e\n\nI think this should be left to implementations to work out.\n\n\n\u003e Lastly, I'm wondering about potential timing issues with transactions;\n\u003e if a merchant system wants to see confirmation of a transaction before\n\u003e sending a PaymentACK...\n\n\n.... not a good idea. The user should get feedback right away. Poking a\n\"pay now\" button and then waiting more than a second or three to get \"your\npayment has been received and is being processed\" is terrible UI.\n\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140426/612df373/attachment.html\u003e",
"sig": "509d9584626d3e03e957b03fa8848e38978362b94436bb55d050beab7eb38969d9647112501addaf84c2b878d563d13386325890c6d6e25eb8903c4ed983772e"
}