summaryrefslogtreecommitdiff
path: root/a4/88ef821b8cf85aee2b9722475825544e93ba9b
blob: c198ea903bcff5bba4d097aa32b8955fb17dd7c7 (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
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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1W88ef-0006Ph-QW
	for bitcoin-development@lists.sourceforge.net;
	Tue, 28 Jan 2014 13:24:41 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.49 as permitted sender)
	client-ip=209.85.219.49; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f49.google.com; 
Received: from mail-oa0-f49.google.com ([209.85.219.49])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1W88ed-0002Wd-TS
	for bitcoin-development@lists.sourceforge.net;
	Tue, 28 Jan 2014 13:24:41 +0000
Received: by mail-oa0-f49.google.com with SMTP id i7so370222oag.8
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 28 Jan 2014 05:24:34 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.148.197 with SMTP id tu5mr1089844oeb.11.1390915474509;
	Tue, 28 Jan 2014 05:24:34 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.99.112 with HTTP; Tue, 28 Jan 2014 05:24:34 -0800 (PST)
In-Reply-To: <CABsx9T2ng9vGMmfFK95A1jBK-FotDL-fA1oOt-=zosCPaug-rQ@mail.gmail.com>
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>
Date: Tue, 28 Jan 2014 14:24:34 +0100
X-Google-Sender-Auth: 7kQyKQQgwpdmKk2TfvjayfbKXTw
Message-ID: <CANEZrP0-i5B1miM9QTpmavvsdMKYwmXYk9=-OvL4sc0cRkgB3A@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b2e3d00c5836d04f107bec9
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: 1W88ed-0002Wd-TS
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 13:24:42 -0000

--047d7b2e3d00c5836d04f107bec9
Content-Type: text/plain; charset=UTF-8

>
> And even if you don't care about CoinJoin, not broadcasting the
> transaction as soon as the inputs are signed adds implementation complexity
> (should you retry if payment_url is unavailable? how many times?
>

I guess a lot of wallets just won't broadcast at all and try to submit via
the URL. If they don't succeed, then the transaction is just never
committed to the wallet. Doesn't seem like a big deal. Payment submission
is online, interactive. If it fails, you keep the coins. This seems simple
and straightforward.

If someone really wanted to do a real-time coinjoin, they can build the
transaction together and submit it via payment_url, and broadcast as well.
If the merchant has an issue with the payment for some reason (e.g. request
is expired or the tx is non-standard), well, you'll have to sort it out
with them manually.

--047d7b2e3d00c5836d04f107bec9
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote">
And even if you don&#39;t care about CoinJoin, not broadcasting the transac=
tion as soon as the inputs are signed adds implementation complexity (shoul=
d you retry if payment_url is unavailable? how many times? </div></div>
</div></blockquote><div><br></div><div>I guess a lot of wallets just won&#3=
9;t broadcast at all and try to submit via the URL. If they don&#39;t succe=
ed, then the transaction is just never committed to the wallet. Doesn&#39;t=
 seem like a big deal. Payment submission is online, interactive. If it fai=
ls, you keep the coins. This seems simple and straightforward.</div>
<div><br></div><div>If someone really wanted to do a real-time coinjoin, th=
ey can build the transaction together and submit it via payment_url, and br=
oadcast as well. If the merchant has an issue with the payment for some rea=
son (e.g. request is expired or the tx is non-standard), well, you&#39;ll h=
ave to sort it out with them manually.=C2=A0</div>
</div></div></div>

--047d7b2e3d00c5836d04f107bec9--