From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W95XE-000635-DD for bitcoin-development@lists.sourceforge.net; Fri, 31 Jan 2014 04:16:56 +0000 X-ACL-Warn: Received: from borboggle.com ([69.164.197.78] helo=mail.borboggle.com) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1W95XD-0006s5-Au for bitcoin-development@lists.sourceforge.net; Fri, 31 Jan 2014 04:16:56 +0000 Received: from [192.168.1.72] (unknown [180.183.149.52]) by mail.borboggle.com (Postfix) with ESMTPSA id 6B81DFA97; Thu, 30 Jan 2014 23:27:57 -0500 (EST) Message-ID: <52EB23A4.9@borboggle.com> Date: Fri, 31 Jan 2014 11:16:36 +0700 From: Chuck User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net, Jeremy Spilman , Pieter Wuille References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.4 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1W95XD-0006s5-Au Cc: Andreas Schildbach Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics 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: Fri, 31 Jan 2014 04:16:56 -0000 On 1/31/2014 3:16 AM, Jeremy Spilman wrote: > I think we want to separate the two issues; > > 1) Reliably getting refund/memo fields to the merchant/payee > 2) Who broadcasts a TX, how it's retried, how outputs are 'locked' and > if/when they should be [double]-spent to clear them > > We should be able to solve '1' without having to fully spec out behavior > for 2. My original message was focused on #1. Not only #1, but ensuring the merchant can't act maliciously too. As far as #2 is concerned, I don't think it makes any difference - it's in both the customer and the merchant's best interest to have the transactions confirmed. > c) Send them as a response to the PaymentRequest/PaymentDetails with the > UNsigned transaction, and then follow up with the signed transaction in a > separate message. ... > On Wed, 29 Jan 2014 21:47:51 -0800, Chuck > wrote: >> 3. Customer builds a set of transactions and sends a new >> PaymentApprovalRequest message which includes a refund address and the >> unsigned transactions and their associated fully-signed transactionhash, >> the whole message signed with the private key of the refund address. > "Unsigned transactions and their associated fully-signed transaction hash" > -- isn't that a fully signed transaction? In this case, it doesn't solve > the core problem of the server being able to broadcast that transaction > without ACKing. What I meant was (and maybe this was roundabout?): the customer includes the UNsigned transactions as well as the hashes (and only the hashes) of the fully signed transactions. The customer keeps the fully signed transactions private until the merchant ACKs the unsigned versions. If the merchant has the hash of the fully signed transaction, he can monitor the network for delivery of the signed transaction. It definitely complicates things, but it's nothing that can't be done. Cheers, Chuck