yes, his work was very helpful for the altcoin community!

good luck with your project!

sorry but if you need a complete rewrite then you're not doing it the right way. If you look at the changes I made in order to adapt the stratum-mining you can see it's not many lines. It's true that the block header has changed so you'll need some rewrite if you didn't plan for that, but it's not that much, any coin that isn't just a btc clone will need some effort. Our stratum code was merged by ahmedbodi in https://github.com/ahmedbodi/stratum-mining, there you can see a version that works for more coins.
If you are developing a mining platform and you open source your code maybe I could help you with riecoin-specific code.

Regards!

I found this dash_hash: https://github.com/dashpay/dash_hash  are you looking for something like this?

If you look here: https://github.com/gatra/stratum-mining
you can find my implementation of the PoW verification. Specifically riecoinPoW in util.py does the math thing after the sha2

Good luck!

great! thanks

Once per week we have a block that has a target of 2hs instead of 2.5mins. So for that block we have a higher difficulty, which was enough to break the record a couple of times. The harder block also has more reward, and for the next blocks after the superblock the reward and target times are a tiny bit smaller than usual. This compensates for the superblock and keeps the average supply and block rates at their originally intended values.

With the new upcoming update I'm hoping to have a new website with all the info put together in a friendlier way.

Thanks  smokim87, you're right. It is fake. I'm the developer of riecoin and the twitter account that I have is https://twitter.com/riecoin
Also I'm the owner of riecoin.org. any other riecoin site is not related to me. Also the code is and have always been at https://github.com/riecoin/riecoin
The site at riecoin.org is down because of DDoS attacks, but I still own the domain and will put the website back online soon.

I'm asking everyone to avoid quoting that original message, and if you do at least redact the fake links like I did here.

Thanks for the info and I'm sorry you had problems at work.

Nice crazy idea might work!
Yes, it would help. I'll think about it because it has its dangers too: if it's low reward then it will not be mined a lot and will have low diff... in general a new algo means a new attack vector. Maybe we could do it with merged mining.

No, I don't want 50%.
If two pools (or one pool and one solo-miner) are fighting for 50% then I want to make a new one and the three would get 33% each.


It's not all well. If it's solo I don't like it either.
Now some miner seems to have 47% and I don't know who it is but I don't like it.

Adding confirmations is a good safety measure but doesn't prevent forks. Neither do changes in the difficulty adjustments.

I was thinking about forbidding reorganizations... so a large alternate chain would be rejected even if it had more work and the network would keep stable, but this solution has the risk of splitting the network.

The other option I considered was checkpointing as in PoS coins, but it's a centralized solution and the checkpointing server could be DDoS'd.

There's no perfect solution. If there are problems again I'm considering investing heavily in mining on an independent well-behaving pool so the chain with most of the miners always wins.

I would like all pools, including yours, to work without problems. I'm just asking all miners to spread the hashes so no pool has more than 50%

Attention miners: please stop using Riepool. It has more than 50% of the hashrate and it's withholding blocks, which is hurting the network. No pool should ever be allowed that much hashrate.
Please switch pools!

There is no problem with the clients or anything to fix in Riecoin Core software. It's the miners who have to take action to avoid ruining the network.

Thank you

I don't understand what it is that you are asking... base32 is just a method for data representation and is not used by the protocol itself so it does not limit how Riecoin or Bitcoin work internally.

http://riecoin.org/faq.html has an explanation of how the primes should be built. The size of the primes is defined by the "difficulty" value and the use of SHA256 does not impose an upper limit.

Hi people,

It is clear that the large reorganisations are caused by riepool having more than 50% "hashrate", but I don't think Simba84 is doing it on purpose.
If his pool node gets isolated from the network but the pool keeps running then when he connects back, his blocks will most likely cause all the blocks from the other miners to get orphaned. If he was "unlucky" and did not generate more work than the rest of the network then HIS blocks will get orphaned that's why he complains that sometimes he has many orphans in a row too.
Simba84, please make sure that ALL your nodes are always connected to the rest of the network, and that your pool is not mining with one or two nodes that are connected between them but isolated to the rest of the network. This should avoid all the orphans seen in the network.
If your nodes are being attacked maybe you can whitelist a couple of good nodes and only let your node connect to those. If it's a problem with the nodes being DDoS'ed then I could generate a new version based on 0.13.1, that's supposed to be more robust.

We have more than 30 nodes, I don't think that just adding more nodes would fix the problems.

I ask all miners to please spread the hashes, change pools or go solo, but don't let any pool (riepool or xpoolx or anyone) have more than 50% of the mining power.


It's unfortunate that we are being attacked by DDoS, but we have to deal with the fact that a CPU coin attracts botnets and botnets are many times used for DDoS attacks. Sometimes I wish we had a GPU miner and the attacks would go away.

Thank you all and best regards,
Gatra

You're right, there have been some reorganizations... no double-spends have been detected but I recommend everyone to wait for more confirmations than usual, just in case.

[citation needed]

please, can you elaborate on this? do you have a link or something? I'd like to know what escapes validation.

I understand that things that it reads from disk are not validated, and only a few last blocks are verified at startup, but they were validated before they were written, so everything gets validated. Doesn't it?

THIS
It's linear, not exponential


you can also fit a quadratic function to your graph
but it's capped by a linear function
segwit may change the slope, but still linear

my prediction: your 5% will start to decrease asymptotically towards 0%

I guess it may be better than a hard fork but it's still worse than a soft work.
It still has the big problem that hard forks have (and soft forks don't): every miner, user, merchant, everyone, would have to update or else they are left behind.
Also, you are forcing everyone to update, but some may not... so some miners may still mine the original chain (they may stop after "phase I" and continue after "phase II") and it may still split.

NO

The size of the blockchain may look exponential if you look from the beginning but it's actually limited by a linear function. It is currently growing as fast as it can so the rate will continue and the size will not grow exponentially.
Current speed is the max speed, and it is about 1MB each 10 minutes. It will not go much faster than this without a change in the protocol (ie a fork)

Yes, there is doubt. PPC still has centralized checkpoints, and even with the checkpoints there is no place where you can short PPC


that could be a good idea: POS rewards would encourage nodes to be online without affecting security (EDIT: for this POS blocks would not count as confirmations)


I don't understand what this means.... executive rights?