ReadMe.md,docs: fix typos (#243)

ReadMe.md

@@ -50,10 +50,10 @@ This is a wallet that prioritizes convenience & security over privacy. Examples:
 2. Convenience (II): there are no pre-generated seeds, this is a brainwallet that uses your passphrase as a seed phrase, so that you don't need to keep backups anymore (and if you have any doubt about the security of this, understand that a hacker will always want to try to solve the WarpWallet challenge rather than target you directly).
 3. Security (I): it's a desktop/mobile wallet, not an online/web wallet like others (e.g. web wallets are easy targets: https://twitter.com/myetherwallet/status/988830652526092288 ).
 4. Security (II): it has cold-storage support (you can run it in off-line mode and import/export transactions in JSON files), but not hardware wallet support. Remember, cold storage is not the same as 'hardware wallet'. This is a software wallet, but which works in air-gapped devices (computers/smartphones) thanks to its cold-storage support, which means that it's safer than hardware wallets (after all, bugs and security issues are constantly being found on hardware wallets, e.g.: https://saleemrashid.com/2018/03/20/breaking-ledger-security-model/).
-5. Convenience over privacy: it's a wallet that can handle multiple cryptocurrencies, so its UX needs to be as generic as possible to accomodate them, therefore only contains minimal currency-specific features. For example, given that the concept of "change-addresses" doesn't exist in the Ethereum world (a concept initially thought to help privacy in the bitcoin world, but which doesn't achieve much of it in the end), then it is not used even when sending bitcoin, to avoid cluttering the UI/UX with currency-specific features/complexities (e.g. see https://twitter.com/NicolasDorier/status/1195181085702774784 ). We will still be investigating the support of more robust privacy features such as the ones provided by TumbleBit or ConfidentialTransactions.
+5. Convenience over privacy: it's a wallet that can handle multiple cryptocurrencies, so its UX needs to be as generic as possible to accommodate them, therefore only contains minimal currency-specific features. For example, given that the concept of "change-addresses" doesn't exist in the Ethereum world (a concept initially thought to help privacy in the bitcoin world, but which doesn't achieve much of it in the end), then it is not used even when sending bitcoin, to avoid cluttering the UI/UX with currency-specific features/complexities (e.g. see https://twitter.com/NicolasDorier/status/1195181085702774784 ). We will still be investigating the support of more robust privacy features such as the ones provided by TumbleBit or ConfidentialTransactions.
 
 In the development side of things, we advocate for simplicity:
-1. We will always be standing in the shoulders of giants, which means that we should not reinvent the wheel, thus we have a complete commitment to opensource as way of evolving the product and achieving the maximum level of security/auditability; unlike other multi-currency wallets (cough... Jaxx ...cough).
+1. We will always be standing on the shoulders of giants, which means that we should not reinvent the wheel, thus we have a complete commitment to opensource as way of evolving the product and achieving the maximum level of security/auditability; unlike other multi-currency wallets (cough... Jaxx ...cough).
 2. We will try to only add new features to the UX/UI that can be supported by all currencies that we support, and we will prioritize new features (Layer2: micropayments) over support for new currencies (no shitcoins thanks).
 3. Thanks to our usage of Xamarin.Forms toolkit, our frontends are based on a single codebase, instead of having to repeat logic for each platform.
 

docs/DevRoadmap.md

@@ -10,12 +10,12 @@ Some other items that haven't been prioritized include (likely only intelligible
   * (Possibly not good -> ) If using Mode.Fast, check if there's a cached balance first. If there isn't, or the time it was cached was long ago, query the confirmed balance only (like in firstStartup, we may be already doing this in case there's no cached balance) returning `decimal*Async<bool>` (the latter to give info, later, about if there's an imminentIncomingPayment), but if it was checked very recently, just query the unconfirmed one (in this case, compare the unconfirmed balance received with the cached one: if lower, show it; if higher, show the cached one and assume imminentIncomingPayment, i.e. refresh interval being shorter).
   * (Unsure about this one -> ) Query confirmed at the same time as unconfirmed, only look at a single value of those if the one to receive earlier was the unconfirmed one.
   * Frontend.XF: start querying servers in WelcomePage, with dummy addresses, just to gather server stats.
-  * Frontend.XF: show balances as soon as the first confirmed balance is retreived, and put an in-progress animated gif in the currency rows that are still being queried (this way you will easily tell as well which currencies have low server availability, which might push the user to turn some of them off in the settings).
+  * Frontend.XF: show balances as soon as the first confirmed balance is retrieved, and put an in-progress animated gif in the currency rows that are still being queried (this way you will easily tell as well which currencies have low server availability, which might push the user to turn some of them off in the settings).
   * Backend.Config.DEFAULT_NETWORK_TIMEOUT: see comment above this setting, to couple it with FaultTolerantParalellClient (or create two timeout settings, see 091b151ff4a37ca74a312609f173d5fe589ac623 ).
   * Improve stats.json feeding by 1) collecting new stats at bump.fsx time; 2) disable cancellation in non-FAST mode for this dev-env collection. 
 - Use this logo for BTC when lightning support is merged: https://www.reddit.com/r/Bitcoin/comments/dklkyo/released_this_logo_for_public_use_at_lighting/
 - Migrate from Nethereum to Nethermind, especially if Light Client Support is implemented: https://gitcoin.co/issue/NethermindEth/nethermind/32/3818 (https://github.com/NethermindEth/nethermind/issues/32)
-- Stop using Newtonsoft.Json, in favour for an alternative that doesn't need type converters. Possible options (note: don't suggest to put Chiron in this list because its approach is too manual, so it defeats the point of fleeing from NewtonsoftJson's type converters):
+- Stop using Newtonsoft.Json, in favour of an alternative that doesn't need type converters. Possible options (note: don't suggest to put Chiron in this list because its approach is too manual, so it defeats the point of fleeing from NewtonsoftJson's type converters):
   * https://github.com/Tarmil/FSharp.SystemTextJson
   * https://github.com/realvictorprm/FSharpCompileTimeJson
   * https://github.com/mausch/Fleece