diff options
| author | Alex Kotenko <alexykot@gmail.com> | 2014-03-06 18:03:20 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-03-06 18:04:23 +0000 |
| commit | bcedf9e347ea8654a35994a8186d2a9032c34ab1 (patch) | |
| tree | 82a47aed6d1de2d1de1356f6b9d4c0f9534a5e56 | |
| parent | 44463a3129133f90312125d30d5b8b2b2a1e1227 (diff) | |
| download | pi-bitcoindev-bcedf9e347ea8654a35994a8186d2a9032c34ab1.tar.gz pi-bitcoindev-bcedf9e347ea8654a35994a8186d2a9032c34ab1.zip | |
Re: [Bitcoin-development] Instant / contactless payments
| -rw-r--r-- | 38/244dac26609ad1fc492a0721f0f7d0ae58186e | 194 |
1 files changed, 194 insertions, 0 deletions
diff --git a/38/244dac26609ad1fc492a0721f0f7d0ae58186e b/38/244dac26609ad1fc492a0721f0f7d0ae58186e new file mode 100644 index 000000000..d9907ab3c --- /dev/null +++ b/38/244dac26609ad1fc492a0721f0f7d0ae58186e @@ -0,0 +1,194 @@ +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 <alexy.kot.all@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>; + 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: <lfa8pf$ckc$1@ger.gmane.org> +References: <CANEZrP3w9c_UX3dd+7LdWNXCEwjnAG+bYWxqKYo_fzakWQu=Bg@mail.gmail.com> + <CALDj+BZE1KtMGpMH3UHtxjN2vXxu39o_hAWPdg==KLsWpe1zqA@mail.gmail.com> + <lfa8pf$ckc$1@ger.gmane.org> +From: Alex Kotenko <alexykot@gmail.com> +Date: Thu, 6 Mar 2014 18:03:20 +0000 +X-Google-Sender-Auth: qQkV-UzrJu2LSSCd9hm0WrV1_Xs +Message-ID: <CALDj+Bbe_rCfAoA1PDX5AXSvhYauObYh7Y6nAD3EbhfHX7exQg@mail.gmail.com> +To: Andreas Schildbach <andreas@schildbach.de> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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. +> +=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 + +<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">= +2014-03-06 16:46 GMT+00:00 Andreas Schildbach <span dir=3D"ltr"><<a href= +=3D"mailto:andreas@schildbach.de" target=3D"_blank">andreas@schildbach.de</= +a>></span>:<br> + +<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= +left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= +adding-left:1ex"><div id=3D":1bd" class=3D"" style=3D"overflow:hidden">Supp= +orting Bluetooth is optional in the sense that if a wallet should<br> + + +not support it, you will still receive the transaction via the P2P<br> +network. So I'd say definately go for Bluetooth.</div></blockquote><div= +><div class=3D"gmail_default" style=3D"font-family:'courier new',mo= +nospace;color:rgb(0,51,0)">=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.</div> + +</div><div class=3D"gmail_default" style=3D"font-family:'courier new= +9;,monospace;color:rgb(0,51,0)">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.</div> + +<div class=3D"gmail_default" style=3D"font-family:'courier new',mon= +ospace;color:rgb(0,51,0)"><br></div><div>=C2=A0I wonder about the receipt s= +tep -- are you generating a PDF on device</div><blockquote class=3D"gmail_q= +uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c= +olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> + +<div id=3D":1bd" class=3D"" style=3D"overflow:hidden"> +and sending it via NFC? This is something that could be supported by the<br= +> +BIP70 payment protocol. We should try to avoid the second tap, its not<br> +intuitive.</div></blockquote></div><div class=3D"gmail_default" style=3D"fo= +nt-family:'courier new',monospace;color:rgb(0,51,0)">=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.</div> + +<br><div class=3D"gmail_default" style=3D"font-family:'courier new'= +,monospace;color:rgb(0,51,0)">=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.</div> + +<div class=3D"gmail_default" style=3D"font-family:'courier new',mon= +ospace;color:rgb(0,51,0)">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</div> + +<div class=3D"gmail_default" style=3D"font-family:'courier new',mon= +ospace;color:rgb(0,51,0)">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.</div> + +<br> +</div></div> + +--bcaec52d55714b721304f3f3f645-- + + |