compilation on debian 11 with gcc 10 fails

./autogen.sh
./configure --with-incompatible-bdb --with-gui=no --disable-tests --disable-bench --without-miniupnpc --disable-zmq --disable-wallet
make -j8

error

httpserver.cpp:75:10: error: ‘deque’ in namespace ‘std’ does not name a template type
   75 |     std::deque<std::unique_ptr<WorkItem>> queue;
      |          ^~~~~
httpserver.cpp:34:1: note: ‘std::deque’ is defined in header ‘<deque>’; did you forget to ‘#include <deque>’?
   33 | #include <support/events.h>
  +++ |+#include <deque>
   34 | 
httpserver.cpp: In member function ‘bool WorkQueue<WorkItem>::Enqueue(WorkItem*)’:
httpserver.cpp:93:13: error: ‘queue’ was not declared in this scope; did you mean ‘Enqueue’?
   93 |         if (queue.size() >= maxDepth) {
      |             ^~~~~
      |             Enqueue
httpserver.cpp:96:9: error: ‘queue’ was not declared in this scope; did you mean ‘Enqueue’?
   96 |         queue.emplace_back(std::unique_ptr<WorkItem>(item));
      |         ^~~~~
      |         Enqueue
httpserver.cpp: In member function ‘void WorkQueue<WorkItem>::Run()’:
httpserver.cpp:107:35: error: ‘queue’ was not declared in this scope; did you mean ‘Enqueue’?
  107 |                 while (running && queue.empty())
      |                                   ^~~~~
      |                                   Enqueue
httpserver.cpp:111:31: error: ‘queue’ was not declared in this scope; did you mean ‘Enqueue’?
  111 |                 i = std::move(queue.front());
      |                               ^~~~~
      |                               Enqueue

This issue affected Bitcoin, Bitcoin Cash, and other coins.

Please refer to the following discussions:

bitcoin/bitcoin#18487
https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/-/issues/327

Running 8.22.0-rc3 n testnet on Windows 10.

The release notes for RC3 state this: "Minimum Transaction Fee Increase: The minimum transaction fee has been increased from 0.001 DGB to 0.1 DGB per kilobyte."

I tried to spend 1million DGB with a fee/kB of 0.1 (supposedly new new minimum tx fee/kB), but received this error (I do not have -maxfee set in config file):

I then changed the fee/kb to 0.01 (which is now below the new minimum tx fee/kB) and the tx was going to work:

You will also notice that the total transaction fee is only 0.00208 DGB, which is far less than the 10 DGB max from #159.
Which, seeing that the tx size is only 0.208 kB, the total fee at the fee/kB rate of 0.1 would still only be 0.0208 DGB. So why did the first attempt not work?

Restoring wallet on android taking long time. it took more than 2 Hours.
I am having latest android phone as of date 8-June-2021. OnePlus 9R and 75MBps broadband connection.

Restoring wallet should be fast and so more people can use user-friendly.

Please add a unit test to check if the wallet can handle thousands of rpc requests per second. It doesn't need to respond to all but the wallet should not crash if it happens.

Currently 7.17.3 crashes randomly on me and I suspect it is do to some kind of buffer over run do to large number of requests. Requests failing is ok but core needs to stay running.

Monolitic Test Executor

Since there are a lot of branches to check, I created this script that will automatically execute all the monolitic PRs and output their return code.

Prerequisites

Clone the repo and make sure the project is ready to compile. Example:

git clone https://github.com/DigiByte-Core/digibyte.git && cd digibyte
./autogen.sh
./configure

Execute the script

The following script will hopefully make sure the tests are executed automatically:

#!/bin/bash

SKIP='-'
REPO='https://github.com/SmartArray/digibyte.git'

BRANCHES=$(cat <<EOF
tests/versionbits_tests
tests/validation_block_tests
tests/rpc_tests
tests/pow_tests
tests/miner_tests
tests/denialofservice_tests
tests/main_tests
tests/key_tests
tests/key_io_tests
tests/txindex_tests
${SKIP}tests/wallet_tests
tests/versionbits_tests
EOF
)

set -e

if [ -z "$1" ]; then
	echo "Please provide repo dir"
	exit 1
fi

PROJECT_DIR=$(cd "$1" && pwd)

if [ ! -d "$PROJECT_DIR" ]; then
	echo "Provided parameter '$PROJECT_DIR' is not a directory"
	exit 1
fi

if [ ! -d "${PROJECT_DIR}/.git" ]; then
	echo "Provided directory is not a git repo"
	exit 1
fi

REMOTE_NAME="smartarray"

rm -rf "${PROJECT_DIR}/logs" && mkdir -p "${PROJECT_DIR}/logs"
cd "$PROJECT_DIR"

# Add remote
git remote | grep -q "$REMOTE_NAME"
rc=$?

if [ $rc -ne 0 ]; then
	git remote add "$REMOTE_NAME" "$REPO"
fi

LOG_DIR=$(cd logs && pwd)
TEST_DIR=$(cd src/test && pwd)
RED='\033[0;31m'
GREEN='\033[0;32m'
RED='\033[0;31m'
NC='\033[0m'

set +e

echo "Executing tests..."

for branch in $(echo "$BRANCHES"); do 
	echo

	if [[ ${branch:0:1} == "-" ]]; then
		# Skip
		echo "> SKIPPING TEST $(echo $branch | cut -c2-)"
		continue
	fi

	TEST_NAME=$(echo "$branch" | awk '{split($0,a,"/"); print a[2]}')
	echo "> TESTING BRANCH $branch [$TEST_NAME]..."
	cd "$PROJECT_DIR"

	# Catch errors
	trap "printf \"${RED}${branch} failed!${NC}\n\" && continue" ERR

	# Check if local branch exists, if not, create it by checking remote out.
	if ! git show-ref --verify --quiet "refs/heads/$branch"; then
		git checkout -f --track "${REMOTE_NAME}/${branch}" >> "${LOG_DIR}/${TEST_NAME}_checkout.log" 2>&1
	fi

	# Pull recent changes.
	git pull "$REMOTE_NAME" "$branch" >> "${LOG_DIR}/${TEST_NAME}_pull.log" 2>&1

	# Compile Tests
	cd "${TEST_DIR}" && make -j4 >> "${LOG_DIR}/${TEST_NAME}_make.log" 2>&1

	# Run Tests
	./test_digibyte -t "${TEST_NAME}" >> "${LOG_DIR}/${TEST_NAME}_test.log" 2>&1
	rt=$?

	printf "  return code = $rt"
	if [ $? -eq 0 ]; then
		printf "${GREEN} Success! ${NC}\n"
	else
		printf "${RED} Failure! ${NC}\n"
	fi
done

I have not been able to mint a coin since:
Wed Sep 15 2021 06:41:29 GMT-0500 (Central Daylight Time)
After block height 13656975

I also noticed that the Coin Difficulty has been much lower that the past.

What is going on with it?

Really old wallets can not spend all there DigiByte. This has been commonly refereed to as the netflix bug because the fix proposed by Jered was to delete the block history and while the wallet was syncing continuously try sending the funds to a new address which takes hours.

I think I may know what causes this bug. The listunspent commands default max confirms is 9,999,999 which is only half the age of DigiByte. I believe the bug is a result of the standard send command using the default value which in really old wallets will not find all utxos.

Even if this is not the cause of the bug this default value should be increased to the max integer value or at least add 1 more 9 to the number so it is longer then the chain.

if this is official now why does it show older version then the old repo?

Please make an example build in Docker and docker-compose. This will make your code much easier to use.

When using coin control & selecting 15 or more manual inputs, the QT core wallet throws a TX error. We don't have the fee rates set correctly.

The error is defined here in code:

It looks like the bug is now in MAX_FEE_EXCEEDED
Well, the bug is the fee rates we just changed most likely. Should be an easy fix, just need to calculate all the fee rates correctly.
MAX_FEE_EXCEEDED is defined here:

Is your feature request related to a problem? Please describe.
At the present time, the GUIX cross compilation capability added by this PR does not support Apple Silicon and will fail with indeterminant errors.

Describe the solution you'd like
Resolve GUIX errors when compiling for Apple Silicon.

I think we should agree on a term for the DigiByte equivalent of a Satoshi and stick to it.

We are not Bitcoin so I think we should avoid using the term sats or satoshis for the smallest denomination of DGB. It will only lead to confusion in the future. I believe these have been referred to as DigiSatoshis in the past which is a bit of a mouthful and in my opinion not a great name. I think we can do better.

Two ideas:

digits (dits for short) - a 'digit' can mean a number. https://www.dictionary.com/browse/digit

bits - a 'bit' has been a term used with fiat money to refer to a small coin. e.g. Thrupenny bit: https://en.wikipedia.org/wiki/Threepence_(British_coin) It also connects with byte.

I personally like bits but perhaps this is a bit too close to Bit-coin?

What do people think? Any other suggestions?

I have been testing DigiByte Core v8.22.0-rc2 (mainnet) on the Raspberry Pi 4 8gb and am seeing some problematic performance issues. I setup a full node to sync from scratch on mainnet, and so far I have been syncing for 37 hours and I am still only at 5.4%. This is incredibly slow compared to what I have typically seen running v7.17.3 when a full sync from scratch never took not more than 24 hours (probably around 18 hours). Does anyone know what could be causing this?

          Awesome you found this @barrystyle ! Thanks for the contribution. It looks like there might be a couple of other places where `COINBASE_MATURITY_2` needs added properly to fix the issue as @beggsdl mentioned above. 

txmempool.cpp needs an additional COINBASE_MATURITY_2 entry:

Here is txmempool.cpp COINBASE_MATURITY_2 in 7.17.3:

Also in src/wallet/wallet.cpp looks like we need change to COINBASE_MATURITY_2 as well:

Here is what 7.17.3 shows:

V7.17.3 mentions COINBASE_MATURITY_2 in these locations:

current 8.22 including this PR onlys shows COINBASE_MATURITY_2 in 3 places outside of tests:

I can add additions on to this PR @barrystyle or you can modify yours. Just let me know.

Originally posted by @JaredTate in #157 (comment)

Describe the issue

When executing the functional test suite, test/functional/interface_zmq.py fails. See here.

What behavior did you expect?

test/functional/interface_zmq.py should not fail when the test runner executes the functional test suite.

What was the actual behavior (provide screenshots if the issue is GUI-related)?

The test/functional/interface_zmq.py functional test fails. See here.

What version of DigiByte Core are you using, where did you get it (website, self-compiled, etc)?

v8.22

Spotted by @Jongjan88. In the fast start code 8.22.0 fast start code, after sending a transaction, the 'from' value says 'unknown':

Expected behaviour

The node is able to synchronise fully and continue operation normally.

Actual behaviour

Somewhere before fully synchronisation the application crashes.

The following is the event on the Windows 11 Event Console.
dgb-evtx.zip

To reproduce

Synchronise the blockchain DB, I guess. I started with an old database from 2018 and synchronised up to the very few days of march 2024.

I then downloaded 7.17.3 and completed the synchronisation. And now the v8.22.0-rc3 seems to work ok. So, I'm not sure what's happening.

System information

• DigiByte Core : v8.22.0-rc3 (github release digibyte-8.22.0-rc3-win64-setup-unsigned.exe)
• OS: Windows 11
• CPU: AMD Ryzen 9 5900HX
• Disk : 1TB PCIe® 3.0 NVMe™ M.2 (model HFM001TD3JX013N )

There's no unusual log entries in debug.log file before the crash. Only the Windows event attached above.

I want to thank everyone for the hard work they have put into the upcoming DGB 8.22.0 client. Over the past 6 months, there has been a tremendous amount of effort poured into 8.22.0.

This will be the largest, most reviewed, and most tested release ever made for DGB. We will also have the most complete release ever as well. Now that we are on the verge of completing the upstream BTC 8.22 merge into our "develop" branch it is important we have a checkoff list so everyone in the community is on the same page as to what is needed.

Here is an initial list, if you have more please mention it and it will be added. The idea is so everyone is on the same page as to what a Minimum Viable Product looks like for 8.22 with remaining tasks.

Note: To those non devs reading this as development progress update, please understand there are 1000s of individual tasks already completed during the upstream BTC merge prior to this final list being drafted. At time of this writing there are +281,173 lines of code added and −92,788 lines of code removed in the 8.22 PR contained in 2,286 commits. That is a massive amount of work.

• TODO-01: Merge https://github.com/DigiByte-Core/digibyte/tree/feature/8.22.0 into https://github.com/DigiByte-Core/digibyte/tree/develop
  • Ensure no merge conflicts from feature branch to develop
  • Setup Dandelion Feature branch
  • Setup Fix Functional Tests Feature Branch
  • Setup Fee Feature Branch
  • Setup Algo Swap Feature Branch
  • Setup GUI/ Theme Feature Branch
  • Setup Supply Curve/ Limit Feature Branch
  • Setup Client Speed / Optimize Loadup feature branch
• TODO-02: Confirm Dandelion Working Properly
  • Validate Dandelion is really disabled when using -disable-dandelion arg & non-dandelion transactions can be sent.
  • Validate Dandelion is enabled (i.e. dandelion thread is starting) when not specifying -disable-dandelion arg
  • Validate Dandelion is enabled & correctly broadcasting a dandelion transaction (observe logs!!). Ensure that the transaction eventually transitions from the stempool into the real mempool.
  • Validate Dandelion is enabled but normal transactions are still possible
• TODO-03: Confirm MultiAlgo Mining Working Properly
  • Mine sha256 block
  • Mine odocrypt block
  • Mine Qubit block
  • Mine Skien block
  • Mine Scrypt block
• TODO-04: Confirm All DGB Chain Specific Settings Set Properly
  • Confirm Buried Deployments
  • Confirm Ports
  • Confirm Protocol Version
  • Confirm Client Version
  • Confirm Seeds
  • Confirm Checkpoints
• TODO-05: Confirm Taproot Deployment Set Properly & Tested
  • Set Taproot Activation Window
  • Test Taproot Activation
• TODO-06: Confirm DGB Signet Added Properly
  • Set initial parameters
  • Test Signet
• TODO-07: Confirm 8.22 DGB GUI Working As Expecting
  • Confirm Theme & Icons
  • Confirm Send Coins Page
  • Confirm Home Screen
  • Update Version Image
  • Confirm Receive Page
  • Test GUI Multi Wallet Feature
• TODO-08: Confirm DGB Testnet Setup Properly & Reset
  • Reset Testnet
  • Test mine all algos
  • Test taproot activation
• TODO-09: Finalize TX Fee Policy for DGB v8.22
  • Remove RBF
  • Determine Minimum DGB TX Fee
  • Test Fee Estimates
• TODO-10: Fix All Unit Tests
• TODO-11: Fix All Functional Tests
• TODO-12: Fix All Util & Fuzz Tests
• TODO-12: Finalize Supply Curve / Distribution Hard Cap Code
• TODO-13: Optimize Initial Client Load Up Speed

This issue is difficult to explain, especially for a non-developer who does not understand the inner workings of the codebase, but I will try. All I can say for sure is that there definitely IS a problem, so please take this issue seriously, even if my assumptions are wrong.

In recent weeks we have been trying to get the testnet into a better state by getting more nodes online. With some people running 7.17.3/7.17.2 and others running 8.22.0-rc2 (or the rc3 preview with fast start), we discovered that there is a fork, though we have struggled to understand both why it happened, and why the nodes on the chain with less work were not automatically reverting to other chain as you would expect. We thought that perhaps this was caused by the fact that the chain had stalled the other week due to there being no miners, but it seems that there is something else going on to cause this.

What we noticed was that there were some nodes stuck on a shorter chain that is currently stalled at block height 2,444,197 and that there seem to be other nodes syncing to 2,7xx,xxx (and climbing). All nodes seemed to be stuck on their respective chain. To try and repair the fork we first resorted to downloading the shorter chain data and bootstapping the other nodes from it. At the time @ZULUPooL was mining on this chain, and this is the one the testnet block explorer was on. He was running the fast start version of 8.22.0 and had been since the summer. But he was still on the short chain. (perhaps because he had been running on it since before the block height that causes the issue). Trying to persuade other nodes to sync with his shorter chain failed.

We then instead had everyone try and sync from scratch to the longer chain. Zulupool stopped mining the short chian, deleted the blockchain data, and resynced to the longer chain. He then began mining on that one. New nodes running 8.22.0-rc2 all seemed to sync automatically with this longer chain, but older nodes running 7.17.x remained stuck on the shorter chain. I am pretty sure (though not positive) that we are seeing new nodes running 7.17.x syncing organically to the shorter chain and new nodes running 8.22.0-rcx syncing to the longer chain. You can see below that we now have more nodes running 8.22.0-rcx on the long chain than nodes on the shorter chain running 7.17.x

In the last 24 hours several of us have now tried to sync a 7.17.3 node from scratch, to see if we could force them to use the longer chain. Given that 7.17.3 running testnet has no working seeders, the only way to get it to start syncing is to manually add an existing node. We have tried to add only existing nodes on the long chain by putting this in digibyte.conf:

[test]

connect=198.58.124.101:12026
connect=157.245.63.215:12026
connect=116.202.241.54:12026
connect=80.123.84.18:12026
connect=80.122.107.230:12026
connect=80.122.142.86:12026

At least two nodes running 7.17.3 have failed to sync to the longer chain. They reach a certain point and stop. The node I synced yesterday is now stuck at block height 2,438,506. It appears to go no further. Others have had their node sync to approximately this height as well (though not always exactly the same height. Please see the chat in the DigiByte Discord here: https://discordapp.com/channels/878200503815782400/1133815334013509764

My debug.log file now just repeats:
2023-12-27T21:12:09Z ERROR: AcceptBlockHeader: prev block invalid

Similarly @dangb048 on Discord has synced his node to 2,438,595 and debug.log is also saying "prev block invalid" like mine.

His other testnet node had finished syncing headers and was trying to sync blocks. The debg log says:

2023-12-27T16:15:32Z UpdateTip: new best=d2219d9029412babde7415caa530a3fd44bced48001dbaffb89642fd732149a2 height=2438594 version=0x20000002 algo=1 (scrypt) log2_work=50.854723 tx=2729902 date='2023-08-31T21:12:34Z' progress=0.021502 cache=451.1MiB(2599378txo)
2023-12-27T16:15:32Z block height for reward is 2438595
2023-12-27T16:15:32Z UpdateTip: new best=ce4ea8dc58a2121bc18fd512a1ef3c084ba922d88218a51a767c9ca3a2678064 height=2438595 version=0x20000002 algo=1 (scrypt) log2_work=50.854723 tx=2729903 date='2023-08-31T21:13:05Z' progress=0.021502 cache=451.1MiB(2599380txo)
2023-12-27T16:15:32Z Pre-allocating up to position 0x7000000 in blk00005.dat
2023-12-27T16:15:32Z ERROR: ConnectBlock: Consensus::CheckTxInputs: aab14bf168e90f8f27682a430e3ad12cdf195bb9a7ae2b1fba8c8b758a2f7f87, bad-txns-premature-spend-of-coinbase, tried to spend coinbase at depth 79 (code 16)
2023-12-27T16:15:32Z InvalidChainFound: invalid block=517d2751438a83ec26d74b7037d394e3777250d42f48d23836829d25f1c0d705  height=2438596  log2_work=50.854723  date=2023-08-31T21:14:40Z
2023-12-27T16:15:32Z InvalidChainFound:  current best=ce4ea8dc58a2121bc18fd512a1ef3c084ba922d88218a51a767c9ca3a2678064  height=2438595  log2_work=50.854723  date=2023-08-31T21:13:05Z
2023-12-27T16:15:32Z ERROR: ConnectTip(): ConnectBlock 517d2751438a83ec26d74b7037d394e3777250d42f48d23836829d25f1c0d705 failed
2023-12-27T16:15:32Z InvalidChainFound: invalid block=957ae573086a2ee26fe2d3d0704bf7c5e78b8947d8e6f288fcd92af110f8f97a  height=2438600  log2_work=50.854724  date=2023-08-31T21:17:04Z
2023-12-27T16:15:32Z InvalidChainFound:  current best=ce4ea8dc58a2121bc18fd512a1ef3c084ba922d88218a51a767c9ca3a2678064  height=2438595  log2_work=50.854723  date=2023-08-31T21:13:05Z
2023-12-27T16:15:46Z ERROR: AcceptBlockHeader: prev block invalid

Are we witnessing an unintended hard fork? I don't know but there is definitely something strange happening. I would appreciate everyone's assistance to get to the bottom of this. We obviously do not want to experience something similar happening on mainnet.

Given that we are now aware that there is a serious bug in these release candidates, I propose that we remove the binaries from GitHub, if not also the source code. We now know that the forking issue noticed on testnet is caused by this coin maturity issue and that it affects both these releases. Hopefully we are close to being ready for an RC3 release but I think the other releases should be taken down immediately. We do not want more people running them as there are already quite a lot of these node already.

debug.log

Describe the issue

When executing the functional test suite via test/functional/test_runner.py --extended, some tests will intermittently fail. However, when running each test in isolation, they will all pass save for test/functional/zmq_test.py which there is another raised issue for..

It does not matter how many threads the test runner is configured to run (e.g. >= 1); all configurations will result in random functional test failures.

What behavior did you expect?

The expected behavior is that regardless of the number of threads the test runner is configured with, all functional tests will pass.

What was the actual behavior (provide screenshots if the issue is GUI-related)?

The actual behavior is that some functional tests will fail intermittently, regardless of the number of threads the test runner is configured with. See here.

How reliably can you reproduce the issue, what are the steps to do so?

This issue can be reproduced on a local machine and via GitHub Actions.

What version of DigiByte Core are you using, where did you get it (website, self-compiled, etc)?

v8.22

What type of machine are you observing the error on (OS/CPU and disk type)?

All machine types can reproduce this issue, but Mac OS 10.15, 11 and 12 were used locally. GitHub Actions with Ubuntu latest were also used.

This issue occurred several years back with legacy wallets, but has emerged again in 7.17.2. The main screen shows the correct balance and when you run 'getbalance' in the console, it matches correctly. In addition, the DigiByte explorer shows the right amount when typing in the wallet address. When you click the 'Send' button in the Core Wallet and use "Total Available Balance", it does not match. It shows a difference in the correct balance. I have tried upgrading to 7.17.3 with the same backup file and it has the same issue.

Sometimes during startup digibyte-cli pauses for long stretches without returning a response - sometimes almost two minutes.

You can see a video showing the issue here. (I tried to post this on Github but it is too big) DigiNode Tools uses digibyte-cli throughout to check on the status of DigiByte Core. Notice that at 00:31 it pauses for almost two minues. This is the script simply waiting for digibyte-cli to respond. Not ideal. If it can't respond in a timely fashion it would be better to return an error rather than freezing.

While not a showstopping bug, perhaps this is something that can be optimized. It also may be something has has already been improved by #142 - more testing is needed. I am sharing this in case anyone else encounters the issue so we can look out for it. If all seems okay, we can close it.

@yacagel previously documented this in Issue #130 - #130

#https://github.com/DigiByte-Core/digibyte/blob/archive/7.17.2/src/wallet/wallet.h
Digibyte 7.17.2
LINE 54:
//! minimum recommended increment for BIP 125 replacement txs
static const CAmount WALLET_INCREMENTAL_RELAY_FEE = 5000;

#https://github.com/bitcoin/bitcoin/blob/23.x/src/wallet/wallet.h
Bitcoin 23,24,25,26
LINE 95:
//! minimum recommended increment for BIP 125 replacement txs
static const CAmount WALLET_INCREMENTAL_RELAY_FEE = 5000;

#https://github.com/DigiByte-Core/digibyte/blob/develop/src/wallet/wallet.h
Digibyte Dev
LINE 86:
//! minimum recommended increment for BIP 125 replacement txs
static const CAmount WALLET_INCREMENTAL_RELAY_FEE = 1000000;

WALLET_INCREMENTAL_RELAY_FEE
From 5.000 to 1.000.000?

No available progress bar showing on DGB 8.22-RC2

DigiByte has 3 address formats.
2x Base58 addresses starting with D and S and 1 bech32 format starting with dgb1

The wallet though also currently also allows sending to Base58 addresses starting with 3. This should be blocked to prevent accidental sending to Bitcoin addresses.

I know addresses starting with 3 use to exist but they where all remapped to addresses starting with S when the header was changed and the private keys still all work with the new address. On the rare unlikely chance someone has a paper wallet with the address starting with 3 printed on it any wallet that supports sweeping will still be able to sweep the funds out irregardless of the address header and the proper new address can still easily be calculated by replacing the header and recompiling the checksum. https://chainz.cryptoid.info/dgb/ even does this automatically if you enter one of these addresses.

[UPDATE: I have rewritten this explanation, after digging deeper into the issue.]

I am in the process of updating DigiNode Tools so that you can optionally switch between the DigiByte Core release version and the pre-release version (if available). This will make it easy for DigiNode users to quickly install/upgrade to the pre-release version with minimal effort, and even revert back to the release version in the event of a problem.

I have the changes to my script pretty much finished, except that I have noticed an inconsistency with the formatting of the release filename for 8.22.0-rc2, which is breaking my script.

Currently in my script the download URL is formatted like this: https://github.com/DigiByte-Core/digibyte/releases/download/v${DGB_VER_RELEASE}/digibyte-${DGB_VER_RELEASE}-${ARCH}-linux-gnu.tar.gz

It inserts the relevant variables as needed:
DGB_VER_RELEASE=digibyte_core_release_version_number e.g. 7.17.3 or 8.22.0-rc1
ARCH=system_architecture e.g. aarch64

This works fine for 7.17.2, 7.17.3 and 8.22.0-rc1:

https://github.com/DigiByte-Core/digibyte/releases/download/v7.17.2/digibyte-7.17.2-aarch64-linux-gnu.tar.gz
https://github.com/DigiByte-Core/digibyte/releases/download/v7.17.3/digibyte-7.17.3-aarch64-linux-gnu.tar.gz
https://github.com/DigiByte-Core/digibyte/releases/download/v8.22.0-rc1/digibyte-8.22-rc1-aarch64-linux-gnu.tar.gz

Unfortunately it breaks on 8.22.0-rc2:

https://github.com/DigiByte-Core/digibyte/releases/download/v8.22.0-rc2/DigiByte-v8.22.0-RC2-aarch64-linux-gnu.tar.gz

With 8.22.0-rc2, the filename now has a letter 'v' before the version number (not to mention the capitalisation in 'DigiByte'). This means my script is not able to correctly generate the correct URL and the download fails.

Obviously, for DigiNode Tools to be able to automatically download all future releases of DigiByte Core automatically, it helps if the formatting of the filename is consistent across all releases. If this is a one off mistake, that's fine - I can obviously handle the discrepancy on this occasion by tweaking the download URL for 8.22.0-rc2 but if not, I think it is really important to ensure there is consistency. It affects anyone who is trying to download DigiByte automatically using bash scripts etc.

DISCLAIMER

This issue may sound exceptionally critical. In fact, it's not. This issue has NO impact on the security of the network, nor does it allow you to print DigiBytes.

Infinite Supply Curve

In fact, people were already noticing that something is a little off regarding DigiByte's Supply Curve, as can be seen in this PR: #9
However, things are a bit different as they initially seemed.

The supply curve in its current version happens to be INFINITE.
DigiByte's maximum ever circulating supply is ∞ due to a little bug in the implementation.
The max total supply was supposed to be 21 Billion DigiBytes in the year 2035, however, in the following I am going to show what it really is like:

Supply Curve Simulation

The following plot illustrates the supply chain starting in the Genesis Block up to BlockHeight 110,579,600:

There are multiple jumps in the logarithmical graph due to many hardforks that DigiByte had, which basically means there are multiple ranges to consider if we want to calculate the maximum total supply. Let me elaborate on this for a second:

1. In the first 1440 blocks each block emits 72000 DGB

   digibyte/src/validation.cpp

   Line 1226 in 3832a2d

   nSubsidy = 72000 * COIN;

2. The next 4320 blocks (up to block height 5760) each emit 16000 DGB

   digibyte/src/validation.cpp

   Line 1230 in 3832a2d

   nSubsidy = 16000 * COIN;

3. Until DigiByte reaches block height 67,200 a constant amount of 8000 DGB is emitted per block

   digibyte/src/validation.cpp

   Line 1222 in 3832a2d

   nSubsidy = 8000 * COIN;

4. From block height 67,200 to block height 400,000 the subsidy is decreased by 0.5% for every 10080th block.

   digibyte/src/validation.cpp

   Lines 1179 to 1185 in 3832a2d

   	{
   	qSubsidy = 8000*COIN;
   	int blocks = nHeight - consensusParams.nDiffChangeTarget;
   	int weeks = (blocks / consensusParams.patchBlockRewardDuration)+1;
   	//decrease reward by 0.5% every 10080 blocks
   	for(int i = 0; i < weeks; i++) qSubsidy -= (qSubsidy/200);
   	}

5. From block height 400,000 to block height 1,430,000 the consensus was altered in a way that the decay factor was set to 0.99 (-1%) for every 80160 blocks

   digibyte/src/validation.cpp

   Lines 1187 to 1193 in 3832a2d

   	{
   	qSubsidy = 2459*COIN;
   	int blocks = nHeight - consensusParams.alwaysUpdateDiffChangeTarget;
   	int weeks = (blocks / consensusParams.patchBlockRewardDuration2)+1;
   	//decrease reward by 1% every month
   	for(int i = 0; i < weeks; i++) qSubsidy -= (qSubsidy/100);
   	}

6. From that point on, another hardfork changed the decay factor to 0.98884 (-1.116%) per month.

   digibyte/src/validation.cpp

   Lines 1201 to 1210 in 3832a2d

   	qSubsidy = 2157*COIN/2;
   	int64_t blocks = nHeight - consensusParams.workComputationChangeTarget;
   	int64_t months = blocks*15/(3600*24*365/12);
   	for(int64_t i = 0; i < months; i++)
   	{
   	qSubsidy*=98884;
   	qSubsidy/=100000;
   	}
   	}

So far so good. With this configuration it will take almost infinite time to reach rock-bottom (an emission of 0 per block).

Why is the supply infinite?

Take a look at this line:

To put in a nutshell, empirical tests have shown that we reach this limit at block height 110579600, which is a total supply of 22,391,673,982 DGB (not taking the genesis block into account).
From there on, every block will emit exactly 1 DGB.

Non-Logarithmic plot of supply chain

Here is another plot (y-Axis cut off a bit) that shows how the supply chain looks:

How to proceed?

We should update the consensus (supply curve parameters) so that we reach a total of 21 billion DGB in year 2035. I am going to propose a valid solution soon.

Hi, I'm trying to compile the source code and I got these errors:

(base) ➜  digibyte git:(master) git remote -v
origin  https://github.com/DigiByte-Core/digibyte (fetch)
origin  https://github.com/DigiByte-Core/digibyte (push)
(base) ➜  digibyte git:(master) make         
Making all in src
make[1]: Entering directory '/home/vzool/Workspace/digibyte/src'
make[2]: Entering directory '/home/vzool/Workspace/digibyte/src'
make[3]: Entering directory '/home/vzool/Workspace/digibyte'
make[3]: Leaving directory '/home/vzool/Workspace/digibyte'
  CXX      qt/libdigibyteqt_a-trafficgraphwidget.o
qt/trafficgraphwidget.cpp: In member function ‘void TrafficGraphWidget::paintPath(QPainterPath&, QQueue<float>&)’:
qt/trafficgraphwidget.cpp:56:9: error: invalid use of incomplete type ‘class QPainterPath’
   56 |         path.moveTo(x, YMARGIN + h);
      |         ^~~~
In file included from /usr/include/qt/QtGui/qbrush.h:49,
                 from /usr/include/qt/QtGui/qpalette.h:46,
                 from /usr/include/qt/QtWidgets/qwidget.h:48,
                 from /usr/include/qt/QtWidgets/QWidget:1,
                 from ./qt/trafficgraphwidget.h:8,
                 from qt/trafficgraphwidget.cpp:7:
/usr/include/qt/QtGui/qmatrix.h:54:7: note: forward declaration of ‘class QPainterPath’
   54 | class QPainterPath;
      |       ^~~~~~~~~~~~
qt/trafficgraphwidget.cpp:60:13: error: invalid use of incomplete type ‘class QPainterPath’
   60 |             path.lineTo(x, y);
      |             ^~~~
In file included from /usr/include/qt/QtGui/qbrush.h:49,
                 from /usr/include/qt/QtGui/qpalette.h:46,
                 from /usr/include/qt/QtWidgets/qwidget.h:48,
                 from /usr/include/qt/QtWidgets/QWidget:1,
                 from ./qt/trafficgraphwidget.h:8,
                 from qt/trafficgraphwidget.cpp:7:
/usr/include/qt/QtGui/qmatrix.h:54:7: note: forward declaration of ‘class QPainterPath’
   54 | class QPainterPath;
      |       ^~~~~~~~~~~~
qt/trafficgraphwidget.cpp:62:9: error: invalid use of incomplete type ‘class QPainterPath’
   62 |         path.lineTo(x, YMARGIN + h);
      |         ^~~~
In file included from /usr/include/qt/QtGui/qbrush.h:49,
                 from /usr/include/qt/QtGui/qpalette.h:46,
                 from /usr/include/qt/QtWidgets/qwidget.h:48,
                 from /usr/include/qt/QtWidgets/QWidget:1,
                 from ./qt/trafficgraphwidget.h:8,
                 from qt/trafficgraphwidget.cpp:7:
/usr/include/qt/QtGui/qmatrix.h:54:7: note: forward declaration of ‘class QPainterPath’
   54 | class QPainterPath;
      |       ^~~~~~~~~~~~
qt/trafficgraphwidget.cpp: In member function ‘virtual void TrafficGraphWidget::paintEvent(QPaintEvent*)’:
qt/trafficgraphwidget.cpp:109:22: error: aggregate ‘QPainterPath p’ has incomplete type and cannot be defined
  109 |         QPainterPath p;
      |                      ^
qt/trafficgraphwidget.cpp:116:22: error: aggregate ‘QPainterPath p’ has incomplete type and cannot be defined
  116 |         QPainterPath p;
      |                      ^
make[2]: *** [Makefile:8309: qt/libdigibyteqt_a-trafficgraphwidget.o] Error 1
make[2]: Leaving directory '/home/vzool/Workspace/digibyte/src'
make[1]: *** [Makefile:11220: all-recursive] Error 1
make[1]: Leaving directory '/home/vzool/Workspace/digibyte/src'
make: *** [Makefile:773: all-recursive] Error 1
(base) ➜  digibyte git:(master) 

Compile Commands

./autogen.sh
./configure --with-incompatible-bdb
make

OS/CPU

(base) ➜  digibyte git:(master) uname -a
Linux abdelaziz-laptop 5.4.64-1-MANJARO #1 SMP PREEMPT Wed Sep 9 18:26:19 UTC 2020 x86_64 GNU/Linux
(base) ➜  digibyte git:(master) lscpu 
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   39 bits physical, 48 bits virtual
CPU(s):                          12
On-line CPU(s) list:             0-11
Thread(s) per core:              2
Core(s) per socket:              6
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           158
Model name:                      Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
Stepping:                        10
CPU MHz:                         900.059
CPU max MHz:                     4500.0000
CPU min MHz:                     800.0000
BogoMIPS:                        5202.65
Virtualization:                  VT-x
L1d cache:                       192 KiB
L1i cache:                       192 KiB
L2 cache:                        1.5 MiB
L3 cache:                        12 MiB
NUMA node0 CPU(s):               0-11
Vulnerability Itlb multihit:     KVM: Mitigation: Split huge pages
Vulnerability L1tf:              Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
Vulnerability Mds:               Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Meltdown:          Mitigation; PTI
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP conditional, RSB filling
Vulnerability Srbds:             Mitigation; Microcode
Vulnerability Tsx async abort:   Not affected
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constan
                                 t_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtp
                                 r pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd
                                  ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt x
                                 saveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d
(base) ➜  digibyte git:(master) 

make check errors

1). amount_tests.cpp(88)
CFeeRate(MAX_MONEY, std::numeric_limits<uint32_t>::max()).GetFeePerK();

