Topic: error - page 31. (Read 360507 times)

Well, to me it looks like we are going to need to do a fork to get around the problem described in the last few pages.  I don't think this one is gonna smooth itself out.  As far as what to implement to resolve the problem, I'm not sure.  I encourage people here to continue to discuss #1, is a fork an acceptable option for staging a fix, and #2: what feature(s) shall we implement that will be effective against the abuse we are seeing...  I noticed Digibyte has some kind of new feature to deter certain kinds of abuse. 

 thoughts and ideas?  I think we need to get a plan in place soon; show the community that this coin is NOT going to die.

Very people are in some situation that you. But, if you go in talk, and propose nothing, is useless

well...  what can I say.  I'm watching people lose their faith in this coin like no tomorrow.  I have been buying up hundreds of RPC but this problem we are discussing isn't going away by just talking about it.  It's like a disease to the coin. 

I know you might say you will buy up all RPC that comes up cheap, but that won't fix the fact that it will cause a few interested individuals to hold the coin in massive amounts which is not what we really want. 

I'd like to see this coin nicely distributed amongst thousands of investors, creating a real value like in any healthy market.  As it stands, I own well over 1% of RPC coins, and it's getting to a point where I am not going to invest much more into it without a plan of action.  I don't want to sell it, because RPC means more to me than money; especially if we have a plan to fix this problem that is fairly obviously going to plague the coin until we do something about the abuse. New spotlight coins are coming and going each and every day, and RPC is getting zero attention in a critical moment for crypto currencies.

So...  what's the plan?

Hello, I propose that you vote in cryptorush for the rpc be add.

https://cryptorush.in/index.php?p=vote

If all we make it, it will occurred.  I would like that this has been promoted since of official web and all investors go to for that ocurred.

FYI, I watched the high net hash rate spike this morning, and it took out briefly Chunky's Pool.  I watched as the blocks flew by on block explorer, and noticed that Chunky's pool was stuck on old work, but for a much shorter time (say, 5 mins) than what happened a few weeks ago at Cryptotycoons or Miner's Coop.  Chunky's pool did correctly leap ahead to the then-current block after a short delay, and then fell behind again.  This happened 2-3 times and then the pool went down.  Stratum down, and website down.  Stratum came back up later that morning, and then the website, with a message that they had "backend problems" and that the integrity of the site was safe.

As for hunting down the cause of the problem:

1) Is there a bug in the MPOS software that causes a database problem / code crash when blocks are completed very rapidly?  If Chunky's owner is on this thread, maybe he can give us insight whether this was a code-generated database problem?

2) Could it be a botnet?  The botnet unleashes 100s of Megahashes, and also DDOSes pools: a two-pronged attack to command 51%?  From what I've read (Meni Rosenfeld on stackexchange) the chances of pulling off a 51% attack successfully exponentially decrease the further back in the block chain one seeks to modify transactions, AND exponentially decrease by the difference between the attacker's total net hash bandwidth vs. the rest of the legitimate network (i.e., just over 51% sucks, owning 90% of the total net hash is much more likely to succeed).  Therefore it seems to make sense to want to attack the network in short bursts, while also blowing legitimate pools offline during that time, to try to command as a high a share of total net hash as possible during a short window wherein fraud blocks can be generated.

I am wondering what more learned members think of this hypothesis vs. pods of "whale" hashers pumping and dumping?  The buy wall at 0.0022 BTC/RPC hasn't eroded yet, even though 100 blocks have certainly been mined.  I'm trying to watch for the "dump," if that's what's going on.

Best,
JSki

+1. Great post. More visibility is needed to encourage use of this coin.

Another hard fork may not be worth the effort.  What may serve better is getting the word out, so there is a stable base of regular miners on the coin.  If the net hash rate troughs are higher, the few hundred megahash influx won't make as big a difference.

I'd love to see precious metals merchants sell copper, silver and gold coins for RPC.  I know from the RPC forum, initial investigation is underway.  Get that in place, I'll throw in for some $$ for advertising on FB and colin012 might be able to put an attractive link on the website.  Coin utility and a bigger user base will help stabilization.

Another thing I've been playing with this week is scooping up coins when they are dumped on Cryptsy.  Come join my buy wall at .0022 BTC/RPC!  Since the coin is young, relatively little incoming capitalization goes along way at stabilizing the price, and this again can be achieved by repping the brand.  In present conditions, about $1500 of USD to RPC would create a buy wall at .0022 that would stand for 4 days even if every single new coin mined was dumped in similar high net hash rate spurts that have been happening this week.

If the coin gets its legs under it in terms of demand, a more dedicated community of miners will pursue it, and help stabilize the coin in terms of exchange price and number of regular miners.

Rather than another hard fork, can the devs round up a team to help propel the RPC brand, so we don't remain undistinguished in the field of new alt cryptocurrencies?  If the devs want to make this coin fly, they've got to get more advocates to help them.  There's been several great ideas, but without coordination with the leadership, they remain untried.

Best,
Jski

App is very confusing how to set up and display a price list of faves on one page. You figure It out?

If you have an iPhone, get this app from the App Store: "Space Cash".

You can get it here: http://robertvalmassoi.com/space-cash.html.

It allows you to track RonPaulCoin easily.

(This was not an endorsed message. I found this app by myself)

