Separate names with a comma.
Please sign up to discuss the most innovative cryptocurrency!
Discussion in 'Official Announcements' started by eduffield, Oct 7, 2014.
Thanks, was browsing trough the BCT thread and was trying to figure out how the fix came to pass
For some reason the pool nicehash keeps paying another MN than mine.
My MN is on the list and should to be paid, but other MN id being paid. weird that it happens only with nicehash and to the same address.
We all await the next level of enforcement 2.0
What is your personal record? The maximum number of days that a masternode didn't get paid since setting up for the first time? This is a total turn off and not sure if I should set up more MNs. I would have made more money by trading on an exchnage
4 days not a single payment.
Edit: If I withdraw 1000 drk to trade on an exchnage and then send it back to the masternode account after Evan fixes fair payment issue, would it automatically start working again?
Light, If you send the 1000 drk to an exchange, your MN is down and later you have to set it up all over again.
All over again? I don't think so. I just send back 1000DRK in one piece and start it :tongue:
Yeah, he is tricking the v14 system, will come to an end with v15 aka Onyx
Pardon my french but what a bunch of bastards!
Flare, how many cheaters are on the list, do you know?
What about it shows a "-" in the Masternode payee column? I am seeing this at drk dot poolhash dot org when search for p2pool. Please see message #149 on the "v10.15 - Onyx Release" thread under darkcointalk for details. Is this another exploit or just the same old 0.10.14.1 exploit?
EDIT: My masternode was ":1" when this happened. Then, shortly after the other address getting paid, my node was shown as ":0".
Sounds like the miner kept the whole reward and no masternode was paid. Because enforcement is off, solo miners and other pools don't have to pay out the current 20% to masternodes. It's all in good faith. When enforcement is turned on, mid-November or 90%, they'll be orphaned.
That was my first guess but when I saw this was paid to another address as a masternode, I started to wonder. If you go to drk dot mn/blocks dot html and search p2pool under Blocks Detail (last 24h), you will see MN payment instead of generation from mining. It lists the XwzmEE1cJ6HG84CgJvAt7ADmJ8W9Wh65Tq address as MN. It will be good to hear from the developers or elberethzone about this.
EDIT: I also think my MN did not went from ":1" to ":0" when the payment went to another address. It did that roughly after 1 hour. (But, I may be wrong here. I will check and confirm this if it goes down again.)
XwzmEE1cJ6HG84CgJvAt7ADmJ8W9Wh65Tq that's the exploit address, probably from a p2pool node running 10.14.1.
Further blocks found by miner XhBLSR1HhoaWrdGgrjCHxJkCWWiFFhveHs used to pay to their own masternode ending in sek but now he just takes the full block reward directly. Again, because enforcement is off.
When grepping your ip in the masternode list from the daemon, is it listed as 1? Do you have green lights on poolhash.org? Drk.mn isn't updated so don't go off that.
Yes, it is green on drk dot poolhash dot org but red on drk dot mn. Both started green. If I did not make a mistake, grepping masternode list was 1 until it reached the next port check time on drk dot mn. Here is the timeline as I remember:
RED on DRK dot mn; GREEN on POOLHASH ; 1 (grepping masternode list)
DRK dot mn port check (next check reached zero); Inactive on POOLHASH; 0 (gripping)
Restart remote darkcoind without starting masternode on local is enough to bring it back to 1 but sometimes it need to restart masternode from the local wallet as well.
poolhash is already updated, drk.mn is stil on 0.10.14.1 and therefore not reporting in a reliable way, so just forget it for now.
The second one (having to restart the Masternode from the local wallet) is a known issue and reported here: http://jira.darkcoin.qa/browse/DRK-104
I think I got a mess here. All the masternode monitoring sites and my own daemon is not reporting the same status. What I am seeing is completely random in behavior. Sometimes, the grep said 0 while green on drk.mn and red on poolhash. Sometime, it is green on poolhash but red on drk.mn. When I run masternode stop on my local wallet, it does not change the masternode from 1 to 0. Masternode start on the local wallet won't change it from 0 to 1 either. It is just so unpredictable that it feels like someone else is running his masternode somewhere else. I did try to regen the key for the masternode. But, it did not help.
Any idea what happened to SuchPool?
drk.mn hasn't updated yet and therefore reports everything wrong.
Not so sure about. Well, we already know that yellows are new green and reds are just pure evil miners But why woudl SuchPool suddenly turn into red? O_O That, I don't get. If it was a flaw of the site then all the yellows should turn into red too.
Edit: Where the hell is everybody? IRC is quiet, no one has any clue what's going on in bitcointalk, No news from @elberethzone either.
There's a life outside internet :tongue:
yes, of course but not during critical days like these Upgrade it and go do whatever you want the rest of the week, month. The entire community depends on these.
I was on vacation during the last update from RC5 to 0.10.14.1 and had to watch for 10 days how my Masternodes got fewer and fewer payments because more and more pools updated to 0.10.14.1
Life's a bitch sometimes...
Just FYI, drk.mn sometimes reports my masternode 100% active when I turned it off. I hope it just needs to wait for a port check when I turned it off.
yea, don't rely on drk.mn at all. Almost everything there is not accurate unless you know how to read things reverse
Thanks for that advice. It drove me nuts!
Besides the late update on drk.mn, I'm also worrying why masternode stop/start successfully on local machine is not really changing the status on the remote machine. Its status just don't change at all. Perhaps, I was switching from 0.10.14.1 to 0.10.15.13 back and forth. Can that be something really bad for the network?
No, it's red because they are paying 100% correctly to the correct protocol but is showing up as 0% because drk.mn isn't on the latest and only sees 10.14.1 as the latest. Coinmine.pl switched recently so half their blocks in that percentage reflect 10.14.1 and the rest 10.15.3. Wait 12-18 hours and it will be all red as well.
I understand that drk.mn hasn't updated the data yet but I don't think being 0% and 'red' means they are on ONYX. if that was the case then all of these would be on ONYX too which I highly doubt:
The link for the linux file is down?