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
|
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 1Vrabx-0006XX-9o
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Dec 2013 21:49:29 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.51 as permitted sender)
client-ip=209.85.219.51; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f51.google.com;
Received: from mail-oa0-f51.google.com ([209.85.219.51])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Vrabw-0007Zj-Gh
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Dec 2013 21:49:29 +0000
Received: by mail-oa0-f51.google.com with SMTP id i7so2730429oag.24
for <bitcoin-development@lists.sourceforge.net>;
Fri, 13 Dec 2013 13:49:23 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.219.167 with SMTP id pp7mr10145obc.85.1386971363125;
Fri, 13 Dec 2013 13:49:23 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.92.72 with HTTP; Fri, 13 Dec 2013 13:49:23 -0800 (PST)
In-Reply-To: <52AB5DA9.1060701@monetize.io>
References: <CANEZrP1gDxcKO8z4hgM9BJU6-+Ft0oaiCZjqjN4MxGEJCgs5Ng@mail.gmail.com>
<CADu7o8MXuUVrRP0vsvEkPLJ4f=2pC6V7W3hYE0jCVDRKmvqu8A@mail.gmail.com>
<CANEZrP33bRx6abbXcf6nQYiPXFOOWSsZJqiFZY+A08x6O3X+pg@mail.gmail.com>
<CABsx9T0VEu15KXH_XPn+cAERQFz=Tmjqna6ZoNpLrxkzeKw9kQ@mail.gmail.com>
<CANEZrP1ha6y-w1Cpq+7t1ogUwNmxSobEREY2tawp7bcFGRPKiw@mail.gmail.com>
<52AB5DA9.1060701@monetize.io>
Date: Fri, 13 Dec 2013 13:49:23 -0800
X-Google-Sender-Auth: 9Gk20SCOy3dt7AtrCd1N99xP1Ak
Message-ID: <CANEZrP00qF+cikCe8_j6YY9Y5_meQkFMvh+BNeK0ZZYtvS2XjQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Mark Friedenbach <mark@monetize.io>
Content-Type: multipart/alternative; boundary=089e0141ab8269fa0504ed716f26
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: 1Vrabw-0007Zj-Gh
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Merge avoidance and P2P connection
encryption
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: Fri, 13 Dec 2013 21:49:29 -0000
--089e0141ab8269fa0504ed716f26
Content-Type: text/plain; charset=UTF-8
>
> Or alternatively, the user-signed payment request without iteration
> count is enclosed within a payr.com-signed envelope that contains the
> iteration count.
But how does that show up in the user interface? I don't know how you would
explain what the signature means or implies, or what you do if the
signature is broken/missing.
The only thing that a maliciously modified iteration count can do is cause
money to be sent to an address that's beyond the recipients gap limit,
meaning they won't receive it (unless they reconfigure their software and
rescan). But you can't steal money that way.
--089e0141ab8269fa0504ed716f26
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">Or alternatively, the user-signed payment reques=
t without iteration<br>
count is enclosed within a payr.com-signed envelope that contains the<br>
iteration count.</blockquote><div><br></div><div>But how does that show up =
in the user interface? I don't know how you would explain what the sign=
ature means or implies, or what you do if the signature is broken/missing.<=
/div>
<div><br></div><div>The only thing that a maliciously modified iteration co=
unt can do is cause money to be sent to an address that's beyond the re=
cipients gap limit, meaning they won't receive it (unless they reconfig=
ure their software and rescan). But you can't steal money that way.</di=
v>
</div></div></div>
--089e0141ab8269fa0504ed716f26--
|
