{"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:On Thu, Mar 6, 2014 at 12:26 PM, Andreas Schildbach\n\u003candreas at schildbach.de\u003ewrote:\n\n\u003e I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick\n\u003e up the phone the connection breaks.\n\n\nIf the phone isn't willing to immediately authorise then it'd have to fall\nback to HTTPS or Bluetooth as normal.\n\n\n\u003e Besides, how do you plan to risk-analyse the memo field?\n\u003e\n\nI guess only the amount and destination are relevant for risk analysis.\n\n\n\u003e It's already very short if you can do without Android Beam, e.g. on\n\u003e Android 2.3.\n\n\nI think IsoDep based protocols must bypass Beam - when I scan my e-passport\nthere's no beam animation.\n\n\n\u003e The most obvious optimization to speed up signature checking is to make\n\u003e it lazy. The user can already inspect the payment while signatures are\n\u003e being checked.\n\n\nWell, for \u003c400msec there can't be any user interaction. But checking\nsignatures on the payment request and constructing and signing the inputs\ncan all be done in parallel - you should be able to max out every core, at\nleast for a brief moment.\n\n\n\u003e Even the current ~10 second roundtrip is a huge improvement to the\n\u003e status quo. I recently tried to buy a subway ticket and it took me 7\n\u003e full minutes (just for the payment process)!\n\n\nThen that subway kind of sucks ;) Have you been to London and used Oyster?\nI think the capital wouldn't work at all without the low latency Oyster\ncards. The tube would have stopped scaling some time ago.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140306/f3881a64/attachment.html\u003e"}