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 ) 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 ; 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: References: Date: Fri, 12 Sep 2014 18:31:36 +0200 X-Google-Sender-Auth: XzWcTOoEp74e_DrHN4RFWRsNsqA Message-ID: From: Mike Hearn To: Christophe Biocca 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" , Andreas Schildbach Subject: Re: [Bitcoin-development] BIP72 amendment proposal X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
Putting aside the question of necessity for a moment, a mo= re efficient approach to this would be;
  1. Add another marker para= m like &s to the end of the URL
  2. 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
  3. 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.
This adds only a few characters to a normal backwards-c= ompatible QR code, and is not hard to implement.

=

On Fri, Sep= 12, 2014 at 5:37 PM, Mike Hearn <mike@plan99.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
<= div class=3D"gmail_quote">
T= hat 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.=C2=A0

--047d7b339813a8eeff0502e0d1bc--