• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

v0.10.9.x Help test RC2 forking issues

Status
Not open for further replies.
Mine sees 8:

Can someone tell a noob how to figure out what my MN hash would be that shows in the voting?
Code:
ubuntu@ip-10-252-204-115:~$ darkcoind masternode votes
{
    "14187" : "OP_DUP OP_HASH160 a83cc7c0004906c57957d420e7dbc19cbc8c2fdb OP_EQUALVERIFY OP_CHECKSIG",
    "14188" : "OP_DUP OP_HASH160 a83cc7c0004906c57957d420e7dbc19cbc8c2fdb OP_EQUALVERIFY OP_CHECKSIG",
    "14189" : "OP_DUP OP_HASH160 012ca2df8c1a5c77c794dd5b9237e595d86d5bf3 OP_EQUALVERIFY OP_CHECKSIG",
    "14190" : "OP_DUP OP_HASH160 7f898281b5ca5b7ec9385e04421b4e2a1aa008d4 OP_EQUALVERIFY OP_CHECKSIG",
    "14191" : "OP_DUP OP_HASH160 012ca2df8c1a5c77c794dd5b9237e595d86d5bf3 OP_EQUALVERIFY OP_CHECKSIG",
    "14192" : "OP_DUP OP_HASH160 012ca2df8c1a5c77c794dd5b9237e595d86d5bf3 OP_EQUALVERIFY OP_CHECKSIG",
    "14193" : "OP_DUP OP_HASH160 0d82037de937dc7d3d6136eb7c19b13a8b588e57 OP_EQUALVERIFY OP_CHECKSIG",
    "14194" : "OP_DUP OP_HASH160 34d7e6bdc2a0131d752f03b6410839657d8d9edc OP_EQUALVERIFY OP_CHECKSIG",
    "14195" : "OP_DUP OP_HASH160 012ca2df8c1a5c77c794dd5b9237e595d86d5bf3 OP_EQUALVERIFY OP_CHECKSIG",
    "14196" : "OP_DUP OP_HASH160 a83cc7c0004906c57957d420e7dbc19cbc8c2fdb OP_EQUALVERIFY OP_CHECKSIG"
}

Haven't figured that out yet, but from watching at my votes list from my nodes (with only 2 active known nodes) i KNOW that

34d7e6bdc2a0131d752f03b6410839657d8d9edc is my node 184.73.179.196
7f898281b5ca5b7ec9385e04421b4e2a1aa008d4 is my node 184.73.179.187
75d86ae5f4d39b751b2716696b23d9b768bca315 is my node 184.73.179.148

:grin:
 

Before i updated my nodes to v0.10.9.3 two of them where stuck on block 14136

This is what i got in debug.log

Code:
2014-06-04 18:14:18 received block 00000000856c6317504f88b7f1d3da02efce669fd48eb4b8c9245cdf7928863d
2014-06-04 18:14:18 ERROR: AcceptBlock() : rejected by synchronized checkpoint
2014-06-04 18:14:18 ERROR: ProcessBlock() : AcceptBlock FAILED
 
Masternode payout started on block 14214, active node count up to 55, voting consistent on all three nodes so far - good, good, good :smile:

Code:
{
    "14218" : "OP_DUP OP_HASH160 34d7e6bdc2a0131d752f03b6410839657d8d9edc OP_EQUALVERIFY OP_CHECKSIG",
    "14219" : "OP_DUP OP_HASH160 dc8e62bd42dfc51fb75319a1764f6155f49d802f OP_EQUALVERIFY OP_CHECKSIG",
    "14220" : "OP_DUP OP_HASH160 5e243325874a1ad5a8fdb979aeeee2341b50fb07 OP_EQUALVERIFY OP_CHECKSIG",
    "14221" : "OP_DUP OP_HASH160 8da5005f4efa2385c50fcfaac37473b3def85143 OP_EQUALVERIFY OP_CHECKSIG",
    "14222" : "OP_DUP OP_HASH160 b4b6f14fe815f175e17dd818cdefd8277bc8420b OP_EQUALVERIFY OP_CHECKSIG",
    "14223" : "OP_DUP OP_HASH160 9f76ea939b892c16eb5e5ab23d743521fde10fdc OP_EQUALVERIFY OP_CHECKSIG",
    "14224" : "OP_DUP OP_HASH160 02d069f1a5dea3f261ae5637df31ded94d5ae728 OP_EQUALVERIFY OP_CHECKSIG",
    "14225" : "OP_DUP OP_HASH160 cc9d15a2c7682233f85a8cff39ca1f152221ef3c OP_EQUALVERIFY OP_CHECKSIG",
    "14226" : "OP_DUP OP_HASH160 5e2a44becdc000fa5331ac7e6f0512d7defe31fe OP_EQUALVERIFY OP_CHECKSIG",
    "14227" : "OP_DUP OP_HASH160 a534bcf52ac17918da047319ac113cbf5a9912ad OP_EQUALVERIFY OP_CHECKSIG"
}
    "votes" : [
        "8a370000000000001976a91451ec377004cca3c27ad8450c130717413f7fe8a588ac03000000",
        "90370000000000001976a91402d069f1a5dea3f261ae5637df31ded94d5ae72888ac04000000",
        "91370000000000001976a914cc9d15a2c7682233f85a8cff39ca1f152221ef3c88ac03000000",
        "92370000000000001976a9145e2a44becdc000fa5331ac7e6f0512d7defe31fe88ac02000000",
        "93370000000000001976a914a534bcf52ac17918da047319ac113cbf5a9912ad88ac01000000"
    ],
    "payee" : "mv48C1GdFQFRSfGRerxtuRzxRuSskWiTkN",
    "masternode_payments" : true
}
 
Last edited by a moderator:
Masternode payout started on block 14214, active node count up to 55, voting consistent on all three nodes so far - good, good, good :smile:

Code:
{
    "14218" : "OP_DUP OP_HASH160 34d7e6bdc2a0131d752f03b6410839657d8d9edc OP_EQUALVERIFY OP_CHECKSIG",
    "14219" : "OP_DUP OP_HASH160 dc8e62bd42dfc51fb75319a1764f6155f49d802f OP_EQUALVERIFY OP_CHECKSIG",
    "14220" : "OP_DUP OP_HASH160 5e243325874a1ad5a8fdb979aeeee2341b50fb07 OP_EQUALVERIFY OP_CHECKSIG",
    "14221" : "OP_DUP OP_HASH160 8da5005f4efa2385c50fcfaac37473b3def85143 OP_EQUALVERIFY OP_CHECKSIG",
    "14222" : "OP_DUP OP_HASH160 b4b6f14fe815f175e17dd818cdefd8277bc8420b OP_EQUALVERIFY OP_CHECKSIG",
    "14223" : "OP_DUP OP_HASH160 9f76ea939b892c16eb5e5ab23d743521fde10fdc OP_EQUALVERIFY OP_CHECKSIG",
    "14224" : "OP_DUP OP_HASH160 02d069f1a5dea3f261ae5637df31ded94d5ae728 OP_EQUALVERIFY OP_CHECKSIG",
    "14225" : "OP_DUP OP_HASH160 cc9d15a2c7682233f85a8cff39ca1f152221ef3c OP_EQUALVERIFY OP_CHECKSIG",
    "14226" : "OP_DUP OP_HASH160 5e2a44becdc000fa5331ac7e6f0512d7defe31fe OP_EQUALVERIFY OP_CHECKSIG",
    "14227" : "OP_DUP OP_HASH160 a534bcf52ac17918da047319ac113cbf5a9912ad OP_EQUALVERIFY OP_CHECKSIG"
}
    "votes" : [
        "8a370000000000001976a91451ec377004cca3c27ad8450c130717413f7fe8a588ac03000000",
        "90370000000000001976a91402d069f1a5dea3f261ae5637df31ded94d5ae72888ac04000000",
        "91370000000000001976a914cc9d15a2c7682233f85a8cff39ca1f152221ef3c88ac03000000",
        "92370000000000001976a9145e2a44becdc000fa5331ac7e6f0512d7defe31fe88ac02000000",
        "93370000000000001976a914a534bcf52ac17918da047319ac113cbf5a9912ad88ac01000000"
    ],
    "payee" : "mv48C1GdFQFRSfGRerxtuRzxRuSskWiTkN",
    "masternode_payments" : true
}

Yay, I think I fixed it. We have sixty something masternodes and we've paid like 98% of the blocks.
 
Sweeet! All of my masternodes are reporting blockchain, votes, etc in sync. Masternode payouts are working fine.
getinfo
Code:
ip-10-179-16-76.ec2.internal:
    {
        "version" : 100903,
        "protocolversion" : 70015,
        "walletversion" : 60000,
        "balance" : 1029.60270000,
        "blocks" : 14253,
        "timeoffset" : 0,
        "connections" : 8,
        "proxy" : "",
        "difficulty" : 0.52492671,
        "testnet" : true,
        "keypoololdest" : 1401679462,
        "keypoolsize" : 101,
        "paytxfee" : 0.00000000,
        "mininput" : 0.00001000,
        "errors" : ""
    }
ip-10-147-240-210.ec2.internal:
    {
        "version" : 100903,
        "protocolversion" : 70015,
        "walletversion" : 60000,
        "balance" : 1043.60280000,
        "blocks" : 14253,
        "timeoffset" : 0,
        "connections" : 8,
        "proxy" : "",
        "difficulty" : 0.52492671,
        "testnet" : true,
        "keypoololdest" : 1401679463,
        "keypoolsize" : 101,
        "paytxfee" : 0.00000000,
        "mininput" : 0.00001000,
        "errors" : ""
    }
masternode votes
Code:
ip-10-179-16-76.ec2.internal:
    {
        "14247" : "OP_DUP OP_HASH160 69d836d0cdd5e85ac4257baf55ded1310625f036 OP_EQUALVERIFY OP_CHECKSIG",
        "14248" : "OP_DUP OP_HASH160 7f898281b5ca5b7ec9385e04421b4e2a1aa008d4 OP_EQUALVERIFY OP_CHECKSIG",
        "14249" : "OP_DUP OP_HASH160 81e9482117114c4d9fbe0d2851b663931a58d0cd OP_EQUALVERIFY OP_CHECKSIG",
        "14250" : "OP_DUP OP_HASH160 d3618641a9f9cd08e4f588f2be3b870e47ab8eb1 OP_EQUALVERIFY OP_CHECKSIG",
        "14251" : "OP_DUP OP_HASH160 4ae265e7bda3b1ef010bc492359daf83170f4b4c OP_EQUALVERIFY OP_CHECKSIG",
        "14252" : "OP_DUP OP_HASH160 8da5005f4efa2385c50fcfaac37473b3def85143 OP_EQUALVERIFY OP_CHECKSIG",
        "14253" : "OP_DUP OP_HASH160 8da5005f4efa2385c50fcfaac37473b3def85143 OP_EQUALVERIFY OP_CHECKSIG",
        "14254" : "OP_DUP OP_HASH160 69d836d0cdd5e85ac4257baf55ded1310625f036 OP_EQUALVERIFY OP_CHECKSIG",
        "14255" : "OP_DUP OP_HASH160 b4ea9aafdce49ee79326a0e44c45e1d2978003d5 OP_EQUALVERIFY OP_CHECKSIG",
        "14256" : "OP_DUP OP_HASH160 02d069f1a5dea3f261ae5637df31ded94d5ae728 OP_EQUALVERIFY OP_CHECKSIG"
    }
ip-10-147-240-210.ec2.internal:
    {
        "14247" : "OP_DUP OP_HASH160 69d836d0cdd5e85ac4257baf55ded1310625f036 OP_EQUALVERIFY OP_CHECKSIG",
        "14248" : "OP_DUP OP_HASH160 7f898281b5ca5b7ec9385e04421b4e2a1aa008d4 OP_EQUALVERIFY OP_CHECKSIG",
        "14249" : "OP_DUP OP_HASH160 81e9482117114c4d9fbe0d2851b663931a58d0cd OP_EQUALVERIFY OP_CHECKSIG",
        "14250" : "OP_DUP OP_HASH160 d3618641a9f9cd08e4f588f2be3b870e47ab8eb1 OP_EQUALVERIFY OP_CHECKSIG",
        "14251" : "OP_DUP OP_HASH160 4ae265e7bda3b1ef010bc492359daf83170f4b4c OP_EQUALVERIFY OP_CHECKSIG",
        "14252" : "OP_DUP OP_HASH160 8da5005f4efa2385c50fcfaac37473b3def85143 OP_EQUALVERIFY OP_CHECKSIG",
        "14253" : "OP_DUP OP_HASH160 8da5005f4efa2385c50fcfaac37473b3def85143 OP_EQUALVERIFY OP_CHECKSIG",
        "14254" : "OP_DUP OP_HASH160 69d836d0cdd5e85ac4257baf55ded1310625f036 OP_EQUALVERIFY OP_CHECKSIG",
        "14255" : "OP_DUP OP_HASH160 b4ea9aafdce49ee79326a0e44c45e1d2978003d5 OP_EQUALVERIFY OP_CHECKSIG",
        "14256" : "OP_DUP OP_HASH160 02d069f1a5dea3f261ae5637df31ded94d5ae728 OP_EQUALVERIFY OP_CHECKSIG"
    }
Edited: Posted a non-masternode by mistake. All is well.
 
Last edited by a moderator:
*** Please update to 10.9.3 or 9.5.3 ***

I think I've fixed all of our masternode voting problems and 1/2 of the ghost masternode problem. I'll fix the other half tomorrow.

Hi Evan,

good work, works much better for me so far. Nevertheless i have found something which either is a bug in the abe blockexplorer or in the algorithm how the clients store the votes in the blockchain.

If you look at the blocks 14214+ since the payout started you will notice the following:

Block 14214
Code:
Blockheight    Pubkey    Votes

14214    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    1

Block 14215
Code:
Blockheight    Pubkey    Votes
14214    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    2
14215    nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE    1

Block 14216
Code:
Blockheight    Pubkey    Votes
14214    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    2
14215    nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE    2
14216    QSp8gRBSez2Y6MQCgGSiMsoKxnsa9HVVk    1

Block 14217
Code:
Blockheight    Pubkey    Votes
14214    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    2
14215    nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE    3
14216    QSp8gRBSez2Y6MQCgGSiMsoKxnsa9HVVk    2
14217    Z92SLSwb3z2D47g47Y1E9LczimJiVFtvv    1

Block 14218
Code:
Blockheight    Pubkey    Votes
14214    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    3
14215    nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE    4
14216    QSp8gRBSez2Y6MQCgGSiMsoKxnsa9HVVk    3
14217    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    1
14218    XomhG7xJcL5iSCQhM4AcS8N381DguAobA    1

So far, so good - each block is appending a vote to the existing votes. But
nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE is receiving votes in each block, too!?
And with the next block the oddness continues

Block 14219
Code:
Blockheight    Pubkey    Votes
14214    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    3
14216    QSp8gRBSez2Y6MQCgGSiMsoKxnsa9HVVk    4
14217    Z92SLSwb3z2D47g47Y1E9LczimJiVFtvv    1
14218    fqgi8JuLcrrnhkw1JnoCFNqV7qPQSQ85f    1
14219    kSoDShs3inDHZjMBVbLLF4n1YXKMFd8sR    1

Obviously nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE got another vote, and since you lowered MASTERNODE_PAYMENTS_MIN_VOTES to 5 in main.h it got paid out. But additionally the vote for 14218 changed from XomhG7xJcL5iSCQhM4AcS8N381DguAobA to fqgi8JuLcrrnhkw1JnoCFNqV7qPQSQ85f to be changed back to XomhG7xJcL5iSCQhM4AcS8N381DguAobA in the next block - odd!?

Block 14220
Code:
Blockheight    Pubkey    Votes
14214    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    4
14217    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    1
14218    XomhG7xJcL5iSCQhM4AcS8N381DguAobA    1
14219    kSoDShs3inDHZjMBVbLLF4n1YXKMFd8sR    2
14220    YvNsM5mxwbSjM6q2MHifymuTZDjaueE1B    1

And here things get messy: Vote counts for 14214 and 14217 and now inconsistently lowered from 4 to 1.
The next block is odd too:

Block 14221
Code:
Blockheight    Pubkey    Votes
14217    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    2
14218    XomhG7xJcL5iSCQhM4AcS8N381DguAobA    2
14219    kSoDShs3inDHZjMBVbLLF4n1YXKMFd8sR    3
14220    YvNsM5mxwbSjM6q2MHifymuTZDjaueE1B    2
14221    dFYvfCtehekxuocBrKewSCNYgg1a5RCtw    1

Vote count for 14217 now changed to 2 (+1), 14218 changed to 2 (+1), 14219 changed to 3 (+1), 14220 changed to 2 (+1) - which would mean this block counted for at least 5 votes?!

So either the abe-explorer is misinterpreting the votes from the blockchain, or the votes are not stored consistently in the blockchain. Can you please dig into this? Thanks!

Holger

EDIT: Seems something is broken with the vote system, votes are stacking up in the same scheme since 14256+ now - which is impossible.

Code:
Blockheight    Pubkey    Votes
142**              ???    5
142**              ???    4
142**              ???    3
142**              ???    2
142**              ???    1

EDIT2:

Verified by 'masternode votes' and 'getblocktemplate', vote system is not counting correctly.

Code:
./darkcoind masternode votes
{
    "14298" : "OP_DUP OP_HASH160 1fed77f7969136e1a4f59b53b34a98c2f6d9a2d6 OP_EQUALVERIFY OP_CHECKSIG",
    "14299" : "OP_DUP OP_HASH160 bce5f22f341d49544ff398a071aac7dfa3bacc4b OP_EQUALVERIFY OP_CHECKSIG",
    "14300" : "OP_DUP OP_HASH160 d8d3cef6e63fa5104f75e2e42a26d69ad9b13dff OP_EQUALVERIFY OP_CHECKSIG",
    "14301" : "OP_DUP OP_HASH160 d3d18906c77e680fb90d8dd0298fdc267d7fecaa OP_EQUALVERIFY OP_CHECKSIG",
    "14302" : "OP_DUP OP_HASH160 5e2a44becdc000fa5331ac7e6f0512d7defe31fe OP_EQUALVERIFY OP_CHECKSIG",
    "14303" : "OP_DUP OP_HASH160 bce5f22f341d49544ff398a071aac7dfa3bacc4b OP_EQUALVERIFY OP_CHECKSIG",
    "14304" : "OP_DUP OP_HASH160 cc9d15a2c7682233f85a8cff39ca1f152221ef3c OP_EQUALVERIFY OP_CHECKSIG",
    "14305" : "OP_DUP OP_HASH160 f860d685867e1f1768bdc22bbcacf7a2a9ee2c31 OP_EQUALVERIFY OP_CHECKSIG",
    "14306" : "OP_DUP OP_HASH160 81e9482117114c4d9fbe0d2851b663931a58d0cd OP_EQUALVERIFY OP_CHECKSIG",
    "14307" : "OP_DUP OP_HASH160 81e9482117114c4d9fbe0d2851b663931a58d0cd OP_EQUALVERIFY OP_CHECKSIG"
}

./darkcoind getblocktemplate
[...]
    "votes" : [
        "df370000000000001976a914bce5f22f341d49544ff398a071aac7dfa3bacc4b88ac05000000",
        "e0370000000000001976a914cc9d15a2c7682233f85a8cff39ca1f152221ef3c88ac04000000",
        "e1370000000000001976a914f860d685867e1f1768bdc22bbcacf7a2a9ee2c3188ac03000000",
        "e2370000000000001976a91481e9482117114c4d9fbe0d2851b663931a58d0cd88ac02000000",
        "e3370000000000001976a91481e9482117114c4d9fbe0d2851b663931a58d0cd88ac01000000"
    ],
    "payee" : "mp6rSxNV1gtSB2KMFDLMkEK6pcFQgEGfXC",
    "masternode_payments" : true
}
[...]

Last two lines should read

Code:
"e237 0000000000001976a914 81e9482117114c4d9fbe0d2851b663931a58d0cd88ac _01_ 000000",
"e337 0000000000001976a914 81e9482117114c4d9fbe0d2851b663931a58d0cd88ac _02_ 000000"

after receiving two votes for 81e9482...
 
Last edited by a moderator:
Back to testnet!
Block height check so I'm on the right fork, but at this time (about 20 mins up to sync) my masternode count = 0
Seems odd

"version" : 100903,
"protocolversion" : 70015,
"walletversion" : 60000,
"balance" : 0.00000000,
"blocks" : 14341,
"timeoffset" : -12,
"connections" : 8,
"proxy" : "",
"difficulty" : 0.50599145,
"testnet" : true,
"keypoololdest" : 1401955602,
"keypoolsize" : 101,
"paytxfee" : 0.00000000,
"mininput" : 0.00001000,
"errors" : ""

Anyone mind sharing a bag of coins? I'm always on IRC with a close eye on the forum, so I can spread some testnet-DRKs love as soon as people request.

This is not my address 0, so feel free to send whatever -
n2kqAZWuLjRpBMKniJ6F85TFjSo1UPPESy
- thanks vertoe!
 
Last edited by a moderator:
Back to testnet!
Block height check so I'm on the right fork, but at this time (about 20 mins up to sync) my masternode count = 0
Seems odd



Anyone mind sharing a bag of coins? I'm always on IRC with a close eye on the forum, so I can spread some testnet-DRKs love as soon as people request.

This is not my address 0, so feel free to send whatever -
n2kqAZWuLjRpBMKniJ6F85TFjSo1UPPESy
Check your logs, you already got coins via IRC.
 
Since updating to the latest version (10.9.3) I don't see any masternodes besides myself in the masternode list.
I'm listed on http://tdrk.poolhash.org/blocks/masterlist.txt with :1
I'm on the right chain.
Anyone else having that problem?

After an hour, I got 1 ... btw, my node is masternode=0 for now.

"54.187.152.9:19999" : 1

Quick question, let try to explain clearly...

1) On my MN, on the mainet darkcoin.conf, I do have a maternode private key already there from 10.8.11 - when updating daemon, do I need to generate a new one?
2) when testnet=1, do I need to genkey a new key for testnet, or use the same as mainnet?
 
Exactly the same problem here on two masternodes.
But after some time another masternode appeared.
All listed on http://tdrk.poolhash.org/blocks/masterlist.txt with :1

this is weird, or I dont get it.

ubuntu@ip-172-31-23-208:~/.darkcoin/testnet3$ darkcoind masternode votes
{
"14365" : "OP_DUP OP_HASH160 9ae2babfc2b6e765261a77475e1f1dc663e298d3 OP_EQUALVERIFY OP_CHECKSIG",
"14366" : "OP_DUP OP_HASH160 9ae2babfc2b6e765261a77475e1f1dc663e298d3 OP_EQUALVERIFY OP_CHECKSIG",
"14367" : "OP_DUP OP_HASH160 9ae2babfc2b6e765261a77475e1f1dc663e298d3 OP_EQUALVERIFY OP_CHECKSIG",
"14368" : "OP_DUP OP_HASH160 9ae2babfc2b6e765261a77475e1f1dc663e298d3 OP_EQUALVERIFY OP_CHECKSIG",
"14369" : "OP_DUP OP_HASH160 9ae2babfc2b6e765261a77475e1f1dc663e298d3 OP_EQUALVERIFY OP_CHECKSIG",
"14370" : "OP_DUP OP_HASH160 9ae2babfc2b6e765261a77475e1f1dc663e298d3 OP_EQUALVERIFY OP_CHECKSIG",
"14371" : "OP_DUP OP_HASH160 9ae2babfc2b6e765261a77475e1f1dc663e298d3 OP_EQUALVERIFY OP_CHECKSIG",
"14372" : "OP_DUP OP_HASH160 9ae2babfc2b6e765261a77475e1f1dc663e298d3 OP_EQUALVERIFY OP_CHECKSIG",
"14373" : "OP_DUP OP_HASH160 9ae2babfc2b6e765261a77475e1f1dc663e298d3 OP_EQUALVERIFY OP_CHECKSIG",
"14374" : "OP_DUP OP_HASH160 9ae2babfc2b6e765261a77475e1f1dc663e298d3 OP_EQUALVERIFY OP_CHECKSIG"
}
 
After an hour, I got 1 ... btw, my node is masternode=0 for now.



Quick question, let try to explain clearly...

1) On my MN, on the mainet darkcoin.conf, I do have a maternode private key already there from 10.8.11 - when updating daemon, do I need to generate a new one?
2) when testnet=1, do I need to genkey a new key for testnet, or use the same as mainnet?
I'm not sure but I think you have to create a new one for testnet. When I started it with my mainnet key I got invalid key. So an error willl be displayed if you have to create a new key.
 
Ok, going to generate a new one and fire up the node. thanks donho

EDIT: After some testing, seems to be just like the addresses. testnet=0/1 require its own genkey.

What is weird though, again, is after I got my "masternode started successfully" - I now still only see 1 MN, but I only see myself now (for now, I'll give it time and report back).
 
Last edited by a moderator:
Ok, major problem. As soon as I activated the masternode, I got stuck on block 14390

ubuntu@ip-172-31-23-208:~/.darkcoin$ darkcoind getinfo
{
"version" : 100903,
"protocolversion" : 70015,
"walletversion" : 60000,
"balance" : 10000.00000000,
"blocks" : 14390,
"timeoffset" : 0,
"connections" : 0,
"proxy" : "",
"difficulty" : 0.44576174,
"testnet" : true,
"keypoololdest" : 1401955602,
"keypoolsize" : 101,
"paytxfee" : 0.00000000,
"mininput" : 0.00001000,
"errors" : ""
}

I stopped the daemon, and started with only "darkcoin --reindex" - again, only went up to 14390.
What gives?

EDIT2:
Ok, so I trash everything on testnet3 folder (backed up testnet 1k wallet.dat), started the daemon and nothing, zero connections. Did nothing to the config file... maybe 23.23.186.131 is down?
Yes, went to check, seems down. I'll go back a few pages and try to grab some more nodes


EDIT3: Indeed, after adding
addnode=184.73.179.148
addnode=184.73.179.187
addnode=184.73.179.196

blocks are up to height now. What a damn coincidence I activate my node right when 23.23.186.131 goes down. But I still only see myself on the node list, but it may be soon as they only ping ever 30 minutes IIRC... Off to lunch then...
 
Last edited by a moderator:
Status
Not open for further replies.
Back
Top