BTCPrivate
/
-WIP-electrum-btcp
mirror of https://github.com/BTCPrivate/-WIP-electrum-btcp.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

update release notes, add date

This commit is contained in:
ThomasV 2018-03-05 10:39:29 +01:00
parent fe67012f71
commit e971bd8498
1 changed files with 28 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
RELEASE-NOTES
View File

@ -1,19 +1,30 @@
# Release 3.1 - (to be released) # Release 3.1 - (March 5, 2018)
* Memory-pool based transaction fees. Users can set dynamic fees that * Memory-pool based fee estimation. Dynamic fees can target a desired
target a desired depth in the memory pool. This feature is depth in the memory pool. This feature is optional, and ETA-based
optional, and ETA-based estimates (from Bitcoin Core) remain the estimates from Bitcoin Core are still available. Note that miners
default. Note that miners could exploit this feature, if they could exploit this feature, if they conspired and filled the memory
conspired and filled the memory pool with expensive transactions pool with expensive transactions that never get mined. However,
that never get mined. However, since the Electrum client already since the Electrum client already trusts an Electrum server with
trusts an Electrum server with fee estimates, activating this fee estimates, activating this feature does not introduce any new
feature does not introduce any new vulnerability; the client uses a vulnerability. In addition, the client uses a hard threshold to
hard threshold to detect unusually high fees. In practice, protect itself from servers sending excessive fee estimates. In
ETA-based estimates have resulted in sticky fees, and caused many practice, ETA-based estimates have resulted in sticky fees, and
users to overpay for transactions. Advanced users tend to visit caused many users to overpay for transactions. Advanced users tend
(and trust) websites that display memory-pool data in order to set to visit (and trust) websites that display memory-pool data in
their fees. 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 * Local transactions: Transactions can be saved in the wallet without
being broadcast. The inputs of local transactions are considered as being broadcast. The inputs of local transactions are considered as
spent, and their change outputs can be re-used in subsequent spent, and their change outputs can be re-used in subsequent
@ -39,20 +50,6 @@
* Watching-only wallets and hardware wallets can be encrypted. * Watching-only wallets and hardware wallets can be encrypted.
* Semi-automated crash reporting * Semi-automated crash reporting
* The SSL checkbox option was removed from the GUI. * 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. * The Trezor T hardware wallet is now supported.
* BIP84: native segwit p2wpkh scripts for bip39 seeds and hardware * BIP84: native segwit p2wpkh scripts for bip39 seeds and hardware
wallets can now be created when specifying a BIP84 derivation wallets can now be created when specifying a BIP84 derivation
@ -70,6 +67,9 @@
Note that due to this change, testnet wallet files created with previous Note that due to this change, testnet wallet files created with previous
versions of Electrum must be considered broken, and they need to be versions of Electrum must be considered broken, and they need to be
recreated from seed words. 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 : # Release 3.0.6 :