[ANN][RIC] Riecoin: constellations POW *CPU* HARD FORK successful, world record

[gavrilo77]

Eveything fine here.

Code:

<- getblockchaininfo
->
{
"chain" : "main",
"blocks" : 171827,
"bestblockhash" : "693eae39ed2973f52ba4e6c5d2a9998934edcff7e9cb5f7e4974d2f51640818e",
"difficulty" : 1458.00000000,
"verificationprogress" : 0.99997783,
"chainwork" : "18c86ca8cc88a438f3f6071e8a935"
}


<- getpeerinfo
->
{
"addr" : "217.160.16.83:28333",
"services" : "00000001",
"lastsend" : 1417906617,
"lastrecv" : 1417907079,
"bytessent" : 4247,
"bytesrecv" : 92286,
"conntime" : 1417905753,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 171816,
"banscore" : 0,
"syncnode" : true
},
{
"addr" : "54.186.107.237:28333",
"services" : "00000001",
"lastsend" : 1417907081,
"lastrecv" : 1417907078,
"bytessent" : 1848,
"bytesrecv" : 83322,
"conntime" : 1417905859,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 171819,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "66.235.34.181:28333",
"services" : "00000001",
"lastsend" : 1417906617,
"lastrecv" : 1417907080,
"bytessent" : 1282,
"bytesrecv" : 77735,
"conntime" : 1417906011,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 171819,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "92.222.19.210:28333",
"services" : "00000001",
"lastsend" : 1417907079,
"lastrecv" : 1417907078,
"bytessent" : 1995,
"bytesrecv" : 78331,
"conntime" : 1417906117,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 171819,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "24.107.75.17:28333",
"services" : "00000001",
"lastsend" : 1417907078,
"lastrecv" : 1417907079,
"bytessent" : 473,
"bytesrecv" : 76392,
"conntime" : 1417906267,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 171820,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "77.92.201.169:28333",
"services" : "00000001",
"lastsend" : 1417907079,
"lastrecv" : 1417906970,
"bytessent" : 1171,
"bytesrecv" : 75658,
"conntime" : 1417906350,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 171820,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "217.79.67.246:28333",
"services" : "00000001",
"lastsend" : 1417907078,
"lastrecv" : 1417907078,
"bytessent" : 692,
"bytesrecv" : 83206,
"conntime" : 1417906395,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 171820,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "192.241.218.56:28333",
"services" : "00000001",
"lastsend" : 1417907079,
"lastrecv" : 1417906971,
"bytessent" : 631,
"bytesrecv" : 3192,
"conntime" : 1417906545,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 171820,
"banscore" : 0,
"syncnode" : false
}

Still doesn't want to sync.
What nodes you use?

Didn't add any extra nodes since I updated my wallet and nor did it ever failed to sync. Those you see from getpeerinfo should be the nodes my wallet registered with currently (oddly some were not in your list). And the latest getpeerinfo I got are

Code:

<- getpeerinfo
->
{
"addr" : "169.237.10.147:28333",
"services" : "00000001",
"lastsend" : 1417958590,
"lastrecv" : 1417958391,
"bytessent" : 6894,
"bytesrecv" : 85965,
"conntime" : 1417955870,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 172121,
"banscore" : 0,
"syncnode" : true
},
{
"addr" : "92.222.19.210:28333",
"services" : "00000001",
"lastsend" : 1417958590,
"lastrecv" : 1417958389,
"bytessent" : 3231,
"bytesrecv" : 82767,
"conntime" : 1417956073,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 172124,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "67.225.172.77:28333",
"services" : "00000001",
"lastsend" : 1417958591,
"lastrecv" : 1417958389,
"bytessent" : 4785,
"bytesrecv" : 99442,
"conntime" : 1417956074,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 172124,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "71.62.186.166:28333",
"services" : "00000001",
"lastsend" : 1417958389,
"lastrecv" : 1417958590,
"bytessent" : 3425,
"bytesrecv" : 84171,
"conntime" : 1417956119,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 172124,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "66.235.34.181:28333",
"services" : "00000001",
"lastsend" : 1417958590,
"lastrecv" : 1417958590,
"bytessent" : 2790,
"bytesrecv" : 81696,
"conntime" : 1417956142,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 172124,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "213.156.113.59:28333",
"services" : "00000001",
"lastsend" : 1417958590,
"lastrecv" : 1417958389,
"bytessent" : 4074,
"bytesrecv" : 79847,
"conntime" : 1417956187,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 172125,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "217.79.67.246:28333",
"services" : "00000001",
"lastsend" : 1417958593,
"lastrecv" : 1417958389,
"bytessent" : 3214,
"bytesrecv" : 84164,
"conntime" : 1417956474,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 172128,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "2.237.176.215:28333",
"services" : "00000001",
"lastsend" : 1417958590,
"lastrecv" : 1417958392,
"bytessent" : 4507,
"bytesrecv" : 77521,
"conntime" : 1417956585,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 172129,
"banscore" : 0,
"syncnode" : false
}

