* Make minconfs dpow-aware in z_listunspent + z_listreceivedbyaddress
* Add dpow-related test files to test suite
* Add dpow simulation to regtest every 7 blocks
* Fix compiler errors
* Fix link error
* Fix stdout spam when running regtests
* Dpowminconfs for listreceivedbyaddress
* dpowconfs tests
* Start adding specific tests for dpowminconfs in listreceivedbyaddress
* Get dpowminconfs tests for listreceivedbyaddress working
* Add dpowminconfs to getreceivedbyaddress + listunspent
* Add test for listtransactions + getreceivedbyaddress support
* Reliably passing dpowminconf tests. We only check for notarized-ness now, not exact confirmation numbers, to avoid race conditions
* Poll for the expected notarization info before running further tests; add support for getbalance
* Migrate tx_height() to a place where asyncrpcoperation_sendmany.cpp can use it
* fix
* Teach GetFilteredNotes about dpowconfs
Many RPCs rely on this internal function, which now correctly uses
dpowconfs to filter by the minconf/maxconf parameters.
* Fix sendmany when using non-default minconf
* inline seems to make things happy
* cleanup
* Add some code to test z_sendmany, which points out https://github.com/jl777/komodo/issues/1247
* try this
* Use already calculated value of dpowconfs instead of calculating it again
Prior commits relate to supporting a limited size network.
It looks like there is an edge case where it is possible for a hash to
be in the mapIndex, without a pindex. If a block with such a hash is
tried to be Accepted, the AcceptBlockHeader returns true but with a
null pindex, and AcceptBlock fails.
The code says that this indicates that the hash was added from a
blockheader without a block, but I didn’t see that happening. In any
case, it happens a lot on a 2 node network. So much so that if one node
is just mining, before too long the other node will not accept the
block and once that happens, no subsequent block would work as the
prior block is missing.
Of course, with more nodes, these blocks will be around a lot more and
likely it won’t be such an issue, but not so sure that it doesn’t
require restarting the node to get it back on track again.
These prior commits implement a KOMODO_LIMITED_NETWORKSIZE logic where
if it sees that a block has come in which is in the mapIndex but has no
pindex, it automatically addtoblockindex.
There is one edge case still left where both the current block being
processed and its previous block are in this limbo state. Since the
pindex is not mapped to the block, it is problematic to retrieve the
CBlock for the pprev and without the valid pprev the pindex will have a
null pprev and no nHeight set. It is possible that all the other code
will properly deal with such a case and automatically fix it, but
rather than rely on that, in such a case the automatic addtoblockindex
is not done.
A node in such a state would need to exit and restart or somehow fill
in the data from other nodes.
From what I can tell, the above is the main reason why the PoS/PoW
networks were having problems staying in sync. Since even with one
mining node, it was just a matter of time before the other node got
stuck, with more than one mining node we end up with independent forks
that won’t reconcile until the node is restarted.
