update release notes

RELEASE-NOTES

@@ -1,14 +1,30 @@
 # Release 4.1.0 - Kangaroo (not released yet)
- * The wallet creation wizard will no longer ask for seed type, and
+
-   create native segwit wallets with bech32 addresses. Older seed
+This version is our first major release since we implemented the
-   types can still be created with the command line.
+Lightning protocol. While our initial Lightning release was mostly
- * GUI (both qt and kivy): invoices (incoming and outgoing) are
+about supporting the protocol, this release brings new features, that
-   automatically removed from the user-visible list once they are paid
+are specifically aimed at keeping Electrum lightweight and trustless,
-   (one confirmation is needed for onchain invoices). Once removed,
+and avoiding single points of failure. Most of the new features in
-   paid invoice details can still be accessed from the transaction
+this release are user-visible.
-   history. In Qt, the lists have been renamed to 'Sending queue' and
+
-   'Receiving queue'.
+ * The wallet creation wizard no longer asks for a seed type, and
- * Lightning: Recoverable channels (option, enabled by default)
+   creates segwit wallets with bech32 addresses. Older seed types can
+   still be created with the command line.
+
+ * Paid Invoices (both incoming and outgoing) are automatically
+   removed from the lists visible in the GUI (one confirmation is
+   needed for onchain invoices). Once removed from the list, invoice
+   details can still be accessed from the transaction history. In Qt,
+   invoice lists have been renamed to 'Sending queue' and 'Receiving
+   queue'.
+
+ * Lightning:
+    - recoverable channels (see below)
+    - trampoline payments (see below)
+    - multi-part-payment (both sending and receiving)
+    - support for upfront_shutdown_script
+
+ * Recoverable channels (option):
    - Recovery data is added to the channel funding transaction using
      an OP_RETURN. This makes it possible to recover a static backup
      of the channel from the wallet seed. Please note that static
@@ -16,11 +32,6 @@
      with the remote node, so that funds not locked in HTLCs can be
      recovered. This assumes that the remote node is still online, did
      not lose its data, and accepts to force close the channel.
-   - Channel recovery data uses 20 bytes (16 bytes of the remote
-     NodeID plus 4 magic bytes) and is encrypted so that only the
-     wallet that owns it can decrypt it. However, blockchain analysis
-     will be able to tell that the transaction was probably created by
-     Electrum.
    - This option is only available for standard wallets with an
      Electrum seed. It is not available for hardware wallets, because
      it requires a deterministic derivation of the nodeID. It is also
@@ -28,51 +39,83 @@
      wallet can have recoverable channels but has an old nodeID, users
      who want to use that feature need to close all their existing
      channels, and to restore their wallet from seed.
-   - If this option is enabled, other nodes cannot open a channel to
+   - Channel recovery data uses 20 bytes (16 bytes of the remote
+     NodeID plus 4 magic bytes) and is encrypted so that only the
+     wallet that owns it can decrypt it. However, blockchain analysis
+     will be able to tell that the transaction was probably created by
      Electrum.
- * Lightning: Support multi-part-payment (both sending and receiving)
+   - If the 'use recoverable channels' option is enabled, other nodes
- * Lightning: Trampoline routing (option, enabled by default).
+     cannot open a channel to Electrum.
-   - Trampoline is enabled by default in order to prevent unwanted
+   - If a channel is force-closed, the information in the on-chain
-     download of the network gossip. If trampoline is disabled, the
+     backup is not sufficient to retrieve the funds in the to_local
-     gossip will be downloaded, regardless of the existence of
+     output, in case the wallet is lost in a boating accident before
-     channels.
+     expiration of the CSV delay. For that reason, an additional
+     backup is presented to the user if they force-close a channel.
+
+ * Trampoline routing (option): Trampoline is a solution that allows a
+   light client to delegate path-finding on the Lightning Network,
+   without having to download the full network graph. Trampoline was
+   originally proposed by Bastien Teinturier and is currently used in
+   Phoenix, with the ACINQ node. Here is how it works in Electrum:
+
+   - Trampoline is enabled by default in Electrum, in order to prevent
+     unwanted download of the network gossip. If trampoline is
+     disabled, the gossip will be downloaded, regardless of the
+     existence of channels.
+
    - Because there is no discovery mechanism for trampoline nodes, the
-     list of available trampolines is hardcoded in the client
+     list of available trampolines is hardcoded in the client (it will
-     (currently 3 nodes on mainnet, 1 on testnet). It will remain so
+     remain so until support for trampoline routing is announced in
-     until OPTION_TRAMPOLINE_ROUTING_OPT is announced in INIT.
+     gossip). 3 trampoline nodes are currently available on mainnet:
-   - If trampoline is enabled:
+     ACINQ, Electrum and Hodlister.
-      - payments use trampoline.
+
+   - If Trampoline is enabled:
+      - payments use trampoline routing.
       - gossip is disabled.
       - the wallet can only open channels with trampoline nodes.
       - pre-existing channels with non-trampoline nodes are frozen for
         sending.
-   - There are two types of trampoline payments: legacy and end-to-end
+
-     We decide whether to perform legacy or end-to-end based on the
+   - There are two types of trampoline payments: legacy and trampoline
-     features in the invoice:
+     end-to-end. Legacy payments are possible with any receiver, but
+     they offer less privacy than end-to-end trampoline
+     payments. Electrum decides whether to perform legacy or
+     end-to-end based on the features in the invoice:
        - OPTION_TRAMPOLINE_ROUTING_OPT (1<<25) for Electrum
        - OPTION_TRAMPOLINE_ROUTING_OPT_ECLAIR (1<<51) for Eclair/Phoenix
-   - When performing a legacy payment, Electrum adds a second
+
+   - When performing a legacy payment, Electrum will add a second
      trampoline node to the route in order to protect the privacy of
      the payer and payee. It will fall back to a single trampoline if
-     the double-trampoline strategy has failed for all trampolines.
+     the two-trampoline strategy has failed for all trampolines.
+     (Note: two-trampoline payments are currently not possible if the
+     first trampoline is the ACINQ node, and is disabled for that
+     node.)
+
    - Similar to Phoenix, the fee and CLTV delay are found by
      trial-and-error. If there is a second trampoline in the route, we
      use the same fee/CLTV for both. This trial-and-error is
      temporary; the final specification should add fee information in
      the failure messages, so that we will be able to better fine-tune
      trampoline fees.
- * Lightning: Support upfront_shutdown_script
+
- * Android password unification: When the app is started, the provided
+ * Watchtowers: The 'use_local_watchtower' feature is deprecated, and
-   password is checked against all wallets in the directory. If the
+   it has been removed from the Qt GUI. The 'use_remote_watchtower'
-   test passes:
+   setting has been renamed to 'use_watchtower'.
+
+ * Password unification (Android only): When the Android app is
+   started, the entered password is checked against all wallets in
+   the directory. If the test passes:
     - all wallets are encrypted
-    - new wallets are created with the existing password
+    - new wallets will use the unified password
     - password updates are performed on all wallets
-   Whether the password is unified can be seen in the GUI: In
+   Whether the password is unified can be seen in the GUI: In the
-   settings, the description for the password setting is 'Change
+   'Settings' dialog, the description for the password setting is
-   password for this wallet', and becomes 'Change password' if
+   'Change password for this wallet' if the password is not unified,
-   password is unified.
+   and becomes 'Change password' if password is unified.
- * Submarine swaps are available on kivy/android.
+
+ * Submarine swaps are now available on kivy/android.
+
  * Android PIN reset: If the password is unified, the PIN can be reset
    by providing the password.