Commit graph

118 commits

Author SHA1 Message Date
Daniel Kraft
af82884ab7 Add "warmup mode" for RPC server.
Start the RPC server before doing all the (expensive) startup
initialisations like loading the block index.  Until the node is ready,
return all calls immediately with a new error signalling "in warmup"
with an appropriate status message (similar to the init message).

This is useful for RPC clients to know that the server is there (e. g.,
they don't have to start it) but not yet available.  It is used in
Namecoin and Huntercoin already for some time, and there exists a UI
hooked onto the RPC interface that actively uses this to its advantage.
2014-11-04 16:01:09 +01:00
Wladimir J. van der Laan
c8a25189bc
doc: release notes update for rpcallowip syntax change 2014-10-23 13:37:54 +02:00
Wladimir J. van der Laan
c313d6ecb9
doc: add headers first backwards compat warning 2014-10-21 14:56:28 +02:00
Wladimir J. van der Laan
680f7252f0 Revert "Add release notes entry"
This reverts commit 9fa53dd3bd.
2014-07-21 07:46:33 +02:00
Wladimir J. van der Laan
ad26dc9c31 Revert "Formatting, spelling, comment fixes."
This reverts commit 7a19efe040.
2014-07-21 07:46:33 +02:00
Gavin Andresen
b33d1f5ee5
Use fee/priority estimates in wallet CreateTransaction
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.
2014-07-03 13:44:33 -04:00
Tom Harding
7a19efe040 Formatting, spelling, comment fixes. 2014-06-27 16:47:33 -07:00
Tom Harding
9fa53dd3bd Add release notes entry 2014-06-27 08:07:14 -07:00
Gavin Andresen
171ca7745e estimatefee / estimatepriority RPC methods
New RPC methods: return an estimate of the fee (or priority) a
transaction needs to be likely to confirm in a given number of
blocks.

Mike Hearn created the first version of this method for estimating fees.
It works as follows:

For transactions that took 1 to N (I picked N=25) blocks to confirm,
keep N buckets with at most 100 entries in each recording the
fees-per-kilobyte paid by those transactions.

(separate buckets are kept for transactions that confirmed because
they are high-priority)

The buckets are filled as blocks are found, and are saved/restored
in a new fee_estiamtes.dat file in the data directory.

A few variations on Mike's initial scheme:

To estimate the fee needed for a transaction to confirm in X buckets,
all of the samples in all of the buckets are used and a median of
all of the data is used to make the estimate. For example, imagine
25 buckets each containing the full 100 entries. Those 2,500 samples
are sorted, and the estimate of the fee needed to confirm in the very
next block is the 50'th-highest-fee-entry in that sorted list; the
estimate of the fee needed to confirm in the next two blocks is the
150'th-highest-fee-entry, etc.

That algorithm has the nice property that estimates of how much fee
you need to pay to get confirmed in block N will always be greater
than or equal to the estimate for block N+1. It would clearly be wrong
to say "pay 11 uBTC and you'll get confirmed in 3 blocks, but pay
12 uBTC and it will take LONGER".

A single block will not contribute more than 10 entries to any one
bucket, so a single miner and a large block cannot overwhelm
the estimates.
2014-06-06 10:44:57 -04:00
Wladimir J. van der Laan
aefbf6e30c
doc: Empty release notes for next release
Now that 0.9 is branched off, the new release notes for 0.10 or 0.11 or
1.0 should be added here.

Edits to preliminary 0.9.0 release notes should be made in the 0.9.0 branch.
2014-03-03 09:45:36 +01:00
Wladimir J. van der Laan
6c0db81c09 Document new walletpassphrase behavior in 0.9
Also add a note to the release notes.
Fixes #3672.
2014-02-16 10:26:12 +01:00
Wladimir J. van der Laan
b7f591555e
doc: add gist link to 'reject' P2P message mention in release notes 2014-02-09 09:09:38 +01:00
Pieter Wuille
e3fff058e0 Correct/add/merge a few release notes entries 2014-02-08 20:25:12 +01:00
Peter Todd
31a4b898be
Cleanup v0.9 release notes 2014-02-08 07:57:03 -05:00
Wladimir J. van der Laan
0ad474ee27 doc: add preliminary release notes for 0.9.0 2014-02-07 14:21:23 +01:00
Wladimir J. van der Laan
69baec9647 doc: Add historical release notes
Add all known release notes for versions since 0.3.12,
thanks to Matt Corallo for collecting them on the wiki.
2014-01-30 12:33:03 +01:00
Pieter Wuille
8c8132be73 Prepare for 0.9 merge window 2013-05-30 04:43:51 +02:00
super3
2341e9b533 Docs Markdown Cleanup 2013-05-20 00:30:00 -04:00
Renamed from doc/release-notes.txt (Browse further)