View Issue Details

IDProjectCategoryView StatusLast Update
0004971Talerwallet (WebExtensions)public2018-04-15 20:34
ReporterFlorian DoldAssigned ToFlorian Dold 
PrioritynormalSeveritytweakReproducibilityhave not tried
Status closedResolutionfixed 
Product VersionSVN HEAD 
Target Version0.5Fixed in Version0.5 
Summary0004971: wallet should optimistically generate key material and compute signature to enhance perceived performance
DescriptionKey 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.
TagsNo tags attached.

Activities

Florian Dold

2017-12-12 17:34

manager   ~0012669

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

Christian Grothoff

2017-12-12 17:50

manager   ~0012670

Eh, I disagree. 50ms is actually a LOT. I get 5 ms RTT to 8.8.8.8, 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.

Florian Dold

2017-12-12 23:09

manager   ~0012672

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.

Issue History

Date Modified Username Field Change
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 => SVN HEAD
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