From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TdJSg-0001eM-Qw for bitcoin-development@lists.sourceforge.net; Tue, 27 Nov 2012 11:36:22 +0000 X-ACL-Warn: Received: from vps7135.xlshosting.net ([178.18.90.41]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1TdJSe-0003tG-Gp for bitcoin-development@lists.sourceforge.net; Tue, 27 Nov 2012 11:36:22 +0000 Received: by vps7135.xlshosting.net (Postfix, from userid 1000) id E4A2F611E9; Tue, 27 Nov 2012 12:36:13 +0100 (CET) Date: Tue, 27 Nov 2012 12:36:13 +0100 From: Pieter Wuille To: Michael Gronager Message-ID: <20121127113612.GA25418@vps7135.xlshosting.net> References: <895A1D97-68B4-4A2F-B4A1-34814B9BA8AC@ceptacle.com> <626D0E73-1111-4380-AABE-6C8C65F2FFCC@ceptacle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <626D0E73-1111-4380-AABE-6C8C65F2FFCC@ceptacle.com> X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.8 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list 0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1TdJSe-0003tG-Gp Cc: Bitcoin Dev 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:36:23 -0000 On Tue, Nov 27, 2012 at 11:42:01AM +0100, Michael Gronager wrote: > > > > The SignedReceipt message is useful in the sense that it shows > > confirmation by the merchant, but if you don't get one, you can still > > prove you paid the invoice. So from this perspective perhaps > > SignedReceipt should be renamed to Acceptance or something like that, > > and then the spec should call out that a signed invoice plus accepted > > Bitcoin transactions is mathematically a proof of purchase. > > Which is why I find the "SignedReceipt" somewhat superfluous. If you implement a payment system, like bit-pay/wallet you are likely to double that through some sort of e-mail receipt anyway. Gavin's proposal differs in this from my original proposal, where I exactly *didn't* want to couple the receipt with the acceptance of the Bitcoin transaction. 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. For that reason, I also had a separate "pending" state, which means the receiver isn't willing to just accept the current state as irrevocably paid. In this case, the sender was allowed to retry until the receipt sayd "accepted" or "rejected". The whole point was to avoid that customers/merchants would have to deal with the uncertainty involved in Bitcoin transaction. At some point, someone is going to accept the transaction (whether that is at 0 or at 120 confirmations), and acceptance will at the higher level be considered a boolean anyway - not some "probably, unless reorg". -- Pieter