From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TdJcU-000882-2w for bitcoin-development@lists.sourceforge.net; Tue, 27 Nov 2012 11:46:30 +0000 X-ACL-Warn: Received: from 2508ds5-oebr.1.fullrate.dk ([90.184.5.129] helo=mail.ceptacle.com) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1TdJcO-0006t0-MB for bitcoin-development@lists.sourceforge.net; Tue, 27 Nov 2012 11:46:30 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.ceptacle.com (Postfix) with ESMTP id E63E426C59C0 for ; Tue, 27 Nov 2012 12:46:18 +0100 (CET) X-Virus-Scanned: amavisd-new at ceptacle.com Received: from mail.ceptacle.com ([127.0.0.1]) by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ct7vchoVViKL for ; Tue, 27 Nov 2012 12:46:18 +0100 (CET) Received: from [109.105.106.200] (unknown [109.105.106.200]) by mail.ceptacle.com (Postfix) with ESMTPSA id B3D4626C59B3 for ; Tue, 27 Nov 2012 12:46:18 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Michael Gronager In-Reply-To: <20121127113612.GA25418@vps7135.xlshosting.net> Date: Tue, 27 Nov 2012 12:46:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <895A1D97-68B4-4A2F-B4A1-34814B9BA8AC@ceptacle.com> <626D0E73-1111-4380-AABE-6C8C65F2FFCC@ceptacle.com> <20121127113612.GA25418@vps7135.xlshosting.net> To: Bitcoin Dev X-Mailer: Apple Mail (2.1499) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1TdJcO-0006t0-MB Subject: Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 11:46:30 -0000 >=20 > 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=