The main thread spends time waiting for the DetectShutdownThread.
So why not just run this waiting loop function in the main thread?
One thread-stack less saves 4MB of virtual memory on 32-bit, and 8MB on
64-bit.
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.
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.
- now logs if -rootcertificates="" was used to disable payment request
authentication via X.509 certificates
- also logs which file is used as trusted root cert, if -rootcertificates
is set
- this is based on #4122 (which can be closed)
Currently a payment request is only checked for expiration upon receipt.
It should be checked again immediately before sending coins to prevent
the user from paying to an expired invoice which would then require a
customer service interaction.
- add static verifyExpired() function to PaymentServer to be able to use
the same validation code in GUI and unit-testing code
- extend unit tests to use that function and also add an unit test which
overflows, because payment requests allow expires as uint64, whereas we
use int64_t for verification of expired payment requests
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.
- verify that payment request network matches client network
- add static verifyNetwork() function to PaymentServer to be able to use
the same validation code in GUI and unit-testing code
- add a second PaymentRequest Test CA certificate to paymentrequestdata.h
(serial number f0:da:97:e4:38:d7:64:16) as caCert2_BASE64
- rename existing Test CA certificate to caCert1_BASE64
- rename existing payment request data to know they belong to
caCert1_BASE64
- update comments to reflect the changes and add a missing comment to one
of the payment requests
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.
- it is helpful to be able to test and verify payment request processing
by allowing self signed root certificates (e.g. generated by Gavins
"certificate authority in a box")
- This option is just shown in the UI options, if -help-debug is enabled.
- 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)
New versions of OpenSSL will reject non-canonical DER signatures. However,
it'll happily decode them. Decode then re-encode before verification in order
to ensure that it is properly consumed.
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.
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).
on rare occasions, rand() was returning duped values, causing duplicate
transactions.
BuildMerkleTree happily used these, but CPartialMerkleTree caught them and
returned a null merkle root.
Rather than taking changes with rand(), use the loop counter to guarantee
unique values.
At sipa's request, also remove the remaining uses of rand().
50cc6ab Merge pull request #178
941e221 Add tests for handling of the nonce function in signing.
10c81ff Merge pull request #177
7688e34 Add magnitude limits to secp256k1_fe_verify to ensure that it's own tests function correctly.
4ee4f7a Merge pull request #176
70ae0d2 Use secp256k1_fe_equal_var in secp256k1_fe_sqrt_var.
7767b4d Merge pull request #175
9ab9335 Add a reference consistency test to ge_tests.
60571c6 Rework group tests
d26e26f Avoid constructing an invalid signature with probability 1:2^256.
b450c34 Merge pull request #163
d57cae9 Merge pull request #154
49ee0db Add _normalizes_to_zero_var variant
eed599d Add _fe_normalizes_to_zero method
d7174ed Weak normalization for secp256k1_fe_equal
0295f0a weak normalization
bbd5ba7 Use rfc6979 as default nonce generation function
b37fbc2 Implement SHA256 / HMAC-SHA256 / RFC6979.
c6e7f4e [API BREAK] Use a nonce-generation function instead of a nonce
cf0c48b Merge pull request #169
603c33b Make signing fail if a too small buffer is passed.
6d16606 Merge pull request #168
7277fd7 Remove GMP field implementation
e99c4c4 Merge pull request #123
13278f6 Add explanation about how inversion can be avoided
ce7eb6f Optimize verification: avoid field inverse
a098f78 Merge pull request #160
38acd01 Merge pull request #165
6a59012 Make git ignore bench_recover when configured with benchmark enabled
1ba4a60 Configure options reorganization
3c0f246 Merge pull request #157
808dd9b Merge pull request #156
8dc75e9 Merge pull request #158
28ade27 build: nuke bashisms
5190079 build: use subdir-objects for automake
8336040 build: disable benchmark by default
git-subtree-dir: src/secp256k1
git-subtree-split: 50cc6ab0625efda6dddf1dc86c1e2671f069b0d8
Instead of using a fixed-width font in a label, which virtually
guarentees a horizontal scrollbar, use a proper text-document
that can re-layout based on user input.
Remove initialization from vector (as this is only used in the tests).
Also implement SetHex and GetHex in terms of uint256, to avoid
duplicate code as well as avoid endianness issues (as they
work in term of bytes).
- Methods that access the guts of arith_uint256 are removed,
as these are incompatible between endians. Use uint256 instead
- Serialization is no longer needed as arith_uint256's are never
read or written
- GetHash is never used on arith_uint256
If uint256() constructor takes a string, uint256(0) will become
dangerous when uint256 does not take integers anymore (it will go
through std::string(const char*) making a NULL string, and the explicit
keyword is no help).
SignatureHash and its test function SignatureHashOld
return uint256(1) as a special error signaling value.
Return a local static constant with the same value instead.
Wladimir J. van der Laan