Skip to content

Conversation

@bitmarkcc
Copy link

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.

dbkeys and others added 30 commits February 23, 2021 06:52
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
This reverts commit 7a6d96d.

Conflicts:
	src/key.h
	src/rpcprotocol.h
Conflicts:
	src/rpcserver.h
Conflicts:
	src/rpcserver.h
Coin Runner and others added 22 commits April 27, 2024 17:40
…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
@jimmypound
Copy link

Overall looks good to me. The only concern is using BoostBigNum instead of CBigNum. If there is any difference in calculation or rounding in these two types we might get a chain split. Similarly, I tried to use arith_uint256 for v.27 updated, but there were small difference in rounding which prevent chain sync.

I'll try to do a basic testing of this version when I find some time.

@bitmarkcc
Copy link
Author

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.

@jimmypound
Copy link

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.

It makes sense. I did a basic test and everything looks good.

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.

Sorry, I missed it. I just replied.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants