b33d1f5ee5
The wallet now uses the mempool fee estimator with a new command-line option: -txconfirmtarget (default: 1) instead of using hard-coded fees or priorities. A new bitcoind that hasn't seen enough transactions to estimate will fall back to the old hard-coded minimum priority or transaction fee. -paytxfee option overrides -txconfirmtarget. Relaying and mining code isn't changed. For Qt, the coin control dialog now uses priority estimates to label transaction priority (instead of hard-coded constants); unspent outputs were consistently labeled with a much higher priority than is justified by the free transactions actually being accepted into blocks. I did not implement any GUI for setting -txconfirmtarget; I would suggest getting rid of the "Pay transaction fee" GUI and replace it with either "target number of confirmations" or maybe a "faster confirmation <--> lower fee" slider or select box.
88 lines
3.1 KiB
Markdown
88 lines
3.1 KiB
Markdown
(note: this is a temporary file, to be added-to by anybody, and moved to
|
|
release-notes at release time)
|
|
|
|
Transaction fee changes
|
|
=======================
|
|
|
|
This release automatically estimates how high a transaction fee (or how
|
|
high a priority) transactions require to be confirmed quickly. The default
|
|
settings will create transactions that confirm quickly; see the new
|
|
'txconfirmtarget' setting to control the tradeoff between fees and
|
|
confirmation times.
|
|
|
|
Prior releases used hard-coded fees (and priorities), and would
|
|
sometimes create transactions that took a very long time to confirm.
|
|
|
|
|
|
New Command Line Options
|
|
========================
|
|
|
|
-txconfirmtarget=n : create transactions that have enough fees (or priority)
|
|
so they are likely to confirm within n blocks (default: 1). This setting
|
|
is over-ridden by the -paytxfee option.
|
|
|
|
New RPC methods
|
|
===============
|
|
|
|
Fee/Priority estimation
|
|
-----------------------
|
|
|
|
estimatefee nblocks : Returns approximate fee-per-1,000-bytes needed for
|
|
a transaction to be confirmed within nblocks. Returns -1 if not enough
|
|
transactions have been observed to compute a good estimate.
|
|
|
|
estimatepriority nblocks : Returns approximate priority needed for
|
|
a zero-fee transaction to confirm within nblocks. Returns -1 if not
|
|
enough free transactions have been observed to compute a good
|
|
estimate.
|
|
|
|
Statistics used to estimate fees and priorities are saved in the
|
|
data directory in the 'fee_estimates.dat' file just before
|
|
program shutdown, and are read in at startup.
|
|
|
|
Double-Spend Relay and Alerts
|
|
=============================
|
|
VERY IMPORTANT: *It has never been safe, and remains unsafe, to rely*
|
|
*on unconfirmed transactions.*
|
|
|
|
Relay
|
|
-----
|
|
When an attempt is seen on the network to spend the same unspent funds
|
|
more than once, it is no longer ignored. Instead, it is broadcast, to
|
|
serve as an alert. This broadcast is subject to protections against
|
|
denial-of-service attacks.
|
|
|
|
Wallets and other bitcoin services should alert their users to
|
|
double-spends that affect them. Merchants and other users may have
|
|
enough time to withhold goods or services when payment becomes
|
|
uncertain, until confirmation.
|
|
|
|
Bitcoin Core Wallet Alerts
|
|
--------------------------
|
|
The Bitcoin Core wallet now makes respend attempts visible in several
|
|
ways.
|
|
|
|
If you are online, and a respend affecting one of your wallet
|
|
transactions is seen, a notification is immediately issued to the
|
|
command registered with `-respendnotify=<cmd>`. Additionally, if
|
|
using the GUI:
|
|
- An alert box is immediately displayed.
|
|
- The affected wallet transaction is highlighted in red until it is
|
|
confirmed (and it may never be confirmed).
|
|
|
|
A `respendsobserved` array is added to `gettransaction`, `listtransactions`,
|
|
and `listsinceblock` RPC results.
|
|
|
|
Warning
|
|
-------
|
|
*If you rely on an unconfirmed transaction, these change do VERY*
|
|
*LITTLE to protect you from a malicious double-spend, because:*
|
|
|
|
- You may learn about the respend too late to avoid doing whatever
|
|
you were being paid for
|
|
- Using other relay rules, a double-spender can craft his crime to
|
|
resist broadcast
|
|
- Miners can choose which conflicting spend to confirm, and some
|
|
miners may not confirm the first acceptable spend they see
|
|
|