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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W7qlT-0003yu-Ub for bitcoin-development@lists.sourceforge.net; Mon, 27 Jan 2014 18:18:31 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; envelope-from=gcbd-bitcoin-development@m.gmane.org; helo=plane.gmane.org; Received: from plane.gmane.org ([80.91.229.3]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1W7qlS-0007FT-NE for bitcoin-development@lists.sourceforge.net; Mon, 27 Jan 2014 18:18:31 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1W7qlL-0001fz-TQ for bitcoin-development@lists.sourceforge.net; Mon, 27 Jan 2014 19:18:23 +0100 Received: from f053014231.adsl.alicedsl.de ([78.53.14.231]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Jan 2014 19:18:23 +0100 Received: from andreas by f053014231.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Jan 2014 19:18:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-development@lists.sourceforge.net From: Andreas Schildbach Date: Mon, 27 Jan 2014 19:18:11 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: f053014231.adsl.alicedsl.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: X-Spam-Score: -0.9 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.91.229.3 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.1 DKIM_ADSP_ALL No valid author signature, domain signs all mail -0.0 SPF_PASS SPF: sender matches SPF record -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1W7qlS-0007FT-NE Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face 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: Mon, 27 Jan 2014 18:18:32 -0000 On 01/27/2014 02:11 PM, Mike Hearn wrote: > I would like to see Bluetooth continue to work for scan-to-pay even in > the signed case. So for this reason the current approach with a BTMAC > parameter in the Bitcoin URI seems to work universally across NFC tags > and QR codes, and would allow download of a signed PaymentRequest even > in the case where a QR code is used. I'm not saying I'm against signed payment requests, but unfortunately they are just too big for QR-codes. Then again, QR-codes *can* take up to 2 KB. How big would a very basic trust chain plus signature be? > Because a Bitcoin URI already contains a public key (hash), re-using > that to establish an encrypted/authd connection on top of an insecure > RFCOMM socket would seem to be relatively straightforward. I was under the impression that addresses will go away. Can you elaborate on the mechanism? > Obviously such QR-encoded payment requests cannot grow in size as much > as using other media. In particular, I expect PKI signed requests are > out of question. However, in face to face payments the value of a sig > based on PKI is highly questionable, and the fact the sig cannot be > verified without TCP connectivity doesn't help. > > Just a correction here - the reason signed payment requests are "large" > (about 4000 bytes) is exactly because they *can* be verified offline, > i.e. by a Trezor. The signed payment request contains all the data > needed to establish its authenticity, including certificates and the > signature itself. No TCP connection is needed. Ok, that's good news (to me). However, you are going to manage trust stores (adding and revoking) without TCP? > For face to face payments, I think signing is still useful. For one, we > want to keep the distinction between "merchant" and "user" as blurry and > indistinct as possible. A strong separation between merchants and > consumers is one of the many bad things about the credit card system. Ack. > Whilst initially we'd expect the payment protocol to be used by online > webshops, in future it could be used by little corner shops, children's > lemonade stands and so on. Well I'm thinking the other way round. Use Bitcoin where its already used today -- face to face. > you probably still would like a receipt if you buy > something from a local market trader. Yes, but where is the problem? > Another use case - we heard a story about a restaurant owner who > accepted Bitcoin. He printed a static bitcoin URI onto a QR code on the > menu. A month or two later he discovered one of his waiters had > re-printed the menus with his own QR code! The people thought they had > been paying for the meal, and in fact it went right into the pocket of > the waiter. Sad story, but it's really a special case. Using a printed QR-code is clearly the wrong tool for his task, for several reasons. And again, how is he going to provide the payment request to the payer without TCP? > As to how it works, well, that's not hard. Comodo give away free email > address certs with a few mouse clicks, it's no harder than signing up > for a website. We don't want to force people to sign up anywhere. Bitcoin is instant-on. > - I chose to re-use the "bitcoin:" URL scheme > > Other wallets won't know what to do with it and would yield a strange > error message. Which is why I said we need some transition time. > Rather than pack a file into a URL, if you don't want to > use the current r= extension it's better for apps to just register to > handle .bitcoinpaymentrequest files / the right MIME type. Downloading > it and opening it would do the right thing automatically. That's a good point. I'll implement this asap. > Remember BIP 73 also! It says that with the apps built-in QR scanner, if > you scan an HTTP[S] URI, you should try downloading it with a magic > header. That way you can get a payment request file out of the server. > Without the magic header (i.e. a normal generic barcode scanner app) it > would open a web page containing a bitcoin URI clickable link. Interesting, did not know about this BIP. However I don't understand the usecase. Its not like my browsers always display QR-codes with URL of the page being shown. And if the page in question bothers to show a QR code, it could just as well also link to a payment request resource (as suggested above).