QT_NO_KEYWORDS prevents Qt from defining the `foreach`, `signals`,
`slots` and `emit` macros.
Avoid overlap between Qt macros and boost - for example #undef hackiness
in #6421.
Conflicts:
src/qt/addressbookpage.cpp
src/qt/peertablemodel.cpp
src/qt/receivecoinsdialog.cpp
src/qt/rpcconsole.cpp
Rebased-From: d29ec6c2301e593d577126d1ca85b93307b32bf1
Github-Pull: #6433
It is unreasonable to ask to change the global package configuration
just to build a package. Not only that, this is potentially harmful to the system.
Also do a few punctuation fixes in REST-interface.md.
Github-Pull: #6413
Rebased-From: 9fbca205d4eaaf82be718b69c6533078aeb3081c
stephenhutchings commented 3 Jul 2015, 6:35 GMT:
> Hi Luke, happy for these to be distributed under the terms of the MIT licence.
> Let me know if you need anything further from me.
This is an ideal version of what the release process should look like,
making it more consistent with the OS X process. Some of the changes
described here would need to be made in the descriptors, which is somewhat
beyond what I would feel comfortable doing, not really understanding the signature process in depth.
[skip ci]
Github-Pull: #6354
Rebased-From: 6e849b8309558ec83710d86c0f784566996da58b
- Moved all seed related scripts to contrib/seeds for consistency
- Updated `makeseeds.py` to handle IPv6 and onions, fix regular
expression for recent Bitcoin Core versions
- Fixed a bug in `generate-seeds.py` with regard to IPv6 parsing
Allow for non-8333 nodes to appear in the internal seeds. This will
allow bitcoind to bypas a filter on 8333. This also makes it possible to
use the same tool for e.g. testnet.
As hosts with multiple nodes per IP are likely abusive, add a filter to
remove these (the ASN check will take care of them for IPv4, but not
IPv6 or onion).
Github-Pull: #6333
Rebased-From: ccd4369a23ca78cc348bc66a7a8c69a971ffcbf7 884454aebe9e20964643b70ff8c41f47709380bc b9329536cd8a6c152b41c9276f1def14b4d2442d
This prevents an edge case where a block downloaded and pruned
in-between successive calls to FindNextBlocksToDownload could
cause the block to be unnecessarily re-requested.
Github-Pull: #6233
Rebased-From: 3e9143386a90e508c8d41719294db11264f5f0a0
- fixes#3136
- the problem is related to Boost path and a static initialized internal
pointer
- using a std::string in CDBEnv::EnvShutdown() prevents the problem
- this removes the boost::filesystem::path path field from CDBEnv
Github-Pull: #6282
Rebased-From: 0ce30eaa36295447c6e7f8d16a05798c746fe28a
Move from sourceforge to linux foundation.
Also get rid of some other stale mentions of sourceforge.
Github-Pull: #6319
Rebased-From: 88d8525ca2ff2afc171cd0f625a098371f3a6af5
Boost assumes variadic templates are always available in GCC 4.4+, but
they aren't since we don't build with -std=c++11.
This applies the patch that fixed the issue in boost 1.57:
eec8085549
See also: https://svn.boost.org/trac/boost/ticket/10500
Github-Pull: #6280
Rebased-From: b19a88b2a0e7bd9ef603055bc8e1ef058673025d
"brew install berkeley-db4" appears to be working again. simplified instructions by removing the berkeley-db4 workaround.
Github-Pull: #6286
Rebased-From: a3a80c253cdd0299f92b9e1ba9888f0f9421f245
Some boost versions have a conflicting overload of wait_until that returns void.
Explicitly use a template here to avoid hitting that overload.
Github-Pull: #6285
Rebased-From: 72bf90d770ce5b2653fd482928646cd6a9f5f6d7
The partition checking code was using chainActive timestamps
to detect partitioning; with headers-first syncing, it should use
(and with this pull request, does use) pIndexBestHeader timestamps.
Fixes issue #6251
Github-Pull: #6256
Rebased-From: 65b94545036ae6e38e79e9c7166a3ba1ddb83f66
Make it possible to opt-out of the centralized alert system by providing
an option `-noalerts` or `-alerts=0`. The default remains unchanged.
This is a gentler form of #6260, in which I went a bit overboard by
removing the alert system completely.
I intend to add this to the GUI options in another pull after this.
Github-Pull: #6274
Rebased-From: 02a6702a82a5b00e0e0351041dd3267308b7f319
Rather than fetching a signature.tar.gz from somewhere on the net, instruct
Gitian to use a signature from a tag in the bitcoin-detached-sigs repository
which corresponds to the tag of the release being built.
This changes detached-sig-apply.sh to take a dirname rather than a tarball as
an argument, though detached-sig-create.sh still outputs a tarball for
convenience.
Github-Pull: #6269
Rebased-From: c110575a92ebe2e9a58b53d56aafa1f1ae37dbb2
Chance "getbalance *" not to use IsTrusted. The method and result
now match the "getbalance <specific-account>" behavior. In
particular, "getbalance * 0" now works.
Also fixed a comment -- GetGalance has required 1 confirmation
for many years, and the default "getbalance *" behavior matches
that.
Github-Pull: #6276
Rebased-From: 7d6a85ab5b1dc96e0f3f6f835f27bb81ba2af919
In some corner cases, it may be possible for recent blocks to end up in
the same block file as much older blocks. Previously, the pruning code
would stop looking for files to remove upon first encountering a file
containing a block that cannot be pruned, now it will keep looking for
candidate files until the target is met and all other criteria are
satisfied.
This can result in a noncontiguous set of block files (by number) on
disk, which is fine except for during some reindex corner cases, so
make reindex preparation smarter such that we keep the data we can
actually use and throw away the rest. This allows pruning to work
correctly while downloading any blocks needed during the reindex.
Rebased-From: c257a8c9a6397eee40734b235a4fdcb8045aec91
Github-Pull: #6221
We don't want to erase orphans that still have missing inputs, they should still be tracked as orphans. Also, the transaction thats being accepted can't be an orphan otherwise it would have previously been accepted, so doesn't need to be added to the erase queue.
Github-Pull: #5985
Rebased-From: 14d4eef79931318cb5968f9154cf458d9f8d27fa
AcceptBlock will no longer process an unrequested block, unless it has not
been previously processed and has more work than chainActive.Tip()
Github-Pull: #5875
Rebased-From: 9be0e6837b878f72bd087ce32b7a2f2ffb2fd544
Change `read_string` to fail when not the entire input has been
consumed. This avoids unexpected, even dangerous behavior (fixes#6223).
The new JSON parser adapted in #6121 also solves this problem so in
master this is a temporary fix, but should be backported to older releases.
Also adds tests for the new behavior.
Github-Pull: #6226
Rebased-From: 4e157fc60dae5ca69933ea4c1585a2a078b4d957
Until secp256k1 is used for verification there is no reason for Bitcoin
Core's secp256k1 to link against gmp, even if available. Pass a flag to
configure to override the bignum implementation.
This fixes a crash at runtime on ppc64 reported by @gmaxwell.
Github-Pull: #6210
Rebased-From: 7fd5b801ff16d748b5ca13ded09ed5da8eacf7e7
Previously due to an off-by-one error the wallet ignored
nLockTime-by-height transactions that would be valid in the next block
even though they are accepted into the mempool. The transactions
wouldn't show up until confirmed, nor would they be included in the
unconfirmed balance. Similar to the mempool behavior fix in 665bdd3b,
the wallet code was calling IsFinalTx() directly without taking into
account the fact that doing so tells you if the transaction could have
been mined in the *current* block, rather than the next block.
To fix this we strip IsFinalTx() of non-consensus-critical
functionality, removing the default arguments, and add CheckFinalTx() to
check if a transaction will be final in the next block.
Github-Pull: #6183
Rebased-From: 28bf06236d3b385e95fe26a7a742395b30efd6ee