From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WLced-00020w-3C for bitcoin-development@lists.sourceforge.net; Thu, 06 Mar 2014 18:04:23 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.128.181 as permitted sender) client-ip=209.85.128.181; envelope-from=alexy.kot.all@gmail.com; helo=mail-ve0-f181.google.com; Received: from mail-ve0-f181.google.com ([209.85.128.181]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WLceN-0002P7-3e for bitcoin-development@lists.sourceforge.net; Thu, 06 Mar 2014 18:04:23 +0000 Received: by mail-ve0-f181.google.com with SMTP id oy12so2980893veb.40 for ; Thu, 06 Mar 2014 10:04:01 -0800 (PST) X-Received: by 10.52.137.143 with SMTP id qi15mr1000000vdb.39.1394129041583; Thu, 06 Mar 2014 10:04:01 -0800 (PST) MIME-Version: 1.0 Sender: alexy.kot.all@gmail.com Received: by 10.59.0.38 with HTTP; Thu, 6 Mar 2014 10:03:20 -0800 (PST) In-Reply-To: References: From: Alex Kotenko Date: Thu, 6 Mar 2014 18:03:20 +0000 X-Google-Sender-Auth: qQkV-UzrJu2LSSCd9hm0WrV1_Xs Message-ID: To: Andreas Schildbach Content-Type: multipart/alternative; boundary=bcaec52d55714b721304f3f3f645 X-Spam-Score: -0.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 (alexy.kot.all[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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 0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline X-Headers-End: 1WLceN-0002P7-3e Cc: bitcoin-development@lists.sourceforge.net 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: Thu, 06 Mar 2014 18:04:23 -0000 --bcaec52d55714b721304f3f3f645 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2014-03-06 16:46 GMT+00:00 Andreas Schildbach : > Supporting Bluetooth is optional in the sense that if a wallet should > not support it, you will still receive the transaction via the P2P > network. So I'd say definately go for Bluetooth. > =E2=80=8BYes, it's part of the=E2=80=8B plan. Just again - I need to make s= ure we support all major wallets. And no other wallets actually support NFC by now, not talking about bluetooth. So I imagine we will decide and implement together some solution here, both on the wallet and POS sides, but I will have to keep URI method and even QR codes for backwards compatibility, and wait for other main wallets to accept innovations before we will be able to completely switch to it. As I said earlier - bluetooth support for my POS is not a problem, we can plug it in easily and make it work. Support among all hardware/software and polished user experience - this is a main thing here really. I wonder about the receipt step -- are you generating a PDF on device > and sending it via NFC? This is something that could be supported by the > BIP70 payment protocol. We should try to avoid the second tap, its not > intuitive. > =E2=80=8BNo, I'm generating it on server and sending only URL via NFC. I th= ink this area will change before we launch in production. Ideally I want =E2=80=8Bth= e device to be completely autonomous, controlled on site by the merchant, probably with an app on his phone. But right now we have a backend server that gives merchant a dashboard with device configuration control, transactions history, daily reconciliation data and copies of receipts. So the PDF is sent from that server. =E2=80=8BWe should avoid second =E2=80=8Btap ideally, but we need to make s= ure receipts and payment proofs are usable and understandable for both payers and payees. Right now a paperless PDF-only process is already a huge leap ahead comparing to numerous paper receipts printed for each transaction by existing POS systems. Implementing proof of payment based on BIP70 payment request+transaction in the blockchain+memo will require even bigger shift in the merchant's view on how business runs. Also it will need additional software on his side to actually be able to view and confirm these proofs of payment. In theory - yes, BIP70 will create a way to implement proof of payment. In practice in real life right now I don't see it viable, it will take time to adopt and few intermediary steps like PDF based paperless process I've implemented. --bcaec52d55714b721304f3f3f645 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 2014-03-06 16:46 GMT+00:00 Andreas Schildbach <andreas@schildbach.de>:
Supp= orting Bluetooth is optional in the sense that if a wallet should
not support it, you will still receive the transaction via the P2P
network. So I'd say definately go for Bluetooth.
=E2=80=8BYes, it's part of the=E2=80=8B plan= . Just again - I need to make sure we support all major wallets. And no oth= er wallets actually support NFC by now, not talking about bluetooth. So I i= magine we will decide and implement together some solution here, both on th= e wallet and POS sides, but I will have to keep URI method and even QR code= s for backwards compatibility, and wait for other main wallets to accept in= novations before we will be able to completely switch to it.
As I said earlier - bluetooth support for m= y POS is not a problem, we can plug it in easily and make it work. Support = among all hardware/software and polished user experience - this is a main t= hing here really.

=C2=A0I wonder about the receipt s= tep -- are you generating a PDF on device
and sending it via NFC? This is something that could be supported by the BIP70 payment protocol. We should try to avoid the second tap, its not
intuitive.
=E2=80=8BNo, I= 'm generating it on server and sending only URL via NFC. I think this a= rea will change before we launch in production. Ideally I want =E2=80=8Bthe= device to be completely autonomous, controlled on site by the merchant, pr= obably with an app on his phone. But right now we have a backend server tha= t gives merchant a dashboard with device configuration control, transaction= s history, daily reconciliation data and copies of receipts. So the PDF is = sent from that server.

=E2=80=8BWe should avoid second =E2=80=8Btap = ideally, but we need to make sure receipts and payment proofs are usable an= d understandable for both payers and payees.
Right now a paperless PDF-only process is already= a huge leap ahead comparing to numerous paper receipts printed for each tr= ansaction by existing POS systems.=C2=A0
Implementing proof of payment based on BIP70 paym= ent request+transaction in the blockchain+memo will require even bigger shi= ft in the merchant's view on how business runs. Also it will need addit= ional software on his side to actually be able to view and confirm these pr= oofs of payment. In theory - yes, BIP70 will create a way to implement proo= f of payment. In practice in real life right now I don't see it viable,= it will take time to adopt and few intermediary steps like PDF based paper= less process I've implemented.

--bcaec52d55714b721304f3f3f645--