rich1.0npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydhttps://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydnjumphttps://nostr.ae📅 Original date posted:2014-03-06 📝 Original message:On Thu, Mar 6, 2014 at 12:26 PM, Andreas Schildbach <andreas at schildbach.de>wrote: > I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick > up the phone the connection breaks. If the phone isn't willing to immediately authorise then it'd have to fall back to HTTPS or Bluetooth as normal. > Besides, how do you plan to risk-analyse the memo field? > I guess only the amount and destination are relevant for risk analysis. > It's already very short if you can do without Android Beam, e.g. on > Android 2.3. I think IsoDep based protocols must bypass Beam - when I scan my e-passport there's no beam animation. > The most obvious optimization to speed up signature checking is to make > it lazy. The user can already inspect the payment while signatures are > being checked. Well, for <400msec there can't be any user interaction. But checking signatures on the payment request and constructing and signing the inputs can all be done in parallel - you should be able to max out every core, at least for a brief moment. > Even the current ~10 second roundtrip is a huge improvement to the > status quo. I recently tried to buy a subway ticket and it took me 7 > full minutes (just for the payment process)! Then that subway kind of sucks ;) Have you been to London and used Oyster? I think the capital wouldn't work at all without the low latency Oyster cards. The tube would have stopped scaling some time ago. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140306/f3881a64/attachment.html>