Since we have a majority of them on v0.13, we could theorically force those masternodes that have not updated yet out of payment by activating a spork.
However as i understand it to activate that spork, we will first need to have DIP003 activation (which depends on 80% of mined blocks signaling v0.13 readyness).

Miners support is a bit disappointing so far and gets complicated as it depends on which miners / miningpools (upgraded versus not upgraded) find the blocks, so the whole v0.13 adoption graph fluctuates like crazy when you look at it. The highest has been 50% and its currently at 41%.
Link : http://178.254.23.111/~pub/Dash/Dash_Info.html (v13 Adoption)

It was always my personal opinion that this update would take several months (which could have been expressed a little better by DCG, when they announced this v0.13 upgrade on mainnet).
So in my opinion with regards to timeframe :

Several months to have miners signal with their mined blocks a readyness to v0.13 (this "several months" started 14th of january 2019 by the way and to complicate things : miners only really started to show update progress 10 days after release on mainnet)

1 week to lock-in DIP003
1 week to activate DIP003

A few days to activate sporks like 15 (which bring deterministic masternodes and kicks older protocols from the network) and 16 (Automatic InstantSend).

Miners support is a bit disappointing so far and gets complicated as it depends on which miners / miningpools (upgraded versus not upgraded) find the blocks, so the whole v0.13 adoption graph fluctuates like crazy when you look at it. The highest has been 50% and its currently at 41%.
Link : http://178.254.23.111/~pub/Dash/Dash_Info.html (v13 Adoption)

Click to expand...

A little clarification - as it stands currently, masternodes _would be_ the ones holding up DIP3 activation if there were 80% (or even 100%) miner support. Some of the miner support confusion is related to them only being able to signal for DIP3 when paying out to an upgraded masternode. So even if 100% of miners were upgraded, the average signaling percentage would not exceed the percent of upgraded masternodes (currently around 70%).

The PR referenced above will allow upgraded miners to signal in every block regardless of the masternode version being paid. Once that is active, we will only have to wait for 80% miner support.

This only puts more emphasis in the fact that there needs to be a mechanism to force the matter. As well-meaning as sporks are, the absolute nature of hard forks provides clarity, even if it is barbaric and clumsy.

If miners just don't care, whatcha gonna do?

MasterNodes aren't very masterful if they can't enforcement versioning somehow... 80% is too much. Simple majority presence should allow an enforcible supremacy... It might be a bit more disruptive, but it'd get sh!t done.

I, also, expected this update to take longer, but this is ridiculous...

I suggest that a more heavy-handed authority needs to be exerted by MasterNodes. Whip 'em into compliance by invalidating their blocks. Version has to match the MN version majority or punted. Kinda like a PoSe score for miners, except it's pure Boolean... The miners need to lose some power. As @thephez pointed out, only 70% of MNs are up to date. 40% would have been enough... Well more than needed to force the matter. And it would encourage the remaining MNs to get their butts in gear, too.

I'm not sure this warrants a 0.13.0.1, but it should be considered in the future... Could be stuck here forever, and that budget isn't getting any larger...

This only puts more emphasis in the fact that there needs to be a mechanism to force the matter. As well-meaning as sporks are, the absolute nature of hard forks provides clarity, even if it is barbaric and clumsy.

If miners just don't care, whatcha gonna do?

MasterNodes aren't very masterful if they can't enforcement versioning somehow... 80% is too much. Simple majority presence should allow an enforcible supremacy... It might be a bit more disruptive, but it'd get sh!t done.

I, also, expected this update to take longer, but this is ridiculous...

Click to expand...

Next update will be interesting (v0.13.1) as it seems to be an update more intended for miners-only, so they can signal DIP3 regardles of the readiness of the corresponding masternode.
How fast will miners / mining pools implement this small update ? (which is minor in size / scale but important in progressing our overall v0.13 adoption)

With masternodes we have a reachability problem, where we cant reach enough masternodes to vote on budget proposals (only a small fraction actively participates in our governance system).
With miners we have a reachability problem, where we cant reach miners effectively to have them update their software in a timely manner.
Both problems dont seem to have simple solutions.

Next update will be interesting (v0.13.1) as it seems to be an update more intended for miners-only, so they can signal DIP3 regardles of the readiness of the corresponding masternode.
How fast will miners / mining pools implement this small update ? (which is minor in size / scale but important in progressing our overall v0.13 adoption)

With masternodes we have a reachability problem, where we cant reach enough masternodes to vote on budget proposals (only a small fraction actively participates in our governance system).

Click to expand...

For the budget, it less of a reach-ability problem, and more of a "no reason to give a damn" problem. The budget is too narcissistic and defective. It fails to consider that people vote with their feet by simply not participating in DASH anymore, or just ignoring all the silliness that's never based on logic or reason. I nearly forgot the budget system exists. It's a joke. This is why no one participates. It's a self-screening system that assures anyone with a brain simply walks away.

With miners we have a reachability problem, where we cant reach miners effectively to have them update their software in a timely manner.

Click to expand...

