Search results

Yeah I think we should learn from this. In hindsight I think it's clear that the last-24h-limit was a bad idea in this case. The intention is good, but should not be combined with a fixed time limit (March 8th in this case) as we are bound to see anomalies in the registrations in the last hours...

Nah, the progress % is over 4% so we need 80% registration, which is very unlikely. Looks like we need to wait another month. Oh well!

I wonder at what time on March 8th the conditions will be evaluated.

Masternodes: 4656 Deterministic: 2775 (59.60%) 24h progress: +94 (2.02%) S15: if 24h progress < 0.63% Last registration: 6 min ago Updated: 06:48:02 UTC It's going to be close! If registrations stop now we'll be under 60% but still have time to sink below the 0.63% limit, though such a...

Like was mentioned here before we are more likely to see a spike in registrations the last 24h than a sudden drop. Yes, it's a bit strange that ppl that rush to register right before the deadline actually postpones the deadline by a month!

From what I understand the logic behind the rules are that we allow a lower total percentage of activated nodes if the registration process slows down. The one thing that seems contradicting is the last entry in the table "80% requires 3.75% or less in last 24h" and the comment "Once we reach...

No, 4% is not less than 1.25% :) Or have I completely misunderstood the rules?

Yes. My point was that the registration rate is stable at around 4%, which is above the 1.25% limit. Looking at the trend it looks unlikely that the rate should drop to below 1.25% before March 8. I'm not worried about making it to the next budget cycle in the beginning of April. That's given...

The registration rate has been pretty constant at 200 / 24h (about 4%) for the last few days, except for some occasional spikes upwards. The rate would have to drastically go up so that we hit 80% total registration, or drop significantly so that we go under the 24h threshold. Both seem unlikely...

:facepalm I mixed up march and may. Time to get some sleep! :D

Dates. May 2nd to May 8th. Yeah, you might be right. In which case we won't make the May 8th target.

Yeah, looks like we manage to hit some kind of worst kind scenario here. Some wild guess on how we progress from here: Time Share Change 2/3 49.0 +4.0 3/3 53.0 +3.0 4/3 56.0 +2.0 5/3 58.0 +1.0 6/3 59.0 +0.5 7/3 59.5 +0.5 8/3 60.0 Looks like we are way more...

I think the point was that the test releases should be labeled beta releases (e.g. beta 1, beta 2 etc) rather than release candidates (rc1, rc2 etc).

I just read about BTCPay, the open Bitpay alternative: http://bitcoinist.com/btcpay-core-developer-better-bitpay/ Support for additional altcoin is just a few days worth. Sounds like something we should look into for dash? Ping @Bradley Zastrow

I guess most MN operators vote identically with all of their MNs. So, we should be able to group all MN IPs that have voted the same on all proposals and hence see how many nodes each MNO have, even though votes are spread out over time. It's no biggie at the moment, but blinded voting may...

Running the old dashman probably put your installation in some state the updated dashman couldn't handle. Running on a clean 0.12.1.5 install (installed by 'dashman install') worked in my case.

Did you run Dashman sync ? The whole process worked for me. No manual step necessary

I noticed that there are some updates to SPORK_8_MASTERNODE_PAYMENT_ENFORCEMENT, which toggles it on and off. Has the purpose of this been explained ? 2017-11-09 09:12:57 SPORK -- hash: 829e447d651103a7806078d08be608bb72f3d3cd351c9b6dd23a445d780da98f id: 10007 value: 4070908800 bestHeight...

The badges were removed some time ago. I tried getting it back by re-entering the information, but no results... ::EDIT Badge is back now. Thanks

Yes. Worked as expected. Note that you need the latest version of dashman