flare
Well-known member
That's OK on a remote node
V12 Release
- Thread starter eduffield
- Start date
That's OK on a remote node
qwizzie
Well-known member
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:
miningfield
New member
Updated to v0.12.0.45 on both windows and linux, everything running smoth
GermanRed+
Active member
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.
qwizzie
Well-known member
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:
do you see your MN IP from another instance as enabled? If yes than no worries
oblox
Well-known member
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
pille
Well-known member
no, only 11.x -> 12.x
vitaly
Active member
okay, thanks
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.
GermanRed+
Active member
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.
GermanRed+
Active member
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?
Sub-Ether
Well-known member
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:
GermanRed+
Active member
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?
