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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WwZRg-0000Sp-Sc
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 16:07:44 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.48 as permitted sender)
client-ip=209.85.219.48; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f48.google.com;
Received: from mail-oa0-f48.google.com ([209.85.219.48])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WwZRf-0007bm-4i
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 16:07:44 +0000
Received: by mail-oa0-f48.google.com with SMTP id m1so5968256oag.7
for <bitcoin-development@lists.sourceforge.net>;
Mon, 16 Jun 2014 09:07:37 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.115.199 with SMTP id jq7mr3235837obb.70.1402934857571;
Mon, 16 Jun 2014 09:07:37 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.162 with HTTP; Mon, 16 Jun 2014 09:07:37 -0700 (PDT)
In-Reply-To: <CAFDyEXgiZH-_zSftbKQRrPu385OwKEnYZo6-6NtWONX+V85awA@mail.gmail.com>
References: <CAKrJrGOBSiY5V59eko6g796j3wh9V9ZLjPbyHeS5=zyX6j3Wdw@mail.gmail.com>
<CANEZrP0Euc1mPhRc9e41tU4zMDrWesvVyiBpAPq6M3m7K=aU=A@mail.gmail.com>
<CAFDyEXgKpbE4WGAqROJ4J1UST=tXWgfn7uKhRO_tngJfVK_Czw@mail.gmail.com>
<loom.20140616T172412-752@post.gmane.org>
<CAFDyEXgiZH-_zSftbKQRrPu385OwKEnYZo6-6NtWONX+V85awA@mail.gmail.com>
Date: Mon, 16 Jun 2014 18:07:37 +0200
X-Google-Sender-Auth: 4H_wFdi68pxMtfQM8EuMrGobVjU
Message-ID: <CANEZrP0S3z5B0vRSQGMQwbnM2mgrFrRjfkCFvD=_No+xhb7QXg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Daniel Rice <drice@greenmangosystems.com>
Content-Type: multipart/alternative; boundary=047d7b678120d42a2c04fbf6397e
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: 1WwZRf-0007bm-4i
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Lawrence Nahum <lawrence@greenaddress.it>
Subject: Re: [Bitcoin-development] instant confirmation via payment protocol
backwards compatible proto buffer extension
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: Mon, 16 Jun 2014 16:07:45 -0000
--047d7b678120d42a2c04fbf6397e
Content-Type: text/plain; charset=UTF-8
>
> Come to think of it, is the payment protocol really the place to put this
> instant provider signature
>
Yes it's the right place. The original attempt at this concept was in fact
called *green addresses* and the idea was you could identify a spend from a
trusted wallet by checking which keys were being used to sign. But the
problem is, lack of privacy. Everyone can see what wallet provider you use.
Also it'd be inefficient to have in the chain. There's no reason for the
extra signatures to be there: double spend risk is something only the
recipient cares about.
--047d7b678120d42a2c04fbf6397e
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><span style=3D"font-family=
:arial,sans-serif;font-size:13px">Come to think of it, is the payment proto=
col really the place to put this instant provider signature</span></div>
</div></blockquote><div><br></div><div>Yes it's the right place. The or=
iginal attempt at this concept was in fact called <i>green addresses</i>=C2=
=A0and the idea was you could identify a spend from a trusted wallet by che=
cking which keys were being used to sign. But the problem is, lack of priva=
cy. Everyone can see what wallet provider you use.</div>
<div><br></div><div>Also it'd be inefficient to have in the chain. Ther=
e's no reason for the extra signatures to be there: double spend risk i=
s something only the recipient cares about.=C2=A0</div></div></div></div>
--047d7b678120d42a2c04fbf6397e--
|
