📅 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>;
Alex Kotenko [ARCHIVE] /
npub14j…h00t4
2023-06-07 15:14:53
in reply to nevent1q…sxve
Author Public Key
npub14jv7tj33yt72yk8mljmvkck3p4xm5s3mxfpj289up38qqsn9dhkqeh00t4Published at
2023-06-07 15:14:53Event JSON
{
"id": "2b69ff03272c5b1b7622649d260984e0dee15346997af104470656af713cdcaa",
"pubkey": "ac99e5ca3122fca258fbfcb6cb62d10d4dba423b3243251cbc0c4e0042656dec",
"created_at": 1686150893,
"kind": 1,
"tags": [
[
"e",
"a596a87c6af457be0f805b03270c063d690d47775921aaf8262e434ce379245e",
"",
"root"
],
[
"e",
"c7952693445444da8874e3c02e2a6e10716dfcbd34a2069dbed5581a509ca501",
"",
"reply"
],
[
"p",
"88fdcee83ee595959771655e21d171024e8e17645cd1e89fd6f34cfa1fd712be"
]
],
"content": "📅 Original date posted:2014-03-06\n📝 Original message:Hi Mike\n\n\nNot sure if you've seen it, but here is how we do NFC right now\nhttp://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal.\nFor now this is just an NDEF URI message with Bitcoin URI inside, and then\ntransaction itself propagated to the network by the phone using it's own\nInternet connection. Far not ideal, but even this is supported only by\nAndreas' Wallet, so we cannot move ahead alot really until other wallets\nwill have some support in this area.\nAs you see - it's taking just few seconds, most of which is manual payment\nconfirmation. Btw, ignore my first screen tap, where I'm selecting wallets\n- it's an unlikely thing to happen IRL to have several wallets installed at\nthe same time.\n\nAlso, I think many people may not know about Oyster cards, so this might\nneed little bit of explanation. And btw, have you been to London lately?\nOyster readers now accept contactless cards directly along with Oyster\ncards itself. I wonder if eventually in future we could add bitcoin support\ninto that system directly, without hardware replacements.\n\nI cannot put much into the actual protocol discussion, but I'm happy to\nprovide feedback on the side of actual POS implementation needed and\ntestbase if required.\n\nHave an idea - it's a good thing to cap confirmationless payments, but the\nactual cap value definition can be tricky considering Bitcoin volatility.\nInless you want to tie it to some external price definition thirdparty\nservice it could be tied to transaction fees. I mean - if with Bitcoin v0.9\ntransaction fees will become really floating, and it should eventually\nreach equilibrium that will reflect some real world value. Probably a tiny\nvalue, but probably also rather stable value. So confirmationless payment\ncap may be defined as \u003ccurrent_average_transaction_fee\u003ex10000.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140306/38cc0863/attachment.html\u003e",
"sig": "a3024ea5538c0476ccbb0b87642282bf7b533b288575570c3b29f20a153357995de0cc66904771cda6f02dbdf983fdc166017728becf3c1e7cc39e1649df2a99"
}