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
153
154
155
156
157
|
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 <jeremy.spilman@gmail.com>) id 1UXEBG-0001uo-Mi
for bitcoin-development@lists.sourceforge.net;
Tue, 30 Apr 2013 17:17:30 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.53 as permitted sender)
client-ip=209.85.212.53; envelope-from=jeremy.spilman@gmail.com;
helo=mail-vb0-f53.google.com;
Received: from mail-vb0-f53.google.com ([209.85.212.53])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UXEBF-00064y-NJ
for bitcoin-development@lists.sourceforge.net;
Tue, 30 Apr 2013 17:17:30 +0000
Received: by mail-vb0-f53.google.com with SMTP id i3so603030vbh.26
for <bitcoin-development@lists.sourceforge.net>;
Tue, 30 Apr 2013 10:17:24 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.58.232.98 with SMTP id tn2mr34570949vec.57.1367342244166;
Tue, 30 Apr 2013 10:17:24 -0700 (PDT)
Received: by 10.58.137.197 with HTTP; Tue, 30 Apr 2013 10:17:23 -0700 (PDT)
In-Reply-To: <CABsx9T0TTZC0EOO3ZLa3cTWhpYJaEVrQ1vO8ofaGbcDJRmfWYA@mail.gmail.com>
References: <CABsx9T3egz=7YNOrgx7WsfSthLfN2gfE60YfPEv8096vyErBqg@mail.gmail.com>
<20130428180304.GA30115@crunch>
<CA+CODZEiWTrmFzrMi2Mi0qtH3dWO5UWx_j09iUwV2qm1O=3o0A@mail.gmail.com>
<CANEZrP2JDc244xvR0ayM700Vy_h3G=aAUUgfxtOcxd0ZeB9b8g@mail.gmail.com>
<517FABE6.8020205@bitonic.nl>
<CABsx9T0TTZC0EOO3ZLa3cTWhpYJaEVrQ1vO8ofaGbcDJRmfWYA@mail.gmail.com>
Date: Tue, 30 Apr 2013 10:17:23 -0700
Message-ID: <CA+CODZHr3h21chGX5YxvuU7LQCneF51h1gKD3ezgfucDO5w30A@mail.gmail.com>
From: Jeremy Spilman <jeremy.spilman@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7b414c2ec008c704db972c6c
X-Spam-Score: -0.6 (/)
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
(jeremy.spilman[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1UXEBF-00064y-NJ
Subject: Re: [Bitcoin-development] Cold Signing Payment Requests
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, 30 Apr 2013 17:17:30 -0000
--047d7b414c2ec008c704db972c6c
Content-Type: text/plain; charset=ISO-8859-1
> 1) The risk that the merchant's web server will be compromised and the
attacker will redirect refunds
> 2) The risk that the merchant will miss payments because they miss a POST
to the payment_url (maybe the customer's machine crashes during the HTTPS
handshake)
> If payments are a lot more common than refunds, then (2) will outweigh
(1).
I think that's oversimplifying. (1) is theft, (2) is payment processing.
Reliable payment processing with refund handling is not simple nor free,
but it should be secure. The cost of (2) depends primarily on the failure
rate, which we can only guess at this point, and secondarily on how much
manual intervention is required to recover.
(2) is perhaps more of a problem if wallets broadcast before POST. It's
trading one failure mode (funds sent but not claimed) for another (coins
marked as spent but not). Either way, you fix it by just retrying the POST.
But only with Transmit-After-ACK can the payer's wallet detect the failure
automatically, and even recover automatically (simply unlock the outputs,
or to be sure, spend them back to self).
Since merchants get to choose whether to have a POST url, they get to
decide if the cost of keeping their server up is worth it. I think
eventually there are enough benefits to Transmit-After-ACK that it will
become a supported use case.
Thanks Mike for explaining the threat.
[Aside] I was reading Peter's fidelitybond writeup for his idea on contract
value accounting, and he points to Stephan's post from last September on
payer-encoded metadata (
https://bitcointalk.org/index.php?topic=108423.msg1178438#msg1178438) which
Timo applies here. As a relative newcomer, this is what I am loving most
about Bitcoin.
--047d7b414c2ec008c704db972c6c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div style=3D"font-family:arial,sans-serif;font-size:13px"=
>> 1) The risk that the merchant's web server will be compromised an=
d the attacker will redirect refunds</div><div style=3D"font-family:arial,s=
ans-serif;font-size:13px">
> 2) The risk that the merchant will miss payments because they miss a P=
OST to the payment_url (maybe the customer's machine crashes during the=
HTTPS handshake)</div><div style=3D"font-family:arial,sans-serif;font-size=
:13px">
> If payments are a lot more common than refunds, then (2) will outweigh=
(1).</div><div style=3D"font-family:arial,sans-serif;font-size:13px"><br><=
/div><div style=3D"font-family:arial,sans-serif;font-size:13px">I think tha=
t's oversimplifying. =A0(1) is theft, (2) is payment processing. Reliab=
le payment processing with refund handling is not simple nor free, but it s=
hould be secure. The cost of (2) depends primarily on the failure rate, whi=
ch we can only guess at this point, and secondarily on how much manual inte=
rvention is required to recover.<br>
</div><div style=3D"font-family:arial,sans-serif;font-size:13px"><br></div>=
<div style=3D"font-family:arial,sans-serif;font-size:13px">(2) is perhaps m=
ore of a problem if wallets broadcast before POST. It's trading one fai=
lure mode (funds sent but not claimed) for another (coins marked as spent b=
ut not). Either way, you fix it by just retrying the POST. But only with Tr=
ansmit-After-ACK can the payer's wallet detect the failure automaticall=
y, and even recover automatically (simply unlock the outputs, or to be sure=
, spend them back to self).</div>
<div style=3D"font-family:arial,sans-serif;font-size:13px"><br></div><div s=
tyle=3D"font-family:arial,sans-serif;font-size:13px">Since merchants get to=
choose whether to have a POST url, they get to decide if the cost of keepi=
ng their server up is worth it. I think eventually there are enough benefit=
s to Transmit-After-ACK that it will become a supported use case.</div>
<div style=3D"font-family:arial,sans-serif;font-size:13px"><br></div><div s=
tyle=3D"font-family:arial,sans-serif;font-size:13px">Thanks Mike for explai=
ning the threat.</div><div style=3D"font-family:arial,sans-serif;font-size:=
13px">
<br></div><div style=3D"font-family:arial,sans-serif;font-size:13px">[Aside=
] I was reading Peter's fidelitybond writeup=A0for his idea on contract=
value accounting, and he points to Stephan's post from last September =
on payer-encoded metadata (<a href=3D"https://bitcointalk.org/index.php?top=
ic=3D108423.msg1178438#msg1178438" style=3D"font-family:arial;font-size:sma=
ll">https://bitcointalk.org/index.php?topic=3D108423.msg1178438#msg1178438<=
/a>) which Timo applies here. As a relative newcomer, this is what I am lov=
ing most about Bitcoin.</div>
</div>
--047d7b414c2ec008c704db972c6c--
|
