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
|
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 <mh.in.england@gmail.com>) id 1W8qsu-00087N-IG
for bitcoin-development@lists.sourceforge.net;
Thu, 30 Jan 2014 12:38:20 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.51 as permitted sender)
client-ip=209.85.214.51; envelope-from=mh.in.england@gmail.com;
helo=mail-bk0-f51.google.com;
Received: from mail-bk0-f51.google.com ([209.85.214.51])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W8qsr-0002az-TC
for bitcoin-development@lists.sourceforge.net;
Thu, 30 Jan 2014 12:38:20 +0000
Received: by mail-bk0-f51.google.com with SMTP id w10so1426224bkz.10
for <bitcoin-development@lists.sourceforge.net>;
Thu, 30 Jan 2014 04:38:11 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.204.103.7 with SMTP id i7mr5503411bko.14.1391085491079; Thu,
30 Jan 2014 04:38:11 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.205.33.205 with HTTP; Thu, 30 Jan 2014 04:38:10 -0800 (PST)
In-Reply-To: <52EA3FAD.5080802@borboggle.com>
References: <52E9E787.8080304@borboggle.com>
<CANEZrP0soR0xRqW=vsKaL__HRuWstA5vW=6_JkGZm=8wkm8Q3g@mail.gmail.com>
<52EA343E.4010208@borboggle.com>
<CAPg+sBg8AGrbny=2tXp3gsok4TX7XV5307Cx1+ArBwxM6xL4jQ@mail.gmail.com>
<CANEZrP2MHqw+c+AVSLzmc6A1xyMvVK=DfR_R-tH1ypGQLRqo_A@mail.gmail.com>
<CAPg+sBhzLVxdU+Kg2N7eW=34X1-6qbg1+rPzyMqfsy01zqnfGA@mail.gmail.com>
<52EA3FAD.5080802@borboggle.com>
Date: Thu, 30 Jan 2014 13:38:10 +0100
X-Google-Sender-Auth: 1T1YDGZ-VSI-dYRoPd91WHtfD0I
Message-ID: <CANEZrP3L-pxEVZAYn+=HmiNjZTX7TTYmdsMoYMc-cZ1OnH105g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Chuck <chuck+bitcoindev@borboggle.com>
Content-Type: multipart/alternative; boundary=001a113351548c7c2204f12f545b
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: 1W8qsr-0002az-TC
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 12:38:20 -0000
--001a113351548c7c2204f12f545b
Content-Type: text/plain; charset=UTF-8
>
> If you sent the Payment message and the server goes silent after receiving
> it, you retry to delivery. However, the merchant can broadcast the
> transactions and force them into your wallet anyway. You could, quite
> likely, pay and never get an ACK.
>
No retries. If there's a timeout the wallet will consider the payment not
made, and if the merchant broadcasts anyway, the wallet will see the
transactions and sync with them correctly. The ACK is not particularly
important in the current design, so that's no big deal.
If we see this situation crop up routinely we can take measures to improve
things. I doubt we will.
--001a113351548c7c2204f12f545b
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">If you sent the Payment message and the server g=
oes silent after receiving it, you retry to delivery. =C2=A0However, the me=
rchant can broadcast the transactions and force them into your wallet anywa=
y. You could, quite likely, pay and never get an ACK.<br>
</blockquote><div><br></div><div>No retries. If there's a timeout the w=
allet will consider the payment not made, and if the merchant broadcasts an=
yway, the wallet will see the transactions and sync with them correctly. Th=
e ACK is not particularly important in the current design, so that's no=
big deal.</div>
<div><br></div><div>If we see this situation crop up routinely we can take =
measures to improve things. I doubt we will.</div></div></div></div>
--001a113351548c7c2204f12f545b--
|
