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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1W8FxR-0005ii-Tp
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Jan 2014 21:12:33 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.58 as permitted sender)
client-ip=62.13.149.58; envelope-from=pete@petertodd.org;
helo=outmail149058.authsmtp.co.uk;
Received: from outmail149058.authsmtp.co.uk ([62.13.149.58])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1W8FxQ-0003KE-KF for bitcoin-development@lists.sourceforge.net;
Tue, 28 Jan 2014 21:12:33 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id s0SLCPbK021613;
Tue, 28 Jan 2014 21:12:25 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s0SLCItf000187
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 28 Jan 2014 21:12:20 GMT
Date: Tue, 28 Jan 2014 16:12:18 -0500
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20140128211218.GE22059@savin>
References: <lc409d$4mf$1@ger.gmane.org>
<CABsx9T1Y3sO6eS54wsj377BL4rGoghx1uDzD+SY3tTgc1PPbHg@mail.gmail.com>
<CANEZrP0ENhJJhba8Xwj_cVzNKGDUQriia_Q=JWTXpztb6ic8rg@mail.gmail.com>
<CAEY8wq4QEO1rtaNdjHXR6-b3Cgi7pfSWk7M8khVi0MHCiVOBzQ@mail.gmail.com>
<CAPg+sBgUNYqYm7d4Rv+f0rBa=nSuqwmZ6_REBS7M-+Wea+za0g@mail.gmail.com>
<CAEY8wq6n_27Y2N7fVw9uJkfiiYqi6JkTwO0q03_J7tUeBhdQYA@mail.gmail.com>
<CANEZrP0HVJ7Uzow1=4-20LnejURqO5uo16H43uhL=TtNfzhAxQ@mail.gmail.com>
<CABsx9T2ng9vGMmfFK95A1jBK-FotDL-fA1oOt-=zosCPaug-rQ@mail.gmail.com>
<20140128172349.GA14168@savin>
<CANEZrP0TiZMzNei2R-cBHGLxF4ts5Pe1_U4V6iQFV7y+Eu_MAA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="KuLpqunXa7jZSBt+"
Content-Disposition: inline
In-Reply-To: <CANEZrP0TiZMzNei2R-cBHGLxF4ts5Pe1_U4V6iQFV7y+Eu_MAA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: e08abad4-8860-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
bgdMdAoUElQaAgsB AmIbWVVeUV97W2I7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrAX99 dWdaBBlydwROfzBy Z0BmXj4OXEwrJxcp
RlNcHWsGeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4hPwZj H0JKJTw+GEADWwwY
DFQ9J1sVGloQOV5a
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1W8FxQ-0003KE-KF
Cc: Andreas Schildbach <andreas@schildbach.de>,
Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics
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: Tue, 28 Jan 2014 21:12:34 -0000
--KuLpqunXa7jZSBt+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jan 28, 2014 at 06:33:28PM +0100, Mike Hearn wrote:
> In practice this should only be an issue if a payment is submitted and
> fails, which should be rare. Barring internal server errors and screwups =
on
> the merchants side, the only reasons for a rejection at submit time would
> be the imperfect fungibility of bitcoins, e.g. you try and pay with a huge
> dust tx or one that's invalid/too low fee/etc.
>=20
> So I think we have a bit of time to figure this out. But yes - once you
> broadcast, you probably accept that there might be a more painful path to
> resolve issues if something goes wrong, I guess. Right now BitPay has a
> support system where you can file a ticket if you pay the bitcoins and th=
ey
> don't recognise it or the tx never confirms or whatever. It's grotty manu=
al
> work but they do it. Not broadcasting unless you "have" to seems like an
> optimisation that can reduce pain without much additional complexity.
That's the reason you use a model where things happen atomicly: the
funds either can or can't be transferred, so if the merchant screws up
due to a server failure at worst the wallet can always send the
original, signed, payment request and transaction details proving to the
merchant that they agreed. Since the asked for txouts exist in the
blockchain they must either refund the money, or ship the goods.
Wallet software can handle that kind of worst-case failure by
automatically sending the original payment request back to the merchant.
At worst all customer support has to do is tell the customer "Sorry
about that; we didn't get your payment. Please start your wallet up and
hit the 'resend transaction' button in your wallet and we'll clear that
right up."
Keep in mind that we're probably going to see fraudsters figuring out
ways to make payment servers fail. This means conversely that a customer
calling up a merchant and saying "Hey! Something didn work but the
wallet says I paid!" is going to be treated more suspiciously. By using
atomic protocols the issue of did or didn't they pay becomes much more
black and white, and failure resistant. That's exactly what we keep
saying Bitcoin offers that PayPal doesn't.
--=20
'peter'[:-1]@petertodd.org
000000000000000085c725a905444d271c56fdee4e4ec7f27bdb2e777c872925
--KuLpqunXa7jZSBt+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGrBAEBCACVBQJS6B0xXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDA4NWM3MjVhOTA1NDQ0ZDI3MWM1NmZkZWU0ZTRlYzdmMjdi
ZGIyZTc3N2M4NzI5MjUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfu+TAf/diHpRv0a8Izo9+qY8qu2zLTZ
GMfj6KRuDTzfTKtXEH7Vr6tRbIqjuUOxC5WrSmikmsk9Hl4ryunoBPrm2HT+/7DG
gLLFM7jebpyE+Iu+ONgsq7brseUbM1bjw9lDYYFkk3LtmnzrA5l5S+3gQ/kUSmyI
KnKdO0Y+iUJTDaYWM5vRKJijzYB5mbubXJ/9CmVuNA/JY+toCtSCumIXKbfyFsmD
A8B5hyMjpCYA2btIQC1aNAW509XxCRTfEr5Q7d8MSRteyf0nxGfARdGcxMQDYGGL
A6uym/jdJmko4VGGmDkM2AgnHHQ2TbZa1pZUyS2A9nBLUYiB9KpxZ+bd50n4aA==
=xdu1
-----END PGP SIGNATURE-----
--KuLpqunXa7jZSBt+--
|