It's a good idea but I think it would be too drastic of a change for a coin that's already in existence. Also, I do not even know how one would pull that off. It would require new miner software as well as new coin coding for the new algorithm, etc.

Well BIONIC, benefits the scientific community by sharing hashes for the block-chain with hashes for scientific research so that could be an intensive for people to be willing to change over. Also, I could easily make the mining guide and post it on my website.

I've been following a few "CPU only" currencies. There is a lot of incentive to make GPU miners for them, and so people eventually do. The big advantage to changing the coin away from scrypt would be not to eliminate GPU mining, but to remove it from the multipools. Of course, that is also a disadvantage as well since the barrier to entry for miners would be higher unless we had a really excellent guide to start mining under the new miner and a lot of incentive to continue mining.

Today the RPC network hashrate is 72MH....

-edit-  and now almost 500MH again

Today we had 500+MH/s on the network, and now it's down to 150MH/s. This was over a 7 hour period though. Where is the hashrate came from?

Bigsky: I too do not know if changing to 1 block recalculations will completely fix the issue, but I feel it would at least improve it, at least as much as Cryddit said-- maybe more.

The question is how much of an improvement? It is a big task to code, release and request the community to accept a new version, so it would have to be a considerable improvement to do so.

G'day folks,

Seems even talking about change gives miners more interest and confidence

Thanks again Colin for your efforts to solve the problem we are having

My concerns still are about whether the current coding is corrupt of not


Now the otherday when I posted that the huge spikes were not showing
up in the net hash-o-meter, these spikes should have been there for an hour
or so, and we had nearly 100 quick blocks, so they should have shown up
if not then shortly after the attack, and they DID NOT show up at all.

Yesterday during our run over 500MHS were registered on the net meter.

This was probably due to us being number 5 at coinwarz, so this is understandable

So why didnt the previous huge spikes show, how do we know if these pools did the
work required to earn such quick coin.

Now the changing of timestamps was mentioned by cryddit, and thanks for sharing
your tech knowledge, whilst I was watching this attack, in the middle of the action
I noticed that one block took around 5 minutes to solve acccording to huchash,
so I checked it at cyrptexplorer and it that block was still the current block,
but when I checked back later at Cryptexplorer it didnt show this hang, it said the
blocks was solved in five seconds, could someone have altered the timestamps.

Will changing to one block adjustments fix the problem, difficulty could half or double in the hour.

It might fix one problem but may create another,

could it fix this from yesterday with a healthy 250MHs

                2014-03-11 18:41:41   2   1.01387864   11.95   30782   35.0701       
30780   2014-03-11 18:32:06   7   56.06920195   11.95   30781   35.0646   77.8628   
30779   2014-03-11 17:00:43   1   1   11.95   30780   35.0243   77.7993   21.2145%
30778   2014-03-11 17:00:34   1   1   11.95   30779   35.0254   77.7992   21.2146%
30777   2014-03-11 17:00:06   1   1   11.95   30778   35.0262   77.7989   21.2147%
30776   2014-03-11 16:59:55   4   3.8522811   11.9530777   35.0272   77.7988   21.2148%
30775   2014-03-11 16:54:57   2   1.17486815   30776   35.0249   77.7953   21.2164%
30774   2014-03-11 16:54:25   1   1   11.95   30775   35.0257   77.7949   21.2166%
30773   2014-03-11 16:53:10   1   1   11.95   30774   35.0259   77.7941   21.217%
30772   2014-03-11 16:52:37   1   1   11.95   30773   35.0267   77.7937   21.2172%
30771   2014-03-11


from around 20 seconds a block to 1 and a half hours a block in one block with the same difficulty,
would this be caused by the speed of the previous blocks catching up, or the work needed to be
done to complete the block. (the address that found the block seems to find one every 50 or
so, so shouldnt be a 50khs solo miner)

If it was the work that was required to solve the block then my idea of having a time parameter
(say 1 minute minimum to 4 minute maximum or half to double the normal block timing), can not
be considered, but if it is at all technically possible it would solve most of our current issues.

cheers

Just to be clear, because ColinIsTheMan's difficulty adjustment consideration is affected by it:

Does the net hash rate meter:
1) Check the Y number of blocks solved after every X minutes, OR
2) Check the X minutes that have past since the last Y blocks were found?

(1) is subject to fast hoppers, (2) isn't.

Since blocks per second determines change of difficulty, and difficulty in turn affects blocks per second, it looks like we have a differential equation system, no?

This may be really difficult to do, I don't know the source code, but there are some people who have CPU only coins. What if we made RPC CPU only. I would prevent ASICS from doing this whale pod thing. Another thought, what if we implemented BIONIC, I don't know it that well, but from what I understand it involves adding a second algorithm, thus complicating things for both multipools and whale pod miners.

Yeah I guess by demonstrating (on a different, basically dead coin) that I can collect on about 70 blocks before the "net hash rate" even reflects the actual increase in hash rates and especially solved blocks.  Maybe just worth noting when using such information to troubleshoot what's currently happening with RPC (which is definitely not dead  )

Net hash rates are calculated based on the frequency of found blocks, so calculations will require a number of found blocks at a more frequent rate before the net hash rate will update. Given that with normal variance, block finds can happen within seconds or considerably longer than normal, this time period for a rate calculation is typically done over a larger sliding scale in order to provide the best picture of what is actually happening across the network.

It's best to observe over an hour to get a better reading of the network hashrate