The path locale is lazy initialized and to avoid deinitialization errors
in multithreading environments, it is set explicitly by the main thread.
Conflicts:
src/util.cpp
Rebased-From: 317e66c741aef0fd272e50aa2e82ff192ca5f7e5
Github-Pull: #5877
When re-indexing, there are a few cases where garbage data may be skipped in
the block files. In these cases, the indices are correctly written to the index
db, however the pointer to the next position for writing in the current block
file is calculated by adding the sizes of the valid blocks found.
As a result, when the re-index is finished, the index db is correct for all
existing blocks, but the next block will be written to an incorrect offset,
likely overwriting existing blocks.
Rather than using the sum of all valid blocks to determine the next write
position, use the end of the last block written to the file. Don't assume that
the current block is the last one in the file, since they may be read
out-of-order.
Rebased-From: bb6acff07982dda68b5c2ac81c99dbd7255bb9cc
Github-Pull: #5864
The only time when a client sends a "getaddr" message is when he
esatblishes an Outbound connection (see ProcessMessage() in
src/main.cpp). Another bitcoin client is expected to receive a
"getaddr" message only on Inbound connection. Ignoring "gettaddr"
requests on Outbound connections can resolve potential privacy issues
(and as was said such request normally do not happen anyway).
Rebased-From: dca799e1db6e319fdd47e0bfdb038eab0efabb85
Github-Pull: #5442
This introduces a fixed limit for the size of p2p messages, and enforces it
before download.
Rebased-From: ba04c4a7801e7d68a5e84035b919e5c3626eb7a7
Github-Pull: #5843
With headers-first we can compare against the best header timestamp, rather
than using checkpoints which require code updates to maintain.
Rebased-From: 85da07a5a001a563488382435202b74a3e3e964a
Github-Pull: #5820
Normally bitcoin core does not display any network originated strings without
sanitizing or hex encoding. This wasn't done for strcommand in many places.
This could be used to play havoc with a terminal displaying the logs,
especially with printtoconsole in use.
Thanks to Evil-Knievel for reporting this issue.
Conflicts:
src/main.cpp
This fixes a potential race condition in the CCheckQueueControl constructor,
which was looking directly at data in CCheckQueue without acquiring its lock.
Remove the now-unnecessary friendship for CCheckQueueControl
Rebased-From: cf008ac8c3c5d582562d88ad89020daef3e64dcb
Github-Pull: #5721
Since permissions and timestamps are changed for the sake of determinism,
. must not be added to the archive. Otherwise, tar may try to modify pwd when
extracting.
Rebased-From: 0c6ab676ee7d2071d48775d81116c86dacc6abf6
Github-Pull: #5790
This harmonizes the block fetch timeout with the existing ping timeout
and eliminates a guaranteed eventual failure from congestion collapse
for a network operating right at its limit.
It's unlikely that we wouldn't suffer other failures if we were really
anywhere near the network's limit, and a complete avoidance of congestion
collapse risk requires (I think) an exponential back-off. So this isn't
a major concern, but I think it's also useful for reducing the complexity
of understanding out timeouts.
Github-Pull: #5647
Rebased-From: 3ff735c99ae75c21397079f49859b81e89a2f5f8
Make this projection of priority in 1 block match the calculation in the low priority reject code.
Rebased-From: 2d9b0b7f03a268e557c6dce1dfa29401b5c9178b
Github-Pull: #5675
- before it was possible to use the steps to change e.g. amouns of
authenticated or unauthenticated payment requests (AmountSpinBox is
already set to read-only here) - this is now fixed
- also move the reimplemented stepEnabled() function to the
protected section of our class, where it belongs (see Qt doc)
Github-Pull: #5637
Rebased-From: 0fd9e2bf43d217d9a76003476661c8ab53606548
Makes it possible to compactly provide a delibrately invalid signature
for use with CHECK(MULTI)SIG. For instance with BIP19 if m != n invalid
signatures need to be provided in the scriptSig; prior to this change
those invalid signatures would need to be large DER-encoded signatures.
Note that we may want to further expand on this change in the future by
saying that only OP_0 is a "valid" invalid signature; BIP19 even with
this change is inherently malleable as the invalid signatures can be any
validly encoded DER signature.
Rebased-From: 2fa9a8ec86033b809a1c48f0396c3482c0d5d33c
Github-Pull: #5627
- qt: avoid hard-coding font names
They may not contain all necessary characters for a language
- qt: fix broken unicode chars on osx 10.10
The default font changed again.
The real fix is to compile qt against a >= 10.8 sdk, but this is simple enough
to backport to 0.10 to avoid having to do that there.
Note: NSAppKitVersionNumber is a double and there's no official value for
NSAppKitVersionNumber10_10. Since == isn't reliable for doubles, use Apple's
guidelines for testing versions here:
https://developer.apple.com/library/mac/releasenotes/AppKit/RN-AppKit/
Chinese and Japanese fonts have been hard-coded as well, otherwise they fail to
show up at all.
- qt: fonts: allow SubstituteFonts to filter based on user's language
SubstituteFonts() has been moved to after app identification so that QSettings
are accessible.
Github-Pull: #5671
Rebased-From: 73cd4edb4f1ff98c20549a609e96fa40834f5e73 52954e6efd373c14736237c4c79769bf00f5dfb8 f5ad78b34af8f50e12fab63b331768b96ec2c779
This avoids a regression for issues like #334 where high speed
repeated connections eventually run the HTTP client out of
sockets because all of theirs end up in time_wait.
Maybe the trade-off here is suboptimal, but if both choices will
fail then we prefer fewer changes until the root cause is solved.
Rebased-From: 1a25a7edf82706c3152e2d978d320ec465a34de1 7d2cb485116636595250fce4ea4eab16a877479b
Github-Pull: #5674
It turns out that some miners have been staying with old versions of
Bitcoin Core because their software behaves poorly with persistent
connections and the Bitcoin Core thread and connection limits.
What happens is that underlying HTTP libraries leave connections open
invisibly to their users and then the user runs into the default four
thread limit. This looks like Bitcoin Core is unresponsive to RPC.
There are many things that should be improved in Bitcoin Core's behavior
here, e.g. supporting more concurrent connections, not tying up threads
for idle connections, disconnecting kept-alive connections when limits
are reached, etc. All are fairly big, risky changes.
Disabling keep-alive is a simple workaround. It's often not easy to turn
off the keep-alive support in the client where it may be buried in some
platform library.
If you are one of the few who really needs persistent connections you
probably know that you want them and can find a switch; while if you
don't and the misbehavior is hitting you it is hard to discover the
source of your problems is keepalive related. Given that it is best
to default to off until they're handled better.
Github-Merge: #5655
Rebased-From: 16a5c18cea7330bd68dc9d2f768eb518af88795b 56c1093dae0c523f9f643f00c67414691272a983 1dd8ee72afc26191da51d8d3a5590eab7c9368f6
This will disconnect peers that do not transfer a block in 10 minutes, plus
5 minutes for every previously queued block with validated headers
(accomodating downstream bandwidth down to a few kilobytes per second - below
that the node would have trouble staying synchronized anyway).
Github-Pull: #5608
Rebased-From: 916130348ca803d762db912307b247f60f9aacd6
