Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TdH4j-0000tW-Cz for bitcoin-development@lists.sourceforge.net; Tue, 27 Nov 2012 09:03:29 +0000 X-ACL-Warn: Received: from 2508ds5-oebr.1.fullrate.dk ([90.184.5.129] helo=mail.ceptacle.com) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1TdH4i-0004OV-FS for bitcoin-development@lists.sourceforge.net; Tue, 27 Nov 2012 09:03:29 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.ceptacle.com (Postfix) with ESMTP id 8F65726C3F6D for ; Tue, 27 Nov 2012 09:43:46 +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 vl4tnd1kfcdq for ; Tue, 27 Nov 2012 09:43:46 +0100 (CET) Received: from [109.105.106.200] (unknown [109.105.106.200]) by mail.ceptacle.com (Postfix) with ESMTPSA id 52C6A26C3F5B for ; Tue, 27 Nov 2012 09:43:46 +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: Date: Tue, 27 Nov 2012 09:43:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <895A1D97-68B4-4A2F-B4A1-34814B9BA8AC@ceptacle.com> References: 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: 1TdH4i-0004OV-FS 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 09:03:29 -0000 Short comments: * What if the SignedReceipt is not received AND the transactions IS = posted on the p2p. Then you have payed for the goods, but you don't have = a receipt. This could happen both from malice or system failures. ** Suggestion - sign the invoice with the key to which to send the = transaction, the proof of payment, equivalent to a signed receipt is = then in the blockchain. This scheme would work both with or without x509, if you want to include = x509, the message in the invoice could simply be signed by the x509 = certificate as well. PRO: Any user can send signed invoices, not only those with a x509 cert. PRO: No limbo situation with no SignedReceipt CON: This disables the use of anything but payment to key/address incl = multisig etc. However, the wast majority of use will anyway be payment to key/address. Support of general pay to script could be supported through the payment = scheme proposed earlier by Mike: No non-fee payments are accepted, = except in a group - i.e. it is up to the merchant to generate the final = transaction incl the fees, and that one could be to a general script. = This also keeps the support of pay to general script needed for a client = to a minimum. Cheers, Michael