2). test/mempool_tests.cpp(476)
error: in "mempool_tests/MempoolSizeLimitTest": check pool.GetMinFee(1).GetFeePerK() == maxFeeRateRemoved.GetFeePerK() + 1000 has failed [208412000000 != 198413000]

3). test/mempool_tests.cpp(553)
error: in "mempool_tests/MempoolSizeLimitTest": check pool.GetMinFee(1).GetFeePerK() == maxFeeRateRemoved.GetFeePerK() + 1000 has failed [208412000000 != 198413000]

4). test/mempool_tests.cpp(557)
error: in "mempool_tests/MempoolSizeLimitTest": check pool.GetMinFee(1).GetFeePerK() == llround((maxFeeRateRemoved.GetFeePerK() + 1000)/2.0) has failed [104206000000 != 99206500]

5). test/mempool_tests.cpp(561)
error: in "mempool_tests/MempoolSizeLimitTest": check pool.GetMinFee(pool.DynamicMemoryUsage() * 5 / 2).GetFeePerK() == llround((maxFeeRateRemoved.GetFeePerK() + 1000)/4.0) has failed [52103000000 != 49603250]

6). test/mempool_tests.cpp(565)
error: in "mempool_tests/MempoolSizeLimitTest": check pool.GetMinFee(pool.DynamicMemoryUsage() * 9 / 2).GetFeePerK() == llround((maxFeeRateRemoved.GetFeePerK() + 1000)/8.0) has failed [26051500000 != 24801625]

