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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
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
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
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] BIP72 amendment proposal
Precedence: list

--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 &amp;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&#39;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">&lt;<a href=3D"mailto:mi=
ke@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</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&#39;s a good suggestion if we do go this way.=C2=A0</div></=
div></div></div>
</blockquote></div><br></div>

--047d7b339813a8eeff0502e0d1bc--