- switching release builds to 10.7
- release binary looks like 64bit only
- tested up to 10.10
- gitian builder builds against 10.7. The docs should be consistant.
- remove 32bit text because nowadays it's obvious to support 64bit only on OSX.
* Support new rpc commands.
* Several commands now take an optional boolean includeWatchonly argument.
* "help" now has section headers, ignore them when compiling list of commands.
Attempt to codify the possible error statuses associated with script
validation. script/types.h has been created with the expectation that it will
be part of the public lib interface. The other flag enums will be moved here in
a future commit.
Logging has also been removed in order to drop the dependency on core.h. It can
be re-added to bitcoind as-needed. This makes script verification finally free
of application state and boost!
Speed up generating blocks in regression test mode, by moving
block-creating and nonce-finding directly into the setgenerate
RPC call (instead of starting up a mining thread and waiting for
it to find a block).
This makes the forknotify RPC test three times quicker, for
example (10 seconds runtime instead of 30 seconds, assuming
the initial blockchain cache is already built).
0d91ae3 The first thing that SelectParams does is call SelectBaseParams. Therefore, we do not need to call SelectBaseParams immediately prior to calling SelectParams. (mruddy)
c8b115e travis: temporarily disable the forknotify test (Cory Fields)
1877390 depends: cleanup better after qt and force a bump (Cory Fields)
560e996 travis: attempt to fix unlikely build issue (Cory Fields)
This is a long chain of errors, and there are likely other changes that could
be made to cope in other places along that chain.
If depends don't build successfully, don't bother trying again for the sake of
better logging. That's likely to hurt more than help. In this case, qt build
failed, and on the second attempt, it appeared to be successful. However, due
to a bad object from an internal gcc error on the first build, the resulting
lib was unusable. This caused bitcoin-qt to not be built, and tests and
packaging which expected bitcoin-qt to be there failed.
The root cause:
Mingw is especially crashy when using -jX, likely compounded by low-memory
environments. I've seen multiple problems with this combo in Gitian as well.
In this case:
i686-w64-mingw32-g++: internal compiler error: Killed (program cc1plus)
...
make[3]: *** [.obj/release/qdrawhelper.o] Error 4
The workaround:
Bump Travis down to using -j2 by default. Additionaly, enable --with-gui for
the windows builds. This will cause configure to fail if qt is not working
while also testing the config flag.
Other failures which may be worth revisiting separately:
- If a depends package fails, maybe remove the workdir so that it doesn't taint
subsequent runs
- See if there's anything repeatable about the ICE when building qt
This is a simplified re-do of closed pull #3088.
This patch eliminates the privacy and reliability problematic use
of centralized web services for discovering the node's addresses
for advertisement.
The Bitcoin protocol already allows your peers to tell you what
IP they think you have, but this data isn't trustworthy since
they could lie. So the challenge is using it without creating a
DOS vector.
To accomplish this we adopt an approach similar to the one used
by P2Pool: If we're announcing and don't have a better address
discovered (e.g. via UPNP) or configured we just announce to
each peer the address that peer told us. Since peers could
already replace, forge, or drop our address messages this cannot
create a new vulnerability... but if even one of our peers is
giving us a good address we'll eventually make a useful
advertisement.
We also may randomly use the peer-provided address for the
daily rebroadcast even if we otherwise have a seemingly routable
address, just in case we've been misconfigured (e.g. by UPNP).
To avoid privacy problems, we only do these things if discovery
is enabled.
We're using GetRandomBytes in several contexts where it's either
unwieldy to return an error, or an error would mean a fatal exception
anyhow.
@gmaxwell checked OpenSSL a while ago and discovered that it never
actually fails, but it can't hurt to be a bit paranoid here.
Wladimir J. van der Laan