It was too hyperactive.
gmaxwell: I mean that right now when the block gap goes over an hour it starts showing synchronizing. Increasing that to 90 minutes or so would make it only happen about 6.4 times per year
Doing so would allow an attack on old nodes, which would relay a
standard transaction spending a BIP16 output in an invalid way,
until reaching a new node, which will disconnect their peer.
Reported by makomk on IRC.
When a 0.6 wallet with compressed pubkeys is created, it writes a
minversion record to prevent older clients from reading it. If the 0.5
loading it sees a key record before seeing the minversion record however,
it will fail with DB_CORRUPT instead of DB_TOO_NEW.
not process any already received messages.
The primary reason to do this is if a node spams hundreds of messages
and we ban them, we don't want to continue processing the rest of it.
It could just as well be on either part of the gitian build, but to safely put it on the Qt side would require bumping the filename, and every gitian user rebuilding it.
v0.5.3.1 put it on the Bitcoin side, and this is easier to work with and keep safe, so I'm moving it.
Use `qmake MINGW_THREAD_BUGFIX=0` to disable
When OpenSSL's BN_bn2mpi is passed a buffer of size 4, valgrind
reports reading/writing one byte past it. I am unable to find
evidence of this behaviour in BN_bn2mpi's source code, so it may
be a spurious warning. However, this change is harmless, as only
the bignum with value 0 results in an mpi serialization of size 4.
It could just as well be on either part of the gitian build, but to safely put it on the Qt side would require bumping the filename, and every gitian user rebuilding it.
v0.5.3.1 put it on the Bitcoin side, and this is easier to work with and keep safe, so I'm moving it.
2^31 milliseconds is only about 25 days. Also clamps Sleep() to 10 years,
because it currently sleeps for 0 seconds when the sleep time would cross
2^31 seconds since the epoch. Hopefully boost will be fixed by 2028.
