Fix for verifychain #634

aguycalled · 2019-11-18T15:31:10Z

Fixes #630

See issue for more details.

Changes introduced

New RPC command getcfunddbstatehash covered by functional test cfunddb-statehash.py
New state for payment requests 6 when those are paid.
The payment request parameter paidOnBlock is substituted by stateChangedOnBlock when state is 6
New structure for storing the state history of CFundDB entries. Those are stored in a map associating blockhash and state, allowing to directly revert state transitions when reorganizations are seen.
verifychain now checks for the consistency of the CFundDB state hash when level 4 is specified.

Important

This set of changes will require older clients to reindex on launch, keeping the node offline for some hours at best. In order to reduce downtime, node operators can proceed as follows if needed:

Close node with old version.
mkdir /tmp/reindexdata; cp -rf <data_folder>/blocks /tmp/reindexdata/; cp -rf <data_folder>/chainstate /tmp/reindexdata/
Reopen node with old version. It will be again online
Launch in parallel a second instance of the node, this time using the new version with the parameters -reindex -datadir=/tmp/reindexdata/
Once the reindex finishes, close both nodes and copy back the reindexed data.
rm -rf <data_folder>/blocks <data_folder>/chainstate; cp -rf /tmp/reindexdata/* <data_folder>
Relaunch new version of the node.

What to test

Launch a wallet with an old copy of the blockchain. It should show that the database is corrupted and that reindex is needed. Test both gui and headless
Launch a fully synced wallet and execute verifychain 4 0. This should return true.
Partial runs of verifychain 4 n return true (being n an arbitrary value between 1 and the length of the chain).
Wallet should be able to sync correctly

navbuilder · 2019-11-18T16:46:58Z

A new build of 91e731d has completed succesfully!
Binaries available at https://build.nav.community/binaries/verifychain-view

navbuilder · 2019-11-18T19:37:40Z

A new build of 70a96a7 has completed succesfully!
Binaries available at https://build.nav.community/binaries/verifychain-view

aguycalled · 2019-11-18T21:29:44Z

Tested locally and fixed with fcc66d1, ready for review

navbuilder · 2019-11-18T22:41:20Z

A new build of fcc66d1 has completed succesfully!
Binaries available at https://build.nav.community/binaries/verifychain-view

navbuilder · 2019-11-19T10:06:47Z

A new build of ceb4a5e has completed succesfully!
Binaries available at https://build.nav.community/binaries/verifychain-view

aguycalled · 2019-11-20T20:09:57Z

Although verifychain 4 0 is returning true in all my systems, partial runs of the check are returning false in certain conditions. As an explanation of its function, verifychain disconnects the amount of blocks specified in the second parameter, and connects them again. If 0 is specified as second parameter the whole chain is disconnected and reconnected again. Partial runs can be done passing an amount different from 0 (up to the current height).

I've initially found that partial runs were failing in mainnet, but each run of verifychain was taking too long. So I've tried to reproduce this is in a private devnet to get a smaller context which would allow me to test quicker.

Archive.zip

verifychain 4 10 returns false using the above attached chain data. I've chosen 10 randomly, but I was curious to see exactly what was failing, so I wrote a bash script to automate the search.

datadir=/Users/alex/navcoin-core/data
navcli="/Users/alex/navcoin-core/src/navcoin-cli -devnet -datadir=$datadir"
blocks=`$navcli getinfo|jq .blocks`

for i in $(seq 1 $blocks);
do
   verifyoutput=`$navcli verifychain 4 $i`
   if [[ "$verifyoutput" == "false" ]]; 
   then
       verifyoutput+=`echo ' - ' && echo failed at $(grep 'ERROR: VerifyDB()' $datadir/devnet/debug.log |tail -1|sed 's/.*block at \(\d*\)/\1/')`
   fi
   echo Rewinding to \
   $(bc <<< $blocks-$i) \
   - reconnecting up to $blocks \
   - verifychain 4 $i -> $verifyoutput;
done

Running this script would be very useful against a mainnet fully synced node, as it would give us certainty about how well the cfunddb behaves with long reorganizations. But it would take an immense amount of time. How to efficiently run this test in mainnet is an open question. A possible solution would be to run it against an stressed testnet, which could even give a richer context than mainnet (due to an elevated count of injected proposals and payment requests). Any other ideas?

Coming back to the script output, I was able to find it was failing disconnecting down to the following ranges:

Disconnected down to any block in the range	Failed when reconnecting	Reason
330-363	363	IsValidPaymentRequest: Could not find parent proposal dd01134fe270e00b79d6685b4f2b49ba19750227fdad0efeb4b99f2fc1c100d6 for payment request 39c8d0c451bf1b52bce3d60f022f53541d6a51ce4abffa1567c514baf6ab9de5 CProposal(hash=dd01134fe270e00b79d6685b4f2b49ba19750227fdad0efeb4b99f2fc1c100d6, nVersion=2, nAmount=10.000000, available=10.000000, nFee=0.000100, address=mtVZbCiSuBW7pE7zUeFTPscTE1dZd616t1, nDeadline=100000, nVotesYes=0, nVotesNo=0, nVotingCycle=2, fState=pending, strDZeel=test, blockhash=0000000000)
364-419	426	CheckBlock() : cant find payment request block 0000000000000000000000000000000000000000000000000000000000000000
511-579	579	IsValidPaymentRequest: Could not find parent proposal 5ca639ac2c0da9a47cdfd40a59f2c2ccd2d29a07e969c95131e33cb0ccba5b36 for payment request 860e07e6a36f16f53579cf96ebc9f37bc2841905c055703ebc3e04a3d3f8a0be CProposal(hash=5ca639ac2c0da9a47cdfd40a59f2c2ccd2d29a07e969c95131e33cb0ccba5b36, nVersion=2, nAmount=1.000000, available=1.000000, nFee=0.000100, address=mu39oWSRd1TKa7zsxS52BjHczd4fYwBpuE, nDeadline=100, nVotesYes=0, nVotesNo=0, nVotingCycle=3, fState=pending, strDZeel=test, blockhash=0000000000)
580-629	636	CheckBlock() : cant find payment request block 0000000000000000000000000000000000000000000000000000000000000000

In devnet, voting cycles last 30 blocks. Blocks cycle from 0 to 29 as in height%30 to determine the position inside of a cycle. The cycle number is determined by int(height/30). Payouts happen in the 7th block of a voting cycle after a payment request has been accepted.

Let's see when there's been votes in the chain:

Entry	Vote	When
Proposal 1	Yes	303-329
Payment request 1	Yes	385-389
Payment request 1	Yes	396-419
Proposal 2	Yes	486-509
Payment request 2	Yes	610-629

Having a closer look at what happened in the critical blocks:

Height	What
329	Proposal 1 is accepted
330	Nothing of interest in the block, voting cycle 11, first block with proposal 1 accepted
363	Payment request 1 is created
364	Nothing of interest besides being the first block of payment request 1
419	Last block of the voting cycle 13, payment request 1 is accepted, proposal 1 expires
426	Payment request 1
509	Proposal 2 is accepted
511	Nothing of interest in the block, voting cycle 17
579	Payment request 2 is created
580	Nothing of interest besides being the first block of payment request 2
629	Last block of the voting cycle 20, payment request 2 is accepted
636	Payout of payment request 2

363 and 579 are both seeing the creation of new payment requests. The creation fails because the parent proposal is not accepted. 426 and 636 see the payouts of the payment requests. Those fail because the node can't validate if the block when the payment request was accepted is in the main chain.

Why?

When we disconnect a block, the state of all the entries which had an update in that block is reseted. This is a wrong design of the cfunddb, because it assumes the entry state will be correctly calculated in the next reorganization, which does not happen all the time.

For example, when we disconnect 419, proposal 1 and payment request 1 will transition like this:

Proposal 1:

State: 3 (expired) -> 0 (nil)
Blockhash: 0x6c504bb8ae6a80bc7b118450dd40e52976951701684cdf86345973faf27263dd -> 0x0

Payment request 1:

State: 1 (accepted) -> 0 (nil)
Blockhash: 0x6c504bb8ae6a80bc7b118450dd40e52976951701684cdf86345973faf27263dd -> 0x0

Now we can stop disconnecting and reconnect 419 and higher blocks, or keep disconnecting lower blocks to reconnect them later. Whatever we do, the votes in the ranges 385-389 and 396-419 won't be counted, because the parent proposal has not the accepted state anymore. If the votes are not counted, the payment request is never accepted, the block hash is never set again and the payout is rejected.

This situation happens unless we reorganise lower than 363. Then we find a different situation when we reconnect 363. We will see an error when the payment request is created, because the proposal is not in an accepted state. For this we would need reorganise lower than 330, so 329 is reconnected and proposal 1 recovers its accepted state.

I have an idea on how to fix this, but would need every wallet to reindex/resync.

I'll leave it here waiting for feedback from others.

aguycalled · 2019-11-20T23:26:42Z

I've committed a fix in 29f404d for the previously described issue.

This will require every node to reindex the first time it's opened. Verified with the aforementioned script, verifychain now passes for partial runs.

With the new patch, the whole history of states is stored in a map. Every time the state changes it is stored and associated with the hash of the black where the transition happened. When an entry is reorganised the state associated with the hash of the disconnected block is erased. The new state will be that one associated with the block with higher height part of the active chain. This completely substitutes the previous reorganisation method.

navbuilder · 2019-11-21T00:37:25Z

A new build of 29f404d has completed succesfully!
Binaries available at https://build.nav.community/binaries/verifychain-view

mxaddict · 2019-11-21T03:44:17Z

This PR is failing the test_navcoin binary with:

../../src/test/cfunddb_tests.cpp(431): error: in "coins_tests/cfunddb_state": check prequest == it.second has failed

aguycalled · 2019-11-21T08:29:40Z

It is fixed in 2eee7d5 @mxaddict

navbuilder · 2019-11-21T09:29:15Z

A new build of 2eee7d5 has completed succesfully!
Binaries available at https://build.nav.community/binaries/verifychain-view

mxaddict · 2019-11-21T09:37:37Z

@aguycalled the cfunddb-fork-reorg-* tests seem to be failing in this build.

navbuilder · 2019-12-06T00:50:57Z

A new build of 1bd70c8 has completed succesfully!
Binaries available at https://build.nav.community/binaries/verifychain-view

navbuilder · 2019-12-06T02:26:43Z

A new build of 475cf7b has completed succesfully!
Binaries available at https://build.nav.community/binaries/verifychain-view

proletesseract · 2019-12-07T07:46:04Z

compiles, running tests. Will review the diff in the morning.

proletesseract · 2019-12-07T22:28:39Z

RPC test suite passes, except getting some error with it not being able to find the file stakeimmaturebalance.py which definitely exists in the file system and has the same permissions as the other files. Travis passes, so I will move on.

proletesseract · 2019-12-07T22:47:15Z

Reindex initiated on OSX both testnet & mainnet

proletesseract

RPC test suite reviewed.

proletesseract · 2019-12-09T05:29:05Z

qa/rpc-tests/cfund-fork-reorg-proposal.py

@@ -16,6 +16,7 @@ class CfundForkReorgProposal(NavCoinTestFramework):
    def __init__(self):
        super().__init__()
        self.setup_clean_chain = True
+        self.node_args = [['-debug=dao'], ['-debug=dao']]


Should this node initialisation done the same way as it is done in cfund-fork-reorg-preq.py consistency?

proletesseract · 2019-12-09T05:30:14Z

qa/rpc-tests/cfund-fork-reorg-proposal.py

@@ -96,7 +97,7 @@ def run_test(self):
        assert_equal(self.nodes[0].getblock(self.nodes[0].getproposal(proposalHash0)["blockHash"]), self.nodes[1].getblock(self.nodes[1].getproposal(proposalHash0)["blockHash"]))
        assert_equal(self.nodes[0].getproposal(proposalHash0), self.nodes[1].getproposal(proposalHash0))

-        # End cycle 2        
+        # End cycle 2


lots of whitespace diffs, i wonder if we should commit some code linter, or auto formatter config to the repo to help make this more consistent?

proletesseract · 2019-12-09T06:05:05Z

qa/rpc-tests/cfund-paymentrequest-payout.py

@@ -169,36 +167,30 @@ def run_test(self):
        for x in range(self.num_nodes):
            assert(self.nodes[x].getbestblockhash() == bestBlockHash)
            assert(self.nodes[x].getpaymentrequest(paymentReq)["state"] == 1)
-            assert(self.nodes[x].getpaymentrequest(paymentReq)["paidOnBlock"] == "0000000000000000000000000000000000000000000000000000000000000000")
+            assert(self.nodes[x].getpaymentrequest(paymentReq)["stateChangedOnBlock"] != "0000000000000000000000000000000000000000000000000000000000000000")


why has this assertion been inverted?

paidOnBlock does not exist anymore, but stateChangedOnBlock is used combined with state==6 to show in which block a payment request has been paid. line 172 checks the payment request is not null

proletesseract · 2019-12-09T06:07:36Z

qa/rpc-tests/cfund-paymentrequest-payout.py


        # disconnect the nodes and generate the payout on each node
        url = urllib.parse.urlparse(self.nodes[1].url)
        self.nodes[0].disconnectnode(url.hostname+":"+str(p2p_port(1)))

        time.sleep(1)

-        while self.nodes[0].getpaymentrequest(paymentReq)["paidOnBlock"] == "0000000000000000000000000000000000000000000000000000000000000000":
+        while self.nodes[0].getpaymentrequest(paymentReq)["state"] == 6:


isn't state 6 the final state of paid? Or will it move from this to something else eventually? The diff says the while condition was previously paidonblock == "000.." which i thought meant loop until it has been paid, but now the while runs until the state is no longer paid? I must be misinterpreting this, the test passes.

d3e786f

$ qa/rpc-tests/cfund-paymentrequest-payout.py Initializing test directory /var/folders/qh/7_l8lmqx2sb5ncxgtzzyb51r0000gn/T/testfn5g4cou/27872 Stopping nodes Cleaning up Tests successful

proletesseract · 2019-12-09T06:10:59Z

qa/rpc-tests/cfund-paymentrequest-state-accept-expired-proposal.py

@@ -150,7 +151,7 @@ def run_test(self):
        self.nodes[0].paymentrequestvote(paymentrequestid0, "remove")

        assert(self.nodes[0].getpaymentrequest(paymentrequestid0)["state"] == 0)
-        assert(self.nodes[0].getpaymentrequest(paymentrequestid0)["status"] == "accepted waiting for end of voting period")
+        assert_equal(self.nodes[0].getpaymentrequest(paymentrequestid0)["status"], "accepted waiting for end of voting period")


any benefit changing from assert with the string comparison to assert_equal? or just for consistency?

just for debug reasons

proletesseract · 2019-12-09T06:17:00Z

qa/rpc-tests/cfunddb-statehash.py

+
+        self.sync_all()
+
+        assert_equal(self.nodes[0].getbestblockhash(), self.nodes[1].getbestblockhash())


should we again check that the cfundstatehash matches on each node after they are reconnected? or is it implied they will match because their bestblockhash is the same?

7ffee61

$ qa/rpc-tests/cfunddb-statehash.py Initializing test directory /var/folders/qh/7_l8lmqx2sb5ncxgtzzyb51r0000gn/T/testivmhhxdf/28317 Stopping nodes Cleaning up Tests successful

proletesseract

some more review added

proletesseract · 2019-12-09T06:54:06Z

src/coins.cpp

+        {
+            if (!it.second.IsNull())
+            {
+                writer << it.second;


Would it be enough to only concatenate the proposal hashes and payment request hashes here since we can already assume those are hashes of the contents of the objects? Or should we be completely verbose and concatenate the whole object like this to be sure? What was the benchmarking results?

the proposal and payment hashes are the hash of the transaction where they were created and do not change with the objects, hence we need to serialize and hash them

proletesseract · 2019-12-09T06:57:30Z

src/coins.h

@@ -310,7 +310,7 @@ struct CCacheEntry
 typedef CCacheEntry<CCoins> CCoinsCacheEntry;
 typedef boost::unordered_map<uint256, CCoinsCacheEntry, SaltedTxidHasher> CCoinsMap;
 typedef std::map<uint256, CProposal> CProposalMap;
-typedef boost::unordered_map<uint256, CPaymentRequest, SaltedTxidHasher> CPaymentRequestMap;
+typedef std::map<uint256, CPaymentRequest> CPaymentRequestMap;


what is SaltedTxidHasher and why is it removed?

https://en.cppreference.com/w/cpp/container/unordered_map

what i would say here, is that in std::map the order is guaranteed while boost::unordered_map does not guarantee it. guaranteed order is needed for cfunddbstate hash consistency. SaltedTxidHasher is removed because now we use std::map

proletesseract · 2019-12-09T07:07:42Z

src/consensus/cfund.cpp

@@ -221,28 +221,95 @@ bool CFund::IsValidPaymentRequest(CTransaction tx, CCoinsViewCache& coins, int n

 }

+flags CFund::CPaymentRequest::GetLastState() const {


As i understand it we're storing the block height of each state change into a <blockhash,state> map against the payment request (and proposal) now correct? How was this done previously? Was it not needed? Did we just kept the last state and the last blockhash?

yes, we store a map of block hash and states (the whole state history, so its easy to roll back).
before we just stored the last state and blockhash, which was the main source of issues related to reorganizations (how to recover previous state)

proletesseract · 2019-12-09T07:24:34Z

src/consensus/cfund.cpp

-        if (fState == ACCEPTED && mapBlockIndex.count(blockhash) > 0) {
-            CBlockIndex* pBlockIndex = mapBlockIndex[blockhash];
-            ret.pushKV("expiresOn", pBlockIndex->GetBlockTime() + (uint64_t)nDeadline);
+        if ((fState == ACCEPTED || fState == PAID) && pblockindex) {


won't pblockindex always evaluate true unless the proposal has not got any state at all? Is that what you're supposed to be checking in this condition? Or should we be using GetLastStateBlockIndexForState() to check a particular state has been correctly achieved?

it's true that (fState == ACCEPTED || fState == PAID) can't give us a null pointer in pblockindex, but i think the check does not hurt for sanity

proletesseract · 2019-12-09T07:29:39Z

src/consensus/cfund.cpp

@@ -767,94 +887,97 @@ void CFund::CFundStep(const CValidationState& state, CBlockIndex *pindexNew, con

            CBlockIndex* pblockindex = mapBlockIndex[prequest->txblockhash];

-            CProposal proposal;
-
-            if (!view.GetProposal(prequest->proposalhash, proposal))


why don't we need this check anymore?

CFundStep has been rewritten a bit

proletesseract · 2019-12-09T07:31:09Z

src/consensus/cfund.cpp

-            if((pindexNew->nHeight + 1) % Params().GetConsensus().nBlocksPerVotingCycle == 0)
+            CProposal proposal;
+
+            if (!view.GetProposal(prequest->proposalhash, proposal))


i can see it's moved here. what was the motive of moving it here? so we get the logging?

CFundStep has been rewritten a bit, i'm not sure if this check would make more sense earlier. it's less likely a payment request has no parent proposal than a payment request being out of chain (previous checks)

proletesseract · 2019-12-09T07:39:00Z

src/consensus/cfund.cpp

+            CProposal tmp;
+            CProposal oldproposal = CProposal();
+
+            if (fLog)


why was this also moved further down?

CFundStep has been rewritten a bit to accomodate the changes of this pull request. this moved some parts of the code

…oin-core into verifychain-view

navbuilder · 2019-12-09T09:57:58Z

A new build of f630567 has completed succesfully!
Binaries available at https://build.nav.community/binaries/verifychain-view

navbuilder · 2019-12-09T16:47:39Z

A new build of 561339d has completed succesfully!
Binaries available at https://build.nav.community/binaries/verifychain-view

proletesseract · 2019-12-10T09:04:19Z

The RPC tests are failing in travis now. For me, either cfund-fork-reorg-preq.py or getstakereport.py seem to be non-deterministically timing out

proletesseract

all reviewed except diff on main.cpp

proletesseract · 2019-12-10T07:48:49Z

src/consensus/cfund.h

        return nAmount == b.nAmount
-                && fState == b.fState
+                && thisMapState == bMapState
                && hash == b.hash


Just confirming how these operator overloads work. In this context hash is the hash property of the CPaymentRequest on the left side of the operator and b.hash is the hash property of the CPaymentRequest on the right side of the operator? Or should we be explicitly defining both objects in parenthesis as lhs and rhs like in the spec?

inline bool operator==(const X& lhs, const X& rhs){ /* do actual comparison */ } inline bool operator!=(const X& lhs, const X& rhs){ return !(lhs == rhs); }

https://en.cppreference.com/w/cpp/language/operators

Either way is fine if it works, i just don't want to make assumptions on my side about how this functions exactly.

yes thats how it works

proletesseract · 2019-12-10T09:40:55Z

src/qt/communityfunddisplaypaymentrequestdetailed.cpp

-        ui->labelPrequestPaymentHashTitle->setVisible(false);
-        ui->labelPrequestPaymentHash->setVisible(false);
-    }
+    ui->labelPrequestPaymentHashTitle->setVisible(false);


should this still be wrapped in the if condition?

paymenthash does not exist anymore, so it makes sense to hide it always

src/rpc/blockchain.cpp

src/wallet/rpcwallet.cpp

This reverts commit 561339d.

navbuilder · 2019-12-10T11:41:30Z

A new build of 3b9d623 has completed succesfully!
Binaries available at https://build.nav.community/binaries/verifychain-view

chasingkirkjufell

did stress testing with the script https://gist.github.com/aguycalled/13f362c29ea9c38624e8dd4593bc37f8 on ubuntu 18.10 and 19.04 for a week and no problem was found besides some scripting issues.

proletesseract · 2019-12-11T05:29:51Z

src/consensus/cfund.cpp

@@ -829,9 +829,9 @@ void CFund::CFundStep(const CValidationState& state, CBlockIndex *pindexNew, con
            CProposalModifier proposal = view.ModifyProposal(it->first);
            proposal->nVotesYes = it->second.first;
            proposal->nVotesNo = it->second.second;
-            proposal->fDirty = true;


what is the purpose of moving this assignment to inside the if statements?

proletesseract · 2019-12-11T06:38:35Z

src/main.cpp

@@ -3911,6 +3881,7 @@ bool static ConnectTip(CValidationState& state, const CChainParams& chainparams,
    int64_t nTime3;
    int64_t nTime4;
    LogPrint("bench", "  - Load block from disk: %.2fms [%.2fs]\n", (nTime2 - nTime1) * 0.001, nTimeReadFromDisk * 0.000001);
+    uint256 statehash;
    {


as a bit of a side note, what is the purpose of these curly braces which don't appear to be enclosing any conditional, loop or function definition? Is it some notation for a constructor or some way of encapsulating the contents?

@proletesseract I think that is for scoping, IIRC any variables declared in the curlies will be destroyed once the code passes the closing curly.

mxaddict · 2019-12-11T08:36:10Z

I'm still running the scenarios:

Ubuntu 19.10 self compiled using depends dir.

mxaddict · 2019-12-11T08:37:00Z

I've also verified that running this branch on an old datadir forces a reindex.

mxaddict

I think we need a linter like @proletesseract suggested, I'm not sure how to go about implementing it though.

fix coins view instead of coins tip

91e731d

aguycalled requested review from mxaddict, proletesseract and chasingkirkjufell November 18, 2019 15:31

aguycalled added the ready for review label Nov 18, 2019

aguycalled removed the ready for review label Nov 18, 2019

alex v added 2 commits November 18, 2019 18:49

recount votes when verifying database

48b2bfc

fix boolean

70a96a7

write instead of insert if it already exists

fcc66d1

aguycalled added the ready for review label Nov 18, 2019

Merge remote-tracking branch 'upstream/master' into verifychain-view

ceb4a5e

aguycalled removed the ready for review label Nov 20, 2019

use mapState instead of fState and blockhash

29f404d

add missing txblockhash to ser function

2eee7d5

aguycalled added the ready for review label Nov 21, 2019

alex v added 3 commits November 21, 2019 10:42

fix log

86503ea

getstate string for paid state

d16f9e0

update paidOnblock to stateChangedOnBlock from cfund tests

755b71e

Merge branch 'master' into verifychain-view

89e9e52

proletesseract reviewed Dec 9, 2019

View reviewed changes

alex v added 6 commits December 9, 2019 08:50

setup consistency

59c872a

Merge branch 'verifychain-view' of https://github.com/aguycalled/navc…

da2432d

…oin-core into verifychain-view

fix loop condition

d3e786f

assert statehash

7ffee61

remove old reference after master merge

61556c8

remove old reference after master merge

f630567

fDirty

561339d

proletesseract reviewed Dec 10, 2019

View reviewed changes

alex v added 2 commits December 10, 2019 11:10

Revert "fDirty"

f3fa184

This reverts commit 561339d.

add extra log

3b9d623

chasingkirkjufell approved these changes Dec 11, 2019

View reviewed changes

proletesseract reviewed Dec 11, 2019

View reviewed changes

proletesseract approved these changes Dec 11, 2019

View reviewed changes

mxaddict approved these changes Dec 11, 2019

View reviewed changes

aguycalled merged commit 049978e into navcoin:master Dec 11, 2019

proletesseract mentioned this pull request Dec 13, 2019

v4.7.2-rc #649

Merged


		self.sync_all()

		assert_equal(self.nodes[0].getbestblockhash(), self.nodes[1].getbestblockhash())

		@@ -221,28 +221,95 @@ bool CFund::IsValidPaymentRequest(CTransaction tx, CCoinsViewCache& coins, int n

		}

		flags CFund::CPaymentRequest::GetLastState() const {

Fix for verifychain #634

Fix for verifychain #634

Conversation

aguycalled commented Nov 18, 2019 • edited

Changes introduced

Important

What to test

navbuilder commented Nov 18, 2019

navbuilder commented Nov 18, 2019

aguycalled commented Nov 18, 2019 • edited

navbuilder commented Nov 18, 2019

navbuilder commented Nov 19, 2019

aguycalled commented Nov 20, 2019 • edited

aguycalled commented Nov 20, 2019 • edited

navbuilder commented Nov 21, 2019

mxaddict commented Nov 21, 2019 • edited

aguycalled commented Nov 21, 2019 • edited

navbuilder commented Nov 21, 2019

mxaddict commented Nov 21, 2019

navbuilder commented Dec 6, 2019

navbuilder commented Dec 6, 2019

proletesseract commented Dec 7, 2019

proletesseract commented Dec 7, 2019

proletesseract commented Dec 7, 2019

proletesseract left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

proletesseract left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

navbuilder commented Dec 9, 2019

navbuilder commented Dec 9, 2019

proletesseract commented Dec 10, 2019

proletesseract left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

navbuilder commented Dec 10, 2019

chasingkirkjufell left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mxaddict commented Dec 11, 2019 • edited

mxaddict commented Dec 11, 2019

mxaddict left a comment

Choose a reason for hiding this comment

aguycalled commented Nov 18, 2019 •

edited

aguycalled commented Nov 18, 2019 •

edited

aguycalled commented Nov 20, 2019 •

edited

aguycalled commented Nov 20, 2019 •

edited

mxaddict commented Nov 21, 2019 •

edited

aguycalled commented Nov 21, 2019 •

edited

mxaddict commented Dec 11, 2019 •

edited