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 1W8sy3-0003r5-0A for bitcoin-development@lists.sourceforge.net; Thu, 30 Jan 2014 14:51:47 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com designates 74.125.82.43 as permitted sender) client-ip=74.125.82.43; envelope-from=jgarzik@bitpay.com; helo=mail-wg0-f43.google.com; Received: from mail-wg0-f43.google.com ([74.125.82.43]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W8sy0-0000JX-Mp for bitcoin-development@lists.sourceforge.net; Thu, 30 Jan 2014 14:51:46 +0000 Received: by mail-wg0-f43.google.com with SMTP id y10so6505450wgg.22 for ; Thu, 30 Jan 2014 06:51:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pAlSnS3tS0Ao5lhkym67sBK7LO+KcZtMKz0/fxqP7wE=; b=BpoqfCqseew4CxGitNH81Gr4x8jvWQh52oCbp9FkfQDdUivpZw8e2FiMfHHyeRXLQa lVU6uwzRskMC0bG7tX6LOslKQvtZAf4xk+ptlbnCs+XOnel+yYav18AAC1dLrVpoTk5X LGxxzRUhpYdkMB4aFaokHk9iqM7EXYpvgFdBjhisS5vuKVOmVfSDJg1ERfuhuYGFNXvF AiTklLhk1KjV8jnrI2Ri/i8++hnGS+2VP3Bv/ze8wU4uzj1PeVnnU0+UQJg7U/sH1+wa mAfgVBh/kJRF6VQTZDDb1XKfL7QcQOnbrWwYBfWdoaucREeBblWu9YGnPeibJW/6now1 vOqw== X-Gm-Message-State: ALoCoQnLeNXW9xLq/CvX2ohPoCl09B0NCfjTYfag1oEXbH3DrhGSX/jXcsHn5UW3CNWf4wWN6q2a MIME-Version: 1.0 X-Received: by 10.180.184.105 with SMTP id et9mr23133902wic.36.1391093484210; Thu, 30 Jan 2014 06:51:24 -0800 (PST) Received: by 10.194.2.164 with HTTP; Thu, 30 Jan 2014 06:51:24 -0800 (PST) In-Reply-To: References: Date: Thu, 30 Jan 2014 09:51:24 -0500 Message-ID: From: Jeff Garzik To: Pieter Wuille Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1W8sy0-0000JX-Mp Cc: Andreas Schildbach , Bitcoin Dev 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: Thu, 30 Jan 2014 14:51:47 -0000 On Mon, Jan 27, 2014 at 5:17 PM, Pieter Wuille wrote: > On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene wrote: > > Should the wallet broadcast the transaction to the bitcoin network when it > > receives an ACK, or always assume that the merchant server will do that? > In my opinion, that should be the primary meaning of receiving an ACK: > acknowledgement that the receiver takes responsibility for getting the > transaction confirmed (to the extent possible, of course). Is this truly the intent? That the merchant/processor takes full responsibility for getting the TX confirmed? It is within the customer's economic incentive -- and right as a free person -- to work to get their transaction relayed to the network and confirmed in parallel with whatever the merchant is doing. BIP 70 states that the customer broadcasts the transaction, in addition to sending the Payment message. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/