From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W8WaJ-0005kA-29 for bitcoin-development@lists.sourceforge.net; Wed, 29 Jan 2014 14:57:47 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.42 as permitted sender) client-ip=209.85.160.42; envelope-from=christophe.biocca@gmail.com; helo=mail-pb0-f42.google.com; Received: from mail-pb0-f42.google.com ([209.85.160.42]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W8WaG-0001tZ-Tx for bitcoin-development@lists.sourceforge.net; Wed, 29 Jan 2014 14:57:47 +0000 Received: by mail-pb0-f42.google.com with SMTP id jt11so1865918pbb.1 for ; Wed, 29 Jan 2014 06:57:39 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.67.5.233 with SMTP id cp9mr8201415pad.147.1391007458996; Wed, 29 Jan 2014 06:57:38 -0800 (PST) Received: by 10.68.146.72 with HTTP; Wed, 29 Jan 2014 06:57:38 -0800 (PST) In-Reply-To: <20140127203435.GU38964@giles.gnomon.org.uk> References: <20140127203435.GU38964@giles.gnomon.org.uk> Date: Wed, 29 Jan 2014 09:57:38 -0500 Message-ID: From: Christophe Biocca To: Roy Badami Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.6 (-) 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 (christophe.biocca[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1W8WaG-0001tZ-Tx 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: Wed, 29 Jan 2014 14:57:47 -0000 > But the face-to-face case isn't intrinsically dependent on SSL security, and it's nice not to introduce that attack vector... If the only concern is to make scan-to-pay work without reliance on SSL's PKI, it might be better to specify the payment protocol url *and* the public key used for signing right in the qr code. The wallet connects to the url, fetches the payment request (maybe over a secure connection, maybe not, doesn't matter), and verifies the signature matches the public key from the qr code. Downsides compared to embedding the entire request: Payee needs to host/serve requests somewhere online. This introduces reliability and DoS concerns. Payer needs an internet connection to fetch the request. Advantages: Serve variable payment requests from the same qr code (improving recipient privacy). Still no hard dependency on CAs. Even if both CA and DNS are compromised by an attacker, the worst they can do is Denial of Service. Optionally use CAs so that the wallet can attach an identity to who you're paying by QR code. This partly addresses the problem of the waiter overwriting the QR code. A non-PKI transaction would simply show "Unknown recipient". Much smaller QR code (only overhead is the key parameter, and you could use a boolean param + the "address as public key" hack Mike mentionned, for only 4 characters of overhead). No need for a backward-incompatible bitcoin: scheme On Mon, Jan 27, 2014 at 3:34 PM, Roy Badami wrote: > 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 > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development