{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-03-06\n📝 Original message:I just did my first contactless nfc payment with a MasterCard. It worked\nvery well and was quite delightful - definitely want to be doing more of\nthese in future. I think people will come to expect this kind of\nno-friction payment experience and Bitcoin will need to match it, so here\nare some notes on what's involved.\n\nThere are two aspects that can be implemented independently of each other:\n\n1) The physical/NFC layer.\n2) The risk analysis layer.\n\nA contactless payment needs two things to work: one is a VERY fast, low\nlatency communication between payment device (phone in our case) and\nterminal. I couldn't find actual latency specs yet but it felt like using\nan Oyster card, which aims for \u003c400msec.\n\nThe other is that obviously the payment device has to decide to sign the\ntransaction without any user interaction, i.e. the payment is at low risk\nof being unintentional. If you nail this it can be used for one-click web\npayments too.\n\nAndreas already did some work on embedding full blown payment requests into\nan NFC tag, but I think we need to switch this to being a packet based\nprotocol (via ISO-DEP), otherwise you can't submit the Payment/tx messages\nback via NFC as well. This isn't a very complicated task and would make a\nfun project for a newbie who has Android and knows some Java. The resulting\nISO-DEP protocol can be turned into a BIP without too much trouble.\n\nThe risk analysis is the more complicated part. The real value\nVisa/MasterCard provide with NFC payments is not so much the tech (the\nclever part is the batteryless nature of the cards rather than the\ncrypto/comms), but the fact that merchants are all verified and can be\nfined or evicted if they abuse the system and try to steal money. Bitcoin\ndoesn't have anything like that.\n\nI think we have a few options to make it safe:\n\n1) Require some very lightweight user confirmation, like pressing the power\nbutton to reach the lock screen and only allowing small payments. The\ncombination of physical proximity and pressing the power button is probably\ngood enough for now to avoid problems. Someone should try it out and see\nhow it feels.\n\n2) Have some kind of semi-centralised merchant verification/approval\nprograms, like what the card networks do. The easiest way to start would be\nto piggyback on the work BitPay/Coinbase do and just auto-sign if payment\namount is \u003cX mBTC and the payment is via one of these processors. But this\nis hardly in the spirit of Bitcoin and is generally unsatisfying.\n\n3) Have some kind of decentralised reputation network. I spent some time\nthinking about this, but it rapidly became very complicated and feels like\nan entirely separate project that should stand alone from Bitcoin itself.\nPerhaps rather than try to make a global system, social data could be\nexchanged (using some fancy privacy preserving protocols?) so if your\nfriends have decided to trust seller X, your phone automatically trusts\nthem too.\n\n4) Have the touch trigger a delayed payment and the phone tries to attract\nattention to itself so the user can cancel. This way if someone tries to\nswipe money out of your pocket by getting up close on a subway or\nsomething, you have a chance to cancel. But it's quite hard for a small\ndevice to reliably attract attention quickly and it opens up the merchant\nto fraud where the user pays, leaves and then cancels the payment.\nEspecially it'd be useless for things like mass transit. So I think such a\nsystem would have to be opt-in by the seller.\n\n5) A combination of all the above.\n\nTo get the very fast light feel the actual contact period has to be quite\nshort, so I bet we'd need to optimise the bootup process of the Android\nwallet app. Right now it does slow things like deserialising giant protocol\nbuffers and is just generally not optimised for startup time. Loading the\nwallet, reading the payment request over NFC, checking the cert signatures,\nmaking the trust decision, calculating a transaction, signing it, sending\nit back to the recipient all in under 400 msec would be a tough (but fun)\nprogramming challenge. Some of the steps can be parallelised and modern\nphones are mostly multicore.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140306/0d93269c/attachment.html\u003e"}