Still doesn't work. have no idea.

My getpeerinfo:


16:32:24

getpeerinfo


16:32:24

[
{
"addr" : "169.237.10.147:28333",
"addrlocal" : "77.46.171.24:28333",
"services" : "00000001",
"lastsend" : 1417966249,
"lastrecv" : 1417966340,
"bytessent" : 229,
"bytesrecv" : 75558,
"conntime" : 1417966243,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 172184,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "217.160.16.83:28333",
"addrlocal" : "77.46.171.24:28333",
"services" : "00000001",
"lastsend" : 1417966332,
"lastrecv" : 1417966333,
"bytessent" : 1340,
"bytesrecv" : 94234,
"conntime" : 1417966244,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 172184,
"banscore" : 0,
"syncnode" : true
},
{
"addr" : "183.97.21.146:28333",
"services" : "00000001",
"lastsend" : 1417966254,
"lastrecv" : 1417966334,
"bytessent" : 229,
"bytesrecv" : 75608,
"conntime" : 1417966252,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 172184,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "217.233.85.41:28333",
"services" : "00000001",
"lastsend" : 1417966332,
"lastrecv" : 1417966333,
"bytessent" : 351,
"bytesrecv" : 76083,
"conntime" : 1417966253,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 172184,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "67.225.172.77:28333",
"services" : "00000001",
"lastsend" : 1417966332,
"lastrecv" : 1417966333,
"bytessent" : 412,
"bytesrecv" : 76296,
"conntime" : 1417966283,
"pingtime" : 0.00000000,
"version" : 10070001,
"subver" : "/Satoshi:0.10.2/",
"inbound" : false,
"startingheight" : 172184,
"banscore" : 0,
"syncnode" : false
}
]

[1714869603]

1714869603

[1714869603]

1714869603

[1714869603]

1714869603

[Ellieo]

Superblock #172944 found 643 digits without glitch about 3 hours ago (2014-12-08 21:20:39 extracted by YPOOL.net).

2501194353229052557234065325048746914306737394727681347553120236609245482522844 6516648216471266956377389009096452758708388136405635904537267227733444054393293 7566502884928590068353069673390946006829565485855809852057441326900138070112914 4230060467843693301013575887009908378890901529110466636251745199927796005572836 9999680135443439152894648631504046975598637835985836954897093372510222387740808 7646182994869664539286659228846846884105555543834366721146937732828943430528358 4850045696280562856838073839094278844293294595053415183071939410792029178217868 6444789316735211988117727405695238346224114000250443793837228794927871957181613 23540861827

But still, much can be said about the timing of superblock to harness the computation power at its peak. At this rate all the subsequent superblocks might as well be overshadowed by the leading Superblock #164880 654 digits found on 2014-11-24 20:28:12

Progress, planning and far sight (with great view) can only be seem from the top...

[Ellieo]

Superblock #176976 found 647 digits (2014-12-15 22:07:33 extracted by YPOOL.net).

