From mboxrd@z Thu Jan 1 00:00:00 1970 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 1WLsWn-0003FQ-C5 for bitcoin-development@lists.sourceforge.net; Fri, 07 Mar 2014 11:01:21 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.176 as permitted sender) client-ip=209.85.214.176; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f176.google.com; Received: from mail-ob0-f176.google.com ([209.85.214.176]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WLsWm-0001Zz-GH for bitcoin-development@lists.sourceforge.net; Fri, 07 Mar 2014 11:01:21 +0000 Received: by mail-ob0-f176.google.com with SMTP id wp18so3929428obc.21 for ; Fri, 07 Mar 2014 03:01:15 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.54.138 with SMTP id j10mr6569683oep.51.1394190075204; Fri, 07 Mar 2014 03:01:15 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.71.231 with HTTP; Fri, 7 Mar 2014 03:01:15 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Mar 2014 12:01:15 +0100 X-Google-Sender-Auth: sb5otwASd_kgYS8qBACar6zE22s Message-ID: From: Mike Hearn To: Andreas Schildbach Content-Type: multipart/alternative; boundary=089e0112cd322e9b9a04f4022cfe 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: 1WLsWm-0001Zz-GH Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Instant / contactless payments 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, 07 Mar 2014 11:01:21 -0000 --089e0112cd322e9b9a04f4022cfe Content-Type: text/plain; charset=UTF-8 > > Interesting side note: They recommend messages transmitted via NFC to > not exceed 1 KB in order for a snappy experience. This (again) questions > usage of bulky X.509 certificates in our payment request messages. > Bitcoin Wallet currently does not sign payment requests, so I could not > try how it would feel. I think you could just put a signed PaymentRequest into an NFC tag and try reading it from that. It's the same underlying radio tech so the transfer speeds should be similar, I'd think. Common X.509 certs are bigger than they need to be for sure, but a lot of the bulk comes from the use of RSA rather than ECC. An RSA signature alone can be 256 bytes! There's nothing that states you have to use RSA for certificates and ECC certs are out there (Google uses one), but I think they are harder to get hold of. I guess over time SSL will migrate to mostly ECC (secp256r1) based certs. --089e0112cd322e9b9a04f4022cfe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Interesting side note: They recommend messages = transmitted via NFC to
not exceed 1 KB in order for a snappy experience. This (again) questions usage of bulky X.509 certificates in our payment request messages.
Bitcoin Wallet currently does not sign payment requests, so I could not
try how it would feel.

I think you could ju= st put a signed PaymentRequest into an NFC tag and try reading it from that= . It's the same underlying radio tech so the transfer speeds should be = similar, I'd think.

Common X.509 certs are bigger than they need to be for = sure, but a lot of the bulk comes from the use of RSA rather than ECC. An R= SA signature alone can be 256 bytes! There's nothing that states you ha= ve to use RSA for certificates and ECC certs are out there (Google uses one= ), but I think they are harder to get hold of. I guess over time SSL will m= igrate to mostly ECC (secp256r1) based certs.
--089e0112cd322e9b9a04f4022cfe--