Miners have never cared, which is why crude systems like hard forks and hash wars work for them; it's all they can comprehend, it's all they care about.

Since MasterNodes pay more attention, and they're called MasterNodes because they're supposed to be the master of something; they needed to be given authority. Pay attention, get with the program, or lose out. You're damn right people will complain; good! Flog them until they quit, or stop being lazy and entitled. It inspire a race to update. You'll get in a fast loop for payments the sooner you do it, as all the lazy bums are kicked offline.

As for miners, you simply won't get paid if you refuse to upgrade. Burning a bunch of electricity, winning a block, and having it rejected would certainly wake the sh!ts up and encourage an upgrade...

Absolute supremacy. You do, indeed, have the ability to reach more MNs than Miners. Look at the current percentage. MasterNodes == majority of a given protocol/version combo nullifies all blocks that don't match that protocol/version number.

Sporks are still used to enable given features and changes.

If your blocks are being punted, this motivates you to upgrade. If your MN PoSe Score is dirt, and you don't get paid anymore, this motivates you to upgrade. This is why I said voting needs to be mandatory. You have to at least pay enough attention to say that you abstain. Allowing both MNs and Miners to make money while paying no attention at all, and being completely uninformed... Well, that's exactly what you get. No one is even aware this is happening. No reason to care. You WILL vote on at least 5 proposals every cycle, even if it's to say that you abstain, or you don't get paid. I told you this would happen. Here we are.

Patiently waiting for people to do X, when they not only lack any incentive to do so, but also lack any incentive to give damn what happens to DASH... That's not a model you can depend on.
Too much Snowflake, not enough Manhood. You gotta grow a pair. If even DASH doesn't care about DASH, why should anyone else? You guys gotta grow a pair...

MNs are paying attention a lot more than miners. Given the state of goofy versions/protocols on the network, supremacy can be dictated by less than 50%. This may change a bit as deterministic enables, etc. encourage less sloppy behavior. Instead of 51% hashpower determining top block, MNs can.

Miners plug in and forget. Punt their blocks and they'll be a lot ore than reachable... They'll be all over the forum whining and complaining how it's not fair to stop paying them even though they are the ones not living up to Proof of Service. See what I did there? Proof of Service needs to be applied to Miners. MNs can do it. Get on the right version/protocol, or kiss your payouts and ROI goodbye.
Pay attention and do your job properly, or you don't get paid. Incentivized. MasterNodes aren't very Master-y if they cede this to the Miners. It the Miners are still the boss, MasterNodes aren't MasterNodes; they're BitchBoyNodes.

You've got handle the savages with a heavy hand. They don't respond to timid requests. DASH has had a chronic problem of a severe lack of Testicular Fortitude... This project has been overwhelmed by politically correct soy/cuckery, and there's no toxic masculinity at all...

I suspect DCG reason for not getting tougher on miners, is that it could increase the risk of our network accidentally forking.
I do like the idea of having some sort of Proof of Service for miners, as long as that does not give an increased risk to our network.

I suspect DCG reason for not getting tougher on miners, is that it could increase the risk of our network accidentally forking.
I do like the idea of having some sort of Proof of Service for miners, as long as that does not give an increased risk to our network.

Well, we never had the situation that our miners never upgraded and i'm not convinced we are in that situation now.
Miners / miningpools (not all of them but some) are just notoriously slow at upgrading most of the time.

I saw that spike, too. It's drawing back down tho... Seems to be anomalous.

Currently in a nosedive at 45%...

Just a lucky series of blocks from miners who had upgraded, going back to the usual...

Click to expand...

Lets see if v0.13.1 (miners-only update) once officially announced, will bring more stability to that chart.....
Since upgraded miners can then signal readyness for v0.13 with each block, regardless if a masternode has upgraded or not.
The current 26% of the masternodes not yet upgraded, could be interfering with that signaling right now (at least thats the impression i get).

14.0 progress is continuing without interruption so there is not a reason from the development side to force full 13.0 activation

I certainly don't want things to drag on like they did with 12.3, but so far the weekly signalling % has been climbing on a relatively constant slope. It seems reasonable that upgrades would happen at different rates particularly with parties that have a lot at stake (i.e. income) like miners.

Also, this is par for the course in a decentralized system - there isn't a dictator to enforce compliance. Disrupting established consensus rules to speed up a software update seems like a dangerous approach because it shifts the balance of power. Centralization "solves" these problems by removing influence over consensus from stakeholders (masternodes, miners, etc.) and concentrating it. At the end of the day, every miner or masternode has just as much of a right to upgrade or not upgrade as every other one. Which is the beauty and frustration of decentralization.

You're making excuses. DASH has a non-centralized way to handle this but fails to do so.

It shouldn't take 6 weeks. It shouldn't take 4 weeks. It shouldn't take 2 weeks.

Yes, it shifts the balance of power; to the new place where it belongs; MasterNodes.

Again, you're pushing adoption away. Vendors don't want a network that goes wonky for weeks or months at a time during upgrades. They want it to happen quickly. It inspires the opposite of confidence when you can't get Miners and MNs to even pay attention to their own network. It's like the influence this has on the key people who might use DASH is not even a consideration...