2049675983117467479892102276291689838485263409405451636635295756261574588597274 1624199604001904856593538339492575655711764836876497988902096506494862712005577 1001073076212399247778915899148829002194894493157875843313206471389211843746647 1093361425890884866792603840452869848145959924149418863811796391739014567334625 4468807025500916342374215790824639674261397844949764474426098606908204446631466 9368552608964167904307634700658634040884401676643125983915296995876022291980043 9739178962314751486085592362565919713463526209486834857714279668227751438187062 1229430623521002526080479570090126998962100509074981734254552060403594687973627 450022888361297

A difference by 4 digits from the last superblock. Bearing the irony that latest superblock could had mined at the peak of 7176 instead 5565 miners with new world records well into the easy 7XX - 8XX digits range (and beyond).

What's wrong with you Riecoin Project??? C'mon, Christmas just around the corner...  

[eule]

Instead of focusing on superblocks and world records, how about focusing on merchant adoption and distribution to newbies?  

[gatra]

A difference by 4 digits from the last superblock. Bearing the irony that latest superblock could had mined at the peak of 7176 instead 5565 miners with new world records well into the easy 7XX - 8XX digits range (and beyond).

What's wrong with you Riecoin Project??? C'mon, Christmas just around the corner...  

It doesn't work exactly like that: the amount of hashing power at the moment of the superblock influences how long does it take to find it, but not how many digits will it have. The quantity of digits (the difficulty) is decided based on the hashing power during the interval prior to the superblock. And since the superblock is in the middle of an interval, its number of digits depends on the number of active miners in the interval of 432 to 144 blocks (expected to be 18hs to 6hs) before the superblock. It's the mining during that 12hs period that defines the superblock's difficulty.

Nothing is wrong! it was kinda expected that after the high of the first record, it would become cold... if the record is broken every week it stops being news after 2 or 3 times...

Instead of focusing on superblocks and world records, how about focusing on merchant adoption and distribution to newbies? 

I'm afraid we're not ready for merchant adoption: volume is not that high, and merchants would sell and convert to fiat immediately making the price go down. I see Riecoin as a scientific research project that pays with actual coins (instead of just "fun" like those math projects in BOINC), but it's not yet a currency for everyday use.
Distribution to newbies OTOH is something we need right now.

[eule]

Fair points. 

My idea: a site that lets reddit users redeem their karma for riecoins. Same could be done for bitcointalk/riecointalk too, more activity = more coins. 

[fairglu]

No longer flat-lined!



What is this?

The rewards mini-chart in the explorer inflation chart for Riecoin!
It used to be flat and utterly boring, and is now starting to show some "beat", thanks to the super-blocks.

[gatra]

No longer flat-lined!



What is this?

The rewards mini-chart in the explorer inflation chart for Riecoin!
It used to be flat and utterly boring, and is now starting to show some "beat", thanks to the super-blocks.

beautiful!

[gatra]

Fair points. 

My idea: a site that lets reddit users redeem their karma for riecoins. Same could be done for bitcointalk/riecointalk too, more activity = more coins. 

nice! much better and more effective than a faucet! but they have to mention Riecoin on their posts, otherwise it's not advertising... I'll think about it

[eule]

Glad you like it! I planned to do something like this for dogecoin, but since I also own a few RIC, why not both?

[Ellieo]

A difference by 4 digits from the last superblock. Bearing the irony that latest superblock could had mined at the peak of 7176 instead 5565 miners with new world records well into the easy 7XX - 8XX digits range (and beyond).

What's wrong with you Riecoin Project??? C'mon, Christmas just around the corner...  

It doesn't work exactly like that: the amount of hashing power at the moment of the superblock influences how long does it take to find it, but not how many digits will it have. The quantity of digits (the difficulty) is decided based on the hashing power during the interval prior to the superblock. And since the superblock is in the middle of an interval, its number of digits depends on the number of active miners in the interval of 432 to 144 blocks (expected to be 18hs to 6hs) before the superblock. It's the mining during that 12hs period that defines the superblock's difficulty.

The Riecoin miners demographic at ypool is very much predictable (with 24/7 pattern of single & twin peaks). There's a 24hrs cycle instance that miners seem to rises from 00AM-2AM to 12PM-14PM and then started to decline there onwards; and the cycle repeats (exception for twin-peak over the weekend). As the peak of miners increases (or decreases) for each different cycle so do too the rising and declining rates (for each side of a peak) over the same fixed time period.

If I understood correctly - A superblock could only defines its difficulty based on past interval of hasing power (as connected miners at ypool's demographic) that ranges from 6hrs to 18hrs (2.5mins per block) before and not the future interval (although I'm confused by “And since the superblock is in the middle of an interval”). At present the superblock event took place around 21PM-22PM of ypool's demographic (at declining side of a peak) that gives at best 8hrs of positive rising rate and 10hrs of negative declining rate with net 2hrs of negative declining rate (for the prior 18hrs difficulty justification), and at worse 6hrs of negative declining rate (for the prior 6hrs difficulty justification).

Now let suppose then 18hrs prior to a superblock event at 14PM justifies the difficulty computation it required from 20PM of the day before (with only 4hrs of negative declining rate before rising again around 12AM that gave at least 12hrs of positive rising rate). And, 6hrs prior to a superblock event at 14PM to justifies the difficulty computation it required from 8AM of the same day (with zero hours of declining rate and at least 12hrs of positive rising rate).

From the surface it's seem illogical to favor a difficulty computed from the declining side of a peak. Since the hashing power at that instance (around 21PM-22PM) is already dwindle down to handle the superblock's difficulty (computed from 6hrs-18hrs hashing power prior). My point being what good is the superblock's difficulty to already declining hashing power at that instance.

How do the superblock difficulty adapts to the amount of hours during either positive and/or negative rate as it required for the 18hrs and/or 6hrs prior? What justify the reason for not fixing the superblock on the rising side if not at the peak itself (but instead around 21PM-22PM)?

Nothing is wrong! it was kinda expected that after the high of the first record, it would become cold... if the record is broken every week it stops being news after 2 or 3 times...

Anything that's new will definitely made it into news. The idea with Riecoin Project should be staying in the lead of world records and gauging potential competition from various form of technologies (fairness apply here) - makes them staying out of the news.

Instead of focusing on superblocks and world records, how about focusing on merchant adoption and distribution to newbies? 

I'm afraid we're not ready for merchant adoption: volume is not that high, and merchants would sell and convert to fiat immediately making the price go down. I see Riecoin as a scientific research project that pays with actual coins (instead of just "fun" like those math projects in BOINC), but it's not yet a currency for everyday use.
Distribution to newbies OTOH is something we need right now.

The not yet a currency (or utility) for everyday use has to start soon or later.

[Ellieo]

My old mining protocol does not work anymore thru

Code:

xptMiner.exe -o http://ypool.net -u <username>.<workername> -p <password> -t 4

It seems ypool.net is in the process of remaking that come new mining protocol thru

Code:

xptMiner.exe -o http://mining.ypool.net -u <username>.<workername> -p <password> -t 4

A lot of miners went off due to the new protocol (4696 workers currently). Hopefully they reconnected with a new demographic profile that optimises the superblock difficulty for Riecoin.

[fairglu]

Hopefully they reconnected with a new demographic profile that optimises the superblock difficulty for Riecoin.

Would be nice, but I do not think Riecoin can affect worldwide daylight times... yet

[Ellieo]

Hopefully they reconnected with a new demographic profile that optimises the superblock difficulty for Riecoin.

Would be nice, but I do not think Riecoin can affect worldwide daylight times... yet

One just needs to wonder how & what sort of parameters were used to estimate the first superblock difficulty before it took off. Had I realized the shortfall of the superblocks timing I'd have warned Gatra but correction is still aplenty. It's just a matter of choice, etc.

I don't have the big picture what's going on behind the scene. For that it's better for me refrained from asking questions that have adverse implication and responsibility in the Riecoin Project. I won't be pursuing this matter of optimizing the superblock's difficulty over the demographic at ypool any further. I've made my points clear enough.

