> 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.

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!
Bitcoin-development mailing list

Reply via email to