What if 7-eleven's payment system went down for 2 months, and the provider didn't care?

They'd have something else before the end of day one, it would never last 2 months.

When they watch it happen, they don't get on board in the first place.

The continuing observation from vendors about DASH is "They just plain don't get it. They don't listen and they don't care."

You're making excuses. DASH has a non-centralized way to handle this but fails to do so.

It shouldn't take 6 weeks. It shouldn't take 4 weeks. It shouldn't take 2 weeks.

Click to expand...

Fxing internet, the age of instant gratification What if DCG group took a fit of madness and released a AML/KYC-friendly everything-tracking client? Taking time over upgrade decisions might not be a bad thing.

I made a post before concerning a similar manner which didn't get much response so i'll repeat my thoughts here since the audience is more relevant now.

Could we perhaps incentivize miners to update by temporarily increasing their block reward percentage from 45% to some higher figure for the first X amount of blocks in a new software version? Its a simple solution but perhaps miners would hop at the chance to upgrade and mine blocks on the upgraded version if we did things that way

I made a post before concerning a similar manner which didn't get much response so i'll repeat my thoughts here since the audience is more relevant now.

Could we perhaps incentivize miners to update by temporarily increasing their block reward percentage from 45% to some higher figure for the first X amount of blocks in a new software version? Its a simple solution but perhaps miners would hop at the chance to upgrade and mine blocks on the upgraded version if we did things that way

Moderator

Yup, small sample size + variance. I don't even look at the 1h moving average line

Click to expand...

I think there's something wonky though always with the last data point on that chart, it's like the data points on the 1-hour before that are smoothed over with larger samples but the last one is always spiking up or down every time you refresh.

Dash Core TeamModerator

I think there's something wonky though always with the last data point on that chart, it's like the data points on the 1-hour before that are smoothed over with larger samples but the last one is always spiking up or down every time you refresh.

Click to expand...

It's the small sample size plus the chart updating each 30mins - and not each hour. This makes the 1h datapoint jitter up and down during the hour.

1h MA --> last 23 blocks --> 1 block is +/- 4.5% So if we have a streak of 4 non-signalled blocks the datapoint will be 13.5% lower than the one before.

24h MA --> last 554 blocks --> 1 block is +/- 0.18% So if the have a streak of 4 non-signalled blocks the datapoint will be just 0.5% lower.

Anyway: All large pools are on v0.13.0+ now, totalling 92% of hashrate. So if we get updated masternodes > 88% DIP3 can lock in: 0.92 x 0.88 = 81%

Yes, I too believe in flogging bad actors. However you can’t consider someone who hasn’t upgraded a bad actor per se. They are not trying to game the system and are still playing by the network rules for all intents and purposes.

And yes, while larger testicles are always nice, I suppose I proposed said carrot because said stick hasn’t been effective from what I’m gathering from your perspective. Isn’t a carrot why masternodes and miners participate in the ecosystem to begin with?

A miner/masternode will eventually upgrade to avoid missing payment because the rest of the miners/masternodes have upgraded before them, hence the stick. But if we wish to incentivize the jumpstart of said upgrade, the carrot needs to be there.

So far I believe that carrot has been only the speculative value an upgraded network brings. However, it very unfortunately hasn’t been a strong enough motivator, which is why I propose a direct financial one. As a MN owner I currently have no incentive to upgrade early, rather to upgrade only before it’s too late, which is the problem right now from what I gather.

Personally, if upgrading early meant I could get paid 2x/3x/5x more (hypothetically) in a given timeframe because I acted quicker than others and in turn was in a smaller/more frequent payment queue, as opposed to missing payments because I didn’t act quick enough, my ass is gonna upgrade ASAP (same with miners and a hypothetical temporary higher block reward). Greed and positive reenforcement is simply a stronger motivator in my opinion.

A carrot gets me to willingly move, a stick makes me only want to keep up with any movement.

I agree with most of what you have to say, but stroking each other is not productive, so I'll reply to the part I find contentious.

Negligence is acting in bad faith. Even if it's a lack of acting. It's the same failure mode as never voting. These are key service functions that don't result in PoSe scoring. Why? There absolutely must be a penalty for gross neglect/negligence, but there isn't. DASH cannot accept that from it's MNOs and Miners. People need to be forced to at the very least pay attention and prove they're alive... If you expect other people, say, vendors, to take the network seriously, but the project itself doesn't take the condition of the network seriously... Just one more thing that puts off potential vendors.

You're right, carrot us better. But, if the carrot isn't worth chasing, and it's clearly not or we'd have lock DIP3 a month ago... DASH's carrot isn't working. If DASH can't offer a better carrot, it needs to use stick. Why bother inventing the concept of PoSe score if you only use it on crap that doesn't matter anyway? These details, voting and upgrading, are maximum important, but neither incentive nor penalty exists.

The short queue carrot used to exist in the early days of MasterNodes. It worked very well. It was eliminated because people complained that they didn't get paid when they didn't upgrade... A very weak move, and we now see the consequences.