To be honest it's tiring to see very attempts to make Riecoin Project worthwhile but only stayed in silence. I hope to see at least one of my suggests (2 were publically announced) came to see the light of day.

[fairglu]

One just needs to wonder how & what sort of parameters were used to estimate the first superblock difficulty before it took off. Had I realized the shortfall of the superblocks timing I'd have warned Gatra but correction is still aplenty. It's just a matter of choice, etc.

The timing is based on block intervals, rather than a set time of day, so the exact time is not set, and will depend on mining power, difficulty adjustement and a bit of random, so day and time will drift over the course of months/years.

First super-block was at 19:50, latest was at 22:07, and we had one at 22:30, so it's not a huge drift, but it's a drift.

So chances are the dry spell will last a few weeks, until we drift to the next peak.

[Ellieo]

One just needs to wonder how & what sort of parameters were used to estimate the first superblock difficulty before it took off. Had I realized the shortfall of the superblocks timing I'd have warned Gatra but correction is still aplenty. It's just a matter of choice, etc.

The timing is based on block intervals, rather than a set time of day, so the exact time is not set, and will depend on mining power, difficulty adjustement and a bit of random, so day and time will drift over the course of months/years.

First super-block was at 19:50, latest was at 22:07, and we had one at 22:30, so it's not a huge drift, but it's a drift.

So chances are the dry spell will last a few weeks, until we drift to the next peak.

The peaks don't drfit. Suffice to said the current superblock made a poor navigator (more stationary than dynamic motion) towards the peaks as its reference. As casues of the blocks drift versus their standard timing were the factors stated then there should be some algorithm placed (perhaps a self correcting drift) to pinpoint the correct timing for superblock at the peak of hashing power.

Since superblock helded as weekly event some database peaks pattern (weekly updated for 1 month of data) built into miners would help guides the drift correction, etc.

Just a thought.

[gatra]

I don't have the big picture what's going on behind the scene. For that it's better for me refrained from asking questions that have adverse implication and responsibility in the Riecoin Project. I won't be pursuing this matter of optimizing the superblock's difficulty over the demographic at ypool any further. I've made my points clear enough

One just needs to wonder how & what sort of parameters were used to estimate the first superblock difficulty before it took off. Had I realized the shortfall of the superblocks timing I'd have warned Gatra but correction is still aplenty. It's just a matter of choice, etc.

The timing is based on block intervals, rather than a set time of day, so the exact time is not set, and will depend on mining power, difficulty adjustement and a bit of random, so day and time will drift over the course of months/years.

First super-block was at 19:50, latest was at 22:07, and we had one at 22:30, so it's not a huge drift, but it's a drift.

So chances are the dry spell will last a few weeks, until we drift to the next peak.

The peaks don't drfit. Suffice to said the current superblock made a poor navigator (more stationary than dynamic motion) towards the peaks as its reference. As casues of the blocks drift versus their standard timing were the factors stated then there should be some algorithm placed (perhaps a self correcting drift) to pinpoint the correct timing for superblock at the peak of hashing power.

Since superblock helded as weekly event some database peaks pattern (weekly updated for 1 month of data) built into miners would help guides the drift correction, etc.

Just a thought.

If some suggestions are not implemented, it's not for lack of will. And some have technical issues that make them undesirable. Instead of refraining from asking questions, I'd like to encourage you to understand the technical details and ask more questions!

Hardcoding patters in the client is a security risk: patterns might change, and attackers could use them to inflate difficulty generating a DoS (long time without transaction processing). Difficulty adjustments should be based on block numbers and relatively large amounts of time, otherwise it would be too erratic. It's not an easy problem, and many others had issues with it (even BTC had an off-by-one bug, and don't get me started on KGW). Also remember that everything is probabilistic, no accurate predictions can be made on how long will a block take. For large sets of blocks it gets more accurate but still you can only get a confidence interval.

