Thanks for the kind words, Colin.
I've been watching the new difficulty adjustments all week. We even hit diff 100 yesterday. One thing is for sure, if we didn't diff fix it, there would be a massive dump right now on cryptsy. Instead, the coin has gone up 500% since last week, which as you and Git noted could be good or bad (i.e., there still could be a build to a dump).
Right now (at block 50084), the average over the past 100 blocks is 125.13 seconds per block...on average, we're on spec.
Yet, there are many batches of blocks that do fly by. I've copied cryptoexplorer below.
My guesses about a few factors that could be at work:
(A) Any averaging algorithm is still going to have a lag when there are sudden high spikes. Even if more recent blocks are weighted more highly, if the Gigahash jumps by a factor of ten, a diff adjustment based on averages is going to take a few blocks to catch up. But is that what we are seeing here?
Easy example: if the diff adj is based on the average of the past three blocks, and on block 3 the total net hash jumps up by a factor of 10 from the previous two blocks, (1+1+10)/3 = 4: you're still going to be 2.5 lower than where you want to be on the next block. Two blocks in, (1+10+10)/3 = 7, still 30% short of ideal.
(B) Someone knows how to milk KGW in pulses to take advantage of this. A disadvantage to an algorithm without a lot of disclosure of its innards, yet one folks have learned to exploit because of its popularity?
Take a look at blocks 50080 to 50070: prev block takes 14 mins, then, bam, 7 blocks in two minutes (avg = 17s/block), then a 10-minute block, then an HOUR block, then things pick up again. Since there's no easy equation to replicate the approach of KGW, the question to empirically determine is: how many blocks are taken at a sub 2-minute rate vs. normal rate? I did a quick hand tally of the hundred blocks below and about 80% of the blocks are getting solved in under 2 mins, the other 20% take much longer on average. As noted above, though, the overall average of 2mins/block is still conserved.
Perhaps larger pools already know to hit it hard, then leave for a bit, to keep the over-time average on spec? This would basically take advantage of the 270-block weighted average approach of KGW. It adjusts smoothly, so it's flabby in response to short spikes. Faster adjustment might be the solution here.
50084 2014-05-03 07:46:37 1 1 21.686 50084.9849 56.0712 130.415 18.5466%
50083 2014-05-03 07:46:04 1 1 21.301 50083.9849 56.0719 130.414 18.5467%
50082 2014-05-03 07:45:22 3 4.87788862 21.555 50082.9849 56.0726 130.414 18.5469%
50081 2014-05-03 07:41:23 2 4 22.251 50081.9849 56.071 130.411 18.5475%
50080 2014-05-03 07:30:52 2 10.0001 26.724 50080.9849 56.0648 130.404 18.5495%
50079 2014-05-03 06:39:28 1 1 27.565 50079.9849 56.0303 130.368 18.559%
50078 2014-05-03 06:29:52 1 1 27.176 50078.9849 56.0247 130.361 18.5608%
50077 2014-05-03 06:26:38 1 1 26.685 50077.9849 56.0236 130.359 18.5614%
50076 2014-05-03 06:26:34 2 2 26.552 50076.9849 56.0247 130.359 18.5615%
50075 2014-05-03 06:26:02 1 1 26.504 50075.9849 56.0255 130.359 18.5615%
50074 2014-05-03 06:25:51 1 1 25.867 50074.9849 56.0265 130.358 18.5615%
50073 2014-05-03 06:25:19 1 1 24.393 50073.9849 56.0272 130.358 18.5616%
50072 2014-05-03 06:25:13 1 1 24.321 50072.9849 56.0283 130.358 18.5616%
50071 2014-05-03 06:25:07 1 1 24.361 50071.9849 56.0293 130.358 18.5617%
50070 2014-05-03 06:24:23 2 2.46880198 26.036 50070.9849 56.0299 130.357 18.5618%
50069 2014-05-03 06:10:21 1 1 27.023 50069.9849 56.0213 130.348 18.5644%
50068 2014-05-03 06:02:43 4 93.79238899 31.008 50068.9849 56.0172 130.342 18.5658%
50067 2014-05-03 05:35:16 3 6 30.679 50067.9849 56.0124 130.323 18.5517%
50066 2014-05-03 05:30:18 1 1 30.822 50066.9849 56.0101 130.32 18.5526%
50065 2014-05-03 05:28:36 1 1 30.238 50065.9849 56.01 130.319 18.553%
50064 2014-05-03 05:28:23 4 16.53781217 30.263 50064.9849 56.011 130.319 18.553%
50063 2014-05-03 05:22:48 1 1 19.925 50063.9849 56.0087 130.315 18.5534%
50062 2014-05-03 05:22:40 1 1 19.869 50062.9849 56.0097 130.315 18.5534%
50061 2014-05-03 05:22:10 2 1000.999 20.061 50061.9849 56.0105 130.314 18.5535%
50060 2014-05-03 05:18:18 1 1 19.232 50060.9849 57.0023 130.312 17.1096%
50059 2014-05-03 05:17:57 1 1 19.287 50059.9849 57.0033 130.311 17.1097%
50058 2014-05-03 05:18:00 1 1 19.261 50058.9849 57.0044 130.311 17.1097%
50057 2014-05-03 05:17:58 1 1 19.292 50057.9849 57.0055 130.311 17.1097%
50056 2014-05-03 05:17:12 1 1 19.165 50056.9849 57.0061 130.311 17.1098%
50055 2014-05-03 05:16:58 1 1 19.229 50055.9849 57.0071 130.311 17.1099%
50054 2014-05-03 05:16:53 1 1 19.222 50054.9849 57.0082 130.311 17.1099%
50053 2014-05-03 05:16:43 1 1 19.221 50053.9849 57.0092 130.31 17.1099%
50052 2014-05-03 05:16:31 1 1 19.172 50052.9849 57.0102 130.31 17.11%
50051 2014-05-03 05:16:03 2 3.18004085 19.132 50051.9849 57.011 130.31 17.11%
50050 2014-05-03 05:15:49 1 1 19.084 50050.9849 57.012 130.31 17.11%
50049 2014-05-03 05:15:46 1 1 19.179 50049.9849 57.0131 130.31 17.11%
50048 2014-05-03 05:15:41 1 1 19.072 50048.9849 57.0142 130.31 17.11%
50047 2014-05-03 05:15:11 1 1 19.088 50047.9849 57.015 130.309 17.1101%
50046 2014-05-03 05:14:42 1 1 19.09 50046.9849 57.0158 130.309 17.1102%
50045 2014-05-03 05:14:22 1 1 19.042 50045.9849 57.0167 130.309 17.1103%
50044 2014-05-03 05:14:15 1 1 19.036 50044.9849 57.0178 130.309 17.1103%
50043 2014-05-03 05:14:07 1 1 19.02 50043.9849 57.0188 130.309 17.1103%
50042 2014-05-03 05:14:02 1 1 18.998 50042.9849 57.0199 130.309 17.1103%
50041 2014-05-03 05:13:55 1 1 18.972 50041.9849 57.021 130.308 17.1104%
50040 2014-05-03 05:12:18 2 4 19.081 50040.9849 57.021 130.307 17.1106%
50039 2014-05-03 05:10:32 1 1 19.066 50039.9849 57.0209 130.306 17.1109%
50038 2014-05-03 05:10:23 1 1 19.051 50038.9849 57.022 130.306 17.1109%
50037 2014-05-03 05:10:15 1 1 19.044 50037.9849 57.023 130.306 17.111%
50036 2014-05-03 05:10:05 2 2 19.037 50036.9849 57.024 130.306 17.111%
50035 2014-05-03 05:09:57 1 1 19.052 50035.9849 57.0251 130.306 17.111%
50034 2014-05-03 05:09:25 1 1 19.034 50034.9849 57.0259 130.305 17.1111%
50033 2014-05-03 05:09:10 1 1 19.037 50033.9849 57.0268 130.305 17.1112%
50032 2014-05-03 05:08:31 1 1 18.997 50032.9849 57.0275 130.305 17.1113%
50031 2014-05-03 05:08:29 2 47.0005 20.037 50031.9849 57.0286 130.305 17.1113%
50030 2014-05-03 04:54:03 1 1 20.003 50030.9849 57.0199 130.295 17.1135%
50029 2014-05-03 04:53:28 1 1 19.936 50029.9849 57.0206 130.294 17.1136%
50028 2014-05-03 04:53:26 1 1 19.591 50028.9849 57.0218 130.294 17.1136%
50027 2014-05-03 04:53:13 2 2.0001 19.44 50027.9849 57.0228 130.294 17.1136%
50026 2014-05-03 04:52:12 1 1 19.292 50026.9849 57.0232 130.293 17.1138%
50025 2014-05-03 04:51:58 1 1 18.599 50025.9849 57.0242 130.293 17.1139%
50024 2014-05-03 04:51:29 1 1 18.594 50024.9849 57.025 130.293 17.1139%
50023 2014-05-03 04:51:05 1 1 18.582 50023.9849 57.0258 130.293 17.114%
50022 2014-05-03 04:50:54 1 1 18.566 50022.9849 57.0269 130.292 17.114%
50021 2014-05-03 04:50:57 1 1 18.563 50021.9849 57.028 130.293 17.114%
50020 2014-05-03 04:50:36 1 1 18.573 50020.9849 57.0289 130.292 17.1141%
50019 2014-05-03 04:50:08 1 1 18.507 50019.9849 57.0297 130.292 17.1142%
50018 2014-05-03 04:49:09 2 2 18.52 50018.9849 57.0302 130.291 17.1143%
50017 2014-05-03 04:46:58 1 1 18.603 50017.9849 57.0299 130.29 17.1147%
50016 2014-05-03 04:45:24 1 1 18.589 50016.9849 57.0299 130.289 17.1149%
50015 2014-05-03 04:45:18 1 1 18.486 50015.9849 57.031 130.289 17.115%
50014 2014-05-03 04:44:51 1 1 18.469 50014.9849 57.0318 130.288 17.115%
50013 2014-05-03 04:44:45 1 1 18.44 50013.9849 57.0329 130.288 17.115%
50012 2014-05-03 04:44:29 1 1 18.438 50012.9849 57.0338 130.288 17.1151%
50011 2014-05-03 04:44:02 1 1 18.477 50011.9849 57.0347 130.288 17.1152%
50010 2014-05-03 04:42:59 1 1 18.466 50010.9849 57.0351 130.287 17.1154%
50009 2014-05-03 04:42:57 1 1 18.458 50009.9849 57.0362 130.287 17.1154%
50008 2014-05-03 04:42:45 1 1 18.392 50008.9849 57.0372 130.287 17.1154%
50007 2014-05-03 04:41:45 1 1 18.388 50007.9849 57.0376 130.286 17.1156%
50006 2014-05-03 04:41:31 1 1 18.37 50006.9849 57.0386 130.286 17.1156%
50005 2014-05-03 04:41:27 2 2 18.382 50005.9849 57.0397 130.286 17.1156%
50004 2014-05-03 04:37:38 1 1 18.491 50004.9849 57.0382 130.283 17.1162%
50003 2014-05-03 04:32:23 6 37.11075746 18.502 50003.9849 57.0357 130.28 17.1171%
50002 2014-05-03 04:28:35 1 1 18.49 50002.9849 57.0356 130.277 17.1158%
50001 2014-05-03 04:28:26 1 1 18.473 50001.9849 57.0367 130.277 17.1158%
50000 2014-05-03 04:28:22 1 1 18.458 50000.9849 57.0378 130.277 17.1158%
49999 2014-05-03 04:28:14 1 1 18.368 49999.9849 57.0388 130.277 17.1158%
49998 2014-05-03 04:27:24 1 1 18.332 49998.9849 57.0394 130.276 17.116%
49997 2014-05-03 04:27:17 1 1 18.294 49997.9849 57.0404 130.276 17.116%
49996 2014-05-03 04:27:14 1 1 18.35 49996.9849 57.0415 130.276 17.116%
49995 2014-05-03 04:25:55 1 1 18.335 49995.9849 57.0418 130.275 17.1162%
49994 2014-05-03 04:25:49 1 1 18.332 49994.9849 57.0428 130.275 17.1163%
49993 2014-05-03 04:25:08 1 1 18.326 49993.9849 57.0435 130.275 17.1164%
49992 2014-05-03 04:24:38 1 1 18.335 49992.9849 57.0443 130.274 17.1165%
49991 2014-05-03 04:23:54 1 1 18.356 49991.9849 57.0449 130.274 17.1166%
49990 2014-05-03 04:22:56 1 1 18.357 49990.9849 57.0454 130.273 17.1168%
49989 2014-05-03 04:22:03 1 1 18.3 49989.9849 57.0459 130.272 17.1169%
49988 2014-05-03 04:21:50 1 1 18.322 49988.9849 57.0469 130.272 17.1169%
49987 2014-05-03 04:20:51 1 1 18.335 49987.9849 57.0474 130.272 17.1171%
49986 2014-05-03 04:20:07 1 1 18.362 49986.9849 57.048 130.271 17.1172%
49985 2014-05-03 04:17:56 1 1 18.321 49985.9849 57.0476 130.27 17.1176%
Topic: error - page 22. (Read 360507 times)
RPC really needs some novel plans. 
I suspect many miners, like myself, long ago after the first fork knew the difficulty changing every 48 blocks was open to abuse by those with huge hash power, like pools. Hence the miners may have mined something else and now the 2nd fork fixed this, the miners can come back knowing they have a fair chance.
Looking at block 49623 diff 77,54 then block 49624 diff 55.35 then block 49626 diff 16.01. It showed that the difficulty adjustment work rapidly as hash rate falls. Rather than being stuck at a high level for so long as it was before. So that's all good imo.
Ouch. Therein lies the problem as i've mentioned before. Using average is flawed. If the average 2 minutes per block then during higher hash rate coming in, the time it takes to solve a block would go up a bit. Block 49623 17:27:20 then block 49624 17:32:40 - just over 5 minutes to get the next block. While the diff did fall, it seemed that it didn't fall enough as pools would have left by then. Now if it took 5 minutes then i suppose in some way it's good. Thus the 5 minutes is above average and when this continues for a while, there are more blocks being solved above average. Average should move higher up but it doesn't as it if fixed at 2 minutes per block. Hence when the diff go low, the time in takes to get to the next block falls to 2 minutes, the pools will come back in and then mine like hell. Remember the previous blocks were above average hence there has to be a number of blocks mined below average in order to rebalance the average to 2 minutes per block.
This is the reason why i said before that the minimum has to be 2 minutes and no lower. If the difficulty is going down by 11% (i'm not sure), then it is an issue. Block 49626 19:27:14.....2 hours to get 2 blocks. Limiting the diff downwards by a fixed percentage (11% i think) is the cause of the problem.
However on balance it is a lot better than before.
Looking at block 49623 diff 77,54 then block 49624 diff 55.35 then block 49626 diff 16.01. It showed that the difficulty adjustment work rapidly as hash rate falls. Rather than being stuck at a high level for so long as it was before. So that's all good imo.
something is definitely wrong. I just watched 12 blocks go by in 60 seconds.
I contacted Tranz to get his professional opinion and he said the following:
I contacted Tranz to get his professional opinion and he said the following:
Quote from: Tranz
I don't think it's an attack. The timestamps are pretty close. KGW uses 270 blocks(off top of my head) to get the average. So the time to adjust can take a bit. No matter what algo you use, when you triple or more the hash rate that quickly, there is not much that can can be done.
Ouch. Therein lies the problem as i've mentioned before. Using average is flawed. If the average 2 minutes per block then during higher hash rate coming in, the time it takes to solve a block would go up a bit. Block 49623 17:27:20 then block 49624 17:32:40 - just over 5 minutes to get the next block. While the diff did fall, it seemed that it didn't fall enough as pools would have left by then. Now if it took 5 minutes then i suppose in some way it's good. Thus the 5 minutes is above average and when this continues for a while, there are more blocks being solved above average. Average should move higher up but it doesn't as it if fixed at 2 minutes per block. Hence when the diff go low, the time in takes to get to the next block falls to 2 minutes, the pools will come back in and then mine like hell. Remember the previous blocks were above average hence there has to be a number of blocks mined below average in order to rebalance the average to 2 minutes per block.
This is the reason why i said before that the minimum has to be 2 minutes and no lower. If the difficulty is going down by 11% (i'm not sure), then it is an issue. Block 49626 19:27:14.....2 hours to get 2 blocks. Limiting the diff downwards by a fixed percentage (11% i think) is the cause of the problem.
However on balance it is a lot better than before.
Seems it is getting more steady as time goes on. Might just need a bit of time for the difficulty to get steady. There are some coins that have incorporated a block limiter to prevent instamining. I'm not sure if that is the best thing to do. Maybe just give it a bit more time and see how it flushes out.
I suspect many miners, like myself, long ago after the first fork knew the difficulty changing every 48 blocks was open to abuse by those with huge hash power, like pools. Hence the miners may have mined something else and now the 2nd fork fixed this, the miners can come back knowing they have a fair chance.
Looking at block 49623 diff 77,54 then block 49624 diff 55.35 then block 49626 diff 16.01. It showed that the difficulty adjustment work rapidly as hash rate falls. Rather than being stuck at a high level for so long as it was before. So that's all good imo.
Ouch. Therein lies the problem as i've mentioned before. Using average is flawed. If the average 2 minutes per block then during higher hash rate coming in, the time it takes to solve a block would go up a bit. Block 49623 17:27:20 then block 49624 17:32:40 - just over 5 minutes to get the next block. While the diff did fall, it seemed that it didn't fall enough as pools would have left by then. Now if it took 5 minutes then i suppose in some way it's good. Thus the 5 minutes is above average and when this continues for a while, there are more blocks being solved above average. Average should move higher up but it doesn't as it if fixed at 2 minutes per block. Hence when the diff go low, the time in takes to get to the next block falls to 2 minutes, the pools will come back in and then mine like hell. Remember the previous blocks were above average hence there has to be a number of blocks mined below average in order to rebalance the average to 2 minutes per block.
This is the reason why i said before that the minimum has to be 2 minutes and no lower. If the difficulty is going down by 11% (i'm not sure), then it is an issue. Block 49626 19:27:14.....2 hours to get 2 blocks. Limiting the diff downwards by a fixed percentage (11% i think) is the cause of the problem.
However on balance it is a lot better than before.
Looking at block 49623 diff 77,54 then block 49624 diff 55.35 then block 49626 diff 16.01. It showed that the difficulty adjustment work rapidly as hash rate falls. Rather than being stuck at a high level for so long as it was before. So that's all good imo.
something is definitely wrong. I just watched 12 blocks go by in 60 seconds.
I contacted Tranz to get his professional opinion and he said the following:
I contacted Tranz to get his professional opinion and he said the following:
Quote from: Tranz
I don't think it's an attack. The timestamps are pretty close. KGW uses 270 blocks(off top of my head) to get the average. So the time to adjust can take a bit. No matter what algo you use, when you triple or more the hash rate that quickly, there is not much that can can be done.
Ouch. Therein lies the problem as i've mentioned before. Using average is flawed. If the average 2 minutes per block then during higher hash rate coming in, the time it takes to solve a block would go up a bit. Block 49623 17:27:20 then block 49624 17:32:40 - just over 5 minutes to get the next block. While the diff did fall, it seemed that it didn't fall enough as pools would have left by then. Now if it took 5 minutes then i suppose in some way it's good. Thus the 5 minutes is above average and when this continues for a while, there are more blocks being solved above average. Average should move higher up but it doesn't as it if fixed at 2 minutes per block. Hence when the diff go low, the time in takes to get to the next block falls to 2 minutes, the pools will come back in and then mine like hell. Remember the previous blocks were above average hence there has to be a number of blocks mined below average in order to rebalance the average to 2 minutes per block.
This is the reason why i said before that the minimum has to be 2 minutes and no lower. If the difficulty is going down by 11% (i'm not sure), then it is an issue. Block 49626 19:27:14.....2 hours to get 2 blocks. Limiting the diff downwards by a fixed percentage (11% i think) is the cause of the problem.
However on balance it is a lot better than before.
Mulitpool hitting your blockchain?
I think that is what is happening.I thought KGW was supposed to protect against this sort of thing. The hashrate is like a 10x increase and apparently that's more than it can handle(?). I thought KGW could handle up to an 80x increase. Apparently not.
Tranz said no matter what algorithm you use, if you get more than a 3x hashrate increase, you'll have problems.
Multipools strike again.
My personal advice to anyone reading this right now is do not buy RPC right now because I am guessing this mysterious 3 MH/s multipool will be dumping a lot of RPC.
Hashrate is very high atm, I used to mine this at 37 difficulty when it was at its prime... right now its around 90 and keeps increasing
This is correct. It's currently levels of hashrate and difficulty never before reached. But it needs more looking into because of the somewhat fast block times. I need more eyes to dissect this with me, if anyone can help.
-update-
something is definitely wrong. I just watched 12 blocks go by in 60 seconds.
I contacted Tranz to get his professional opinion and he said the following:
Quote from: Tranz
I don't think it's an attack. The timestamps are pretty close. KGW uses 270 blocks(off top of my head) to get the average. So the time to adjust can take a bit. No matter what algo you use, when you triple or more the hash rate that quickly, there is not much that can can be done.
Mulitpool hitting your blockchain?
Hashrate is very high atm, I used to mine this at 37 difficulty when it was at its prime... right now its around 90 and keeps increasing
This is correct. It's currently levels of hashrate and difficulty never before reached. But it needs more looking into because of the somewhat fast block times. I need more eyes to dissect this with me, if anyone can help.
-update-
something is definitely wrong. I just watched 12 blocks go by in 60 seconds.
I contacted Tranz to get his professional opinion and he said the following:
Quote from: Tranz
I don't think it's an attack. The timestamps are pretty close. KGW uses 270 blocks(off top of my head) to get the average. So the time to adjust can take a bit. No matter what algo you use, when you triple or more the hash rate that quickly, there is not much that can can be done.
ProfJski, I really apprecaite your post and you are the one who alerted me to the issues with RonPaulCoin in the beginning. It was partly in due to you that I decided to do another fork and fix this issue. Thank you very much for just being a good "RonPaulCoin citizen".
- - -
Ironically though, something wonky is going on with the network right now. There are HUUUUGEEEE hashrate increases (to 3.7GH/s currently) and difficulty levels are going all over the place. I'm not sure what is going on yet. I'd like to just think this is good news but the blocks are getting mined quickly and then when KGW finally makes the difficulty hit 80+ to compensate, the network seems to come to a crawl for a few hours while the next block is solved. I'm guessing the several hour delay is when the massive hashrate whales are jumping off it, but this is my guess only.
I'm posting my observations as I notice them and I am continuing to look into this. Feel free to offer help or observations if you are good with this sort of thing.
3.7GH/s network hashrate is the most that RonPaulCoin has ever seen in its entire life so that is a good thing. The bad thing is it seems that somehow they are pumping blocks faster than 2 minutes on average.
The size of the "mining whale" just stepped up their game? This happened the moment the value of RPC went up... I do not think that was coincidence.
- - -
Ironically though, something wonky is going on with the network right now. There are HUUUUGEEEE hashrate increases (to 3.7GH/s currently) and difficulty levels are going all over the place. I'm not sure what is going on yet. I'd like to just think this is good news but the blocks are getting mined quickly and then when KGW finally makes the difficulty hit 80+ to compensate, the network seems to come to a crawl for a few hours while the next block is solved. I'm guessing the several hour delay is when the massive hashrate whales are jumping off it, but this is my guess only.
I'm posting my observations as I notice them and I am continuing to look into this. Feel free to offer help or observations if you are good with this sort of thing.
3.7GH/s network hashrate is the most that RonPaulCoin has ever seen in its entire life so that is a good thing. The bad thing is it seems that somehow they are pumping blocks faster than 2 minutes on average.
The size of the "mining whale" just stepped up their game? This happened the moment the value of RPC went up... I do not think that was coincidence.
"Very little volume"? -- I see a few thousand coins transacted during three hours May 1st. Since RPC is 1 coin per block, that's decent volume, 3-4 days worth of coins in a couple hours. Not massive, but decent.
As far as ASICs go, I plan to obtain one, and use it to buy and hold. A smaller ASIC, a few hundred bucks...I won't need return on my money immediately.
Whether ASICs bode well or poorly for the coin is based on the same concern individual miners have: to sell or hold. It's just that fewer people (the ASIC owners) will get a lot more coins. But only an idiot would mine, dump, and ditch if they thought the coin might double (again) in the next week or two. They may sell earlier than a committed coin owner, but whether to dump is still a decision about whether the coin might go up vs. junk crypto that won't hold value for long.
As far as I can tell, things are looking very good right now after the fix. Thanks, ColinIsTheMan, for "fixing the hole in my bag." As a mine-and-hold supporter, my portfolio just doubled in two days. That's a return I can live with
Onward to a link to precious metals! Right now, folks who want to mine-and-sell have only BTC as an outlet. If there was another asset they could obtain, people would sell toward that (gold, silver, copper), and not just to BTC, which lowers RPC/BTC prices. If the coin gains purchasing power for a tangible good, there will be fewer people dumping to BTC. Since RPC-to-BTC-to-USD is usually how the exchange value is established to USD, give them a use for the coin, and you will further stabilize / increase value, since fewer RPC will be sold to BTC.
Best wishes and thanks,
Jski
As far as ASICs go, I plan to obtain one, and use it to buy and hold. A smaller ASIC, a few hundred bucks...I won't need return on my money immediately.
Whether ASICs bode well or poorly for the coin is based on the same concern individual miners have: to sell or hold. It's just that fewer people (the ASIC owners) will get a lot more coins. But only an idiot would mine, dump, and ditch if they thought the coin might double (again) in the next week or two. They may sell earlier than a committed coin owner, but whether to dump is still a decision about whether the coin might go up vs. junk crypto that won't hold value for long.
As far as I can tell, things are looking very good right now after the fix. Thanks, ColinIsTheMan, for "fixing the hole in my bag." As a mine-and-hold supporter, my portfolio just doubled in two days. That's a return I can live with
Onward to a link to precious metals! Right now, folks who want to mine-and-sell have only BTC as an outlet. If there was another asset they could obtain, people would sell toward that (gold, silver, copper), and not just to BTC, which lowers RPC/BTC prices. If the coin gains purchasing power for a tangible good, there will be fewer people dumping to BTC. Since RPC-to-BTC-to-USD is usually how the exchange value is established to USD, give them a use for the coin, and you will further stabilize / increase value, since fewer RPC will be sold to BTC.
Best wishes and thanks,
Jski
Why don't we change the mining algo of RPC like Diamond?
https://bitcointalksearch.org/topic/ann-dmd-diamond-30-scarce-valuable-secure-pos-30-masternodes-65-580725
It maybe the best way to save the coin.
https://bitcointalksearch.org/topic/ann-dmd-diamond-30-scarce-valuable-secure-pos-30-masternodes-65-580725
It maybe the best way to save the coin.
I don't think that is warranted. I do not want to alter the basic properties of this coin because I want it to gain stability. It now has that with the latest update. I plan for that to be the last update.
What advantage does using a different mining algorithm provide (aside from the pure novelty of a new algorithm)?
What do you think what could keep a coin from dying? IMHO it's the people who support this.
What do you think in next few months the normal hobby miners like us will continue to mine this scrypt coin while one ASICs user could kill 1000 from us?
And you think the ASIC miners will mine this coin to keep it ?? They need turn coin back to cash for possible ROI.
I have mined RPC from the start and tried to support it, but now I'm out. Keep whatever you want for the coin and we will see.
Sorry if I sound harsh.
Regards,
RPC going crazy @ cryptsy
RPC up over a 1000% just today
91001 tot 950.000
and still gaining value!!!
been holding for months, will still hold
Just pure pump & dump from some whales. Nothing special.
Very little volume....
RPC added to whattomine.com Enjoy!
Cool Thanks. Will add link to OP and websiteAppreciate it, thank you.
RPC added to whattomine.com Enjoy!
Cool Thanks. Will add link to OP and website
RPC added to whattomine.com Enjoy!
Have to agree that there is no point changing algorithm at this stage. Those who created x11 are just people with huge GPU mining rig and they know that ASIC would make GPU mining unprofitable.
One should wait and see how things pan out before making changes. If it ain't broke, leave it. The previous block difficulty was broken and was fixed. There's no evidences that scrypt algorithm is broken, just pure speculations.
Exactly, I agree completely. In fact, scrypt is proven to be workable and succesful and works great with no flaws. X11 and these other algorithms are newer and perhaps have holes that we don't yet know about. I mean, look at the original release of KGW that everyone copied. After it was tested for a little while, there was an exploit found in it. I'm a fan of sticking with what works. One should wait and see how things pan out before making changes. If it ain't broke, leave it. The previous block difficulty was broken and was fixed. There's no evidences that scrypt algorithm is broken, just pure speculations.
Did those who invested in RPC mistaken this coin for PRC prosper day?
Have to agree that there is no point changing algorithm at this stage. Those who created x11 are just people with huge GPU mining rig and they know that ASIC would make GPU mining unprofitable.
One should wait and see how things pan out before making changes. If it ain't broke, leave it. The previous block difficulty was broken and was fixed. There's no evidences that scrypt algorithm is broken, just pure speculations.
Have to agree that there is no point changing algorithm at this stage. Those who created x11 are just people with huge GPU mining rig and they know that ASIC would make GPU mining unprofitable.
One should wait and see how things pan out before making changes. If it ain't broke, leave it. The previous block difficulty was broken and was fixed. There's no evidences that scrypt algorithm is broken, just pure speculations.
RPC going crazy @ cryptsy
RPC up over a 1000% just today
91001 tot 950.000
and still gaining value!!!
been holding for months, will still hold
RPC going crazy @ cryptsy
RPC up over a 1000% just today
91001 tot 950.000
and still gaining value!!!
Jump to: