From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WLZTT-0008Vd-Mr for bitcoin-development@lists.sourceforge.net; Thu, 06 Mar 2014 14:40:39 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.173 as permitted sender) client-ip=209.85.220.173; envelope-from=alexy.kot.all@gmail.com; helo=mail-vc0-f173.google.com; Received: from mail-vc0-f173.google.com ([209.85.220.173]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WLZTS-0005WL-L2 for bitcoin-development@lists.sourceforge.net; Thu, 06 Mar 2014 14:40:39 +0000 Received: by mail-vc0-f173.google.com with SMTP id ld13so2685294vcb.32 for ; Thu, 06 Mar 2014 06:40:33 -0800 (PST) X-Received: by 10.58.133.15 with SMTP id oy15mr5420523veb.19.1394116833148; Thu, 06 Mar 2014 06:40:33 -0800 (PST) MIME-Version: 1.0 Sender: alexy.kot.all@gmail.com Received: by 10.59.0.38 with HTTP; Thu, 6 Mar 2014 06:39:52 -0800 (PST) In-Reply-To: References: From: Alex Kotenko Date: Thu, 6 Mar 2014 14:39:52 +0000 X-Google-Sender-Auth: _94VRkk9BvRcOsJm0mLjyNHjOuA Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=047d7b6d9f829d84ea04f3f11e7f 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 X-Headers-End: 1WLZTS-0005WL-L2 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 14:40:39 -0000 --047d7b6d9f829d84ea04f3f11e7f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mike Not sure if you've seen it, but here is how we do NFC right now http://www.youtube.com/watch?v=3DDGOMIG9JUY8 with XBTerminal. For now this is just an NDEF URI message with Bitcoin URI inside, and then transaction itself propagated to the network by the phone using it's own Internet connection. Far not ideal, but even this is supported only by Andreas' Wallet, so we cannot move ahead alot really until other wallets will have some support in this area. As you see - it's taking just few seconds, most of which is manual payment confirmation. Btw, ignore my first screen tap, where I'm selecting wallets - it's an unlikely thing to happen IRL to have several wallets installed at the same time. =E2=80=8BAlso, I think many people may not know about Oyster cards, so this= might need little bit of explanation. And btw, have you been to London lately? Oyster readers now accept contactless cards directly along with Oyster cards itself. I wonder if eventually in future we could add bitcoin support into that system directly, without hardware replacements. I cannot put much into the actual protocol discussion, but I'm happy to provide feedback on the side of actual POS implementation needed and testbase if required. Have an =E2=80=8Bidea - it's a good thing to cap confirmationless payments,= but the actual cap value definition can be tricky considering Bitcoin volatility. Inless you want to tie it to some external price definition thirdparty service it could be tied to transaction fees. I mean - if with Bitcoin v0.9 transaction fees will become really floating, and it should eventually reach equilibrium that will reflect some real world value. Probably a tiny value, but probably also rather stable value. So confirmationless payment cap may be defined as x10000. --047d7b6d9f829d84ea04f3f11e7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mike=C2=A0


Not= sure if you've seen it, but here is how we do NFC right now=C2=A0http://www.youtube.com/= watch?v=3DDGOMIG9JUY8 with XBTerminal.=C2=A0
For now this is just an NDEF URI message with Bit= coin URI inside, and then transaction itself propagated to the network by t= he phone using it's own Internet connection. Far not ideal, but even th= is is supported only by Andreas' Wallet, so we cannot move ahead alot r= eally until other wallets will have some support in this area.
As you see - it's taking just few seconds, mo= st of which is manual payment confirmation. Btw, ignore my first screen tap= , where I'm selecting wallets - it's an unlikely thing to happen IR= L to have several wallets installed at the same time.

=E2=80=8BAlso= , I think many people may not know about Oyster cards, so this might need l= ittle bit of explanation. And btw, have you been to London lately? Oyster r= eaders now accept contactless cards directly along with Oyster cards itself= . I wonder if eventually in future we could add bitcoin support into that s= ystem directly, without hardware replacements.

I cannot put much into the actual protocol discussion,= but I'm happy to provide feedback on the side of actual POS implementa= tion needed and testbase if=C2=A0required.

Have an =E2=80=8Bidea - it= 9;s a good thing to cap confirmationless payments, but the actual cap value= definition can be tricky considering Bitcoin volatility. Inless you want t= o tie it to some external price definition thirdparty service it could be t= ied to transaction fees. I mean - if with Bitcoin v0.9 transaction fees wil= l become really floating, and it should eventually reach equilibrium that w= ill reflect some real world value. Probably a tiny value, but probably=C2= =A0also=C2=A0rather stable value. So confirmationless payment cap may be de= fined as <current_average_transaction_fee>x10000.

--047d7b6d9f829d84ea04f3f11e7f--