Alex Kotenko [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-06 📝 Original message:Hi Mike Not sure if you've ...
📅 Original date posted:2014-03-06
📝 Original message:Hi Mike
Not sure if you've seen it, but here is how we do NFC right now
http://www.youtube.com/watch?v=DGOMIG9JUY8 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.
Also, 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 idea - 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 <current_average_transaction_fee>x10000.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140306/38cc0863/attachment.html>;
📝 Original message:Hi Mike
Not sure if you've seen it, but here is how we do NFC right now
http://www.youtube.com/watch?v=DGOMIG9JUY8 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.
Also, 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 idea - 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 <current_average_transaction_fee>x10000.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140306/38cc0863/attachment.html>;