V12 Release
- Thread starter eduffield
- Start date
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.
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
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.
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.
just delete peers.dat & mncache.dat and do a -reindex with new version 0.12.0.45Hi 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
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:
- Apr 8, 2014
- 1,926
- 1,287
- 1,283
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.do you see your MN IP from another instance as enabled? If yes than no worries
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.
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 !!
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)
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 !!
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?
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?
- Apr 9, 2014
- 8,902
- 6,729
- 1,283
Yes.
The subver text version is retrieved by the port checker by connecting directly to the nodes and interacting on protocol level. This is retrieved every hour.
The protocol version is retrieved from the masternode list full.
If the masternode daemon was updated but without doing a masternode start the protocol version might still be the old one (70075 or 70076).
This does not mean they are faking v0.12.
Elbereth, thanks for all the information. I also looked up some older posts on the forum. Evan mentioned that v0.12 has a hybrid state for the reference node. Your reply really helps clearing things up for people like me who do not read all the posts.
If you're using 0.12.0.45, try shutting down dash then restarting, this time without the --reindex. This worked for me - it seemed to go back a few months to start loading blocks again but when finished, got past the "synchronizing budgets".
This version is looking incredibly stable for me across all of my nodes. I'm running windows 64 and OSX locally (qt) and Linux 64 bit daemon remote.
- Darksend mixing is moving faster than before (I wish I had a benchmark to quantify this)
- All messages such as "Synchronizing masternodes", "Synchronizing masternode winners", "Synchronizing budgets", "Synchronizing sporks" are finally disappearing (probably owing to the larger share of the network that's upgraded by now)
- All my masternodes have been up and stable for the last 24 hours without any issues
- Upgrade from v44 to v45 didn't even require a restart (since they had the same protocol)
- I do recommend removing any addnode commands... I found that my clients found more v12 nodes to connect to without it
Tried it, but qt keeps freezing on me and won't quit, I have to restart the comp each time.
Pablo.
Because the QT wallet freezes and won't shut down. So I have to restart the comp to get rid of it. This is on an HP laptop with Ubuntu 14 and only the wallet running.
Pablo.
Shouldn't have to start the comp if it freezes. Just do
kill -9 [pid of dash-qt]
or if using windows, kill it using Task Manager.
I get a bit scared when doing this with wallets so I'd recommend you only do this if you already have a backup copy of your wallet.dat somewhere...but we all have this, don't we
Yes i would suggest to install with a fresh, empty wallet first, and make sure everything works first.Shouldn't have to start the comp if it freezes. Just do
kill -9 [pid of dash-qt]
or if using windows, kill it using Task Manager.
I get a bit scared when doing this with wallets so I'd recommend you only do this if you already have a backup copy of your wallet.dat somewhere...but we all have this, don't we