Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1W8pq4-0000ZC-WC
	for bitcoin-development@lists.sourceforge.net;
	Thu, 30 Jan 2014 11:31:21 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.174 as permitted sender)
	client-ip=209.85.214.174; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f174.google.com; 
Received: from mail-ob0-f174.google.com ([209.85.214.174])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1W8pq3-0007EF-2W
	for bitcoin-development@lists.sourceforge.net;
	Thu, 30 Jan 2014 11:31:20 +0000
Received: by mail-ob0-f174.google.com with SMTP id uy5so3308265obc.5
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 30 Jan 2014 03:31:03 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.102.134 with SMTP id fo6mr11058505obb.10.1391081463185; 
	Thu, 30 Jan 2014 03:31:03 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.99.112 with HTTP; Thu, 30 Jan 2014 03:31:03 -0800 (PST)
In-Reply-To: <52EA343E.4010208@borboggle.com>
References: <52E9E787.8080304@borboggle.com>
	<CANEZrP0soR0xRqW=vsKaL__HRuWstA5vW=6_JkGZm=8wkm8Q3g@mail.gmail.com>
	<52EA343E.4010208@borboggle.com>
Date: Thu, 30 Jan 2014 12:31:03 +0100
X-Google-Sender-Auth: eh61bszL9RjYtdjWyOlGKGigeck
Message-ID: <CANEZrP2JMGdcCa_6p-vmLJ3yO=GVBZXA39VLwiPRUbDu2zeH5w@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Chuck <chuck+bitcoindev@borboggle.com>
Content-Type: multipart/alternative; boundary=089e0149c3807789c604f12e64dc
X-Spam-Score: -0.5 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1W8pq3-0007EF-2W
Cc: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 11:31:21 -0000

--089e0149c3807789c604f12e64dc
Content-Type: text/plain; charset=UTF-8

On Thu, Jan 30, 2014 at 12:15 PM, Chuck <chuck+bitcoindev@borboggle.com>wrote:

> In arbitration the merchant could argue the transactions seen on the
> network were insufficient.
>

The arbitrator would presumably have some rules about what is or isn't an
acceptable form of payment.

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.

--089e0149c3807789c604f12e64dc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jan 30, 2014 at 12:15 PM, Chuck <span dir=3D"ltr">&lt;<a href=3D"mailto=
:chuck+bitcoindev@borboggle.com" target=3D"_blank">chuck+bitcoindev@borbogg=
le.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">In arbitration the merchant could argue the transactions s=
een on the network were insufficient.<br>
</blockquote><div><br></div><div>The arbitrator would presumably have some =
rules about what is or isn&#39;t an acceptable form of payment.</div><div><=
br></div><div>HTTP has response codes for submission of the Payment message=
. We could add signing to PaymentACK and other things in future, if that tu=
rns out to be insufficient in practice.</div>
</div></div></div>

--089e0149c3807789c604f12e64dc--