TestNet Testing Thread - Test IPFS Integration (Decentralized IP File System)

[jaapgvk]

It seems I cheered too early 

I got my home testnet rig up an running again though. I hope it has a different CPID associated, but I'm not sure because I tried some re-associations in the past days.

[Rob Andrews]

So on the positive side we broke through the chain, and we are rolling.

But the thing Togo mentioned in his log he has solved prior blocks; so I set up two distinct CPIDs in testned and they are both synced to the top.
Whats very, very strange is they both also say they solved prior blocks (like Togo).

In addition, I took a look at the code, and it looks fine, and we havent changed anything related to mining with this QT feature, so Im confused how we introduced a failure in this respect.  Im also mining at .80 hps.

So, let me add some special logging for this and Ill get to the root of the problem.

[Rob Andrews]

All - I decided to remove QT (quant tightening) due to lack of popularity.

Please get 1.1.5.4, and resync the chain.

Windows is compiling...

[jaapgvk]

All - I decided to remove QT (quant tightening) due to lack of popularity.

Please get 1.1.5.4, and resync the chain.

Windows is compiling...

Upgrading...

[togoshigekata]

My CPID for testnet may have not solved any work in over a month, not sure if thats part of the issue

[Rob Andrews]

All - I decided to remove QT (quant tightening) due to lack of popularity.

Please get 1.1.5.4, and resync the chain.

Windows is compiling...

Oops, after I removed QT, I just realized one of the chain parameters in testnet was adjusted to look back 30 days for the QT 'governanceinfo' prior total (this was for future qt).... Sorry...

Please all, upgrade to 1.1.5.4b....

Building windows now.


We can talk about the cpids solving ability tomorrow after we resync again.

Thanks.

[Rob Andrews]

Oops, after I removed QT, I just realized one of the chain parameters in testnet was adjusted to look back 30 days for the QT 'governanceinfo' prior total (this was for future qt).... Sorry...

Please all, upgrade to 1.1.5.4b....

Building windows now.


We can talk about the cpids solving ability tomorrow after we resync again.

Thanks.

When you guys re-sync today, please delete your mnc*.* and mnp*.* files and the banlist.dat also first.

I have found that we may be caching a superblock (in the govobj system) with a bad payment - and I believe that will fix our sync issue in testnet.

[MIP]

Oops, after I removed QT, I just realized one of the chain parameters in testnet was adjusted to look back 30 days for the QT 'governanceinfo' prior total (this was for future qt).... Sorry...

Please all, upgrade to 1.1.5.4b....

Building windows now.

MacOS version for testnet also available.

[jaapgvk]

When you guys re-sync today, please delete your mnc*.* and mnp*.* files and the banlist.dat also first.

I have found that we may be caching a superblock (in the govobj system) with a bad payment - and I believe that will fix our sync issue in testnet.

Alright, I've updated all my wallets and deleted the .dat's you suggested. Resynching now...

[Rob Andrews]

Alright, I've updated all my wallets and deleted the .dat's you suggested. Resynching now...

Thanks all - Ive relaunched 4 nodes and 2 are mining.  Although each block I solve is having trouble being added to the other nodes.
But, I believe we are back in the same state we were in prior to the QT fiasco, so Im thinking we just need another miner online now.

Lets be patient and see if another miner allows us to sync.  Im on block :
getblockhash 67726
35fa0d84e64d0fb0b4ec6a05588d8b38b42967e5acbebaa5384e780d10f55728

[jaapgvk]

Thanks all - Ive relaunched 4 nodes and 2 are mining.  Although each block I solve is having trouble being added to the other nodes.
But, I believe we are back in the same state we were in prior to the QT fiasco, so Im thinking we just need another miner online now.

Lets be patient and see if another miner allows us to sync.  Im on block :
getblockhash 67726
35fa0d84e64d0fb0b4ec6a05588d8b38b42967e5acbebaa5384e780d10f55728

I have three wallets. Only one was syncing to the tip (and had the same blockhash as you have), but that one didn't have a CPID associated with it. I just associated a CPID with that one, so let's wait and see if that's going to work.

The other two I'll try to resync...

[Rob Andrews]

I have three wallets. Only one was syncing to the tip (and had the same blockhash as you have), but that one didn't have a CPID associated with it. I just associated a CPID with that one, so let's wait and see if that's going to work.

The other two I'll try to resync...

Something is starting to happen now... I think.


Yes- all the wallets are clicking up now in tandem.  We had some type of problem based on where we sputtered out (right at the block before the last boinc superblock) and since our masternodes were all dead, the wallet couldnt come to consensus on that superblock.  Now we are past it and we have 6 or so testers online.  We just need to bring up our sancs now.

[togoshigekata]

Hmmm, my wallet crashed, v1.1.5.4b, I had upgraded, cleaned and reindexed

Code Select Expand

Segmentation fault (core dumped)

tail debug.log

Code Select Expand

ERROR: Block has no ancestor
Misbehaving: 84.29.208.33:62767
ERROR: invalid header received bd9004da***6d0fea
ERROR: Found block with no ancestor
ERROR: Block has no ancestor.
ERROR: ProcessNewBlock: AcceptBlock FAILED
Misbehaving: 84.29.208.33:62767

Im going to clean and reindex again

[Rob Andrews]

Hmmm, my wallet crashed, v1.1.5.4b, I had upgraded, cleaned and reindexed

Code Select Expand

Segmentation fault (core dumped)

tail debug.log

Code Select Expand

ERROR: Block has no ancestor
Misbehaving: 84.29.208.33:62767
ERROR: invalid header received bd9004da***6d0fea
ERROR: Found block with no ancestor
ERROR: Block has no ancestor.
ERROR: ProcessNewBlock: AcceptBlock FAILED
Misbehaving: 84.29.208.33:62767

Im going to clean and reindex again

84.29 is running 1154.  I know that area of code, we crashed a couple times there in the past - there is even some code in there to try to prevent the crash.  Its really elusive because every time I hear this and try to valgrind it, there is no way to reproduce the exact situation again - I know it has something to do with having a lot of forks in your getchaintips.  I think one of the forks best block hashes is NULL to the wallet.  But we dont save NULL blocks in the map.  I did check Dash to see if they changed that but not yet.

[togoshigekata]

mnsync status
shows that Im synced now AssetID 999

getblockhash 67777
bd687ccb***0788387b2

Masternode is PRE_ENABLED

hashps: 0.135,
networkhashps: 178.888