rich1.0npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7https://nostr.ae/npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7njumphttps://nostr.ae📅 Original date posted:2014-03-06 📝 Original message: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. It's ok if some people decide to let the app do risk analysis, but you cannot force it onto users by picking a protocol that cannot deal with manual verification. Users should always have the choice to verify their payment without time pressure and by holding the device of their choice at their individual viewing distance. Besides, how do you plan to risk-analyse the memo field? In current phone implementations, the screen must be on already for NFC to be active. Also it must be unlocked, although I certainly hope future OSes will allow payment apps on the lock screen, just like they allow music players. > To get the very fast light feel the actual contact period has to be > quite short, so I bet we'd need to optimise the bootup process of the > Android wallet app. It's already very short if you can do without Android Beam, e.g. on Android 2.3. I'd say <200 ms for an BIP21 payment request. Bootup of the app and everything else happens after -- no need to continue contact. Indeed most of the bootup time goes into loading complex wallets. Our long standing plans to clean up the wallet and archieve transactions should help. Also, if Bitcoin catches on the app will just stay in memory. 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. Even transaction signing could already happen in advance, if it can be made sure that no signed transaction "escapes" the dialog without the users consent. 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)!