update release notes

RELEASE-NOTES

@@ -1,31 +1,41 @@
+
 # Release 3.1 - (to be released)
 
- * Mempory pool based fee estimates. If this option is activated,
+ * Memory-pool based transaction fees. Users can set dynamic fees that
-   users can set transaction fees that target a desired depth in the
+   target a desired depth in the memory pool. This feature is
-   memory pool. This feature might be controversial, because miners
+   optional, and ETA-based estimates (from Bitcoin Core) remain the
-   could conspire and fill the memory pool with expensive transactions
+   default. Note that miners could exploit this feature, if they
-   that never get mined. However, our current time-based fee estimates
+   conspired and filled the memory pool with expensive transactions
-   results in sticky fees, which cause inexperienced users to overpay,
+   that never get mined. However, since the Electrum client already
-   while more advanced users visit (and trust) websites that display
+   trusts an Electrum server with fee estimates, activating this
-   memorypool data, and set their fee accordingly.
+   feature does not introduce any new vulnerability; the client uses a
- * Local transactions: Transactions that have not been broadcasted can
+   hard threshold to detect unusually high fees. In practice,
-   be saved in the wallet file, and their outputs can be used in
+   ETA-based estimates have resulted in sticky fees, and caused many
-   subsequent transactions. Transactions that disapear from the memory
+   users to overpay for transactions. Advanced users tend to visit
-   pool stay in the wallet, and can be rebroadcasted. This feature can
+   (and trust) websites that display memory-pool data in order to set
-   be combined with cold storage, to create several transactions
+   their fees.
-   before broadcasting.
+ * Local transactions: Transactions can be saved in the wallet without
- * The initial headers download was replaced with hardcoded
+   being broadcast. The inputs of local transactions are considered as
-   checkpoints, one per retargeting period. Past headers are
+   spent, and their change outputs can be re-used in subsequent
-   downloaded when needed.
+   transactions. This can be combined with cold storage, in order to
- * The two coin selection policies have been merged, and the policy
+   create several transactions before broadcasting them. Outgoing
-   choice was removed from preferences. Previously, the 'privacy'
+   transactions that have been removed from the memory pool are also
-   policy has been unusable because it was was not prioritizing
+   saved in the wallet, and can be broadcast again.
-   confirmed coins.
+ * Checkpoints: The initial download of a headers file was replaced
+   with hardcoded checkpoints. The wallet uses one checkpoint per
+   retargetting period. The headers for a retargetting period are
+   downloaded only if transactions need to be verified in this period.
+ * The 'privacy' and 'priority' coin selection policies have been
+   merged into one. Previously, the 'privacy' policy has been unusable
+   because it was was not prioritizing confirmed coins. The new policy
+   is similar to 'privacy', except that it de-prioritizes addresses
+   that have unconfirmed coins.
  * The 'Send' tab of the Qt GUI displays how transaction fees are
    computed from transaction size.
- * RBF is enabled by default. This might cause some issues with
+ * The wallet history can be filtered by time interval.
-   merchants that use wallets that do not display RBF transactions
+ * Replace-by-fee is enabled by default. Note that this might cause
-   until they are confirmed.
+   some issues with wallets that do not display RBF transactions until
+   they are confirmed.
  * Watching-only wallets and hardware wallets can be encrypted.
  * Semi-automated crash reporting
  * The SSL checkbox option was removed from the GUI.