rich1.0npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwhttps://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwnjumphttps://nostr.ae📅 Original date posted:2012-11-29 📝 Original message:RE: Roy Badami's comments on edge cases around submitting a Payment message to a merchant and then not receiving a timely response: I agree, it is messy. I'm hesitant to try to specify One True Way of handling it in the spec; I've got a feeling that this might be a place where different implementations might try different things, with the best implementation winning. For example, if some future nifty-keen Bitcoin client is re-using an old Invoice to send a monthly subscription payment and they can't contact the paymentURI, then the right thing is probably for it to retry once a day for three or four days and if they all fail then give up and tell the user that the service is no longer in business (or changed their paymentURI without leaving behind a redirect). If it has a single-use Invoice created a minute or two ago, the right logic might be: + If the paymentURI is completely non-responsive, just error and tell the user "payment failed" + If connected to the paymentURI and payment sent, but disconnected before receiving a response, then try to send-to-self the coins to cancel payment. Again, I'm not at all sure that is the best way to handle it; implementors have the right incentives to give their users the best user experience, so I feel comfortable leaving the spec fuzzy for now. -- -- Gavin Andresen