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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
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 1XSTl9-0001hM-S2
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Sep 2014 16:31:43 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.218.43 as permitted sender)
client-ip=209.85.218.43; envelope-from=mh.in.england@gmail.com;
helo=mail-oi0-f43.google.com;
Received: from mail-oi0-f43.google.com ([209.85.218.43])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XSTl8-0004II-Gz
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Sep 2014 16:31:43 +0000
Received: by mail-oi0-f43.google.com with SMTP id i138so678401oig.16
for <bitcoin-development@lists.sourceforge.net>;
Fri, 12 Sep 2014 09:31:37 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.164.101 with SMTP id yp5mr6877387oeb.59.1410539496990;
Fri, 12 Sep 2014 09:31:36 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.22.108 with HTTP; Fri, 12 Sep 2014 09:31:36 -0700 (PDT)
In-Reply-To: <CANEZrP2adsaM8dtA94JV+5qThDNrT8m+X45-q_DecT42i5L=jg@mail.gmail.com>
References: <mailman.341412.1410515709.2178.bitcoin-development@lists.sourceforge.net>
<A4CC413B-D5A5-423C-9D56-463FCDBDDE08@coinqy.com>
<luuk5f$i8o$1@ger.gmane.org>
<CANEZrP1iTfZxY915hzoAEApz1+wd_S9j5RCwVJCNFqQ_+DNTSQ@mail.gmail.com>
<luv0dp$qms$1@ger.gmane.org>
<CANOOu=8RJgUW+=regOcqa9udiLr=nK=4fiZoW0fj2UU2GCjH3w@mail.gmail.com>
<CANOOu=-yhKK-db+VtoJbWH8H_rwrNHqXM1J12SketBXeLL6L1Q@mail.gmail.com>
<CANEZrP2adsaM8dtA94JV+5qThDNrT8m+X45-q_DecT42i5L=jg@mail.gmail.com>
Date: Fri, 12 Sep 2014 18:31:36 +0200
X-Google-Sender-Auth: XzWcTOoEp74e_DrHN4RFWRsNsqA
Message-ID: <CANEZrP2D9RbMVHS12PnEjXiz7TjjGFDvybOs6+kCb-aZKwXy-A@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Christophe Biocca <christophe.biocca@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b339813a8eeff0502e0d1bc
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: 1XSTl8-0004II-Gz
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>,
Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] BIP72 amendment proposal
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, 12 Sep 2014 16:31:44 -0000
--047d7b339813a8eeff0502e0d1bc
Content-Type: text/plain; charset=UTF-8
Putting aside the question of necessity for a moment, a more efficient
approach to this would be;
1. Add another marker param like &s to the end of the URL
2. Add another field to PaymentRequest that contains an ECC signature
calculated using the public key that hashes to the address in the URI
3. Upgraded wallets look for the additional param and if it's there,
expect to find the PaymentDetails signed with the address key. PKI signing
of course is still useful to provide an actual identity for receipts,
display on hardware wallets, dispute mediation etc.
This adds only a few characters to a normal backwards-compatible QR code,
and is not hard to implement.
On Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn <mike@plan99.net> wrote:
> That way we leave up to implementers to experiment with different
>> lengths and figure out what the optimum is
>
>
> Ah, that's a good suggestion if we do go this way.
>
--047d7b339813a8eeff0502e0d1bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Putting aside the question of necessity for a moment, a mo=
re efficient approach to this would be;<div><ol><li>Add another marker para=
m like &s to the end of the URL</li><li>Add another field to PaymentReq=
uest that contains an ECC signature calculated using the public key that ha=
shes to the address in the URI</li><li>Upgraded wallets look for the additi=
onal param and if it's there, expect to find the PaymentDetails signed =
with the address key. PKI signing of course is still useful to provide an a=
ctual identity for receipts, display on hardware wallets, dispute mediation=
etc.</li></ol><div>This adds only a few characters to a normal backwards-c=
ompatible QR code, and is not hard to implement.</div></div><div><br></div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Sep=
12, 2014 at 5:37 PM, Mike Hearn <span dir=3D"ltr"><<a href=3D"mailto:mi=
ke@plan99.net" target=3D"_blank">mike@plan99.net</a>></span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">T=
hat way we leave up to implementers to experiment with different<br>
lengths and figure out what the optimum is</blockquote><div><br></div></spa=
n><div>Ah, that's a good suggestion if we do go this way.=C2=A0</div></=
div></div></div>
</blockquote></div><br></div>
--047d7b339813a8eeff0502e0d1bc--
|
