View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004971||Taler||wallet (WebExtensions)||public||2017-03-23 19:30||2018-04-15 20:34|
|Reporter||Florian Dold||Assigned To||Florian Dold|
|Priority||normal||Severity||tweak||Reproducibility||have not tried|
|Product Version||git (master)|
|Target Version||0.5||Fixed in Version||0.5|
|Summary||0004971: wallet should optimistically generate key material and compute signature to enhance perceived performance|
|Description||Key generation is pretty slow with the emscripten libgcrypt, we should generate some keys in the background and use them when available.|
Same applies to signatures, we can pre-compute the signature before the user accepts the proposal, and throw the signature away when the user rejects.
|Tags||No tags attached.|
After thinking about it and looking at the current performance numbers, this is not a good idea.
- Creating the signatures is very fast, 50ms on a relatively old machine. Correctly creating the signature before the user accepts is quite a pain, since the coins we used for this might be spend in another transaction before the user confirms the first one. It's too complex to save 50ms. We'd save more by having a wasm implementation of the signing algorithm.
- The real performance bottleneck is generating keys (0.2s to 1s on my machine per planchet), but again this is a problem of using libgcrypt via emscripten. The browser's web crypto API can fill a 64KB buffer with cryptographically secure randomness in <1ms. Doing the pre-generation is bad: we could accidentally re-use values unless we don't save them across browser restarts. If we don't save them on browser restart, we're doing some CPU bound thing for a bunch of seconds, which potentially makes the browser slow in the first seconds.
The browser probably already collects entropy in the background, when we try to do it ourselves the implementation will only end up worse.
So we should:
- not worry about signature performance, it's not a bottleneck
- use webcrypto instead of emscripten+libgcrypt to get randomness
Eh, I disagree. 50ms is actually a LOT. I get 5 ms RTT to 18.104.22.168, we are likely to get <20ms RTT for good hosting of the exchange. I get less than 50ms RTT to taler.net in Rennes right now!
And humans _can_ notice latencies in that order of magnitude. So don't dismiss the 50 ms, I had expected it to be less (and still judged it worth it). Sure, there is checking/making sure the coins were not spent elsewhere in the meantime and some complexity, but I do think it's worth it. Note that for withdrawing, that's not an issue as that is not really on the critical path.
Speculative computation of signature for /pay is implemented in ca2a46a8575.
Aside from the problems mentioned above, we can't really pre-compute planchets unless we know the amounts and denominations.
|2017-03-23 19:30||Florian Dold||New Issue|
|2017-03-23 19:30||Florian Dold||Status||new => assigned|
|2017-03-23 19:30||Florian Dold||Assigned To||=> Florian Dold|
|2017-04-02 00:49||Christian Grothoff||Severity||minor => tweak|
|2017-04-02 00:49||Christian Grothoff||Product Version||=> git (master)|
|2017-04-02 00:49||Christian Grothoff||Target Version||=> 0.5|
|2017-12-12 17:34||Florian Dold||Note Added: 0012669|
|2017-12-12 17:34||Florian Dold||Assigned To||Florian Dold => Christian Grothoff|
|2017-12-12 17:35||Florian Dold||Status||assigned => feedback|
|2017-12-12 17:50||Christian Grothoff||Note Added: 0012670|
|2017-12-12 17:50||Christian Grothoff||Assigned To||Christian Grothoff => Florian Dold|
|2017-12-12 17:50||Christian Grothoff||Status||feedback => assigned|
|2017-12-12 23:09||Florian Dold||Note Added: 0012672|
|2017-12-12 23:09||Florian Dold||Status||assigned => resolved|
|2017-12-12 23:09||Florian Dold||Resolution||open => fixed|
|2017-12-14 15:39||Christian Grothoff||Fixed in Version||=> 0.5|
|2018-04-15 20:34||Christian Grothoff||Status||resolved => closed|