<oembed><type>rich</type><version>1.0</version><author_name>npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd</author_name><author_url>https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2012-11-27&#xA;📝 Original message:On Tue, Nov 27, 2012 at 9:43 AM, Michael Gronager &lt;gronager at ceptacle.com&gt; wrote:&#xA;&gt; * What if the SignedReceipt is not received AND the transactions IS posted on the p2p.&#xA;&#xA;I think this is a problem with confusing terminology rather then the&#xA;spec itself.&#xA;&#xA;The original formulation had a receipt being something generated&#xA;purely by the buyer. The signed Invoice message  + the Bitcoin&#xA;transactions paying to the outputs + the merkle branches showing&#xA;acceptance by the network *is* the receipt.&#xA;&#xA;The SignedReceipt message is useful in the sense that it shows&#xA;confirmation by the merchant, but if you don&#39;t get one, you can still&#xA;prove you paid the invoice. So from this perspective perhaps&#xA;SignedReceipt should be renamed to Acceptance or something like that,&#xA;and then the spec should call out that a signed invoice plus accepted&#xA;Bitcoin transactions is mathematically a proof of purchase.</html></oembed>