> > 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.
I guess that moves the discussion from developers to lawyers ;) Even though you send a signed receipt, if you can proof you didn't get the money, you will never be expected to deliver the goods. (and you can even write that in the the receipt ...) So the SignedReceipt is legally not worth the bits it is composed of, hence I don't see the point in supporting it. 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't find a use case where a Signed Receipt in the proposed form is advantageous. /M ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
