-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version 0.9.7.6 #136
base: master
Are you sure you want to change the base?
Version 0.9.7.6 #136
Conversation
Compiles under TLS/SSL libraries in Ubuntu 20 "Focal Fossa"
Merge SSL branch (changed to compile under new SSL/TLS) back into master
…eys-ssl-only Merge ssl-only branch back into master branch; This commit will be tagged as Release v0.9.7.4
Development of TLS / SSL compatibility changes for latest Linux OS is merged back into master branch
v0.9.7.4 TLS / SSL Compatibility
This reverts commit 7a6d96d. Conflicts: src/key.h src/rpcprotocol.h
Conflicts: src/rpcserver.h
Conflicts: src/rpcserver.h
…or setting the needed algo without affecting the global miningAlgo variable.
…ies, no .libs dir, no dynamic linking (by default). Note: This feature was initially introduced by secp256k1.
… a bit to the documentation.
…for the 0.9.7.5 release
…ihash and cryptonight blocks when "getheaders" are requested.
…nversion for the current and peak hashrate RPC calculations. Use a custom version of the bn.h header, with BN_ULONG set to uint64_t when the platform is 32 bit.
…ing factor (as is done on 64 bit machines, and should be done on 32 bit machines as well). Restore the openssl/bn.h includes.
…t, then use the max uint64_t as the uint64_t value. This is consistent with openssl's bignum
Overall looks good to me. The only concern is using I'll try to do a basic testing of this version when I find some time. |
Thanks for looking...The BigNum SSF calculation has an overflow issue that we thought about fixing earlier and it behaves differently on 32 bit vs 64 bit machines. As long as most miners are using 64 bit machines, there is no problem, but I want to make sure everything is compatible, so that's why I did that. The overflow behavior can be looked at positively also, since it causes the subsidy to 'jump around' when hashrate is close to peak hashrate (>97.6%), which can be good in preventing miners from sitting close to the peak and getting full reward without ever crossing the peak. By the way we tried contacting you on the email you put in your git commits, but no response. If you don't want to chat, that's ok, but we can if you want. |
It makes sense. I did a basic test and everything looks good.
Sorry, I missed it. I just replied. |
This pull request fixes some compilation errors present in the current tip of the master branch, fixes a bug that affects headers-first sync compatibility, as well as numerous other improvements, which can be read in the release notes for 0.9.7.5 and 0.9.7.6.
This pull request prepares us for the next stage (v27.x+), i.e. the pull request by @jimmypound.