blob: aa7ae360698e5aaa9cd7f5121e51124cd45867f1 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
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 <chuck+bitcoindev@borboggle.com>) 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 <chuck+bitcoindev@borboggle.com>
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 <mike@plan99.net>
References: <52E9E787.8080304@borboggle.com> <CANEZrP0soR0xRqW=vsKaL__HRuWstA5vW=6_JkGZm=8wkm8Q3g@mail.gmail.com> <52EA343E.4010208@borboggle.com>
<CANEZrP2JMGdcCa_6p-vmLJ3yO=GVBZXA39VLwiPRUbDu2zeH5w@mail.gmail.com>
In-Reply-To: <CANEZrP2JMGdcCa_6p-vmLJ3yO=GVBZXA39VLwiPRUbDu2zeH5w@mail.gmail.com>
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 <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: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
|
