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; 
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Mon, 27 Jan 2014 18:39:53 +0100
Message-ID: <lc65ks$2tr$1@ger.gmane.org>
References: <lc5hmg$1jh$1@ger.gmane.org> <op.xacvcukvyldrnw@laptop-air>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
In-Reply-To: <op.xacvcukvyldrnw@laptop-air>
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Precedence: list

On 01/27/2014 06:11 PM, Jeremy Spilman 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?
>
> How about putting a Bluetooth address in the payment_url inside the
> PaymentDetails message for the smartphone to send back the Payment
> response and get PaymentAck?

That's exactly what I have prototyped. I am putting a Bluetooth MAC
address into the payment_url. Have a look at the TAP TO PAY paragraph
for details, its mostly the same mechanism.