Topic: [ANN][RIC] Riecoin: constellations POW *CPU* HARD FORK successful, world record - page 121. (Read 685207 times)

With i7-4790K 4400Mhz i have 2ch/s: 74

is it ok?

Yes, of course.

No, I do not have it, possibly if there is enough interest, I can try.
Would the fee around 3% be OK ?

When will the big records, then there will be mention of them.

I'm interested in GPU miner. Do you have?

hmmm.... seems like nobody is interested in this RIC for some time now,
even with the  nice table of the world records here

https://chainz.cryptoid.info/ric/halloffame.dws

(thanks fairglu !)

it is a pitty we do not have more media coverage ...
... btw - anybody interested in GPU miner ?

Does anyone have a node IP for the testnet?  I can't seem to find one anywhere.

I'm trying to develop a client for the parallella board, and having access to testnet would really help

Worldrecord will be broken in the near days.

Got a Rank #2 World Record this morning, 649 digits.

https://chainz.cryptoid.info/ric/halloffame.dws

Difficulty has been slowly creeping up, so it was a "near miss" for Rank #1. Last time difficulty peaked higher (outside super-blocks) was in may, so maybe next week

very nice ! liket it

what about p2pool (distribudetd pool) for riecoin ?

Got a 643 digits, rank #4
Rank #3 also has 643 digits but is almost twice larger (50048... vs 25077...).

still mining regularly with cpu, finally gave in signed up for ypool , Riecoin continues !!
2015 will probably be the year it gets more recognition ,
network is fairly active also in terms of tx, nodes ect..... 
purring like a kitten

Yes, at the top of the explorer (https://chainz.cryptoid.info/ric/), follow the Hall of Fame link

https://chainz.cryptoid.info/ric/halloffame.dws

Next world record should hit the top 10 sometime today

any new world records ? Is there any list available ?

Rolling out an update for the address pages in the explorer

https://chainz.cryptoid.info/ric/

This speeds up loading for address with very large amounts of transactions (ypool's mostly) and adds a couple filters.

Let me know if there are any issues!


@PeaMin it resolves from here (at least in http)

anyone else get:
Cannot resolve 'mine2.ric.nonce-pool.com'. Is it a valid URL?
on the git clone https://github.com/gatra/fastrie.git miner?

I'm all for the records breaking since it indicates to me there is increasing hashpower (miners) between each successive record breaker (3 2 birds with 1 stone). Obviously the data (with frequent updates) for hashpower peak optimization needed for superblock timing would be gathered from the pool that contributed the record breaker as the first tier filter then followed by the second, third, etc.

No prediction pattern can guarantee 100% accuracy but at least it's way better than having unacceptable hashpower (less than 80%) during the superblock event. Taking the drift assumption as reliable means of reaching the peak hashpower of any pool is far more less unpredictable. Inspecting the past few superblock records said it has no decisive & consistent direction.

Superblock   Date      Time      Drift      Drift from Average Time
160848   2014-11-17      19:50      0      -01:25
164880   2014-11-24      20:28      +00:38      -00:47
168912   2014-12-01      22:33      +02:05      +01:18
172944   2014-12-08      21:20      -01:13      +00:05
176976   2014-12-15      22:07      +00:47      +00:52
                     
   Average Time =      21:15            





   

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.


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.


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


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.

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.

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

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.