[ANN][PIVX] - PRIVATE INSTANT VERIFIED TRANSACTION - PROOF OF STAKE - ZEROCOIN

[jakiman]

Fixed and no crashes/corrupts so far then?

Yes. My masternodes (linux) are all up now and haven't had any crashes yet which I was having very frequently past 1.5 days or so.
As for my controller wallet (windows), it is synced up and is receiving some MN payments although it's not frequent yet as expected.
But yeah, my Windows wallet feels very fragile atm. (had chain corruption multiple times today whenever it hung during MN startup)

Another day or so is needed till I can really say that this setup is now working as expected.

[borris123]

Fixed and no crashes/corrupts so far then?

Yes. My masternodes (linux) are all up now and haven't had any crashes yet which I was having very frequently past 1.5 days or so.
As for my controller wallet (windows), it is synced up and is receiving some MN payments although it's not frequent yet as expected.
But yeah, my Windows wallet feels very fragile atm. (had chain corruption multiple times today whenever it hung during MN startup)

Another day or so is needed till I can really say that this setup is now working as expected.

Will get mine updated in min then. let us know of there a change

[mxnsch]

Fun fact: Didnt upgrade yet, but no crashes anymore on either side 

[mikegi]

Fun fact: Didnt upgrade yet, but no crashes anymore on either side 

Me neither. Don't plan to unless necessary.

[BitcoinFX]

Dev has just released an updated v2.1.2.1 wallet (non-mandatory) that might help with blockchain corruption issues.
Source is up and binaries are currently being compiled for each OS by s3v3nh4cks. Let us know if it fixes your issue.

https://github.com/Darknet-Crypto/Darknet/releases/tag/v2.1.2.1

'Upgrading' to v2.1.2.1 from v2.1.2.0 will most likely cause;

error: {"code":-1,"message":"ReserveKeyFromKeyPool() : read failed"}
error: {"code":-1,"message":"CWallet::GenerateNewKey() : AddKey failed"}
error: {"code":-1,"message":"CDB : Error -30974, can't open database "}
Error: Error: A fatal internal error occured, see debug.log for details

1. Have varying developers compiled / uploaded the binary releases with different / 'incompatible' database versions ?

2. Time to take a look over the code for other issues. More haste, less speed.

If these issues are not fully resolved (explained) over the next weeks, it is highly likely that folks will simply switch off Masternode hosting due to server costs etc.,

[jakiman]

Checking my controller wallet's debug log, this error is streaming. Any idea what this is? Is it a problem?
(I edited the Tx/hash/address incase they were private)

2016-08-23 11:10:16 Masternode payment enforcement is disabled, accepting block
2016-08-23 11:10:16 ProcessNewBlock : ACCEPTED
2016-08-23 11:10:16 CMasternodePayments::IsTransactionValid - Missing required payment - DTjWr8TggGm6ypCc1HrFLNYJNtNJ
2016-08-23 11:10:16 Invalid mn payment detected CTransaction(hash=d008f86, ver=1, vin.size=1, vout.size=3, nLockTime=0)
    CTxIn(COutPoint(b7c884a2c2aec6a3d2c56bcd9aee06ea15dd96145c392516813d409e7, 1), scriptSig=30450220085f09cb0027)
    CTxOut(nValue=0.00000000, scriptPubKey=)
    CTxOut(nValue=2980.94996357, scriptPubKey=02292b1ca3c7cc5ac9ee7d3470)
    CTxOut(nValue=33.75000781, scriptPubKey=OP_DUP OP_HASH160 a813a6368d)

Also, it just crashed out of the blue with this in the db.log:

file wallet.dat has LSN 38/1014714, past end of log at 1/476
Commonly caused by moving a database from one database environment
to another without clearing the database LSNs, or by removing all of
the log files from a database environment
file wallet.dat has LSN 38/1014714, past end of log at 1/476
Commonly caused by moving a database from one database environment
to another without clearing the database LSNs, or by removing all of
the log files from a database environment
DB_ENV->log_flush: LSN of 38/1014714 past current end-of-log of 1/476
Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment
PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
wallet.dat: unable to flush page: 84
PANIC: fatal region error detected; run recovery

