Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W8q1Z-0004rk-0M for bitcoin-development@lists.sourceforge.net; Thu, 30 Jan 2014 11:43:13 +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 1W8q1Y-0006hT-8W for bitcoin-development@lists.sourceforge.net; Thu, 30 Jan 2014 11:43:12 +0000 Received: from [192.168.1.72] (unknown [180.183.159.154]) by mail.borboggle.com (Postfix) with ESMTPSA id 2A003F86F; Thu, 30 Jan 2014 06:54:13 -0500 (EST) Message-ID: <52EA3AC0.5090709@borboggle.com> Date: Thu, 30 Jan 2014 18:42:56 +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: Mike Hearn References: <52E9E787.8080304@borboggle.com> <52EA343E.4010208@borboggle.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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: 1W8q1Y-0006hT-8W Cc: Bitcoin-Dev Subject: Re: [Bitcoin-development] BIP70 message delivery reliability 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: Thu, 30 Jan 2014 11:43:13 -0000 On 1/30/2014 6:31 PM, Mike Hearn wrote: > The arbitrator would presumably have some rules about what is or isn't > an acceptable form of payment. Do you think this puts unnecessary trust into a third party? If the merchant instead signed and agreed to the unsigned transactions before they were broadcast (as in my OP), these arbitration concerns disappear. > HTTP has response codes for submission of the Payment message. We > could add signing to PaymentACK and other things in future, if that > turns out to be insufficient in practice. HTTP isn't the only message delivery mechanism. Merchants can also lie: reply with 200 OK and an empty body. Or, reply with 404 not found and broadcast transactions anyway. Cheers, Chuck