Anyone building bitcoind/-qt on windows is welcome to contribute
a new one. The current information in this document is outdated,
or otherwise mostly worthless.
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.
This is PR #4271, but with the changes to the descriptors, both the names of the
files and the names of the intermediate build artifact archives, removed.
This also closes#3775 if it goes in, because it covers the changes in
that PR.
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.
Upgrade for https://www.openssl.org/news/secadv_20140605.txt
Just in case - there is no vulnerability that affects ecdsa signing or
verification.
The MITM attack vulnerability (CVE-2014-0224) may have some effect on
our usage of SSL/TLS.
As long as payment requests are signed (which is the common case), usage
of the payment protocol should also not be affected.
The TLS usage in RPC may be at risk for MITM attacks. If you have
`-rpcssl` enabled, be sure to update OpenSSL as soon as possible.
1411a51 doc: Update hash in release process for new windows deps intermediate (Wladimir J. van der Laan)
386e732 gitian: make linux qt intermediate deterministic (Wladimir J. van der Laan)
I added a link to my guide about using docker containers + LXC (I am planning to maintain this at work
for future bitcoin versions), then I mentioned other virtualization options (KVM, LXC).
This commit includes a fix issue for documentation issue #4269 that consists in telling users to
checkout correct bitcoin version before using the gitian descriptors (otherwise all hell can break loose).
Also, I replaced URL for Debian 7.4 ISO with a correct one and added link to official Debian ISO sources.
A qt installation date snuck into the host utils (lrelease etc)
This doesn't affect the end product, so no dependency version bump.
It also doesn't explain why gavin's and mine build is different
There is no need to use any specific version of boost on Linux/Unix.
Even 1.37 should still work.
Also the mention of boost-dev doesn't belong after adding oldstable.
Remove it. libboost-all-dev is already mentioned earlier.
3a54ad9 Full translation update (Wladimir J. van der Laan)
9dd5d79 devtools: add a script to fetch and postprocess translations (Wladimir J. van der Laan)
58c01a3 qt: add transifex configuration file (Wladimir J. van der Laan)
202c95c devtools: have symbol check script check for exported symbols (Wladimir J. van der Laan)
92e3022 gitian: don't export any symbols from executable (Wladimir J. van der Laan)
3ab1664 gitian: build against Qt 4.6 (Wladimir J. van der Laan)
The year is 2014. All supported operating systems have IPv6 support,
most certainly at build time (this doesn't mean that IPv6 is configured,
of course).
If noone is exercising the functionality to disable it, that means it
doesn't get tested, and IMO it's better to get rid of it.
(it's also not used consistently in RPC/boost and Net code...)
