rich1.0npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rhttps://nostr.ae/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rnjumphttps://nostr.ae📅 Original date posted:2012-11-27 📝 Original message:On Tue, Nov 27, 2012 at 11:42:01AM +0100, Michael Gronager wrote: > > > > The SignedReceipt message is useful in the sense that it shows > > confirmation by the merchant, but if you don't get one, you can still > > prove you paid the invoice. So from this perspective perhaps > > SignedReceipt should be renamed to Acceptance or something like that, > > and then the spec should call out that a signed invoice plus accepted > > Bitcoin transactions is mathematically a proof of purchase. > > Which is why I find the "SignedReceipt" somewhat superfluous. If you implement a payment system, like bit-pay/wallet you are likely to double that through some sort of e-mail receipt anyway. Gavin's proposal differs in this from my original proposal, where I exactly *didn't* want to couple the receipt with the acceptance of the Bitcoin transaction. If a merchant/payment processor is willing to take the risk of zero or low confirmation transactions (because they are insured against it, for example), they were allowed to reply "accepted" immediately, and this would be a permanent proof of payment, even if the actual Bitcoin transaction that backs it gets reverted. For that reason, I also had a separate "pending" state, which means the receiver isn't willing to just accept the current state as irrevocably paid. In this case, the sender was allowed to retry until the receipt sayd "accepted" or "rejected". The whole point was to avoid that customers/merchants would have to deal with the uncertainty involved in Bitcoin transaction. At some point, someone is going to accept the transaction (whether that is at 0 or at 120 confirmations), and acceptance will at the higher level be considered a boolean anyway - not some "probably, unless reorg". -- Pieter