<oembed><type>rich</type><version>1.0</version><author_name>npub1nc78dlt7hp3v5dl32qu3m678h2j0ss374glcjnz8df75xcx7ngpq4gw452</author_name><author_url>https://nostr.ae/npub1nc78dlt7hp3v5dl32qu3m678h2j0ss374glcjnz8df75xcx7ngpq4gw452</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2012-11-27&#xA;📝 Original message:&gt; &#xA;&gt; If a merchant/payment processor is willing to take the risk of zero or&#xA;&gt; low confirmation transactions (because they are insured against it,&#xA;&gt; for example), they were allowed to reply &#34;accepted&#34; immediately, and&#xA;&gt; this would be a permanent proof of payment, even if the actual Bitcoin&#xA;&gt; transaction that backs it gets reverted.&#xA;&#xA;I guess that moves the discussion from developers to lawyers ;) Even though you send a signed receipt, if you can proof you didn&#39;t get the money, you will never be expected to deliver the goods. (and you can even write that in the the receipt ...)&#xA;&#xA;So the SignedReceipt is legally not worth the bits it is composed of, hence I don&#39;t see the point in supporting it.&#xA;&#xA;If you are selling atoms you can usually wait for N confirmations (even though you start shipping I guess you can recall a parcel within 144 blocks). If you are selling bits (like access to a site), you can revoke that access once you discover the transaction did not go through. So I can&#39;t find a use case where a Signed Receipt in the proposed form is advantageous.&#xA;&#xA;/M</html></oembed>