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

V12 Release

Right now we have 76.6% of the blocks getting paid correctly via version 12 (with 95% on latest version 0.12.0.47) and we have still some 16.2% on version 11 and 7.2% on unknown version. Those 16.2% and 7.2% don't seem to move much.

Are we still waiting on those 16.2% and 7.2% to change to correct version before getting enforcement back on or are we waiting on something else ? Im just curious what we are waiting for right now with regards to putting enforcement back on...
I think the devs are sleeping....
 
I guess it's .45, right? Try .47 then, should be way better.

Here is after updating from 0.44 to 0.47.

upload_2015-8-22_8-20-48.png


upload_2015-8-22_8-21-9.png
 
Right now we have 76.6% of the blocks getting paid correctly via version 12 (with 95% on latest version 0.12.0.47) and we have still some 16.2% on version 11 and 7.2% on unknown version. Those 16.2% and 7.2% don't seem to move much.

Are we still waiting on those 16.2% and 7.2% to change to correct version before getting enforcement back on or are we waiting on something else ? Im just curious what we are waiting for right now with regards to putting enforcement back on...
"SPORK_8_MASTERNODE_PAYMENT_ENFORCEMENT" : 1440246078,
 
V12 Update

Everything looks stable now, so we're locking down v12 development and moving on to v12.1 We'll be making announcements soon about the direction of the project. I'm currently doing a lot of research so it could take a bit.

- 12.0.47 has resolved most of the issues that we were having with CPU load and consensus of masternode payment winners
- It's also really nice to see CPU usage and bandwidth are both much lower than v11

A note on queue reset:

When a masternode joins the network it gets in the queue, then waits, usually a few days for a payment. However, what would happen if you dropped out of the masternode list and then rejoined 5 days later? You would receive your payment in about 15 minutes.

To stop this type of attack, whenever you join the masternode pool, you will automatically move to the back of the list. This means that you shouldn't do a cold "masternode start" unless you're trying to bring a specific masternode back online.

This also has a couple nice side effects:
- When people do a mass start-many, they are giving up privacy because their masternodes can be grouped by the signature times. So we will increase the privacy of anyone using start-many frequently.
- SigTime is also intended to represent when the masternode first joined the masternode pool. This will allow us to better determine the average uptime of the masternodes and their level of service.
 
V12 Update
This also has a couple nice side effects:
- When people do a mass start-many, they are giving up privacy because their masternodes can be grouped by the signature times. So we will increase the privacy of anyone using start-many frequently.
Could you elaborate on this? What do you mean "giving up privacy"? Thank you.
 
Could you elaborate on this? What do you mean "giving up privacy"? Thank you.

Each masternode has a sigTime, which was when the original message was signed and propagated. So if you sign and propagate 10 at once, they will have the same sigTime, which means that they are probably all owned by the same person.
 
So everytime a masternode start command is issued the Sigtime is updated, effectively putting you at the back of queue, only start in emergencies then!
 
Each masternode has a sigTime, which was when the original message was signed and propagated. So if you sign and propagate 10 at once, they will have the same sigTime, which means that they are probably all owned by the same person.

So do you think you can 'gap' the start-many's by "random timing" of 5s-30s
[just a thought]
 
Can't wait to test v.12.1!

Could we please also have another key that Masternode providers can't steal mn votes from mn owners.

Also, ... a fix for jmmA the naughty MN payment hijacker !!!! ?
(He seriously needs to be neutered!... just sayin.)
 
I never start my masternode if it's not delisted.
If all ok Evan, enforcement is On then?

yep


SPORK INFO
{
"SPORK_2_INSTANTX" : true,
"SPORK_3_INSTANTX_BLOCK_FILTERING" : false,
"SPORK_5_MAX_VALUE" : true,
"SPORK_7_MASTERNODE_SCANNING" : true,
"SPORK_8_MASTERNODE_PAYMENT_ENFORCEMENT" : true, <<<<<<<<<<<<<<<<<<<<<<<<<<<<
"SPORK_9_MASTERNODE_BUDGET_ENFORCEMENT" : false,
"SPORK_10_MASTERNODE_PAY_UPDATED_NODES" : true,
"SPORK_11_RESET_BUDGET" : true,
"SPORK_12_RECONSIDER_BLOCKS" : true,
"SPORK_13_ENABLE_SUPERBLOCKS" : false
 
Well, seems we're finally finding out the answer to that one.
https://dashtalk.org/threads/v12-release.5888/page-29#post-64451
All my 128/128 nodes were managing to parse the chain, but all the "new stuff" that happened afterwards was looping. I bumped to 512 just for the hell of it and it's fine now.

I have a good relationship with my VPS provider becasue I monitor for problems and make sure I keep my actual usage well below what the VPSes are set to do. For this, he hooks me up super cheap since I rare occupy more than half of the footprint, and way less in many categories.

CPU exceeds 2% maybe for a few hours every year.
Bandwidth is a fraction of allowed.
I monitor and catch runaway problems before it causes havoc on his server.
I use about 1/3 of the allowed RAM that I'm paying for.
HD footprint is also super tiny...

Trying to get him hooked up with crypto payments.

Be nice to your host, they'll return the favor.

I've noticed that it tends to sit at ~34% of the 512MB I have now. V11 often expanded to fill whatever it could get. Seems to self-regulate RAM occupation better, as previously it only limited itself when it had no choice... 256 would probably do fine, but since it was so cheap, I went with some wiggle room.

Now I can use my VPSes to goof around doing other stuffs.
 
Last edited by a moderator:
So if everything is settled, are we going to have enforcement on? Or are we waiting until September 5th?
 
uugh, I have another problem, saw that pablo was having the same issue, but did not find any fix for it. my local wallet freezes while sync, restarted several times and always the same problem, goes to 100% of synchronizing budgets but crashes then, im on linux and running the.47 :confused:
 
uugh, I have another problem, saw that pablo was having the same issue, but did not find any fix for it. my local wallet freezes while sync, restarted several times and always the same problem, goes to 100% of synchronizing budgets but crashes then, im on linux and running the.47 :confused:
I keep sitting back down at the computer, LOL.

Are your --reindexing each time? Try just restarting.

Awesome, flare , thanks!
 
Back
Top