|
Strange. The last few posts seem to not understand the difference between ASIC and mulitpool at all.
Scrappy Do:
Nobody has made a single comment about excluding ASICs (that I remember) in the last several pages. In fact we've been supportive of ASICs. Then again, if you want to see 80+% of the algo you bought ASICs for go to multipools and be satisfied with less than 20% to split with other ASIC miners, have at it. My guess is your 1GH will be wasted on MYR as the multipools raid the blocks at low diff.
Zer0Sum:
Go back and read the posts. Nobody here is blaming the current price of MYR on multipools or ASICs. We all know the market's soft. This has been going on for months. Try actually reading the posts that describe the problem.
foodies:
Are you bipolar? First it's not an issue. Then maybe it's an issue. Then we know about it and are working on it. Then it's not an issue again because ASIC EVERYBODY INCLUDE. WTF dude? Nobody here had any intentions of excluding anybody in Scrappy's shoes. Preach full acceptance? Yeah, when multipool's incorporate algo switching and are generating 80% of all blocks on all algos, where will your acceptance level be then? We are trying to point out that if you don't look at this, YOU WILL CAUSE THIS COIN TO EXCLUDE EVERYONE BUT MINE 'N DUMP POOLS.
As someone once told me, sorry for the all caps, but I just feel like you're not getting the point.
|
|
|
|
zoe, phoenix, the fact that I responded to this means we are aware of this problem (although it's not exactly a problem but something specific to all coins with a smaller network hashrate) and we're thinking about the issue. what I posted I genuinely thought was the answer for stopping multipools but as I thought deeper I realized someone could use that to perform a double-spend attack, although I think that can be avoided with prolonguing confirmation from 6 to more blocks.
That's awesome! That's why we pay you the big bucks!  Again, just my point of view, but acknowledging the fact there may be an issue that requires research makes me feel a lot more comfortable about this coin's future. I think you guys have the time and the gray matter to do this right. |
|
|
|
Cut ties with Bryce Weiner or this will end up really bad.
I know nothing about Bryce, or his plans. What I do know is he pumped this coin with grandiose plans and pre-announcement about announcements and then disappeared. Hell, I've seen scam coins announced here with more upfront information. If he's just spitballing ideas, great. Tell us. If he really is working on this other stuff, great. Again, tell us. Until he's a little more forthcoming, there is no reason to give any weight to his meanderings. I really hope colored coins take off on MYR, but that doesn't need Bryce. It needs someone with a motivation and a drive to create and release. |
|
|
|
thanks and i am truly sorry for being an asshole to you.
No worries. I was just as much of a jackass (probably more). |
|
|
|
I've got the perfect anti multipool solution but like I said ass biting to come.
Here it is:
Whenever a surge happens on one algo we add a shitload weighing factor to other algos thus when they find their normally timed block they'll most likely orphan the string of fast submitted blocks belonging to the multipool.
Tadaaa I am now your myrssaiah.
I have no idea on the feasibility, Mr. MYRssaiah, but if something like that worked it would only add to the benefits of multi-PoW. Would be funny as hell to watch all the multipools spend half their time just trying to herd their clients between algos. The question would be which algo you weighted favorably? Or do you weight them all? I like the idea of weighting the weakest, but then you introduce the possibility of pre-determination so that a pool could switch to that algo just as it gets weighted. 99% sure it works. Here's the concept: scrypt diff goes max up (which is 15% or something) for longer than say 5 consecutive blocks + block time is < 30 seconds (per scrypt) + blocks are scrypt blocks triggers the guard dogs program in all other algos meaning all algos receive a getwork with the height being current height minus the number of consecutive scrypt blocks found under the projected timeframe and whichever algo finds the block announces it with the height at which scrypt (or any other algo for that matter) surged up triggering a reorganization since the announcet block outweighs the other blocks thus the announced chain is higher. Oh wait I think you can use this to doublespend later on  ), see ? this is what I meant by things like this comming around to bite us in the arse. Dude, that's the whole point of development and testing!!! Can you imagine if every project just died because nobody was willing to explore updates or upgrades for fear of breaking anything? I'm sorry foodies but this is just a horrible attitude to have. Fear should not control the future of this coin. |
|
|
|
I've got the perfect anti multipool solution but like I said ass biting to come.
Here it is:
Whenever a surge happens on one algo we add a shitload weighing factor to other algos thus when they find their normally timed block they'll most likely orphan the string of fast submitted blocks belonging to the multipool.
Tadaaa I am now your myrssaiah.
I have no idea on the feasibility, Mr. MYRssaiah, but if something like that worked it would only add to the benefits of multi-PoW. Would be funny as hell to watch all the multipools spend half their time just trying to herd their clients between algos. The question would be which algo you weighted favorably? Or do you weight them all? I like the idea of weighting the weakest, but then you introduce the possibility of pre-determination so that a pool could switch to that algo just as it gets weighted. |
|
|
|
<snipping multiquote for foodies!  > The situation is being closely monitored. We are the first coin with a multi-PoW framework so there will be bumps in the road that nobody else has had to go over yet. We need to spend the proper time assessing the situation, gathering data, and providing meaningful responses. This is a perfect response. Thanks to that multi-PoW framework there is time. There should be no rush to implement something, but researching this should be a top priority. I think the concern is that this is being ignored until now. If the devs now consider this worth looking into, I'm sure there are those in the community with the technical skills to help. It's a good thing Myriad was designed with an incredibly fair distribution model (48 weeks of initial block rewards!). We do not need to trip over forwards trying to create a hurried solution. A few days of multipool "rape" means nothing in the long run, it is the creativity, intelligence, and diligence of our decision-making that define it.
Can't agree more. Multi-PoW is awesome, and very under-appreciated IMO. I know iamphoenix brought this up well before the rest of us, and I'm sorry I dismissed his points because I didn't see the bigger picture beyond scrypt (and to be honest, based a little on our previous dispute). If the devs take this seriously enough start the researching/monitoring of how multipool is effecting scrypt now, and can extrapolate that data into some educated estimates of how this may effect MYR once algo-switching multipools come into play, I think many of us would feel much more confident in MYR. Once that is done, and a determination made as to whether a solution is truly needed, there should be time to develop and test something practical with minimal impact. |
|
|
|
To fight multipools we should have our own one!
You fight multipools by focusing your energy on giving people reasons to buy Myriad. Then mutlipools become an afterthought you couldn't believe you spent so much time worrying about. I hate to disagree, but I am 100% against a solution like this. All you end up doing is making profit switching pools desire you even more. This means algo switchers become even more valuable to profit switching pools and are implemented sooner. This means regular miners are squeezed out even sooner. This means all of your work building up the MYR community was ultimately to support profit switching while the community itself slowly slipped away. MYR needs to focus on giving people reasons to buy AND mine. You lose the mining community, and you are left with investors who only care about trading and multipools who only care about BTC. You have nobody left who actually cares about MYR. A resistance feature to multipools would be another selling point for MYR, as well as another innovative solution that could be touted to the world and make others stop and take notice. This would give people reasons to buy MYR AND to mine it. |
|
|
|
The pools don't get cutoff, they decide difficulty has increased enough to change coins and left it to the regular miners. For why that is bad for regular miners, just read SilentBit's post.
The next 15 blocks in the list are the same 3 addresses listed above, with the addition of one more (MQkqCo7Wdr88iM5F6pJjc3x69iEmqiaD7F) grabbing the first and last three of the series. Someone with more time (I need to go back to work), can look at those addresses.
That's what I meant by being cut off, the diff catches up to them and they stop hashing while normal miners continue as usual. Now ask yourself this question: how would the litecoin network react to a 5-10x increase in hashrate and a 5-10x decrease in hashrate as soon as the diff adjusts to the increase. Allow me to answer: their network would freeze up as most of the other coins in existence that have larger networks than myr. But those normal miners continue on with little to show for it. Read SilentBit's post. Regarding LTC, their network is already so much larger that it wouldn't make much difference. Many profit pools have LTC as their low coin. LTC gets hit regularly, and has been for a while. For evidence, just go look at http://wafflepool.com/statsThat's not the point though. The point is a combination of SilentBit's post that explains how normal miners get borked and the fact that profit switching pools are working towards including algo switching. This means that the normal miner will get borked across ALL altos in the future. It was/is interesting to watch on one algo, but across all that would absolutely destroy this coins primary "for all" theme as the normal mine and hold guys get shafted. I feel I'm not getting through to you so I'll say it again: WHAT WOULD HAPPEN TO LITECOIN IF IT HAD OUR SCRYPT HASHRATE AND GET HIT LIKE THAT ? WHAT WOULD HAPPEN TO ANY KNOWN COIN ? IT WOULD GO TO SHIT THAT WOULD HAPPEN, ON OUR COIN IT'S BARELY NOTICEABLE. THAT'S THE POINT. EDIT: sorry for the caps, it's meant to take the point across not as shouting or something else. But that point is incorrect. There are a bunch of new altcoins that get hit by profit switching pools every day. They survive the network hit. What they complain about is loss of value to the miners and investors who want to hold rather than dump for BTC. The networks don't drop (most of the time). If you want to point out the loss of value to the MYR community (everyone that actually acquires MYR rather than mine 'n dump) as being low since there are other algos, that's what I'm warning about. Those other algos will not be free of profit switching pools long. Again, whether or not the network survives is unimportant to this conversation. This is not something unique to MYR. I've seen it on many new altcoins that get hit. The drag is on the pools themselves. They have less resilience to a bump in hashrate than the altcoin chains. This has nothing to do with the concerns raised about MYR and the response to profit switching pools. We are not talking about frozen networks or forked chains. We are talking about loss of value to the coin and the community that supports it in favor mine 'n dump profit switching pools. I'm just trying to understand: Your main concern right now with multipools is that they mine and dump and this creates a loss of value? I want to make a couple points if so: 1) If Myriad had the most perfect difficulty readjustment calculations for dealing with mutlipools, it still does not prevent them from mining and dumping. Nothing can prevent this. 2) Instead of worrying about something we cannot fix (mutlipool dumping) and its perceived negative impact on the day-to-day value of MYR (which is still debatable), why not attack this problem from the other direction? I think we should focus on creating buying demand for Myriad that would offset any multipool effects. Actually, there are two concerns, but I'll address the mine 'n dump first. 1) Correct, there is no way to prevent people from mining and dumping there coins. The difference is the rate at which generated coins are dumped. I would love to see someone figure out how many coins generated on 5/27 (UTC) were dumped that day, that did not come from the two addresses I looked at. This would give us a much better understanding. Someone needs to take this concern seriously and do some detailed research. 2) While any idea to attack this problem is a good start, this would not work. Based on the second concern (again, Silent Bit's post is a very good walk through of how normal miners get squeezed out), all the work we do making MYR more desirable would be in support of the multipools as they would be the ones generating all the coins. Yes, value would increase. Ironically this would make MYR even more desirable to mine 'n dumps, and at the same time make it more difficult for the community to mine. The value of our holdings may go up, but we would end up seeing a net loss as our daily take of coins goes down. This would be another way to kill MYR. While multipools are currently confined to scrypt, now is the perfect time to analyze what overall effects they have on a coin while that coin is still healthy (which I believe MYR is). I don't know what the solution is, but there is time to find one before multipools spread to other algos. I really dread the day that happens if MYR is not prepared. I believe it would be very destructive. |
|
|
|
Just doing some research into an address (MREBM2LWmmxxAF1vYyfoEcpQhZjJ5fQpAQ) that keeps popping up using http://myr.coinpi.pe/ since it will display addresses with large numbers of transaction. On 5/27 (UTC), this address generated 305,000 MYR ( http://pastebin.com/AU2EakQW). Based on a block time of 2:30 (150 seconds), there should be an average of 576 blocks per day (per algo). This one address accounted for 53% of those blocks. At the end of the day, that address held a whopping 13,000 MYR. The rest were sent to M8LtymYa42xrxXmA8yydFcBDzeRhdz9X25. That account currently holds 17,537,005 MYR, and I can only assume is an exchange. This is the address used by Wafflepool, as you can see from the image below (taken from the Wafflepool rolling stats page)...  The referenced hash (6ad7beca9ba28732c598c06f6c40f958fe02e565d39d7d6988f16e82a895b45a) links to a payout to MREBM2LWmmxxAF1vYyfoEcpQhZjJ5fQpAQ. http://myr.coinpi.pe/tx/cb96fe1fc6b4d91631767b3b630b3baaef9d5faad701d2e61de371c83790b881This is ONE profit switching pool grabbing greater than 50% of the expected blocks in a 24 hour period. I did not look to see if blocks were created in greater numbers than expected, although I suspect they may have been based on the overall percentage of scrypt blocks climbing to 21.6%. Looking at a second address from that "burst" of blocks (MQgsHVckUWdELkyHxeQJJ3m7Dfu23ZKkpH) is interesting as well. On 5/27 (UTC), this address generated 160,000 MYR ( http://pastebin.com/jrtdG9Z2). It also dumped most of its coins to a single address (MEuTEpcNfFmMC8msP1t2vhis63rZgfo82f), having a total of 15,000 MYR left at the end of the day. I'm assuming this is also an exchange, as that address has a current balance of 4,403,000 MYR. On these 4 addresses (wafflepool & exchange + suspected profit switching pool & suspected exchange), there are no micropayments (sub reward size) like you would expect to see from a regular pool to miners. We know that one is a profit switching pool, and if we assume the second is as well, that means that 465 of the 576 daily blocks went to profit switching pools. That is almost 81% of scrypt blocks on 5/27 payed out to profit switching pools. That is almost 81% of scrypt blocks on 5/27 dumped the same day. (assuming that each pool carries over an average 10k - 15k daily) I would love to see some more detailed research performed to validate/invalidate my assumptions. Please! Now I can understand the thinking that, "oh, it's just ASIC flooded scrypt and we don't care because we have 3 other GPU algos." That's what I thought originally. But follow it through the next most likely progression. 80% or more of all blocks created by all 4 gpu algos will be generated by profit switching pools that dump everything as soon as they can. Like I said earlier, the folks on the Wafflepool thread are already talking about an algo+profit switching pool. This can't be far away. A solution should be researched NOW, before it spreads. If those of us concerned about this are correct, this coin will soon become nothing but a mine & dump with no one holding but us poor schlubs who believed in the coin. Please, somebody take a look and waylay our fears with analytical data sets, not assumptions or questions. This is a big enough concern that I believe needs to be answered. We need to stay ahead of the curve. Very very interesting research you have done here. This is the type of analysis I love. I'm going to make a record of this, pass it along to a few of the devs to ensure they read it, and start thinking about the problem in depth. One thing to think about: If the multipools on Scrypt didn't exist and those 81% of Scrypt blocks went to the other miners on Scrypt...would they have dumped too? Furthermore, the 305,000 MYR that the multipool mined yesterday in your first address report comes out to be ~0.88 BTC at 300 satoshis. This is a pretty damn mild "dump" that at the very worst puts MYR into the hands of someone who wants them.
Thank you. Someone with a much better crypto background should be able to do a much more in-depth look at this. I'd love to see it. In the hypothetical that the multipools don't exist, I think a much smaller amount of MYR gets dumped on a daily basis, limiting supply and helping to firm up the price floor. How much smaller of an amount? I honestly don't know and any guess on my part would be completely unfounded. I 100% completely agree that right now the "damage" is limited. As SilentBit's post explained, anyone with a GPU mining scrypt should change algos now. Scrypt should be considered dead for GPU miners between ASICs and multipools. To be honest I feel sorry for ASIC owners, as they will get squeezed out by the multipools. Assuming that MYR scrypt is only producing the expected ~576 blocks a day, and only 80% of that goes to multipools, then that is only 16% of the overall blocks generated daily. Thanks to the awesome multi-POW architecture of this coin, the mutlipool threat to MYR has been greatly contained to date. I cannot express enough how awesome this coin design is and how much potential I think it has.Because of that, the devs have time to approach this with a very cautious mindset and not rush into something. Other coins have fallen all over themselves trying to implement KGW badly, or early on in the lifecycle resulting in horrible side effects such as week long + confirm times. Yes there is time enough to avoid those pitfalls. Thankfully. But that window is closing. Now is the time to be researching the issue and spitballing solutions, testing options, brainstorming side effects, etc. Multipools won't be confined to scrypt for long, and if MYR is not ready for it, the resulting "damage" could be disastrous. As far as value damage to the coin, I have no idea. I know Wafflepool started mining MYR on Apr 6 ( first transaction). That second suspected address started Apr 23 ( first transaction). I don't believe the current slump in price is due to profit switching pools (again, thanks to multi-POW), but instead to "slow news, lack of hype" at the moment. To be honest, I'm OK with a floor of 300 while MYR grows and evolves. I'd prefer a floor of 500, but if market cap continues to grow and the community continues to grow, then per coin value will come. All is good. Let's make sure it stays this way. Heck, a resilient and well implemented solution would just be another feather in the cap of MYR devs and another great feature to advertise. |
|
|
|
Just doing some research into an address (MREBM2LWmmxxAF1vYyfoEcpQhZjJ5fQpAQ) that keeps popping up using http://myr.coinpi.pe/ since it will display addresses with large numbers of transaction. On 5/27 (UTC), this address generated 305,000 MYR ( http://pastebin.com/AU2EakQW). Based on a block time of 2:30 (150 seconds), there should be an average of 576 blocks per day (per algo). This one address accounted for 53% of those blocks. At the end of the day, that address held a whopping 13,000 MYR. The rest were sent to M8LtymYa42xrxXmA8yydFcBDzeRhdz9X25. That account currently holds 17,537,005 MYR, and I can only assume is an exchange. This is the address used by Wafflepool, as you can see from the image below (taken from the Wafflepool rolling stats page)... The referenced hash (6ad7beca9ba28732c598c06f6c40f958fe02e565d39d7d6988f16e82a895b45a) links to a payout to MREBM2LWmmxxAF1vYyfoEcpQhZjJ5fQpAQ. http://myr.coinpi.pe/tx/cb96fe1fc6b4d91631767b3b630b3baaef9d5faad701d2e61de371c83790b881This is ONE profit switching pool grabbing greater than 50% of the expected blocks in a 24 hour period. I did not look to see if blocks were created in greater numbers than expected, although I suspect they may have been based on the overall percentage of scrypt blocks climbing to 21.6%. Looking at a second address from that "burst" of blocks (MQgsHVckUWdELkyHxeQJJ3m7Dfu23ZKkpH) is interesting as well. On 5/27 (UTC), this address generated 160,000 MYR ( http://pastebin.com/jrtdG9Z2). It also dumped most of its coins to a single address (MEuTEpcNfFmMC8msP1t2vhis63rZgfo82f), having a total of 15,000 MYR left at the end of the day. I'm assuming this is also an exchange, as that address has a current balance of 4,403,000 MYR. On these 4 addresses (wafflepool & exchange + suspected profit switching pool & suspected exchange), there are no micropayments (sub reward size) like you would expect to see from a regular pool to miners. We know that one is a profit switching pool, and if we assume the second is as well, that means that 465 of the 576 daily blocks went to profit switching pools. That is almost 81% of scrypt blocks on 5/27 payed out to profit switching pools. That is almost 81% of scrypt blocks on 5/27 dumped the same day. (assuming that each pool carries over an average 10k - 15k daily) I would love to see some more detailed research performed to validate/invalidate my assumptions. Please! Now I can understand the thinking that, "oh, it's just ASIC flooded scrypt and we don't care because we have 3 other GPU algos." That's what I thought originally. But follow it through the next most likely progression. 80% or more of all blocks created by all 4 gpu algos will be generated by profit switching pools that dump everything as soon as they can. Like I said earlier, the folks on the Wafflepool thread are already talking about an algo+profit switching pool. This can't be far away. A solution should be researched NOW, before it spreads. If those of us concerned about this are correct, this coin will soon become nothing but a mine & dump with no one holding but us poor schlubs who believed in the coin. Please, somebody take a look and waylay our fears with analytical data sets, not assumptions or questions. This is a big enough concern that I believe needs to be answered. We need to stay ahead of the curve. |
|
|
|
Guys, I see I'm clearly not the only one that thinks there is a problem to be addressed. Thanks to all those that quoted me previously. But the question and subsequent discussion as served its only purpose: we're still ahead of thinking this through and come up with a solution. I fell happy we're getting there, as those that have been trying for a while should. The good news is : at this point, it's still possible to tackle this in code, with new routines to control diff re-targeting and counteract the potential pernicious value damaging impacts of multipools or any other future operation that has the power to cause massive fluctuations on hashrate The bad news is: myr is already taking a tool on value, in part, from that  Technically, I can't tell a pig's tail from a crypto algo, so I'm completely and utterly useless to the coding part , but I'm quite good at tackling problems using different approaches, so here's my idea.
Attention: this might be the dumbest/stupidest idea ever in crypto or might just become a genious one. AFAIK, there's a 50% chance either way, so please be gentle on how you land the fallback/feedback on me, I'm a gentle soul  IDEA: Would it be possible to implement a time constrained reward system, where the amount of coin generated by the block depends on how much time it took from the the 1st confirmation of the previous block and it's own 1st check? This way, no matter how many blocks were mined, the reward would be the same on a time basis. Multipools woudn't be a problem, because if they find 10 blocks in one minute they will get the same reward from those 10 blocks as the small pool that only found 1 block in the same amount of time. In fact, this would probably remove the multipools altogether (coin not profitable when compared to others, never gets selected) or keep them on the coin forever (coin is very stable because price/availability is a function of time spent finding blocks and not hashrates used) Is this feasible? Interesting idea, but I have no idea how feasible that is. It really shouldn't be that hard logically, something simple like...if (seconds since last scrypt block < 142) then reward = (seconds since last scrypt block) * 7; else reward = 1000. No idea is something like that is actually doable, or what it may break down the line. Interesting to think about though. |
|
|
|
The pools don't get cutoff, they decide difficulty has increased enough to change coins and left it to the regular miners. For why that is bad for regular miners, just read SilentBit's post.
The next 15 blocks in the list are the same 3 addresses listed above, with the addition of one more (MQkqCo7Wdr88iM5F6pJjc3x69iEmqiaD7F) grabbing the first and last three of the series. Someone with more time (I need to go back to work), can look at those addresses.
That's what I meant by being cut off, the diff catches up to them and they stop hashing while normal miners continue as usual. Now ask yourself this question: how would the litecoin network react to a 5-10x increase in hashrate and a 5-10x decrease in hashrate as soon as the diff adjusts to the increase. Allow me to answer: their network would freeze up as most of the other coins in existence that have larger networks than myr. But those normal miners continue on with little to show for it. Read SilentBit's post. Regarding LTC, their network is already so much larger that it wouldn't make much difference. Many profit pools have LTC as their low coin. LTC gets hit regularly, and has been for a while. For evidence, just go look at http://wafflepool.com/statsThat's not the point though. The point is a combination of SilentBit's post that explains how normal miners get borked and the fact that profit switching pools are working towards including algo switching. This means that the normal miner will get borked across ALL altos in the future. It was/is interesting to watch on one algo, but across all that would absolutely destroy this coins primary "for all" theme as the normal mine and hold guys get shafted. I feel I'm not getting through to you so I'll say it again: WHAT WOULD HAPPEN TO LITECOIN IF IT HAD OUR SCRYPT HASHRATE AND GET HIT LIKE THAT ? WHAT WOULD HAPPEN TO ANY KNOWN COIN ? IT WOULD GO TO SHIT THAT WOULD HAPPEN, ON OUR COIN IT'S BARELY NOTICEABLE. THAT'S THE POINT. EDIT: sorry for the caps, it's meant to take the point across not as shouting or something else. But that point is incorrect. There are a bunch of new altcoins that get hit by profit switching pools every day. They survive the network hit. What they complain about is loss of value to the miners and investors who want to hold rather than dump for BTC. The networks don't drop (most of the time). If you want to point out the loss of value to the MYR community (everyone that actually acquires MYR rather than mine 'n dump) as being low since there are other algos, that's what I'm warning about. Those other algos will not be free of profit switching pools long. Again, whether or not the network survives is unimportant to this conversation. This is not something unique to MYR. I've seen it on many new altcoins that get hit. The drag is on the pools themselves. They have less resilience to a bump in hashrate than the altcoin chains. This has nothing to do with the concerns raised about MYR and the response to profit switching pools. We are not talking about frozen networks or forked chains. We are talking about loss of value to the coin and the community that supports it in favor mine 'n dump profit switching pools. |
|
|
|
The pools don't get cutoff, they decide difficulty has increased enough to change coins and left it to the regular miners. For why that is bad for regular miners, just read SilentBit's post.
The next 15 blocks in the list are the same 3 addresses listed above, with the addition of one more (MQkqCo7Wdr88iM5F6pJjc3x69iEmqiaD7F) grabbing the first and last three of the series. Someone with more time (I need to go back to work), can look at those addresses.
That's what I meant by being cut off, the diff catches up to them and they stop hashing while normal miners continue as usual. Now ask yourself this question: how would the litecoin network react to a 5-10x increase in hashrate and a 5-10x decrease in hashrate as soon as the diff adjusts to the increase. Allow me to answer: their network would freeze up as most of the other coins in existence that have larger networks than myr. But those normal miners continue on with little to show for it. Read SilentBit's post. Regarding LTC, their network is already so much larger that it wouldn't make much difference. Many profit pools have LTC as their low coin. LTC gets hit regularly, and has been for a while. For evidence, just go look at http://wafflepool.com/statsThat's not the point though. The point is a combination of SilentBit's post that explains how normal miners get borked and the fact that profit switching pools are working towards including algo switching. This means that the normal miner will get borked across ALL altos in the future. It was/is interesting to watch on one algo, but across all that would absolutely destroy this coins primary "for all" theme as the normal mine and hold guys get shafted. |
|
|
|
Here's the scoop with the Scrypt "multipool rape" everyone is talking about, as I see it.
1) The "memory kernal" of the difficulty calculations is 10 blocks, meaning only the hashrate over the last 10 blocks solved by Scrypt impact the present difficulty.
2) If a Scrypt multipool hops on and solves 5 blocks in a row on Scrypt (where SHA256d, Skein, Myr-Groestl, and Qubit have NOT found any blocks in this span), and it solves these 5 blocks in perhaps 1 minute (~12 seconds per block), does it jump off immediately or does it stay on longer?
A) If it jumps off immediately, the multipool only obtained 5000 MYR before the difficulty catches up, which doesn't seem like a hefty payout to the miners on the multipool.
B) If the multipools stay on longer, the difficulty catches up and everyone, including the multipool, is mining on a fair playing field again with a difficulty that accurately represents the current network hashrate at that time.
3) Once the multipool jumps off, the remaining Scrypt miners may experience longer times between solved blocks, but by the time they solve 6, 7, 8, etc.. the difficulty should be relatively close to what its value at the 10th block is, meaning the negative impact of the multipool is mostly eradicated before that 10th block is solved.
4) Let's quickly think about the state of Scrypt hash vs. difficulty right after a multipool jumps off: 1 algo (in this case, Scrypt) should normally find 10 blocks (the "memory kernal" of Myriad) in about 25 minutes (2.5 mins b/w blocks).
My question is: Once we see a run of 5 Scrypt blocks in a row (evidence of multipool), how long does it take for Scrypt to find its next 10 blocks right after this run? If it's ~30 minutes then the multipools's negative impact on Scrypt miners is almost negligible. If it's ~1-2hours, then this is certainly a negative impact placed on the non-multipool Scrypt miners. In this 1-2 hour time (IF this is the case), all the other algos are finding blocks at their normal rate and the miners on Scrypt are at a disadvantage until they catch up by finding their 10th block.
I think it would be very interesting if someone can write a program that analyzes the blockchain in this fashion to assess the "damage" done by multipools in a quantifiable manner. Basically: After a run of 5 or more Scrypt blocks is observed, how long does it take Scrypt to find its next 10 blocks? There should be multiple instances of 5 or more Scrypt runs all through the blockchain which we can use as different sample sets and compute an average for this multipool "damage".
First off, this is not just an issue of 5 blocks. For example, take this 60 second timeline... 273750 17:39:05 19.297273749 17:38:57 175.583 273748 17:38:54 18.911
273747 17:38:53 18.533
273746 17:38:48 19.274
273745 17:38:46 20.045
273744 17:38:44 20.847
273743 17:38:33 21.681
273742 17:38:21 22.548
273741 17:38:21 23.45273740 17:38:09 1623484.878 273739 17:38:08 24.388There are two NON-scrypt blocks. That's 12 blocks in 60 seconds. 10 from scrypt. In theory, at 150 minutes per algo block time, that means there shouldn't be another scrypt block for almost half an hour (25 minutes). That's not the case. Here is the next 10 minutes on the chain... 273781 17:48:48 26.661273780 17:48:37 1749421.842 273779 17:47:29 152.34 273778 17:48:17 1724929.76 273777 17:46:58 5511.767 273776 17:46:47 158.432 273775 17:46:42 26.128
273774 17:46:08 25.606273773 17:46:04 164.768 273772 17:45:55 528.642 273771 17:45:38 518.069 273770 17:45:25 5401.53 273769 17:45:01 5293.495 273768 17:43:38 25.093
273767 17:43:32 24.592273766 17:43:19 171.358 273765 17:43:18 24.1
273764 17:42:55 23.618
273763 17:42:47 23.145273762 17:42:43 507.708 273761 17:43:02 1690430.263 273760 17:41:48 22.682
273759 17:41:45 22.229
273758 17:41:04 21.784
273757 17:40:59 21.348
273756 17:40:31 20.921273755 17:39:37 5187.622 273754 17:40:57 1656619.519 273753 17:39:38 20.503
273752 17:39:22 20.093
273751 17:39:17 19.691That's another 15 scrypt blocks. There should have been 0 based on the previous 60 second run off. At least it's not a block every 6 seconds like the first minute, but it is still a block every 40 seconds which is still less than a third of the time it is supposed to take. This is not something that should be ignored. This is something the devs should be looking at. Yes, we need a community to help the block grow, but this should be a dev responsibility to investigate. EDIT: At this point, I already consider scrypt as being lost to ASICs, but profit switching pools are a different threat than ASICs and I now see scrypt as being lost to profit switchers. Meaning even ASICs will have a hard time mining scrypt through basic pools. Profit switching pools will likely come after the other algos before ASICs do. For example, there is already planning discussion of this in the Wafflepool thread. Any efforts done with the MMAMAOPMAPA (or whatever it is) will end up supporting the profit switching pools to hit MYR and all the other non-scrypt coins. MYR devs should be proactive about this, not waiting for the community to do the research. This issue (and it is an issue) will not end with scrypt. Since I'm confident enough about what I'm saying I won't even double check before I say it: check the wallet that got the generated 1000 MYR and you'll see a pattern that every ~5 blocks another address gets that MYR meaning the pool gets cut off at some point after about 5 blocks be it 4 or 6 even but it does. The general trend is that it's cut off by a scrypt miner at first and then other algos. Here are the addresses from the 60 seconds above, in order... MREBM2LWmmxxAF1vYyfoEcpQhZjJ5fQpAQ MREBM2LWmmxxAF1vYyfoEcpQhZjJ5fQpAQ MQgsHVckUWdELkyHxeQJJ3m7Dfu23ZKkpH MQ2dXj2wMovF3jdeoDw7mm3Mqrsa2188qY MREBM2LWmmxxAF1vYyfoEcpQhZjJ5fQpAQ MQgsHVckUWdELkyHxeQJJ3m7Dfu23ZKkpH MQgsHVckUWdELkyHxeQJJ3m7Dfu23ZKkpH MQgsHVckUWdELkyHxeQJJ3m7Dfu23ZKkpH MQgsHVckUWdELkyHxeQJJ3m7Dfu23ZKkpH MREBM2LWmmxxAF1vYyfoEcpQhZjJ5fQpAQ Notice that address beginning MREBM? That was the address we pointed out as grabbing all the blocks previously (wafflepool). Now it appears another switching pool is on, address beginning MQgsHV. I posted this screen cap earlier, but here is an example of Wafflepool grabbing 11 blocks in 4 minutes...  The pools don't get cutoff, they decide difficulty has increased enough to change coins and left it to the regular miners. For why that is bad for regular miners, just read SilentBit's post. The next 15 blocks in the list are the same 3 addresses listed above, with the addition of one more (MQkqCo7Wdr88iM5F6pJjc3x69iEmqiaD7F) grabbing the first and last three of the series. Someone with more time (I need to go back to work), can look at those addresses. |
|
|
|
Here's the scoop with the Scrypt "multipool rape" everyone is talking about, as I see it.
1) The "memory kernal" of the difficulty calculations is 10 blocks, meaning only the hashrate over the last 10 blocks solved by Scrypt impact the present difficulty.
2) If a Scrypt multipool hops on and solves 5 blocks in a row on Scrypt (where SHA256d, Skein, Myr-Groestl, and Qubit have NOT found any blocks in this span), and it solves these 5 blocks in perhaps 1 minute (~12 seconds per block), does it jump off immediately or does it stay on longer?
A) If it jumps off immediately, the multipool only obtained 5000 MYR before the difficulty catches up, which doesn't seem like a hefty payout to the miners on the multipool.
B) If the multipools stay on longer, the difficulty catches up and everyone, including the multipool, is mining on a fair playing field again with a difficulty that accurately represents the current network hashrate at that time.
3) Once the multipool jumps off, the remaining Scrypt miners may experience longer times between solved blocks, but by the time they solve 6, 7, 8, etc.. the difficulty should be relatively close to what its value at the 10th block is, meaning the negative impact of the multipool is mostly eradicated before that 10th block is solved.
4) Let's quickly think about the state of Scrypt hash vs. difficulty right after a multipool jumps off: 1 algo (in this case, Scrypt) should normally find 10 blocks (the "memory kernal" of Myriad) in about 25 minutes (2.5 mins b/w blocks).
My question is: Once we see a run of 5 Scrypt blocks in a row (evidence of multipool), how long does it take for Scrypt to find its next 10 blocks right after this run? If it's ~30 minutes then the multipools's negative impact on Scrypt miners is almost negligible. If it's ~1-2hours, then this is certainly a negative impact placed on the non-multipool Scrypt miners. In this 1-2 hour time (IF this is the case), all the other algos are finding blocks at their normal rate and the miners on Scrypt are at a disadvantage until they catch up by finding their 10th block.
I think it would be very interesting if someone can write a program that analyzes the blockchain in this fashion to assess the "damage" done by multipools in a quantifiable manner. Basically: After a run of 5 or more Scrypt blocks is observed, how long does it take Scrypt to find its next 10 blocks? There should be multiple instances of 5 or more Scrypt runs all through the blockchain which we can use as different sample sets and compute an average for this multipool "damage".
First off, this is not just an issue of 5 blocks. For example, take this 60 second timeline... 273750 17:39:05 19.297273749 17:38:57 175.583 273748 17:38:54 18.911
273747 17:38:53 18.533
273746 17:38:48 19.274
273745 17:38:46 20.045
273744 17:38:44 20.847
273743 17:38:33 21.681
273742 17:38:21 22.548
273741 17:38:21 23.45273740 17:38:09 1623484.878 273739 17:38:08 24.388There are two NON-scrypt blocks. That's 12 blocks in 60 seconds. 10 from scrypt. In theory, at 150 minutes per algo block time, that means there shouldn't be another scrypt block for almost half an hour (25 minutes). That's not the case. Here is the next 10 minutes on the chain... 273781 17:48:48 26.661273780 17:48:37 1749421.842 273779 17:47:29 152.34 273778 17:48:17 1724929.76 273777 17:46:58 5511.767 273776 17:46:47 158.432 273775 17:46:42 26.128
273774 17:46:08 25.606273773 17:46:04 164.768 273772 17:45:55 528.642 273771 17:45:38 518.069 273770 17:45:25 5401.53 273769 17:45:01 5293.495 273768 17:43:38 25.093
273767 17:43:32 24.592273766 17:43:19 171.358 273765 17:43:18 24.1
273764 17:42:55 23.618
273763 17:42:47 23.145273762 17:42:43 507.708 273761 17:43:02 1690430.263 273760 17:41:48 22.682
273759 17:41:45 22.229
273758 17:41:04 21.784
273757 17:40:59 21.348
273756 17:40:31 20.921273755 17:39:37 5187.622 273754 17:40:57 1656619.519 273753 17:39:38 20.503
273752 17:39:22 20.093
273751 17:39:17 19.691That's another 15 scrypt blocks. There should have been 0 based on the previous 60 second run off. At least it's not a block every 6 seconds like the first minute, but it is still a block every 40 seconds which is still less than a third of the time it is supposed to take. This is not something that should be ignored. This is something the devs should be looking at. Yes, we need a community to help the block grow, but this should be a dev responsibility to investigate. EDIT: At this point, I already consider scrypt as being lost to ASICs, but profit switching pools are a different threat than ASICs and I now see scrypt as being lost to profit switchers. Meaning even ASICs will have a hard time mining scrypt through basic pools (as SilentBit points out very well). Profit switching pools will likely come after the other algos before ASICs do. For example, there is already planning discussion of this in the Wafflepool thread. Any efforts done with the MMAMAOPMAPA (or whatever it is) will end up supporting the profit switching pools to hit MYR and all the other non-scrypt coins. MYR devs should be proactive about this, not waiting for the community to do the research. This issue (and it is an issue) will not end with scrypt. |
|
|
|
hes got a bid for 40 stakes at 10k nxt each? your shitting me? he wants 1% of the currency... and when someone wants that much they very much intend on getting it! this should drive the price way way up!
not 40 stakes, this are 4 stakes ....!!! 1 full stake are 10 quantity No, it is not. These can be sold in tenths. 1 stake = 1 token = 1,000,000 NEM. 0.1 stake = 0.1 token = 100,000 NEM. so its 4 stakes for 400k nxt? thats unreal!!!! im actually gob smacked! No, it's 40 stakes. EDIT: He's offering 10,000 NXT per "nemstake token". Each token is worth one full stake of 1,000,000 NEM. You can buy or sell these tokens by the tenth (0.1). Every tenth of a token is worth 100,000 NEM. ya wasnt on the AE.. just saw 1000 tokens and thats how many people can claim stakes so coppd it then... top bid is 2 stakes for 36k nxt... this is astonishing! before even a white paper, alpha, logo, client or marketing.. seriously... WOW 1.3 BTC per stake? Yeah, I'm tempted! EDIT: Although if NEM reaches 1/10 the value of NXT, that's 7 BTC. Maybe I'll hold on a little while longer. |
|
|
|
|
Just for example, you can now see an order for 0.1 nemstake tokens with a buy price of 1 NXT.
|
|
|
|
hes got a bid for 40 stakes at 10k nxt each? your shitting me? he wants 1% of the currency... and when someone wants that much they very much intend on getting it! this should drive the price way way up!
not 40 stakes, this are 4 stakes ....!!! 1 full stake are 10 quantity No, it is not. These can be sold in tenths. 1 stake = 1 token = 1,000,000 NEM. 0.1 stake = 0.1 token = 100,000 NEM. so its 4 stakes for 400k nxt? thats unreal!!!! im actually gob smacked! No, it's 40 stakes. EDIT: He's offering 10,000 NXT per "nemstake token". Each token is worth one full stake of 1,000,000 NEM. You can buy or sell these tokens by the tenth (0.1). Every tenth of a token is worth 100,000 NEM. |
|
|
|
hes got a bid for 40 stakes at 10k nxt each? your shitting me? he wants 1% of the currency... and when someone wants that much they very much intend on getting it! this should drive the price way way up!
not 40 stakes, this are 4 stakes ....!!! 1 full stake are 10 quantity No, it is not. These can be sold in tenths. 1 stake = 1 token = 1,000,000 NEM. 0.1 stake = 0.1 token = 100,000 NEM. |
|
|
|
|
Show Posts