[mxnsch]

Checking my controller wallet's debug log, this error is streaming. Any idea what this is? Is it a problem?
(I edited the Tx/hash/address incase they were private)

2016-08-23 11:10:16 Masternode payment enforcement is disabled, accepting block
2016-08-23 11:10:16 ProcessNewBlock : ACCEPTED
2016-08-23 11:10:16 CMasternodePayments::IsTransactionValid - Missing required payment - DTjWr8TggGm6ypCc1HrFLNYJNtNJ
2016-08-23 11:10:16 Invalid mn payment detected CTransaction(hash=d008f86, ver=1, vin.size=1, vout.size=3, nLockTime=0)
    CTxIn(COutPoint(b7c884a2c2aec6a3d2c56bcd9aee06ea15dd96145c392516813d409e7, 1), scriptSig=30450220085f09cb0027)
    CTxOut(nValue=0.00000000, scriptPubKey=)
    CTxOut(nValue=2980.94996357, scriptPubKey=02292b1ca3c7cc5ac9ee7d3470)
    CTxOut(nValue=33.75000781, scriptPubKey=OP_DUP OP_HASH160 a813a6368d)

Also, it just crashed out of the blue with this in the db.log:

file wallet.dat has LSN 38/1014714, past end of log at 1/476
Commonly caused by moving a database from one database environment
to another without clearing the database LSNs, or by removing all of
the log files from a database environment
file wallet.dat has LSN 38/1014714, past end of log at 1/476
Commonly caused by moving a database from one database environment
to another without clearing the database LSNs, or by removing all of
the log files from a database environment
DB_ENV->log_flush: LSN of 38/1014714 past current end-of-log of 1/476
Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment
PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
wallet.dat: unable to flush page: 84
PANIC: fatal region error detected; run recovery

The errors on the top are probably harmless, you just encountered a masternode without the proper collateral. Is DTjWr8TggGm6ypCc1HrFLNYJNtNJ you?

The DB errors are most probably related to the issue BitcoinFX just pointed out and what i said in the past:
We need properly tested, trusted binary releases.

[jakiman]

Hmm. I see. Thanks. I'll go back to v2.1.2.0 for my main controller wallet and see how I go.
But seems my linux masternodes are running fine with v2.1.2.1 so I'll leave them be for now.

[BitcoinFX]

The network does not care which DB version an individual node runs. The wallet.dat does care about which pre-requisite version of the DB it is using and/or that it is or is not compatible with.

- https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md

... " Ubuntu and Debian have their own libdb-dev and libdb++-dev packages, but these will install BerkeleyDB 5.1 or later, which break binary wallet compatibility with the distributed executables which are based on BerkeleyDB 4.8. If you do not care about wallet compatibility, pass --with-incompatible-bdb to configure. " ...

It will be easier to do bug tracking if everyone is "singing from the same song sheet", at least.

[mxnsch]

The network does not care which DB version an individual node runs. The wallet.dat does care about which pre-requisite version of the DB it is using and/or that it is or is not compatible with.

- https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md

... " Ubuntu and Debian have their own libdb-dev and libdb++-dev packages, but these will install BerkeleyDB 5.1 or later, which break binary wallet compatibility with the distributed executables which are based on BerkeleyDB 4.8. If you do not care about wallet compatibility, pass --with-incompatible-bdb to configure. " ...

It will be easier to do bug tracking if everyone is "singing from the same song sheet", at least.

Exactly, that's why we should get the travis builds working. Should be piece of cake since dash is using them, too.

[borris123]

Dev has just released an updated v2.1.2.1 wallet (non-mandatory) that might help with blockchain corruption issues.
Source is up and binaries are currently being compiled for each OS by s3v3nh4cks. Let us know if it fixes your issue.

https://github.com/Darknet-Crypto/Darknet/releases/tag/v2.1.2.1

'Upgrading' to v2.1.2.1 from v2.1.2.0 will most likely cause;

error: {"code":-1,"message":"ReserveKeyFromKeyPool() : read failed"}
error: {"code":-1,"message":"CWallet::GenerateNewKey() : AddKey failed"}
error: {"code":-1,"message":"CDB : Error -30974, can't open database "}
Error: Error: A fatal internal error occured, see debug.log for details

1. Have varying developers compiled / uploaded the binary releases with different / 'incompatible' database versions ?

2. Time to take a look over the code for other issues. More haste, less speed.

If these issues are not fully resolved (explained) over the next weeks, it is highly likely that folks will simply switch off Masternode hosting due to server costs etc.,

it is annoying updating and then to find out it doesnt work.

Worst thing is trying to activate the node and the controller freezing. when you have multiple nodes this is a real pain in the arse.

[mxnsch]

it is annoying updating and then to find out it doesnt work.

Worst thing is trying to activate the node and the controller freezing. when you have multiple nodes this is a real pain in the arse.

no offense please, but you are repeating yourself here.

It is annoying for all of us and we will resolve this by supporting the Devs in the best way we can, right?

They have the knowledge and with a little more patience to actually slow down development and invest more time - to fix the expected regressions after the switch - we will get that issues sorted.

Additionally, i think we should create a vote to prioritize these annoying things as we did in the past.

DNET is much more than a DASH clone now, let's proceed and proof it!

[borris123]

it is annoying updating and then to find out it doesnt work.

Worst thing is trying to activate the node and the controller freezing. when you have multiple nodes this is a real pain in the arse.

no offense please, but you are repeating yourself here.

It is annoying for all of us and we will resolve this by supporting the Devs in the best way we can, right?

They have the knowledge and with a little more patience to actually slow down development and invest more time - to fix the expected regressions after the switch - we will get that issues sorted.

Additionally, i think we should create a vote to prioritize these annoying things as we did in the past.

DNET is much more than a DASH clone now, let's proceed and proof it!

only agreeing about it.

that be a good idea about the list of things and a vote.

Can we create a test net as well. we shouldnt have to be updating all the time. Everyone on here I am sure will test on the testnet and not release anything until its solid.

[q327K091]

update: all 47 nodes were updated w/ latest git master, are operating well, staking steadily and towards 48th node

[muchoman]

Sorry to say but I sold my dnet, coin is not working and too much hassle to keep up.

[q327K091]

Sorry to say but I sold my dnet, coin is not working and too much hassle to keep up.

a! that was you that made 50$    no problem at all. codebase is stabilizing with every release

tip for the community, even iff all stable and even if it would be dash coin, it pays off to use supervisor (or similar task manager) with autorestart and cleanup prior (in a shall scrypt) , then you can walk away and collect one could also put git pull inside the restart scrypt (automatic pull of fresh codebase) rm blockchain and chainstate and then really go for vacation, I do this with every coin and let dev/community workout small defects

how much time do I spend on dnet a week ? I say because of the above few hours a week at most

great this below (there is some other similar for unix forgot its name popular amongst php folks.. and for windows there has to be something similar as well...)

http://supervisord.org/

[DRPD]

just for info:

so far non of my masternodes running with version 2.1.2.1 crashed
some masternodes still running with 2.1.2.0 & just crashed again, so i guess the new version is a nice step ahead for masternodes

[EcoChavCrypto]

just for info:

so far non of my masternodes running with version 2.1.2.1 crashed
some masternodes still running with 2.1.2.0 & just crashed again, so i guess the new version is a nice step ahead for masternodes

What addnodes are you using?  I have been syncing for the past 3 hours with none in the masternode darknet.conf files and it's still less than 50% done on the first node.

[DRPD]

just for info:

so far non of my masternodes running with version 2.1.2.1 crashed
some masternodes still running with 2.1.2.0 & just crashed again, so i guess the new version is a nice step ahead for masternodes

What addnodes are you using?  I have been syncing for the past 3 hours with none in the masternode darknet.conf files and it's still less than 50% done on the first node.

only addnode=coin-server.com
but yes syncing on masternodes is very slow ....

[Tecem]

Yesterday I was stuck at block 264538. Now with the new wallet I still can't get ast block 264538.