And even if we nailed it on the peak every week, we won't have a record each time: in fact it would be very similar to what is happening now (some weeks are record-breakers, some aren't, but all are above the previous record before Riecoin started). The only way to achieve a new record each week is by getting more miners each week.

[fairglu]

Since superblock helded as weekly event some database peaks pattern (weekly updated for 1 month of data) built into miners would help guides the drift correction, etc.

The problem is that database would need to be trust-less as well and fork-proof.

It could be derived from difficulty, if difficulty had faster adjustments, though you would also need to devise a super-block timing algorithm that could not be gamed/abused.

Looking at the time intervals between blocks, the worker variations are reflected so faster difficulty adjustments would likely reflect them as well, but it's nothing as "clean" as the ypool connected workers graphs, so scheduling the superblocks based on that would be difficult.

A human could spot the trend easily, where an algorithm could not however, so it could be possible to inject a human element or "trusted" entity, but then that would affect the trustless aspect and be detrimental to the currency aspect...

I wonder if there could be some trustless way to have humans "synchronize" the superblocks?

Maybe by having users "burn" coins?

Burned coins could be detected by the wallet, and the amount burned could be understood by the code as a "drift adjustment" command.

"Good" RIC owners could help correct the drift that way by burning and "donating to the cause", while "evil & rich" RIC owners could burn to throw it off... it might turn RIC into more of an hybrid social/math game/experiment... hehehehe

[Ellieo]

The database pattern for peak hashpower optimization (with frequent updates) is the first suggestion I regarded as technically related. And I've seem similar problem in the different accredit field of applications adapted very successfully. A few case examples for the light headed: Heuristics patterns found in antivirus, Weather forecasting, Automated trading system, Traffic control, Abstract game engines such as Chess, etc.

And guess what - they are all have some probabilistic elements.

But I admit not all my suggestions were technically as challenging but instead either opinionated by words alone (like here) or silenced until when attention deemed necessary (I can play that game too).

I hate asking questions with no relevant answers, or otherwise presented with counterexamples that could have their own solution unrelated or twisted into different form of misconceptions, etc. And that brings back if the problem presented was understood in the first place. It's mind-boggling how the same problem presented earlier categorized as “nothing is wrong” could later acknowledged to had some valid substance or points. Perhaps that mindset should change with different motivation and environment as in Employer-Employee (carrot & stick metaphor) relationship, higher level of recognition for great achievers as self starter, etc.

Don't call yourself a problem solver (very wide definition here) if you can't tie up the loose ends you created in the first place. Nobody likes hear another vapor passing thru or be interpreted as such.

Again for the second time – what good is getting new miners when the superblock can't even make the full use hashpower at its peak (nevermind the records breaking)? Would you agree improving the odd of finding record breakers by having hashpower used at least by 95% is better than 35% all the time? Or do you prefer the current 35% level to climb up at steady rate to reach the current 95% level sometime later and then ask yourself why is it records breaking is so technically tough?

There you are - questions.

[gatra]

My answers below, having in mind that peak detection is error prone. For ypool it's easy to measure quantity of miners or shares per second. But it's very hard for the network to measure the block rate with fast response time. The measurements done right now take the last 12hs of blocks, meaning it will get the average of the high/low peaks. If you adjust faster, the adjustments get more erratic because variance plays a higher role in the measurements.

what good is getting new miners when the superblock can't even make the full use hashpower at its peak (nevermind the records breaking)?

Getting new miners is always good because it improves the security of the network. The superblock may not always come at the hashrate's peak but it will, eventually. Since it cannot be predicted in time, statistically it should drift until it hits the peaks again.

Would you agree improving the odd of finding record breakers by having hashpower used at least by 95% is better than 35% all the time?

Yes, but if it implies the risk of overestimating hashpower and leaving the network without blocks for a long time, then no. So, no.

Or do you prefer the current 35% level to climb up at steady rate to reach the current 95% level sometime later and then ask yourself why is it records breaking is so technically tough?

Yes, I'd like that because it would mean we have more miners, and when the time of the superblocks drifts to the peaks we would have much larger records.