7). test/mempool_tests.cpp(569)
error: in "mempool_tests/MempoolSizeLimitTest": check pool.GetMinFee(1).GetFeePerK() == 1000 has failed [0 != 1000]

8). test/miner_tests.cpp(203)
fatal error: in "miner_tests/CreateNewBlock_validity": critical check pblocktemplate->block.vtx.size() == 9U has failed [6 != 9]

9). test/policy_fee_tests.cpp(23)
error: in "policy_fee_tests/FeeRounder": check *results.begin() == 974 has failed [0 != 974]

10). test/policy_fee_tests.cpp(24)
error: in "policy_fee_tests/FeeRounder": check *++results.begin() == 1071 has failed [500000 != 1071]

11). test/policy_fee_tests.cpp(31)
error: in "policy_fee_tests/FeeRounder": check fee_rounder.round(MAX_MONEY) == 9170997 has failed [9170997512 != 9170997]

12). test/policyestimator_tests.cpp(86)
error: in "policyestimator_tests/BlockPolicyEstimates": check feeEst.estimateFee(2).GetFeePerK() < 9*baseRate.GetFeePerK() + deltaFee has failed

4X
13). test/policyestimator_tests.cpp(105)
error: in "policyestimator_tests/BlockPolicyEstimates": check origFeeEst[i-1] < mult*baseRate.GetFeePerK() + deltaFee has failed

14). test/transaction_tests.cpp(774)
error: in "transaction_tests/test_IsStandard": check nDustThreshold == 546 has failed [5460000 != 546]

15). test/transaction_tests.cpp(778)
error: in "transaction_tests/test_IsStandard": check !IsStandardTx(CTransaction(t), reason) has failed

16). test/transaction_tests.cpp(779)
error: in "transaction_tests/test_IsStandard": check reason == "dust" has failed [ != dust]

17). wallet/test/wallet_tests.cpp(551)
error: in "wallet_tests/ListCoins": check list.begin()->second.size() == COINBASE_MATURITY_2 - COINBASE_MATURITY + 1 has failed [1 != 93]

18). wallet/test/wallet_tests.cpp(558)
error: in "wallet_tests/ListCoins": check expectedAmount == wallet->GetAvailableBalance() has failed [669600000000000 != 7200000000000]

19). wallet/test/wallet_tests.cpp(571)
error: in "wallet_tests/ListCoins": check list.begin()->second.size() == COINBASE_MATURITY_2 - COINBASE_MATURITY + 2 has failed [2 != 94]2024-02-26T00:29:35.362750Z (mocktime: 2020-08-31T18:54:12Z) [scheduler] [validationinterface.cpp:200] [operator()] UpdatedBlockTip: new block hash=435e2436edead73c3c7e6733dbf27345970a9693bcdb94424fe570ae03948ae2 fork block hash=50d0507ef8fe28a4b6e3ba6aeb1ae2362b3295da895f58b551f28ab1f0364e41 (in IBD=false)

20). wallet/test/wallet_tests.cpp(578)
error: in "wallet_tests/ListCoins": check available.size() == COINBASE_MATURITY_2 - COINBASE_MATURITY + 2 has failed [2 != 94]

21). wallet/test/wallet_tests.cpp(600)
error: in "wallet_tests/ListCoins": check list.begin()->second.size() == COINBASE_MATURITY_2 - COINBASE_MATURITY + 2 has failed [2 != 94]

22). bench/block_assemble.cpp(42)
void AssembleBlock(ankerl::nanobench::Bench&): Assertion res.m_result_type == MempoolAcceptResult::ResultType::VALID failed.

Updates

RC1 / RC2 Make check same first error ( amount_tests.cpp ) as RC3.

Attempting to compile the latest develop branch or 7.17.3 natively after setting up the latest macOS Big Sur V 11.4 & Xcode 12.5.1 dev environment throws the following error.

OBJCXX qt/digibyte_qt-macdockiconhandler.o
qt/macdockiconhandler.mm:31:18: error: no matching function for call to 'objc_msgSend'
id appInst = objc_msgSend((id)cls, sel_registerName("sharedApplication"));
^~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/objc/message.h:63:1: note: candidate function not viable: requires 0 arguments, but 2 were provided
objc_msgSend(void /* id self, SEL op, ... / )
^
qt/macdockiconhandler.mm:34:23: error: no matching function for call to 'objc_msgSend'
id delegate = objc_msgSend(appInst, sel_registerName("delegate"));
^~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/objc/message.h:63:1: note: candidate function not viable: requires 0 arguments, but 2 were provided
objc_msgSend(void / id self, SEL op, ... / )
^
qt/macdockiconhandler.mm:35:33: error: no matching function for call to 'objc_msgSend'
Class delClass = (Class)objc_msgSend(delegate, sel_registerName("class"));
^~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/objc/message.h:63:1: note: candidate function not viable: requires 0 arguments, but 2 were provided
objc_msgSend(void / id self, SEL op, ... */ )
^
3 errors generated.

This issue appears to have been similar to issues fixed in Bitcoin, Dogecoin, Dash, and others.

Bitcoin Issue
Bitcoin Fix

DogeCoin Fix

I am currently working on and testing a PR that fixes this issue by replacing objc_msgSend() function calls with the native Objective-C syntax and is compatible with the latest versions of QT used in native macOS builds.

Also, our documentation for building on OS X need to be updated as well. Have needed to do several different things than what is currently written.

Hello, how is everything?

I'm studying digibyte and wanted to fork, how can I create a genesis block, I tried everything already in GenesisH0, what would be the pubkey of the genesis block of digibyte?

