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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W7stP-0002XY-3X for bitcoin-development@lists.sourceforge.net; Mon, 27 Jan 2014 20:34:51 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gnomon.org.uk designates 93.93.131.22 as permitted sender) client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk; helo=darla.gnomon.org.uk; Received: from darla.gnomon.org.uk ([93.93.131.22]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1W7stN-000614-1i for bitcoin-development@lists.sourceforge.net; Mon, 27 Jan 2014 20:34:51 +0000 Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id s0RKYbUh033400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jan 2014 20:34:42 GMT (envelope-from roy@darla.gnomon.org.uk) Received: (from roy@localhost) by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id s0RKYawR033399; Mon, 27 Jan 2014 20:34:36 GMT (envelope-from roy) Date: Mon, 27 Jan 2014 20:34:36 +0000 From: Roy Badami To: Jeremy Spilman Message-ID: <20140127203435.GU38964@giles.gnomon.org.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -2.0 (--) 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 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1W7stN-000614-1i Cc: bitcoin-development@lists.sourceforge.net, Andreas Schildbach 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 20:34:51 -0000 On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote: > On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach > wrote: > > > SCAN TO PAY > > For scan-to-pay, the current landscape looks different. I assume at > > least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded > > into a QR-code. Nevertheless, I tried to encode a payment request into > > the bitcoin URL. I used my existing work on encoding transactions into > > QR-codes. Steps to encode: > > Really interesting work. When using scan-to-pay, after the payer scans the > QR code with the protobuf PaymentRequest (not a URL to download the > PaymentRequest) are they using their own connectivity to submit the > Payment response? > > If we assume connectivity on the phone, might as well just get a URL from > the QR code and re-use existing infrastructure for serving that? My first thought was likewise. In the case where the phone needs Internet connectivity anyway, why not include an HTTPS URL in a BIP 72 URL? I'm assuming that every client will have to support this is any case, since it's effectively mandated by the BIP, so why add another mode of operation? However, PaymentRequest-over-QR-code does seem to me to have one rather attractive advantage: the authentication model is orders of magnitude simpler and more intuitive for a face-to-face transaction than anything else. You're saying "pay the coins to that thing over there displaying that QR code". Which, most of the time, is exactly what you want. In the web case, it's fine to ignore the case where the URL domain has been subverted (and an cert obtained by the attacker) because in that case you've lost before you even get to payments (MitM attacker shows you a modified web page with different payment details). But the face-to-face case isn't intrinsically dependent on SSL security, and it's nice not to introduce that attack vector... roy