public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Alex Kotenko <alexykot@gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Instant / contactless payments
Date: Thu, 6 Mar 2014 18:03:20 +0000	[thread overview]
Message-ID: <CALDj+Bbe_rCfAoA1PDX5AXSvhYauObYh7Y6nAD3EbhfHX7exQg@mail.gmail.com> (raw)
In-Reply-To: <lfa8pf$ckc$1@ger.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2531 bytes --]

2014-03-06 16:46 GMT+00:00 Andreas Schildbach <andreas@schildbach.de>:

> 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.
>
​Yes, it's part of the​ plan. Just again - I need to make sure 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.
>
​No, I'm generating it on server and sending only URL via NFC. I think this
area will change before we launch in production. Ideally I want ​the 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.

​We should avoid second ​tap ideally, but we need to make sure 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.

[-- Attachment #2: Type: text/html, Size: 3940 bytes --]

  parent reply	other threads:[~2014-03-06 18:04 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-06  9:45 [Bitcoin-development] Instant / contactless payments Mike Hearn
2014-03-06 11:26 ` Andreas Schildbach
2014-03-06 13:44   ` Mike Hearn
2014-03-06 14:51     ` Andreas Schildbach
2014-03-06 16:55       ` [Bitcoin-development] Instant / contactless payments, IsoDep Andreas Schildbach
2014-03-06 17:00         ` Mike Hearn
2014-03-07  8:45           ` Andreas Schildbach
2014-03-07  9:26   ` [Bitcoin-development] Instant / contactless payments Johannes Zweng
2014-03-07 10:00     ` Mike Hearn
2014-03-07 10:23     ` Andreas Schildbach
2014-03-07 11:01       ` Mike Hearn
2014-03-07 12:00       ` Johannes Zweng
2014-03-06 14:20 ` Brooks Boyd
2014-03-06 17:07   ` Mike Hearn
2014-03-06 18:08     ` Brooks Boyd
2014-03-06 18:12       ` Mike Hearn
2014-03-06 18:20         ` Brooks Boyd
2014-03-06 18:24           ` Mike Hearn
2014-03-07 18:07   ` Joel Kaartinen
2014-03-06 14:39 ` Alex Kotenko
2014-03-06 16:46   ` Andreas Schildbach
2014-03-06 16:52     ` Mike Hearn
2014-03-06 18:03     ` Alex Kotenko [this message]
2014-03-07  8:59       ` Andreas Schildbach
2014-03-06 17:03   ` Mike Hearn
2014-03-06 18:49     ` Alex Kotenko
2014-03-08  8:52   ` Jan Vornberger
2014-03-10 15:09     ` Alex Kotenko
2014-03-10 19:28       ` Andreas Schildbach
2014-03-10 19:47         ` Alex Kotenko
2014-03-07 19:08 ` Troy Benjegerdes
2014-03-10 16:04 ` Mike Hearn
2014-03-10 16:14   ` Jean-Paul Kogelman
2014-03-10 16:27     ` Alex Kotenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALDj+Bbe_rCfAoA1PDX5AXSvhYauObYh7Y6nAD3EbhfHX7exQg@mail.gmail.com \
    --to=alexykot@gmail.com \
    --cc=andreas@schildbach.de \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox