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

V12 Release

2015-08-16 08:35:53 CActiveMasternode::ManageStatus() - Checking inbound connection to 'MYOWNPUBIPADDRESS:9999'
2015-08-16 08:35:53 CActiveMasternode::GetMasterNodeVin - Could not locate specified vin from possible list
2015-08-16 08:35:53 CActiveMasternode::ManageStatus() - Could not find suitable coins!
2015-08-16 08:35:53 connected to self at 108.61.189.14:58556, disconnecting

That's OK on a remote node
 
another question, not really related to this specific version : is it okay to have a cold mn wallet connect to your hot mn wallet ? My malwarebytes antimalware premium keeps blocking an outgoing connection from my windows cold wallet to my hot wallet IP address and it originates from my dash-qt.exe .. can i make an exception to that outgoing connection ?

I also had to make an exception for PUTTY and WINSCP but i'm not sure about this outgoing connection and its only one of my MN wallets that tries to connect outbound and then gets blocked.
 
Last edited by a moderator:
Hi guys, I follow this forum now and then. I'm not an IT pro but I have 1 MN (local cold) running in the previous version.
Are there big chances I have to take in account or is it just update the wallets as before? Should I edit something in the config file?

Thanks ;)
 
I have been paying attention to whether MNs get paid correctly during the upgrade. I did not expect these MNs getting paid correctly during the upgrade period. But, I just noticed something on dashninja.pl:

HeightConsensusMajorityNot in consensus
320216100%Xk8KRpRa6PzJB7xxPFiRiUEfjTN5aZ22Xj
320215100%XhAGGdSgfPkHtkH9teXCJdZbnJAoSqTqJg

That 320215 block was reported to be paid to XhAGGdSgfPkHtkH9teXCJdZbnJAoSqTqJg but it actually goes into XbQzpQCk5kC5NPDDwDV2GdZMH7HrEe91hE as you can see here:

http://explorer.dashninja.pl/block/0000000000041a5e0047515fd086f54b02e3b7340852b5af5e9e41d52511b5a7

As I said, MNs not getting the correct payment during this period is not what I am complaining, I am just afraid that things will get undetected like this one. There is no indication from dashninja.pl about this particular wrong payment.
 
Hi guys, I follow this forum now and then. I'm not an IT pro but I have 1 MN (local cold) running in the previous version.
Are there big chances I have to take in account or is it just update the wallets as before? Should I edit something in the config file?

Thanks ;)

just delete peers.dat & mncache.dat and do a -reindex with new version 0.12.0.45
thats pretty much it.

oh and most rpc commands have moved to dash-cli, so only use dashd to start and use dash-cli for the other rpc commands.
Oh hell, i can just as well show it in details :

Hot Wallet

./dashd stop

replace old dashd with new winrar extracted dashd with help of WINSCP

add new winrar extracted dash-cli to same location as dashd with help of WINSCP

chmod +x ./dashd

chmod +x ./dash-cli

rm ~/.dash/peers.dat

rm ~/.dash/mncache.dat

./dashd --reindex

./dash-cli getinfo

wait for full sync

Cold wallet :

replace old dash-qt.exe with new dash-qt.exe

delete peers.dat & mncache.dat

start wallet with commandline option -reindex

wait for full sync

issue "masternode start passphrase"

Hot wallet :

./dash-cli masternodelist full | grep -e IPADDRESS
 
Last edited by a moderator:
Updated to v45 on all nodes, one still will not start even with repeat stopping of the daemon and issuing start-many and start-alias from cold.
 
Further, all of my nodes have yet to show up on dashninja (that's why I was asking if it has been working for others). Bah.

EDIT: SOLVED by cache-refreshing the website.
 
Last edited by a moderator:
Further, all of my nodes have yet to show up on dashninja (that's why I was asking if it has been working for others). Bah.
do you see your MN IP from another instance as enabled? If yes than no worries ;)
 
do you see your MN IP from another instance as enabled? If yes than no worries ;)
Strange, wasn't pulling it on its own instance, the second I found it on another and went back to the problematic instance, it showed up on the masternodelist. Beats me. Will continue to monitor.
 
I have been paying attention to whether MNs get paid correctly during the upgrade. I did not expect these MNs getting paid correctly during the upgrade period. But, I just noticed something on dashninja.pl:

HeightConsensusMajorityNot in consensus
320216100%Xk8KRpRa6PzJB7xxPFiRiUEfjTN5aZ22Xj
320215100%XhAGGdSgfPkHtkH9teXCJdZbnJAoSqTqJg

That 320215 block was reported to be paid to XhAGGdSgfPkHtkH9teXCJdZbnJAoSqTqJg but it actually goes into XbQzpQCk5kC5NPDDwDV2GdZMH7HrEe91hE as you can see here:

http://explorer.dashninja.pl/block/0000000000041a5e0047515fd086f54b02e3b7340852b5af5e9e41d52511b5a7

As I said, MNs not getting the correct payment during this period is not what I am complaining, I am just afraid that things will get undetected like this one. There is no indication from dashninja.pl about this particular wrong payment.

On the masternode monitoring page the Consensus voting table is only indicating if all nodes agrees on who should get paid on each vote. And it is the consensus for v0.12.
The page knows if it was paid correctly or not for each masternode.
Example:
https://dashninja.pl/mndetails.html...9bc6f346fc28dfac6915449158b762138b18514b2d8-0
https://dashninja.pl/mndetails.html...387d08c6d63e5d560956970275baa871e2f2d270efd-0

Enforcement is off and the v0.11 and v0.12 nodes that are currently on the network do not agree on who should win.

I might add the expected payee on the block page.
 
On the masternode monitoring page the Consensus voting table is only indicating if all nodes agrees on who should get paid on each vote. And it is the consensus for v0.12.
The page knows if it was paid correctly or not for each masternode.
Example:
https://dashninja.pl/mndetails.html...9bc6f346fc28dfac6915449158b762138b18514b2d8-0
https://dashninja.pl/mndetails.html...387d08c6d63e5d560956970275baa871e2f2d270efd-0

Enforcement is off and the v0.11 and v0.12 nodes that are currently on the network do not agree on who should win.

I might add the expected payee on the block page.

So, we still have enforcement in v0.12 and it will be activated after most nodes upgrade. I originally thought enforcement no longer exists in v0.12 because the reference node is removed. Sounds like I completely misunderstood what the reference node does.
 
The reference node in previous versions was sending spork messages (like the alert messages of Bitcoin) AND indicating who should get pay.
Now the reference node only is here for spork messages. The network itself elects the masternode payees in consensus.
When the spork message for enforcement is sent it will force correct payment, but this needs that the majority of the network (miners) are updated.
 
The reference node in previous versions was sending spork messages (like the alert messages of Bitcoin) AND indicating who should get pay.
Now the reference node only is here for spork messages. The network itself elects the masternode payees in consensus.
When the spork message for enforcement is sent it will force correct payment, but this needs that the majority of the network (miners) are updated.
So, the selection of payees will be done in consensus for v0.12 but the enforcement is still controlled by the reference node. Is that a correct interpretation of your reply?
 
A weird error I had in testnet has reared it's ugly head again.
In windows, when I attempt to send a transaction, after entering the password, I get a runtime error
(if I click ignore I get invalid password)
So can not access the funds using v0.12.0.45 !!

upload_2015-8-16_15-17-33.png


error log.
2015-08-16 14:22:47 The wallet is probably corrupted: Some keys decrypt but not all.

Edit:if you get this error, the only workaround I can see is to use a V11 .exe version to access the funds from the wallet and then send to a fresh V12 installation (and do not copy the wallet over)
 
Last edited by a moderator:
Are we seeing 6.1% of non-conforming MNs?

From dashninja.pl,

0.12.0.45 (70076) 0.1%
0.12.0.44 (70075) 2.5%
0.12.0.44 (70076) 3.5%

Are these nodes trying to fake 0.12 with 7007[56] protocols?
 
Beside the Master Node problem. I found another problem which is the translation ZH_HK and it still using Darkcoin (暗黑幣) in Chinese. Maybe it is the Outdated translation text. And it can be removed since ZH_HK and ZH_TW is basically the same. It is no need to keep this outdated translation in the program.
http://img107.imagevenue.com/img.php?image=590967356_2015_08_1507.37.08_122_575lo.jpg

did you double check 12.0.45 ?
as far as i know zh_CN + TW is all good now
tx
 
Back
Top