tupdate release notes, add date - electrum - Electrum Bitcoin wallet
HTML git clone https://git.parazyd.org/electrum
DIR Log
DIR Files
DIR Refs
DIR Submodules
---
DIR commit e971bd849868122135012b836ece86aeb591efb7
DIR parent fe67012f71293a9bcefe436087f1d62100e5ba4a
HTML Author: ThomasV <thomasv@electrum.org>
Date: Mon, 5 Mar 2018 10:39:29 +0100
update release notes, add date
Diffstat:
M RELEASE-NOTES | 58 +++++++++++++++---------------
1 file changed, 29 insertions(+), 29 deletions(-)
---
DIR diff --git a/RELEASE-NOTES b/RELEASE-NOTES
t@@ -1,19 +1,30 @@
-# Release 3.1 - (to be released)
-
- * Memory-pool based transaction fees. Users can set dynamic fees that
- target a desired depth in the memory pool. This feature is
- optional, and ETA-based estimates (from Bitcoin Core) remain the
- default. Note that miners could exploit this feature, if they
- conspired and filled the memory pool with expensive transactions
- that never get mined. However, since the Electrum client already
- trusts an Electrum server with fee estimates, activating this
- feature does not introduce any new vulnerability; the client uses a
- hard threshold to detect unusually high fees. In practice,
- ETA-based estimates have resulted in sticky fees, and caused many
- users to overpay for transactions. Advanced users tend to visit
- (and trust) websites that display memory-pool data in order to set
- their fees.
+# Release 3.1 - (March 5, 2018)
+
+ * Memory-pool based fee estimation. Dynamic fees can target a desired
+ depth in the memory pool. This feature is optional, and ETA-based
+ estimates from Bitcoin Core are still available. Note that miners
+ could exploit this feature, if they conspired and filled the memory
+ pool with expensive transactions that never get mined. However,
+ since the Electrum client already trusts an Electrum server with
+ fee estimates, activating this feature does not introduce any new
+ vulnerability. In addition, the client uses a hard threshold to
+ protect itself from servers sending excessive fee estimates. In
+ practice, ETA-based estimates have resulted in sticky fees, and
+ caused many users to overpay for transactions. Advanced users tend
+ to visit (and trust) websites that display memory-pool data in
+ order to set their fees.
+ * Capital gains: For each outgoing transaction, the difference
+ between the acquisition and liquidation prices of outgoing coins is
+ displayed in the wallet history. By default, historical exchange
+ rates are used to compute acquisition and liquidation prices. These
+ values can also be entered manually, in order to match the actual
+ price realized by the user. The order of liquidation of coins is
+ the natural order defined by the blockchain; this results in
+ capital gain values that are invariant to changes in the set of
+ addresses that are in the wallet. Any other ordering strategy (such
+ as FIFO, LIFO) would result in capital gain values that depend on
+ the presence of other addresses in the wallet.
* Local transactions: Transactions can be saved in the wallet without
being broadcast. The inputs of local transactions are considered as
spent, and their change outputs can be re-used in subsequent
t@@ -39,20 +50,6 @@
* Watching-only wallets and hardware wallets can be encrypted.
* Semi-automated crash reporting
* The SSL checkbox option was removed from the GUI.
- * Capital gains: For each outgoing transaction, the difference
- between the acquisition and liquidation prices of outgoing coins is
- displayed in the wallet history. By default, historical exchange
- rates are used to compute acquisition and liquidation prices. These
- values can also be entered manually, in order to match the actual
- price realized by the user. The order of liquidation of coins is
- the natural order defined by the blockchain; this results in
- capital gain values that are invariant to changes in the set of
- addresses that are in the wallet. Any other ordering strategy (such
- as FIFO, LIFO) would result in capital gain values that depend on
- the set of addresses in the wallet.
- * A new version of the Electrum protocol is required by the client
- (version 1.2). Servers using older versions of the protocol will
- not be displayed in the GUI.
* The Trezor T hardware wallet is now supported.
* BIP84: native segwit p2wpkh scripts for bip39 seeds and hardware
wallets can now be created when specifying a BIP84 derivation
t@@ -70,6 +67,9 @@
Note that due to this change, testnet wallet files created with previous
versions of Electrum must be considered broken, and they need to be
recreated from seed words.
+ * A new version of the Electrum protocol is required by the client
+ (version 1.2). Servers using older versions of the protocol will
+ not be displayed in the GUI.
# Release 3.0.6 :