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
152
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1W8COK-0006R6-26
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Jan 2014 17:24:04 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.106 as permitted sender)
client-ip=62.13.148.106; envelope-from=pete@petertodd.org;
helo=outmail148106.authsmtp.co.uk;
Received: from outmail148106.authsmtp.co.uk ([62.13.148.106])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1W8COI-0007wY-6g for bitcoin-development@lists.sourceforge.net;
Tue, 28 Jan 2014 17:24:04 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s0SHNsx3014690;
Tue, 28 Jan 2014 17:23:54 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 s0SHNnkY090285
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 28 Jan 2014 17:23:52 GMT
Date: Tue, 28 Jan 2014 12:23:49 -0500
From: Peter Todd <pete@petertodd.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20140128172349.GA14168@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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o"
Content-Disposition: inline
In-Reply-To: <CABsx9T2ng9vGMmfFK95A1jBK-FotDL-fA1oOt-=zosCPaug-rQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: f569f8f4-8840-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
bgdMdAoUElQaAgsB AmIbWlNeUl57XGE7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrAX95 eEBFOxl7dwdOfTBy Z0ZhXj4NWUJzI04r
RlNcHWkGeGZhPWMC 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: 1W8COI-0007wY-6g
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Andreas Schildbach <andreas@schildbach.de>
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 17:24:04 -0000
--IS0zKkzwUGydFO0o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jan 28, 2014 at 07:53:14AM -0500, Gavin Andresen wrote:
> On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn <mike@plan99.net> wrote:
>=20
> > Yeah, that's the interpretation I think we should go with for now. There
> > was a reason why this isn't specified and I forgot what it was - some
> > inability to come to agreement on when to broadcast vs when to submit v=
ia
> > HTTP, I think.
> >
>=20
> If the wallet software is doing automatic CoinJoin (for example), then
> typically one or several of the other participants will broadcast the
> transaction as soon as it is complete.
>=20
> If the spec said that wallets must not broadcast until they receive a
> PaymentACK (if a payment_url is specified), then you'd have to violate the
> spec to do CoinJoin.
>=20
> And even if you don't care about CoinJoin, not broadcasting the transacti=
on
> as soon as the inputs are signed adds implementation complexity (should y=
ou
> retry if payment_url is unavailable? how many times? if you eventually
> unlock the probably-not-quite-spent-yet inputs, should you double-spend
> them to yourself just in case the merchant eventually gets around to
> broadcasting the transaction, or should you just unlock them and squirrel
> away the failed Payment so if the merchant does eventually broadcast you
> have a record of why the coins were spent).
Also users don't have infinite unspent txouts in their wallets - if they
need to make two payments in a row and run out their wallet software is
(currently) going to spend the change txout and either be forced to
broadcast both transactions anyway, or the second payment-protocol-using
recipient will do so on their behalf. (in the future they might also do
a replacement tx replacing the first with a single tx paying both to
save on fees, again with the same problem)
Anyway what you want is payment atomicity: the customer losing control
of the funds must be atomic with respect to the payment going through.
=46rom that point of view it's unfortunate that Payment message contains
refund_to, memo, etc. That information should have been provided to the
merchant prior to them providing the list of addresses to pay.
--=20
'peter'[:-1]@petertodd.org
000000000000000085c725a905444d271c56fdee4e4ec7f27bdb2e777c872925
--IS0zKkzwUGydFO0o
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGrBAEBCACVBQJS5+ekXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDA4NWM3MjVhOTA1NDQ0ZDI3MWM1NmZkZWU0ZTRlYzdmMjdi
ZGIyZTc3N2M4NzI5MjUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvgawf/QRLs1/9UNwVtb6kN+e2QQPAJ
FG9SfOAU3MOB7np/HkhEpqRZew5u0cLAUni/b1p30GVpbvh5yujIAJvNkOfH1hDC
ysRHFSqfeUbB+Vemt6v4EO33/T4Lj5BqleY1DhqXni2BJ75mk0AHw5h2nzYXFbZV
U+j3AXokG+6ShszapL+wCZUcBMuKtRVZYzhq1aCGKCQL8kmZHeU+dKhiGM0IwSQU
xeWjWGZqZoG/r6QQlGs8Z+RCnpvIQXncbnNGGIzHG4X+OKclVoyRLtZ/Tn5nx7EU
u6xdKG3+STR4j//hl+srT3QrT6fOYJpLhMWc52NGx7Ku4rQgApNZCEmD0bqSjQ==
=bkXh
-----END PGP SIGNATURE-----
--IS0zKkzwUGydFO0o--
|