There is a lot here, but I just wanted to get this put out so others can take a look. These are notes I made from COINBASE_MATURITY related things that I found, and think need to be looked at and probably fixed, in the tests. In some places, I was not sure what the code was doing, so I mention that, but I think that code needs to be reviewed.

Three different variables are used throughout the tests:
- COINBASE_MATURITY = 8 from test_framework/blocktools.py
- COINBASE_MATURITY_ORIGINAL = 100 from test_framework/blocktools.py
- COINBASE_MATURITY_2 = 100 from consensus/consensus.h

Files to be reviewd:

test/functional/test_framework/blocktools.py
- COINBASE_MATURITY and COINBASE_MATURITY_ORIGINAL below are used in a lot of the tests. These are their values.
- Line 62: COINBASE_MATURITY = 8
- Line 63: COINBASE_MATURITY_ORIGINAL = 100

test/functional/feature_assumevalid.py
- At about line 35, should it import COINBASE_MATURITY_ORIGINAL rather than setting it at line 56?
- The use of COINBASE_MATURITY_ORIGINAL in the rest of the file makes sense.

test/functional/feature_backwards_compatibility.py
- Line 24 imports COINBASE_MATURITY (value of 8), probably should import COINBASE_MATURITY_ORIGINAL (100)?
- Line 67, blocks are generated, but not enough to have 100 confirmations
- Line 91, tried to send 10 DGB, but coinbase maturity of 100 was never reached, so it is not spendable

test/functional/feature_coinstatsindex.py
- Appears to correctly use COINBASE_MATURITY_ORIGINAL on lines 16 and 72

test/functional/feature_loadblock.py
- Appears to correctly use COINBASE_MATURITY_ORIGINAL on lines 19 and 32

test/functional/feature_nulldummy.py
- This uses COINBASE_MATURITY from test_framework.blocktools
- COINBASE_MATURITY in test_framework.blocktools is set to 8
- The comment on line 9 says the coinbases should be mature. Because of this, should it not use COINBASE_MATURITY_ORIGINAL?
- COINBASE_MATURITY would then need to be changed to COINBASE_MATURITY_ORIGINAL on lines 9, 18, 53, 79, 81, 84, 98, and 115

test/functional/feature_rbf.py
- Lines 10 and 56 should use COINBASE_MATURITY_ORIGINAL so all txs spend confirmed coins

test/functional/feature_taproot.py
- I'm not clear on it lines 9 and 1465 should be using COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY

test/functional/interface_digibyte_cli.py
- On line 22, block reward stated as being 72000. Is that correct? 72000 is used on line 26.
- Should lines 11, 23, 24, 25, and 26 be COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY?
- Shouldn't the comment on line 23 state "after mining 100+1 blocks"?

test/functional/mempool_compatibility.py
- Should lines 15 and 45 use COINBASE_MATURITY_ORIGINAL?

test/functional/mempool_expiry.py
- Lines 15 and 40 should use COINBASE_MATURITY_ORIGINAL so all txs can spend confirmed coins

test/functional/mempool_limit.py
- Line 9 imports COINBASE_MATURITY. Shouldn't it import COINBASE_MATURITY_ORIGINAL?
- Shouldn't line 61 use COINBASE_MATURITY_ORIGINAL so it uses a value of 100?

test/functional/mempool_package_onemore.py
- Lines 13 and 34 need to use COINBASE_MATURITY_ORIGINAL so they will mature

test/functional/mempool_packages.py
- Appears to correctly use COINBASE_MATURITY_ORIGINAL on lines 10 and 50

test/functional/mempool_reorg.py
- Should lines 14 and 106 be COINBASE_MATURITY or COINBASE_MATURITY_ORIGINAL
- Why does line 35/36 say block 76 is the first spendable coinbase tx?

test/functional/mempool_resurrect.py
- Lines 7 and 24 should use COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY since it spends coins on line 93.

test/functional/mempool_spend_coinbase.py
- Lines 17, 33, 36, and 38 should use COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY. The math on lines 36 and 38 should take 198-100+1 and 198-100+2, but COINBASE_MATURITY = 8, not 100.

test/functional/mining_getblocktemplate_longpoll.py
- Lines 11 and 66 should use COINBASE_MATURITY_ORIGINAL so all txs spend confirmed coins
- Some blocks have previously been generated, so on line 66, a "+1" do not need to be added to COINBASE_MATURITY_ORIGINAL

test/functional/p2p_blocksonly.py
- Line 9 imports COINBASE_MATURITY (value of 8)
- Comment on line 25 says "Add enough mature utxos to the wallet, so that all txs spend confirmed coins"
- Line 27 only generates 8, but aren't 100 needed?

test/functional/p2p_compactblocks.py
- Not sure if coins need to be matured or not.
- If they need to be matured, should lines 13, 168, 279, and 297 use COINBASE_MATURITY_ORIGINAL?

test/functional/p2p_dandelion.py
- Lines 31 and 87 should use COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY since it spends coins on line 102.

test/functional/p2p_eviction.py
- Line 19, import COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY?
- Line 56, use COINBASE_MATURITY_ORIGINAL?

test/functional/p2p_feefilter.py
- Line 9 imports COINBASE_MATURITY (value of 8)
- Comment on line 83 says "Add enough mature utxos to the wallet, so that all txs spend confirmed coins"
- Line 85 only generates 8, but aren't 100 needed?

test/functional/p2p_leak_tx.py
- Line 7 imports COINBASE_MATURITY. Shouldn't it import COINBASE_MATURITY_ORIGINAL?
- Shouldn't line 31 use COINBASE_MATURITY_ORIGINAL so it uses a value of 100?

test/functional/rpc_createmultisig.py
- Line 131, shouldn't this be COINBASE_MATURITY_ORIGINAL?

test/functional/rpc_dumptxoutset.py
- Appears to correctly be using COINBASE_MATURITY_ORIGINAL on lines 10 and 29.

test/functional/rpc_getblockstats.py
- Appears to correctly use COINBASE_MATURITY_ORIGINAL on lines 13 and 54

test/functional/rpc_net.py
- Lines 15 and 58 should use COINBASE_MATURITY_ORIGINAL so all txs spend confirmed coins

test/functional/rpc_rawtransaction.py
- Need mature coins to spend on line 80, so use COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY on lines 18 and 78

test/functional/rpc_signrawtransaction.py
- Should lines 8, 184, and 203 use COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY so there is a matured coinbase tx?

test/functional/rpc_txoutproof.py
- Lines 7, 33, and 36 should use COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY so txs can spend confirmed coins

test/functional/wallet_abandonconflict.py
- Lines 15 and 32 should use COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY since it spends coins on line 34.

test/functional/wallet_address_types.py
- Import on line 56 could be deleted. The rest of the code uses COINBASE_MATURITY_ORIGINAL

test/functional/wallet_backup.py
- Comment on line 157 says to "Generate 101 more blocks"
- Lines 39, 129, and 158 should use COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY
- Part of the comments on lines 168 and 169 are incorrect. Shouldn't there be 114 mature blocks?

test/functional/wallet_balance.py
- On line 103, it looks like it is sending coins. If that is the case, shouldn't lines 11, 76, and 160 use COINBASE_MATURITY_ORIGINAL?

test/functional/wallet_basic.py
- The comment on line 58 says "DigiByte specific: COINBASE_MATURITY is set to 8 instead of 100 (in BTC)."
- In this test, does a coinbase tx really mature after only 8 blocks? See comment on line 188.
- Should lines 11, 98, and 189 be COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY?

test/functional/wallet_bumpfee.py
- Line 20 imports COINBASE_MATURITY (value of 8)
- Line 78: should it use COINBASE_MATURITY_2 so there are 10 confirmed blocks? Maybe I am not understanding what this is doing.

test/functional/wallet_coinbase_category.py
- Lines 10 and 45 needs to use COINBASE_MATURITY_ORIGINAL
- Comments on lines 44 and 46 need to be updated to reflect correct number of blocks for maturity

test/functional/wallet_descriptor.py
- Lines 8 and 88 should use COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY since it spends coins on line 93.

test/functional/wallet_fallbackfee.py
- Lines 7 and 20 should use COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY since it spends coins on line 23.

test/functional/wallet_groups.py
- Lines 7 and 37 should use COINBASE_MATURITY_ORIGINAL so all txs spend confirmed coins

test/functional/wallet_hd.py
- Lines 10 and 52 should use COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY since it spends coins on line 65.

test/functional/wallet_importdescriptors.py
- Line 19 imports COINBASE_MATURITY (value of 8)
- Not sure if this needs a mature utxo or not, but it is only creating 9 blocks

test/functional/wallet_importmulti.py
- Lines 258, 278, 298, 323
○ Should they use COINBASE_MATURITY_ORIGINAL?
○ Should they actually use "COINBASE_MATURITY_ORIGINAL + 1" since the next line tries to spend 10?

test/functional/wallet_importprunedfunds.py
- Lines 8, 28, and 48 should use COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY since it spends coins on line 64.

test/functional/wallet_keypool_topup.py
- If there needs to be a mature block, shouldn't it use COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY on lines 16 and 35?

test/functional/wallet_labels.py
- Don't know if this needs 8+1 blocks or 100+1 blocks when it generates blocks.

test/functional/wallet_listsinceblock.py
- Line 45 needs mature coins to spend, so use COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY on lines 8 and 33

test/functional/wallet_multiwallet.py
- Not sure what this is doing. Does it need confirmed blocks? If so, lines 17 and 233 should use COINBASE_MATURITY_ORIGINAL

test/functional/wallet_orphanedreward.py
- Having a little difficulty following this, but is the purpose of line 22 to generate a bunch of blocks so that some are spendable? If so, shouldn't it use COINBASE_MATURITY_ORIGINAL so it generates 150 blocks instead of just 58 blocks?
- Same thing for lines 33 and 40

test/functional/wallet_taproot.py
- Line 9 imports COINBASE_MATURITY (value of 8)
- Don't understand exactly what's happening here, so not sure if 8+1 or 100+1 blocks are needed

test/functional/wallet_txn_clone.py
- Comments on lines 54, 109, and 151 refer to COINBASE_MATURITY being 8 for DigiByte. Should it be referring to COINBASE_MATURITY_ORIGINAL (100)?

test/functional/wallet_txn_doublespend.py
- Not sure what is happening here, but two comments reference "In DigiByte, since COINBASE_MATURITY is only set to 8", so is something in here expecting coins to be matured after 8 blocks?

test/functional/wallet_upgradewallet.py
- Not sure if this needs confirmed coins or not, but if it does, lines 19, 122, 125, 133 need to use COINBASE_MATURITY_ORIGINAL

test/functional/wallet_watchonly.py
- Line 8, import COINBASE_MATURITY_ORIGINAL instead of COINBASE_MATURITY?
- Line 40, use COINBASE_MATURITY_ORIGINAL

src/test/fuzz/process_message.cpp
- I am not clear on if this should be using COINBASE_MATURITY or COINBASE_MATURITY_2 on line 61

src/test/fuzz/process_messages.cpp
- Already uses COINBASE_MATURITY_2

src/test/fuzz/tx_pool.cpp
- Lines 37 and 40 appear to be correctly using COINBASE_MATURITY_2
- Not exactly sure what line 132 is calculating. Should it use COINBASE_MATURITY_2 instead of COINBASE_MATURITY? What is the value 50?

src/test/fuzz/utxo_snapshot.cpp
- Already uses COINBASE_MATURITY_2

src/test/util/setup_common.cpp
- This correctly uses COINBASE_MATURITY_2 from consensus/consensus.h

src/test/validation_block_tests.cpp
- Already using COINBASE_MATURITY_2

src/wallet/test/wallet_tests.cpp
- I'm not exactly sure what this is doing.
- This uses both COINBASE_MATURITY and COINBASE_MATURITY_2, so the code might be good

Running digibyte in regtest mode (digibyted -regtest) on two nodes connected to each other, I mined the first 150 blocks with digibyte-cli -regtest generatetoaddress, everything goes fine, the multi-algos are active as well as the softforks:

{
  "chain": "regtest",
  "blocks": 159,
  "headers": 159,
  "bestblockhash": "32e2dfdb9c068e4a93afd92999fcd772f9c12b441cf69319f1221bb5745e190e",
  "mediantime": 1622079644,
  "verificationprogress": 1,
  "initialblockdownload": false,
  "chainwork": "00000000000000000000000000000000000000000000000000000000e7db92f1",
  "size_on_disk": 48177,
  "pruned": false,
  "difficulties": {
    "sha256d": 4.656542373906925e-10,
    "scrypt": 4.583655290791708e-05,
    "groestl": 4.656542373906925e-10,
    "skein": 4.656542373906925e-10,
    "qubit": 4.656542373906925e-10
  },
  "softforks": [
  ],
  "bip9_softforks": {
    "csv": {
      "status": "defined",
      "startTime": 0,
      "timeout": 9223372036854775807,
      "since": 0
    },
    "segwit": {
      "status": "active",
      "startTime": -1,
      "timeout": 9223372036854775807,
      "since": 0
    },
    "nversionbips": {
      "status": "defined",
      "startTime": 9,
      "timeout": 7308892999128540205,
      "since": 0
    },
    "reservealgo": {
      "status": "active",
      "startTime": -1,
      "timeout": 9223372036854775807,
      "since": 0
    },
    "odo": {
      "status": "active",
      "startTime": -1,
      "timeout": 94171832018720,
      "since": 0
    }
  },
  "warnings": ""
}

However, when I try to solo mine locally with cpuminer (https://github.com/tpruvot/cpuminer-multi), only the scrypt algo works, while the other four (sha256d, groestl, skein, qubit) don't work at all. Their PoW are rejected by the daemon with the following error:
ERROR: ProcessNewBlock: AcceptBlock FAILED (high-hash, proof of work failed (code 16))

Am I missing something? Is there a special cpuminer version that works with Digibyte?

If you sign a message using a bech32 address the resulting signature does not have the segwit flag set so it fails tests using message signature libraries.

As documented by James from CoinMinerz on 26th October on the DigiByte Discord:

"Another thing we need to address is tx fee bug to make sure anyone using RC2 or RC3 on mainnet doesn't have the mempool issue we've seen on coinminerz when payments go out. What happens is the tx fee is too low in the code and when sent it sits in mempool as it's a cheaper tx fee."

https://discord.com/channels/878200503815782400/1117868419283423293/1166363365061431417

Looks like we got a bit ahead of ourselves by not fixing tests on every PR in the last few months. I had issues getting my Python dev environment set up after upgrading to the latest macOS a few weeks ago, so I just now was able to get around fixing it and getting functional tests to run for me. It would be great to have someone else get the same failure results. Most of these failures are likely to do Fees in the test environment, and a few other changes we recently made. Should not be hard, just time-consuming to fix them all. Definitely something we need to do. It could reveal a few more bugs to squash.

I know there are some fixes already being worked on with #172

To compile for tests:
./autogen.sh
./configure --enable-debug
make

After compiling locally you can run the following:
make check

Then run:
test/functional/test_runner.py

Note: it can take hours for these tests to run.

To speed it up run & adjust # of jobs... too high and you get more failures. I have an 8-core CPU and run 6 jobs at a time:
test/functional/test_runner.py --extended --jobs=6

feature_coinstatsindex.py                          | ✖ Failed  | 22 s
feature_config_args.py                             | ✖ Failed  | 16 s
feature_pruning.py                                 | ✖ Failed  | 799 s
feature_taproot.py                                 | ✖ Failed  | 21 s
interface_digibyte_cli.py                          | ✖ Failed  | 16 s
mempool_unbroadcast.py                             | ✖ Failed  | 28 s
mining_basic.py                                    | ✖ Failed  | 75 s
p2p_addr_relay.py                                  | ✖ Failed  | 6 s
p2p_compactblocks.py                               | ✖ Failed  | 5 s
rpc_blockchain.py                                  | ✖ Failed  | 39 s
rpc_createmultisig.py --descriptors                | ✖ Failed  | 62 s
rpc_createmultisig.py --legacy-wallet              | ✖ Failed  | 108 s
rpc_fundrawtransaction.py --descriptors            | ✖ Failed  | 2 s
rpc_fundrawtransaction.py --legacy-wallet          | ✖ Failed  | 9 s
rpc_psbt.py --descriptors                          | ✖ Failed  | 18 s
rpc_psbt.py --legacy-wallet                        | ✖ Failed  | 32 s
rpc_rawtransaction.py --descriptors                | ✖ Failed  | 21 s
rpc_rawtransaction.py --legacy-wallet              | ✖ Failed  | 26 s
rpc_signrawtransaction.py --descriptors            | ✖ Failed  | 11 s
rpc_signrawtransaction.py --legacy-wallet          | ✖ Failed  | 13 s
wallet_abandonconflict.py --descriptors            | ✖ Failed  | 29 s
wallet_abandonconflict.py --legacy-wallet          | ✖ Failed  | 38 s
wallet_avoidreuse.py --descriptors                 | ✖ Failed  | 39 s
wallet_avoidreuse.py --legacy-wallet               | ✖ Failed  | 40 s
wallet_backup.py --descriptors                     | ✖ Failed  | 19 s
wallet_backup.py --legacy-wallet                   | ✖ Failed  | 24 s
wallet_balance.py --descriptors                    | ✖ Failed  | 11 s
wallet_balance.py --legacy-wallet                  | ✖ Failed  | 13 s
wallet_basic.py --descriptors                      | ✖ Failed  | 6 s
wallet_basic.py --legacy-wallet                    | ✖ Failed  | 11 s
wallet_bumpfee.py --descriptors                    | ✖ Failed  | 13 s
wallet_bumpfee.py --legacy-wallet                  | ✖ Failed  | 15 s
wallet_coinbase_category.py --descriptors          | ✖ Failed  | 8 s
wallet_coinbase_category.py --legacy-wallet        | ✖ Failed  | 10 s
wallet_create_tx.py --descriptors                  | ✖ Failed  | 92 s
wallet_create_tx.py --legacy-wallet                | ✖ Failed  | 180 s
wallet_descriptor.py --descriptors                 | ✖ Failed  | 7 s
wallet_fallbackfee.py --descriptors                | ✖ Failed  | 5 s
wallet_fallbackfee.py --legacy-wallet              | ✖ Failed  | 6 s
wallet_groups.py --descriptors                     | ✖ Failed  | 14 s
wallet_groups.py --legacy-wallet                   | ✖ Failed  | 28 s
wallet_hd.py --descriptors                         | ✖ Failed  | 15 s
wallet_hd.py --legacy-wallet                       | ✖ Failed  | 17 s
wallet_importdescriptors.py --descriptors          | ✖ Failed  | 19 s
wallet_importmulti.py --legacy-wallet              | ✖ Failed  | 22 s
wallet_importprunedfunds.py --descriptors          | ✖ Failed  | 7 s
wallet_importprunedfunds.py --legacy-wallet        | ✖ Failed  | 10 s
wallet_keypool.py --descriptors                    | ✖ Failed  | 9 s
wallet_keypool.py --legacy-wallet                  | ✖ Failed  | 18 s
wallet_keypool_topup.py --descriptors              | ✖ Failed  | 24 s
wallet_keypool_topup.py --legacy-wallet            | ✖ Failed  | 75 s
wallet_labels.py --descriptors                     | ✖ Failed  | 2 s
wallet_labels.py --legacy-wallet                   | ✖ Failed  | 4 s
wallet_listsinceblock.py --descriptors             | ✖ Failed  | 12 s
wallet_listsinceblock.py --legacy-wallet           | ✖ Failed  | 24 s
wallet_multiwallet.py --descriptors                | ✖ Failed  | 55 s
wallet_multiwallet.py --legacy-wallet              | ✖ Failed  | 98 s
wallet_multiwallet.py --usecli                     | ✖ Failed  | 111 s
wallet_orphanedreward.py                           | ✖ Failed  | 11 s
wallet_send.py --descriptors                       | ✖ Failed  | 20 s
wallet_send.py --legacy-wallet                     | ✖ Failed  | 50 s
wallet_taproot.py                                  | ✖ Failed  | 13 s
wallet_txn_clone.py                                | ✖ Failed  | 19 s
wallet_txn_clone.py --mineblock                    | ✖ Failed  | 15 s
wallet_txn_clone.py --segwit                       | ✖ Failed  | 20 s
wallet_txn_doublespend.py --descriptors            | ✖ Failed  | 11 s
wallet_txn_doublespend.py --legacy-wallet          | ✖ Failed  | 15 s
wallet_txn_doublespend.py --mineblock              | ✖ Failed  | 19 s
wallet_watchonly.py --legacy-wallet                | ✖ Failed  | 21 s
wallet_watchonly.py --usecli --legacy-wallet       | ✖ Failed  | 22 s
ALL                                                | ✖ Failed  | 14782 s (accumulated) ```

Building Windows binaries on Ubuntu 20.04 gives the following error:

utiltime.cpp: In function ‘std::string FormatISO8601DateTime(int64_t)’:
utiltime.cpp:86:5: error: ‘gmtime_r’ was not declared in this scope; did you mean ‘gmtime_s’?
   86 |     gmtime_r(&time_val, &ts);
      |     ^~~~~~~~
      |     gmtime_s
utiltime.cpp: In function ‘std::string FormatISO8601Date(int64_t)’:
utiltime.cpp:97:5: error: ‘gmtime_r’ was not declared in this scope; did you mean ‘gmtime_s’?
   97 |     gmtime_r(&time_val, &ts);
      |     ^~~~~~~~
      |     gmtime_s
utiltime.cpp: In function ‘std::string FormatISO8601Time(int64_t)’:
utiltime.cpp:108:5: error: ‘gmtime_r’ was not declared in this scope; did you mean ‘gmtime_s’?
  108 |     gmtime_r(&time_val, &ts);
      |     ^~~~~~~~
      |     gmtime_s

compiler: gcc (Gentoo 11.1.0-r1 p2) 11.1.0
valgrind-3.17.0
running the develop branch (hash 02bfbf7)

Ran valgrind --track-origins=yes --read-var-info=yes ./test_digibyte

and it reported:

==14528==    at 0x4724A6: CBlockIndex::GetAncestor(int) const (chain.cpp:98)
==14528==    by 0x5B4322: CChainState::ConnectBlock(CBlock const&, CValidationState&, CBlockIndex*, CCoinsViewCache&, CChainParams const&, bool) (validation.cpp:2052)
...
==14528==  Uninitialised value was created by a heap allocation
==14528==    at 0x483FF5F: operator new(unsigned long) (vg_replace_malloc.c:417)
==14528==    by 0x60F313: CreateChainParams(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (chainparams.cpp:585)
==14528==    by 0x60F3A7: SelectParams(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (chainparams.cpp:592)

looking at the CRegTestParams::CRegTestParams() it looks like it never sets consensus.BIP34Height = 4394880;

Over the course of the past few weeks I have experienced a hard to track down bug where the v8.22.0 test client #63 randomly crashes. I have experienced this now on OS X & Ubuntu with multiple clients. After repeating the crash enough I have been able to track it down to what I believe is dandelion related issues when the client is asked to be part of a TX relay during the stem phase of a dandelion TX from a 7.17 client. The common error repeats itself 100s of time and looks like

2021-10-23T23:39:01Z received: inv (37 bytes) peer=33
2021-10-23T23:39:01Z got inv: dandeliontx ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff  new peer=33
2021-10-23T23:39:01Z sending getdata (36 bytes) peer=33
2021-10-23T23:39:01Z sending inv (37 bytes) peer=33
2021-10-23T23:39:01Z received: getdata (36 bytes) peer=33
2021-10-23T23:39:01Z ProcessMessages(getdata, 36 bytes): Exception 'CDataStream::read(): end of data: iostream error' (NSt8ios_base7failureB5cxx11E) caught
2021-10-23T23:39:01Z received: inv (37 bytes) peer=33
2021-10-23T23:39:01Z got inv: dandeliontx ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff  new peer=33
2021-10-23T23:39:01Z sending getdata (36 bytes) peer=33
2021-10-23T23:39:01Z sending inv (37 bytes) peer=33
2021-10-23T23:39:01Z received: getdata (36 bytes) peer=33
2021-10-23T23:39:01Z ProcessMessages(getdata, 36 bytes): Exception 'CDataStream::read(): end of data: iostream error' (NSt8ios_base7failureB5cxx11E) caught

Here is a paste bin with 5000 lines of same error from DigiHash server: https://pastebin.com/buhkFkxM

Basically I have watch clients crash a dozen times or more with this being the main error message:

2021-10-23T23:39:01Z received: getdata (36 bytes) peer=33
2021-10-23T23:39:01Z ProcessMessages(getdata, 36 bytes): Exception 'CDataStream::read(): end of data: iostream error' (NSt8ios_base7failureB5cxx11E) caught

Only way to make sure you actually see that error is to have debug=1 in your digibyte.conf or -debug=1 on command line startup for digibyted or digibyte-qt.

What didn't make sense was while running 4 instances of DigiByteD on that server, only 1 at a time would randomly crash, which makes sense considering only the client involved in the relay of a dandelion tx during stem phase would be affected.

To further track down the issue we attempted to add "disabledandelion=1" to the DigiByte.conf only to find that no longer worked and the code to actually disable dandelion was missing. Upon diving further in it became apparent that RelayWalletTransaction is now SubmitMemoryPoolAndRelay.

So in new 8.22 code we have: https://github.com/DigiByte-Core/digibyte/blob/feature/8.22.0/src/wallet/wallet.cpp#L1712

bool CWalletTx::SubmitMemoryPoolAndRelay(std::string& err_string, bool relay)
{
    // Can't relay if wallet is not broadcasting
    if (!pwallet->GetBroadcastTransactions()) return false;
    // Don't relay abandoned transactions
    if (isAbandoned()) return false;
    // Don't try to submit coinbase transactions. These would fail anyway but would
    // cause log spam.
    if (IsCoinBase()) return false;
    // Don't try to submit conflicted or confirmed transactions.
    if (GetDepthInMainChain() != 0) return false;

    // Submit transaction to mempool for relay
    pwallet->WalletLogPrintf("Submitting wtx %s to mempool for relay\n", GetHash().ToString());
    // We must set fInMempool here - while it will be re-set to true by the
    // entered-mempool callback, if we did not there would be a race where a
    // user could call sendmoney in a loop and hit spurious out of funds errors
    // because we think that this newly generated transaction's change is
    // unavailable as we're not yet aware that it is in the mempool.
    //
    // Irrespective of the failure reason, un-marking fInMempool
    // out-of-order is incorrect - it should be unmarked when
    // TransactionRemovedFromMempool fires.
    bool ret = pwallet->chain().broadcastTransaction(tx, pwallet->m_default_max_tx_fee, relay, err_string);
    fInMempool |= ret;
    return ret;
}

However 7.17.3 code reads: https://github.com/DigiByte-Core/digibyte/blob/develop/src/wallet/wallet.cpp#L1828

bool CWalletTx::RelayWalletTransaction(CConnman* connman)
{
    assert(pwallet->GetBroadcastTransactions());
    if (!IsCoinBase() && !isAbandoned() && GetDepthInMainChain() == 0)
    {
        LogPrintf("Inside IF Test \n");
        CValidationState state;
        /* GetDepthInMainChain already catches known conflicts. */
        LogPrintf("Transaction in memory pool: %u, Accepted To MemoryPool: %u", InMempool(), AcceptToMemoryPool(maxTxFee, state));
        if (InMempool() || AcceptToMemoryPool(maxTxFee, state)) {
            pwallet->WalletLogPrintf("Relaying wtx %s\n", GetHash().ToString());
            if (connman) {
                if (!gArgs.GetBoolArg("-disabledandelion", DEFAULT_DISABLE_DANDELION)) {
                    int64_t nCurrTime = GetTimeMicros();
                    int64_t nEmbargo = 1000000*DANDELION_EMBARGO_MINIMUM+PoissonNextSend(nCurrTime, DANDELION_EMBARGO_AVG_ADD);
                    connman->insertDandelionEmbargo(GetHash(),nEmbargo);
                    LogPrint(BCLog::DANDELION, "dandeliontx %s embargoed for %d seconds\n", GetHash().ToString(), (nEmbargo-nCurrTime)/1000000);
                    CInv inv(MSG_DANDELION_TX, GetHash());
                    return connman->localDandelionDestinationPushInventory(inv);
                } else {
                    CInv inv(MSG_TX, GetHash());
                    connman->ForEachNode([&inv](CNode* pnode)
                    {
                        pnode->PushInventory(inv);
                    });
                    return true;
                }
            }
        }
    }
    return false;
}

So it appears the BTC devs reworked the relay TX code which breaks our dandelion implementation in an attempt to enhance privacy as seen here: bitcoin/bitcoin#15734

And here: bitcoin/bitcoin#16698

The original Dandelion implementation, which can be seen here by original developers has not been reworked since their 2018 update. The entire dandelion implementation can be seen here: dandelion-org/bitcoin@d043e36

If we can re-enable "disabledandelion" this should prevent the random crash bug, however we need to fully fix the dandelion relay TX feature. All help with this is much appreciated. As stated above it has taken a couple weeks to get this far into understanding the problem, as it was not apparent at all in the beginning what was triggering random crashes.

This issue most likely will go a bit deeper, but it definitely seems to be an issue with relaying txs. I just had this error locally on my Mac client right before it crashed:

2021-10-24T16:11:53Z got inv: tx a938e42a4c436db4c0bdf0c8b6dafc05d274404451e2a12070031707eb558728  new peer=1
2021-10-24T16:11:53Z Requesting tx a938e42a4c436db4c0bdf0c8b6dafc05d274404451e2a12070031707eb558728 peer=1
2021-10-24T16:11:53Z sending getdata (37 bytes) peer=1
2021-10-24T16:11:53Z received: tx (223 bytes) peer=1
2021-10-24T16:11:53Z Enqueuing TransactionAddedToMempool: txid=a938e42a4c436db4c0bdf0c8b6dafc05d274404451e2a12070031707eb558728 wtxid=a938e42a4c436db4c0bdf0c8b6dafc05d274404451e2a12070031707eb558728
2021-10-24T16:11:53Z Blockpolicy error mempool tx a938e42a4c436db4c0bdf0c8b6dafc05d274404451e2a12070031707eb558728 already being tracked
2021-10-24T16:11:53Z Enqueuing TransactionAddedToMempool: txid=a938e42a4c436db4c0bdf0c8b6dafc05d274404451e2a12070031707eb558728 wtxid=a938e42a4c436db4c0bdf0c8b6dafc05d274404451e2a12070031707eb558728
2021-10-24T16:11:53Z AcceptToMemoryPool: peer=1: accepted a938e42a4c436db4c0bdf0c8b6dafc05d274404451e2a12070031707eb558728 (poolsz 1 txn, 1 kB)
2021-10-24T16:11:53Z TransactionAddedToMempool: txid=a938e42a4c436db4c0bdf0c8b6dafc05d274404451e2a12070031707eb558728 wtxid=a938e42a4c436db4c0bdf0c8b6dafc05d274404451e2a12070031707eb558728
2021-10-24T16:11:53Z TransactionAddedToMempool: txid=a938e42a4c436db4c0bdf0c8b6dafc05d274404451e2a12070031707eb558728 wtxid=a938e42a4c436db4c0bdf0c8b6dafc05d274404451e2a12070031707eb558728
2021-10-24T16:11:54Z sending inv (37 bytes) peer=14
2021-10-24T16:11:54Z sending inv (37 bytes) peer=4
2021-10-24T16:11:54Z received: inv (37 bytes) peer=8
2021-10-24T16:11:54Z got inv: tx a938e42a4c436db4c0bdf0c8b6dafc05d274404451e2a12070031707eb558728  have peer=8
2021-10-24T16:11:55Z sending inv (37 bytes) peer=13
2021-10-24T16:11:55Z received: ping (8 bytes) peer=1
2021-10-24T16:11:55Z sending pong (8 bytes) peer=1
2021-10-24T16:11:55Z sending inv (37 bytes) peer=5
2021-10-24T16:11:56Z received: inv (73 bytes) peer=10
2021-10-24T16:11:56Z got inv: tx a938e42a4c436db4c0bdf0c8b6dafc05d274404451e2a12070031707eb558728  have peer=10
2021-10-24T16:11:56Z got inv: tx ec35e6a0b9cf38e30ee1179b21b53b099856ce648ca1ff3eb3f24ebf9b67294f  new peer=10
2021-10-24T16:11:56Z Requesting tx ec35e6a0b9cf38e30ee1179b21b53b099856ce648ca1ff3eb3f24ebf9b67294f peer=10
2021-10-24T16:11:56Z sending getdata (37 bytes) peer=10
2021-10-24T16:11:56Z sending inv (37 bytes) peer=9
2021-10-24T16:11:56Z received: tx (259 bytes) peer=10
2021-10-24T16:11:56Z Enqueuing TransactionAddedToMempool: txid=ec35e6a0b9cf38e30ee1179b21b53b099856ce648ca1ff3eb3f24ebf9b67294f wtxid=ec35e6a0b9cf38e30ee1179b21b53b099856ce648ca1ff3eb3f24ebf9b67294f
2021-10-24T16:11:56Z Blockpolicy error mempool tx ec35e6a0b9cf38e30ee1179b21b53b099856ce648ca1ff3eb3f24ebf9b67294f already being tracked
2021-10-24T16:11:56Z Enqueuing TransactionAddedToMempool: txid=ec35e6a0b9cf38e30ee1179b21b53b099856ce648ca1ff3eb3f24ebf9b67294f wtxid=ec35e6a0b9cf38e30ee1179b21b53b099856ce648ca1ff3eb3f24ebf9b67294f
2021-10-24T16:11:56Z AcceptToMemoryPool: peer=10: accepted ec35e6a0b9cf38e30ee1179b21b53b099856ce648ca1ff3eb3f24ebf9b67294f (poolsz 2 txn, 2 kB)
2021-10-24T16:11:56Z TransactionAddedToMempool: txid=ec35e6a0b9cf38e30ee1179b21b53b099856ce648ca1ff3eb3f24ebf9b67294f wtxid=ec35e6a0b9cf38e30ee1179b21b53b099856ce648ca1ff3eb3f24ebf9b67294f
2021-10-24T16:11:56Z TransactionAddedToMempool: txid=ec35e6a0b9cf38e30ee1179b21b53b099856ce648ca1ff3eb3f24ebf9b67294f wtxid=ec35e6a0b9cf38e30ee1179b21b53b099856ce648ca1ff3eb3f24ebf9b67294f
2021-10-24T16:11:56Z received: inv (37 bytes) peer=8
2021-10-24T16:11:56Z got inv: tx ec35e6a0b9cf38e30ee1179b21b53b099856ce648ca1ff3eb3f24ebf9b67294f  have peer=8
2021-10-24T16:11:57Z sending inv (37 bytes) peer=13
2021-10-24T16:11:57Z sending inv (37 bytes) peer=14
2021-10-24T16:11:57Z received: inv (37 bytes) peer=9
2021-10-24T16:11:57Z got inv: tx ec35e6a0b9cf38e30ee1179b21b53b099856ce648ca1ff3eb3f24ebf9b67294f  have peer=9
2021-10-24T16:11:58Z sending inv (37 bytes) peer=4
2021-10-24T16:11:58Z received: getdata (37 bytes) peer=13
2021-10-24T16:11:58Z received getdata (1 invsz) peer=13
2021-10-24T16:11:58Z received getdata for: witness-tx 8b9f8731d0337676c1c9ed56177ca175bf0e4255f4e080f73eb5774b50d14e69 peer=13

Hi guys!

I am currently trying to activate a Testnet node. Looks like I need some peers to addnode. Can you please share a list of active ones since the list here (https://dgbwiki.com/wikifiles/DigiByteIntegration-v1.4.pdf) seems to be unreachable.

I also would be grateful for instructions on how to add nodes specifically for the Testnet.

Thank you in advance!

A mining pool provided this feedback regarding 8.22 RC2 testnet.

First observation about v8.22 ( testnet)

• Syncing headers is extremely slow
• Wallet cli also very slow ( While in header sync )
  ~ 2 minutes for a getblockchaininfo request through digibye-cli

Using Ubuntu 22.04
CPU: Intel xeon 24core / 48 threat
RAM: 256gb DDR4

So, the wallet has finally synced the testnet chain.
However, after a restart of the wallet to change some RPC settings.
It's now hanging in "Loading block index…" for about 2 hours already.

Now that nist is done we should modify Digi-Id and DigiByte to use CRYSTALS-Dilithium algo. Would be nice if part of 8.22

https://arstechnica.com/information-technology/2022/07/nist-selects-quantum-proof-algorithms-to-head-off-the-coming-cryptopocalypse/?amp=1

For a time at least Digi-Id needs to use both. A new address scheme is probably best for DigiByte so it can be soft forked in.

Algo Details:
https://csrc.nist.gov/CSRC/media/Presentations/Crystals-Dilithium/images-media/CRYSTALS-Dilithium-April2018.pdf

It appears we have a bug in the current 8.22.0 dev branch where the same tx is added to mempool twice & this causes ZMQ functional tests & possibly other tests to fail even though ZMQ is working correctly. ZMQ Issue we ran into here: #96

After much effort I think I have narrowed down why the interface_zmq.py keeps failing. First off it's important to know what ZMQ is exactly. ZMQ is effectively acting in Bitcoin & DigiByte core as a lightweight, read-only notification wrapper for RPC commands. This means no miner or exchange or any platform performing wallet operations is using ZMQ. Its really only being used instead of walletnotify and blocknotify rpc commands. It could be used for a block explorer, or other services simply listening to the network. I don't think it is widely used.

You can view ZMQ readme here: https://github.com/DigiByte-Core/digibyte/blob/feature/8.22.0/doc/zmq.md

ZMQ allows 5 notifications:

-zmqpubhashtx=address
-zmqpubhashblock=address
-zmqpubrawblock=address
-zmqpubrawtx=address
-zmqpubsequence=address

In order to even use ZMQ you need to do two things, add settings to your digibyte.conf & write a separate program to test ZMQ. There is no way to test from within DigiByte Core.

You need to add the following to your digibyte.conf to tell digibyted to publish the zmq notifications:

zmqpubrawblock=tcp://127.0.0.1:29000
zmqpubrawtx=tcp://127.0.0.1:29000
zmqpubhashtx=tcp://127.0.0.1:29000
zmqpubhashblock=tcp://127.0.0.1:29000

Once done you can run the following under digibyte-cli to make sure its working, if its blank you need to make sure settings are in .conf:

 ./digibyte-cli getzmqnotifications
[
  {
    "type": "pubhashblock",
    "address": "tcp://127.0.0.1:29000",
    "hwm": 1000
  },
  {
    "type": "pubhashtx",
    "address": "tcp://127.0.0.1:29000",
    "hwm": 1000
  },
  {
    "type": "pubrawblock",
    "address": "tcp://127.0.0.1:29000",
    "hwm": 1000
  },
  {
    "type": "pubrawtx",
    "address": "tcp://127.0.0.1:29000",
    "hwm": 1000
  }
]

Next you have to write a simple program to listen to zmq notifications. Here is a simple index.js program I wrote in javascript using node to test zmq. You just need to "npm install zeromq@5"

Learn more about ZeroMQ here: https://zeromq.org/languages/nodejs/

Sample program:

var zmq = require('zeromq')
  , sock = zmq.socket('sub')

sock.connect('tcp://127.0.0.1:29000');

sock.on('message', function(topic, message) {
    console.log(topic, message)
  })

sock.subscribe('hashtx')
sock.on('message', function(topic, message) {
  console.log(topic.toString(), message.toString('hex'))
})

This bitcoin zmq article was helpful but a bit out of date: https://bitcoindev.network/accessing-bitcoins-zeromq-interface/

After running index.js with the above code you will get an output with both binary form of TX & hex form of same TX:

<Buffer 68 61 73 68 74 78> <Buffer 4f 63 d2 9f ae 15 7f bd cf 78 06 fb ab 51 6a 4f 66 4e e6 8b 99 78 d0 69 3f 9f f8 34 5a 42 41 47>
hashtx 4f63d29fae157fbdcf7806fbab516a4f664ee68b9978d0693f9ff8345a424147
<Buffer 68 61 73 68 74 78> <Buffer 4f 63 d2 9f ae 15 7f bd cf 78 06 fb ab 51 6a 4f 66 4e e6 8b 99 78 d0 69 3f 9f f8 34 5a 42 41 47>
hashtx 4f63d29fae157fbdcf7806fbab516a4f664ee68b9978d0693f9ff8345a424147
<Buffer 68 61 73 68 74 78> <Buffer 9b 54 5b d9 33 e8 74 7d aa e3 c3 c5 c4 9c e6 a2 b9 b4 11 50 e1 86 ba 29 9f 86 7f 08 f7 95 95 1b>
hashtx 9b545bd933e8747daae3c3c5c49ce6a2b9b41150e186ba299f867f08f795951b
<Buffer 68 61 73 68 74 78> <Buffer 28 93 30 ce 36 8a 41 a9 0a 9e 6d 79 1a 40 bf db 46 25 98 0e b5 f0 c0 db a6 af 0c e8 3c 15 40 ab>
hashtx 289330ce368a41a90a9e6d791a40bfdb4625980eb5f0c0dba6af0ce83c1540ab
<Buffer 68 61 73 68 74 78> <Buffer 92 d4 29 f5 4b 3a a2 f4 80 88 28 30 fd c9 1a 5a 9e d7 c0 37 09 b2 f2 04 c4 7b 37 f9 38 5c a1 a9>
hashtx 92d429f54b3aa2f480882830fdc91a5a9ed7c03709b2f204c47b37f9385ca1a9
<Buffer 68 61 73 68 74 78> <Buffer 5d 39 f7 a9 56 e5 83 5b 86 59 5e 1a a9 c3 3f cc 25 56 0e 88 e2 68 79 25 ed 93 f6 67 f9 36 87 df>
hashtx 5d39f7a956e5835b86595e1aa9c33fcc25560e88e2687925ed93f667f93687df
<Buffer 68 61 73 68 74 78> <Buffer 5d 39 f7 a9 56 e5 83 5b 86 59 5e 1a a9 c3 3f cc 25 56 0e 88 e2 68 79 25 ed 93 f6 67 f9 36 87 df>
hashtx 5d39f7a956e5835b86595e1aa9c33fcc25560e88e2687925ed93f667f93687df
<Buffer 68 61 73 68 74 78> <Buffer 93 b8 2e ee 7f 9e cb 59 fc c5 96 fb 96 f8 99 11 70 70 56 2c ba 9a de b6 37 a9 f4 27 33 2b d7 8e>
hashtx 93b82eee7f9ecb59fcc596fb96f899117070562cba9adeb637a9f427332bd78e
<Buffer 68 61 73 68 74 78> <Buffer 93 b8 2e ee 7f 9e cb 59 fc c5 96 fb 96 f8 99 11 70 70 56 2c ba 9a de b6 37 a9 f4 27 33 2b d7 8e>
hashtx 93b82eee7f9ecb59fcc596fb96f899117070562cba9adeb637a9f427332bd78e

While looking through the digibyted logs & zmq notifications it became obvious the client was pushing the same notification twice for TXs being added to mempool twice. This kept causing sequence test failures in interface_zmq.py as well as failures where tx hashes don't match throwing assertion errors.

This double tx mempool addition behavior has been something we noticed when we started the upstream DGB 8.22 merge. We need to get to bottom of it as it could have other unintended consequences. However, once in the mempool the TX behaves normally as expected according to all other tests.

2022-08-09T19:47:56Z received: cmpctblock (204 bytes) peer=2
2022-08-09T19:48:03Z received: inv (37 bytes) peer=12
2022-08-09T19:48:03Z got inv: tx 6ff2038ea62f41d3ebdba5074ff6dcac781efbc84c01283f498bb5403e97eec9  new peer=12
2022-08-09T19:48:03Z Requesting tx 6ff2038ea62f41d3ebdba5074ff6dcac781efbc84c01283f498bb5403e97eec9 peer=12
2022-08-09T19:48:03Z sending getdata (37 bytes) peer=12
2022-08-09T19:48:03Z received: inv (37 bytes) peer=19
2022-08-09T19:48:03Z got inv: tx 6ff2038ea62f41d3ebdba5074ff6dcac781efbc84c01283f498bb5403e97eec9  new peer=19
2022-08-09T19:48:03Z received: tx (372 bytes) peer=12
2022-08-09T19:48:03Z Enqueuing TransactionAddedToMempool: txid=6ff2038ea62f41d3ebdba5074ff6dcac781efbc84c01283f498bb5403e97eec9 wtxid=6ff2038ea62f41d3ebdba5074ff6dcac781efbc84c01283f498bb5403e97eec9
2022-08-09T19:48:03Z TransactionAddedToMempool: txid=6ff2038ea62f41d3ebdba5074ff6dcac781efbc84c01283f498bb5403e97eec9 wtxid=6ff2038ea62f41d3ebdba5074ff6dcac781efbc84c01283f498bb5403e97eec9
2022-08-09T19:48:03Z zmq: Publish hashtx 6ff2038ea62f41d3ebdba5074ff6dcac781efbc84c01283f498bb5403e97eec9 to tcp://127.0.0.1:29000
2022-08-09T19:48:03Z Enqueuing TransactionAddedToMempool: txid=6ff2038ea62f41d3ebdba5074ff6dcac781efbc84c01283f498bb5403e97eec9 wtxid=6ff2038ea62f41d3ebdba5074ff6dcac781efbc84c01283f498bb5403e97eec9
2022-08-09T19:48:03Z zmq: Publish rawtx 6ff2038ea62f41d3ebdba5074ff6dcac781efbc84c01283f498bb5403e97eec9 to tcp://127.0.0.1:29000
2022-08-09T19:48:03Z AcceptToMemoryPool: peer=12: accepted 6ff2038ea62f41d3ebdba5074ff6dcac781efbc84c01283f498bb5403e97eec9 (poolsz 2 txn, 2 kB)
2022-08-09T19:48:03Z TransactionAddedToMempool: txid=6ff2038ea62f41d3ebdba5074ff6dcac781efbc84c01283f498bb5403e97eec9 wtxid=6ff2038ea62f41d3ebdba5074ff6dcac781efbc84c01283f498bb5403e97eec9
2022-08-09T19:48:03Z zmq: Publish hashtx 6ff2038ea62f41d3ebdba5074ff6dcac781efbc84c01283f498bb5403e97eec9 to tcp://127.0.0.1:29000
2022-08-09T19:48:03Z zmq: Publish rawtx 6ff2038ea62f41d3ebdba5074ff6dcac781efbc84c01283f498bb5403e97eec9 to tcp://127.0.0.1:29000
2022-08-09T19:48:04Z received: inv (37 bytes) peer=20

Catching this issue is the important benefit of going through all the work to get 210+ functional tests working properly. Slow and steady is the safe & secure way to make blockchain changes. We definitely would love to get more people helping us with this.

This issue is actually more critical for 7.17.3 though 8.22.x is also affected. In 7.17.3 without this seeder, there is currently only one working seeder for mainnet operated by @JaredTate - seed.digibyte.io. If Jared's goes offline we have no working seeders for 7.17.3. (Side note: there are currently NO working testnet seeders in 7.17.3. All the existing ones seem to have gone offline so new nodes have to be added to the network manualy.)

I have been asking around for several months to try and find out who owns the digibyte.org domain, and who maintains the seed.digibyte.org seeder. It was working a few months ago but now seems to be permanently offline. Can anyone help identify who maintains it? The source code says "Website Collective" which is not a lot to go on.

We have added a lot of new seeders in 8.22.x but it would be good to find out who manages this seeder, and if possible get it working. If we are unable to do either of these things, we can find someone else to run a seeder and remove it from the v8 codebase.

If v8 is still a long way off, I am of the opinion that we should urgently put together an interim 7.17.4 release that simply replaces the existing seeders with the new ones we have got setup for v8. This would ensure that new nodes can continue to join the network automatically.

Do you know who is operating the seed.digibyte.org seeder?

If this is you, can you get it up and running again?

Hi folks

Am I right in thinking sendmany is not yet supported (for sha256)? I get insufficient balance whether specifying a source address or not whilst sendtoaddress works fine? The only mention I can find to sendmany is a PR where it is unticked.

Thanks!
Simon

There are currently no Tor nodes in chainparamseeds.h:
https://github.com/DigiByte-Core/digibyte/blob/develop/src/chainparamsseeds.h

To better fortify DigiByte against attack we should add some static Tor nodes to this file.

The current DigiByte static nodes list is here: https://github.com/DigiByte-Core/digibyte/blob/develop/contrib/seeds/nodes_main.txt

For comparison, see the Bitcoin static nodes list here: https://github.com/bitcoin/bitcoin/blob/master/contrib/seeds/nodes_main.txt

More info here: https://github.com/DigiByte-Core/digibyte/tree/develop/contrib/seeds

Setup (solo cpu mining against each of these testnet nodes):
NodeA:

• running on Windows 10 22H2 19045.3930
• i7-6700K CPU
• 32 GB memory
• everyday computer used for other things
• solo mining against this node
• running 8.22.0-rc2 with PR-157 and PR-160

NodeB:

• running on Windows 10 1903 18362.1082
• i7-4770 CPU
• 16 GB memory
• dedicated to node and solo mining against this node
• running 8.22.0-rc2 with PR-157

NodeC:

• running on Ubuntu 22.04, i7-4770 CPU
• at least 8 GB memory
• dedicated to node and solo mining against this node
• running 8.22.0-rc2 with PR-157

NodeD:

• running in different folder on same computer as NodeA
• NOT solo mining against this node
• running 8.22.0-rc2 with PR-157 and PR-160

Solo mining against testnet core NodeA with a wallet (walletA) setup. This core node is configured for mining scrypt.
I have 2 other testnet nodes currently configured for mining sha256 and quibit. All coinbase transactions are directed to walletA.
This wallet (walletA) has several addresses for it to receive coinbase txs from solo mining scrypt, sha256, and qubit (some from odo and skein also).
With walletA, after some period of time (typically about once per day, with coinbase txs from 3 algos going to this wallet), the node will crash.
The following messages are visible in debug.log:

2024-01-23T19:01:14Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-23T19:01:14Z [default wallet] AddToWallet 4fbb983400c7e30593bc4acc6c5276d46db104b492e70658168b0f3012b9356f  new
2024-01-23T19:01:26Z UpdateTip: new best=6658d6b3626a4ff59b42f5918833d92f564c919d2818c76855b0586b7d97cbaa height=2541225 version=0x20000e02 algo=7 (odo) log2_work=50.940828 tx=2834251 date='2024-01-23T19:01:24Z' progress=1.000000 cache=1.1MiB(8307txo)
2024-01-23T19:01:26Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-23T19:01:26Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-23T19:02:06Z UpdateTip: new best=00000002153afe72e2dc261b131e88e96fb129b08e682c3601c28e1c4c937c63 height=2541226 version=0x20000202 algo=0 (sha256d) log2_work=50.940829 tx=2834252 date='2024-01-23T19:01:24Z' progress=1.000000 cache=1.1MiB(8308txo)
2024-01-23T19:02:06Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-23T19:02:06Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-23T19:02:06Z [default wallet] AddToWallet 2899af90a9c803dd91c17f1e4f004b83576e71428524e5bbec2548638a491fbb  new
2024-01-23T19:02:17Z UpdateTip: new best=bd6f5e44fbfd589c4097f932b9912d245c8fd2886f494805e04b858f9bcb305b height=2541227 version=0x20000002 algo=1 (scrypt) log2_work=50.94083 tx=2834253 date='2024-01-23T19:02:06Z' progress=1.000000 cache=1.1MiB(8309txo)
2024-01-23T19:02:17Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-23T19:02:17Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-23T19:02:17Z [default wallet] AddToWallet db29e48a4aa1532cac698ead09d9b645d518a08691f32ca615c344bc104e4d91  new
2024-01-23T19:02:17Z GUI: getDiBits: GetDIBits() failed to get bitmap bits. (The operation completed successfully.)
2024-01-23T19:02:17Z GUI: getDiBits: GetDIBits() failed to get bitmap bits. (The operation completed successfully.)
2024-01-23T19:02:17Z GUI: getDiBits: GetDIBits() failed to get bitmap bits. (The operation completed successfully.)
2024-01-23T19:03:09Z Potential stale tip detected, will try using extra outbound peer (last tip update: 52 seconds ago)
2024-01-23T19:03:14Z UpdateTip: new best=99ba65cda6a9cda2fed596a6fd5210e117525cafda0ec78d8ed62f0ac12aeea8 height=2541228 version=0x20000002 algo=1 (scrypt) log2_work=50.940831 tx=2834254 date='2024-01-23T19:02:17Z' progress=0.999999 cache=1.1MiB(8310txo)
2024-01-23T19:03:14Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-23T19:03:14Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-23T19:03:14Z [default wallet] AddToWallet 36ca0f3c05d067e3a2a8691ca728995b1f09b29c07f8a99409ea50fe32e86df2  new
2024-01-23T19:03:15Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The operation completed successfully.)
2024-01-23T19:03:15Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The operation completed successfully.)
2024-01-23T19:03:15Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-23T19:03:15Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-23T19:03:22Z UpdateTip: new best=00000002ed909e1d01ad98f4e73ef584ed1a76f4fa5fd37a0c79c5bf4064d41b height=2541229 version=0x20000202 algo=0 (sha256d) log2_work=50.940832 tx=2834255 date='2024-01-23T19:03:13Z' progress=1.000000 cache=1.1MiB(8311txo)
2024-01-23T19:03:22Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-23T19:03:22Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-23T19:03:22Z [default wallet] AddToWallet faddcbef6e8c40c3093185ab78b23c4ab700af5a58ba3c09ee96959bbdc4d2b6  new
2024-01-23T19:03:22Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-23T19:03:22Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-23T19:03:22Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-23T19:03:22Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-23T19:03:39Z UpdateTip: new best=29918161772db92c7ba9743f14e83f4064fa61b07774d64b525d9a3c6a7b5574 height=2541230 version=0x20000e02 algo=7 (odo) log2_work=50.940833 tx=2834256 date='2024-01-23T19:03:36Z' progress=1.000000 cache=1.1MiB(8312txo)
2024-01-23T19:03:39Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.

*************** QPixmap::fromWinHICON() messages keep repeating ***************

2024-01-23T21:49:24Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-23T21:49:24Z [default wallet] AddToWallet 0750dfd6ff5782148903c87e387475eac4f38207d629bb5f851535de8b275752  new
2024-01-23T21:49:24Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-23T21:49:24Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-23T21:49:24Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-23T21:49:24Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-23T21:49:41Z UpdateTip: new best=ec8759b26e6a22fad446f88ff2d8cb33b2b83774069c5e241f46cc9144c92d09 height=2541766 version=0x20000802 algo=4 (qubit) log2_work=50.941254 tx=2834792 date='2024-01-23T21:49:39Z' progress=1.000000 cache=1.2MiB(8848txo)
2024-01-23T21:49:41Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-23T21:49:41Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-23T21:49:41Z [default wallet] AddToWallet 9063ba1e0d420ae4db026f42e127d22269e10d0cba7c8540f0b211d42189a454  new
2024-01-23T21:49:42Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-23T21:49:42Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-23T21:49:42Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-23T21:49:42Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-23T21:50:25Z UpdateTip: new best=58ff7dcd3f9f987bb3e8f5e41b7f2a59526704bda0976293f1e30653a41fbb87 height=2541767 version=0x20000802 algo=4 (qubit) log2_work=50.941255 tx=2834793 date='2024-01-23T21:50:22Z' progress=1.000000 cache=1.2MiB(8849txo)
2024-01-23T21:50:25Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-23T21:50:25Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-23T21:50:25Z [default wallet] AddToWallet 425f77d8dc7d373334fa12a8b5ce11c62615c2300c43d634547b711aaedaa21e  new
2024-01-23T21:50:25Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-23T21:50:25Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-23T21:50:25Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-23T21:50:25Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-23T21:50:45Z GUI: flush: GetDC failed (The operation completed successfully.)
2024-01-23T21:51:08Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-23T21:51:08Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-23T21:51:08Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-23T21:51:08Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-23T21:51:08Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-23T21:51:08Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-23T21:51:08Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-23T21:51:08Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-23T21:51:08Z GUI: createDIB: CreateDIBSection failed (182x1, format: 6)

Changing the algo mining against NodeA does not impact the result. I still get the same result of NodeA crashing about 1 time per day.

I then changed the sha256 coinbase txs (mining against NodeB) to be directed to walletB on NodeB to see if NodeB would also crash at some point. NodeB did crash. It took a bit longer to do so, maybe because there were coinbase txs from only one algo going to it.
The log is basically the same as above, except some different messages at the very end:

2024-01-26T16:21:56Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-26T16:21:56Z [default wallet] AddToWallet 3f0d4d355e5fc118e50683332e678bdad2a2f18c328b3d88b4252ae2c9762aa2  new
2024-01-26T16:22:02Z UpdateTip: new best=02db4f324238ed0a6945815423ca8f13fa9925e8a0bdcd40fbe5df542266ff3e height=2554811 version=0x20000802 algo=4 (qubit) log2_work=50.951346 tx=2847838 date='2024-01-26T16:21:59Z' progress=1.000000 cache=0.4MiB(2608txo)
2024-01-26T16:22:02Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-26T16:22:02Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-26T16:22:47Z UpdateTip: new best=2b689835e6501c62496a1aad71648b5a59952486d29f556de601bff8d5de44e3 height=2554812 version=0x20000802 algo=4 (qubit) log2_work=50.951347 tx=2847839 date='2024-01-26T16:22:48Z' progress=1.000000 cache=0.4MiB(2609txo)
2024-01-26T16:22:47Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-26T16:22:47Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-26T16:23:22Z UpdateTip: new best=0000000189bc6e3f7d13c3c704218418edbc091e43e87da301e710dde32d7093 height=2554813 version=0x20000202 algo=0 (sha256d) log2_work=50.951348 tx=2847840 date='2024-01-26T16:22:47Z' progress=1.000000 cache=0.4MiB(2610txo)
2024-01-26T16:23:22Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-26T16:23:22Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-26T16:23:22Z [default wallet] AddToWallet 6b95cadb096decadf69edb5ab53b89013e86e9d59a0969cc693cc06c784cc451  new
2024-01-26T16:23:22Z GUI: getDiBits: GetDIBits() failed to get bitmap bits. (The operation completed successfully.)
2024-01-26T16:23:22Z GUI: getDiBits: GetDIBits() failed to get bitmap bits. (The operation completed successfully.)
2024-01-26T16:23:22Z GUI: getDiBits: GetDIBits() failed to get bitmap bits. (The operation completed successfully.)
2024-01-26T16:24:11Z UpdateTip: new best=000000040ae24784c1d0362769917f4d4458093e3dc42be3e991fc861923e94d height=2554814 version=0x20000202 algo=0 (sha256d) log2_work=50.951349 tx=2847841 date='2024-01-26T16:23:22Z' progress=1.000000 cache=0.4MiB(2611txo)
2024-01-26T16:24:11Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-26T16:24:11Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-26T16:24:11Z [default wallet] AddToWallet 6bf6ff3c4a2477fc3c5cc63bc5389240b79b75ac27edf17cc2dce316f462eff9  new
2024-01-26T16:24:11Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The operation completed successfully.)
2024-01-26T16:24:11Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The operation completed successfully.)
2024-01-26T16:24:11Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-26T16:24:11Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-26T16:24:13Z UpdateTip: new best=d21dfbd0d2fcc9a5a6d0ed6117db6680182b0fa0b861d673fd144a2b53e708ee height=2554815 version=0x20000002 algo=1 (scrypt) log2_work=50.951349 tx=2847842 date='2024-01-26T16:24:12Z' progress=1.000000 cache=0.4MiB(2612txo)
2024-01-26T16:24:13Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.

*************** QPixmap::fromWinHICON() messages keep repeating ***************

024-01-26T23:12:54Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-26T23:12:58Z UpdateTip: new best=423092b4976821b9f5d464214ea4a0cc2110f9a6ee3ed0ec859441202ddd8df7 height=2556156 version=0x20000e02 algo=7 (odo) log2_work=50.952419 tx=2849183 date='2024-01-26T23:12:59Z' progress=1.000000 cache=0.5MiB(3956txo)
2024-01-26T23:12:58Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-26T23:12:58Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-26T23:13:31Z UpdateTip: new best=0000000221d69623b36b8aff1e71eb725fcf813747322114dfb744e0ac5c91f8 height=2556157 version=0x20000202 algo=0 (sha256d) log2_work=50.95242 tx=2849184 date='2024-01-26T23:12:58Z' progress=1.000000 cache=0.5MiB(3957txo)
2024-01-26T23:13:31Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-26T23:13:31Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-26T23:13:31Z [default wallet] AddToWallet 19a311fc939d1ef5e6c5a4eb3d5631994cf1fbd9111bfd3a06d28f3a1dbdce4f  new
2024-01-26T23:13:31Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-26T23:13:31Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-26T23:13:31Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-26T23:13:31Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-26T23:14:22Z UpdateTip: new best=7f6af197656e5c7b857b4011f39d3f4074fe7837dd47448c66e1e3c595bd4cb4 height=2556158 version=0x20000002 algo=1 (scrypt) log2_work=50.952421 tx=2849185 date='2024-01-26T23:13:32Z' progress=1.000000 cache=0.5MiB(3958txo)
2024-01-26T23:14:22Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-26T23:14:22Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-26T23:14:37Z UpdateTip: new best=00000001fad9fe88d22f53b9c60041a9178525ca98fc3415318a4aaae68cee37 height=2556159 version=0x20000202 algo=0 (sha256d) log2_work=50.952422 tx=2849186 date='2024-01-26T23:14:22Z' progress=1.000000 cache=0.5MiB(3959txo)
2024-01-26T23:14:37Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-26T23:14:37Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-26T23:14:37Z [default wallet] AddToWallet 364eb9386f83cbe88a03941e8bc5730a3106fe8fe5060105daa8f616b5b00c0b  new
2024-01-26T23:14:37Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-26T23:14:37Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-26T23:14:37Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-26T23:14:37Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-26T23:14:46Z UpdateTip: new best=2f6ccbf879050f2575c47112d0923a4fbbf81019b88165d61f50fa49f66bc4d4 height=2556160 version=0x20000e02 algo=7 (odo) log2_work=50.952423 tx=2849187 date='2024-01-26T23:14:45Z' progress=1.000000 cache=0.5MiB(3960txo)
2024-01-26T23:14:46Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-26T23:14:46Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 400
2024-01-26T23:14:48Z GUI: flush: GetDC failed (The operation completed successfully.)
2024-01-26T23:14:49Z GUI: flush: GetDC failed (The operation completed successfully.)
2024-01-26T23:14:49Z GUI: flush: GetDC failed (The operation completed successfully.)
2024-01-26T23:14:49Z GUI: flush: GetDC failed (The operation completed successfully.)
2024-01-26T23:14:49Z GUI: flush: GetDC failed (The operation completed successfully.)
2024-01-26T23:14:50Z GUI: flush: GetDC failed (The operation completed successfully.)
2024-01-26T23:14:50Z GUI: flush: GetDC failed (The operation completed successfully.)
2024-01-26T23:14:50Z GUI: flush: GetDC failed (The operation completed successfully.)
2024-01-26T23:14:50Z GUI: flush: GetDC failed (The operation completed successfully.)
2024-01-26T23:14:50Z GUI: flush: GetDC failed (The operation completed successfully.)
2024-01-26T23:14:50Z GUI: flush: GetDC failed (The operation completed successfully.)
2024-01-26T23:14:50Z GUI: flush: GetDC failed (The operation completed successfully.)
2024-01-26T23:14:51Z GUI: flush: GetDC failed (The operation completed successfully.)
2024-01-26T23:14:51Z GUI: flush: GetDC failed (The operation completed successfully.)
2024-01-26T23:14:52Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-26T23:14:52Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-26T23:14:52Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-26T23:14:52Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-26T23:14:52Z GUI: createDIB: CreateDIBSection failed (182x19, format: 6)

My next test was to direct all coinbase txs to walletD on NodeD instead of to a wallet on a node being mined against.
NodeD was NOT being mined against. It was only receiving coinbase txs from the three solo miners.
I moved the wallet.dat file from the NodeA folder to the NodeD folder, so the wallet receiving all the coinbase txs had the same addresses and all the previous coinbase txs. NodeA was still being mined against, but now did not have a wallet configured.
After running like this for about 24 hours, NodeD crashed:

2024-01-29T08:21:14Z [test] AddToWallet 0ccab627f963adca3d488b1e092d024d2c9a7d3ce36f85ac2f842428e2e69825  new
2024-01-29T08:21:27Z UpdateTip: new best=0000000536cbecb8608537345743e4471d124905635d882f25999f3d28b75495 height=2567337 version=0x20000202 algo=0 (sha256d) log2_work=50.961692 tx=2860364 date='2024-01-29T08:21:16Z' progress=1.000000 cache=0.5MiB(4167txo)
2024-01-29T08:21:27Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-29T08:21:27Z [test] AddToWallet 58de48078268d6bc246c3e35e5aca46741a250e2bf0213f0c8e78f63b0523495  new
2024-01-29T08:21:46Z UpdateTip: new best=065b3a0f94e2b28b8d43149bc00f24441f9be3868f7e8540d1902a73908225be height=2567338 version=0x20000e02 algo=7 (odo) log2_work=50.961693 tx=2860365 date='2024-01-29T08:21:45Z' progress=1.000000 cache=0.5MiB(4168txo)
2024-01-29T08:21:46Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-29T08:21:48Z UpdateTip: new best=30c18cbc545ebc6e38b42b3530c16fad437046d7ac7d6aab1ce6374a861fb7d2 height=2567339 version=0x20000602 algo=3 (skein) log2_work=50.961694 tx=2860366 date='2024-01-29T08:21:47Z' progress=1.000000 cache=0.5MiB(4169txo)
2024-01-29T08:21:48Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-29T08:21:48Z [test] AddToWallet e5c4c620d25559c1c41182495044a104a9351afcbd1672373265cc66bad7f8fe  new
2024-01-29T08:21:48Z GUI: getDiBits: GetDIBits() failed to get bitmap bits. (The operation completed successfully.)
2024-01-29T08:21:48Z GUI: getDiBits: GetDIBits() failed to get bitmap bits. (The parameter is incorrect.)
2024-01-29T08:21:48Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The operation completed successfully.)
2024-01-29T08:21:55Z UpdateTip: new best=97a47ab9db5938dc333b9be36c58443167ba044c47b0b38b39508e9b9d629f80 height=2567340 version=0x20000e02 algo=7 (odo) log2_work=50.961695 tx=2860367 date='2024-01-29T08:21:51Z' progress=1.000000 cache=0.5MiB(4170txo)
2024-01-29T08:21:55Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-29T08:22:00Z UpdateTip: new best=9af59eae4ee9c0b539c1c96ba4d42c3d9b41b1604fa577d7c9ff6a83acfead15 height=2567341 version=0x20000602 algo=3 (skein) log2_work=50.961695 tx=2860368 date='2024-01-29T08:21:57Z' progress=1.000000 cache=0.5MiB(4171txo)
2024-01-29T08:22:00Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-29T08:22:00Z [test] AddToWallet 66da604f6bc746587d4d8514b5001fb97b761970bdc9bd20a794238df8cdf84d  new
2024-01-29T08:22:00Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The operation completed successfully.)
2024-01-29T08:22:00Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-29T08:22:00Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-29T08:22:00Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-29T08:22:02Z UpdateTip: new best=00000002a055f9df4568b6af98a813e162b75f739e43755520c2a883725d121f height=2567342 version=0x20000202 algo=0 (sha256d) log2_work=50.961696 tx=2860369 date='2024-01-29T08:22:02Z' progress=1.000000 cache=0.5MiB(4172txo)
2024-01-29T08:22:02Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-29T08:22:02Z [test] AddToWallet 73e541a134bdc61da0b0b9b7cac8c203822b27e6feda614cd5301a09cee25b09  new
2024-01-29T08:22:03Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-29T08:22:03Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-29T08:22:03Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-29T08:22:03Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-29T08:22:05Z UpdateTip: new best=0000000610f306e48b4bdab842099c7d4ab9c941eba905d83347198f40ea7980 height=2567343 version=0x20000202 algo=0 (sha256d) log2_work=50.961697 tx=2860370 date='2024-01-29T08:22:03Z' progress=1.000000 cache=0.5MiB(4173txo)
2024-01-29T08:22:05Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.

*************** QPixmap::fromWinHICON() messages keep repeating ***************

2024-01-29T10:38:14Z [test] AddToWallet 5a5becbf62c1a8aebbcda8660c8ba15913297adc3869533dd3133babd914f403  new
2024-01-29T10:38:14Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-29T10:38:14Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-29T10:38:14Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-29T10:38:14Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-29T10:38:29Z UpdateTip: new best=ad4fc4b048465b5ea42f1a32e302ab91be13a704f6c620ee4a027bde74d40064 height=2567785 version=0x20000e02 algo=7 (odo) log2_work=50.9622 tx=2860812 date='2024-01-29T10:38:26Z' progress=1.000000 cache=0.6MiB(4615txo)
2024-01-29T10:38:29Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-29T10:38:44Z UpdateTip: new best=000000020c7834a48a400233aa43bf949b9663fbd8e635bf9d89e8658aaaeb6b height=2567786 version=0x20000202 algo=0 (sha256d) log2_work=50.962201 tx=2860813 date='2024-01-29T10:38:30Z' progress=1.000000 cache=0.6MiB(4616txo)
2024-01-29T10:38:44Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-29T10:38:44Z [test] AddToWallet 20b519a38aef46b62540400053a6bdb992e0a06fcc5078a9b7a40b09f6da2b6e  new
2024-01-29T10:38:44Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-29T10:38:44Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-29T10:38:44Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-29T10:38:44Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-29T10:38:50Z UpdateTip: new best=0000000188c99dad1439cd63c6ef9c621c309d97256431fa098f5f2e2ba7c666 height=2567787 version=0x20000202 algo=0 (sha256d) log2_work=50.962202 tx=2860814 date='2024-01-29T10:38:46Z' progress=1.000000 cache=0.6MiB(4617txo)
2024-01-29T10:38:50Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2024-01-29T10:38:50Z [test] AddToWallet 3dbc5374e9dfd95e90cad1f8b927f565f1ab26c716f7cead71a4f403dfadc58a  new
2024-01-29T10:38:50Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-29T10:38:50Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-29T10:38:50Z GUI: QPixmap::fromWinHICON(), failed to GetIconInfo() (The parameter is incorrect.)
2024-01-29T10:38:50Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-29T10:39:00Z GUI: flush: GetDC failed (The operation completed successfully.)
2024-01-29T10:39:06Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-29T10:39:06Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-29T10:39:06Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-29T10:39:06Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-29T10:39:06Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-29T10:39:06Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-29T10:39:06Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-29T10:39:06Z GUI: qt_imageToWinHBITMAP, failed to create dibsection (The parameter is incorrect.)
2024-01-29T10:39:06Z GUI: createDIB: CreateDIBSection failed (182x1, format: 6)

My conclusion is a core wallet that is open/running and receiving lots of transactions will eventually crash. If this core wallet is being mined against, mining will obviously stop when it crashes. The crashing from receiving lots of transactions does not seem to be impacted at all by mining against that core node or not.

The only test I have not yet completed is to direct all coinbase txs to the 7.17.3 node to see if it will also crash. I am currently doing this test and update with the result.