[ANN][XMY] Myriad | Multi-Algo, Fair, Secure

[neuroMode]

I've been talking about this with Mr_burdell on IRC. It seems to not be a pressing issue to him. The multipools have yet to ever fork Myriad (praise be to multi-PoW).

The only issue I see is that the brief period after we see 5 block runs by multipools--the next 10 blocks. If these next 10 blocks are taking way longer than 25 minutes to solve by the normal ecosystem of miners without multipools, then it's unfair to them. But as each block is solved, the difficulty adjustment goes down faster and faster until it stabilizes completely after 10 blocks.

Yeah, forking isn't an issue due to multi-algo, but neuro, the rest IS
The pool I'm in, mining with scrypt, hasn't found a block in almost 10 hours!!!  
As a miner, I'm totally wasting my resources as I'll get zilch myr for them ...
It doesn't matter if I can switch to other algos, because this simply says that I must move into another coin that I can mine in a profitable way and, maybe, use the proceeds to by myr (assuming I have the necessary hw; yes,I'm using asics to mine scrypt)

Personally, I don't see this outcome as positive for myr  

To put it simply, I really think myr's developers should start discussing changing the code to be more multipool resilient (notice the word : resilient, not resistant )

Multipools are part of the ecosystem and have their role to play, but we need to better get along with them ... and have ways to avoid such impacts.

The current diff calculation algo is probably one of the best in existence. I don't think there is a better diff calculation method that can protect you when your hashrate is under 1GH and a 5-10-20 GH multipool jumps on you. I think the diff retargeting is coping very very well with such attacks where other coins would fork sideways or get stuck at some absurd diff height.

Is there compiled list of all difficulty calculation algorithms? Is there any way to assess which one works best?

For SilentBit: How many miners are on your pool? Is it a good size of the Scrypt hashrate or is it a small pool? Just because your pool doesn't find a block in 10 hours does not mean other Scrypt miners are not finding blocks.

[neuroMode]

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".

[instantskeleton]

Hey guys, I am new to this coin but have been around earthcoin for a while, a member of the earthcoin community launched a commerce site months back called earthazaar.com, Silver and gold ounces have been sold there for earthcoin. Now the owner is opening the floor to BTC, LTC, and DOGE. I sent him a message telling him about the myriad community and that he should accept myr. check out this link. https://earthazaar.com/earthazaar-now-accepts-several-digital-currencies-for-payments/   
If the Dev of MYR, or members are interested in having myriad accepted at earthazzar.com send him an email.  community members can buy and sell items on this site aswell.

[Rainer4256]

Hey guys, I am new to this coin but have been around earthcoin for a while, a member of the earthcoin community launched a commerce site months back called earthazaar.com, Silver and gold ounces have been sold there for earthcoin. Now the owner is opening the floor to BTC, LTC, and DOGE. I sent him a message telling him about the myriad community and that he should accept myr. check out this link. https://earthazaar.com/earthazaar-now-accepts-several-digital-currencies-for-payments/   
If the Dev of MYR, or members are interested in having myriad accepted at earthazzar.com send him an email.  community members can buy and sell items on this site aswell.

Sounds interesting. Thank you!

[SlientBit]

Is there compiled list of all difficulty calculation algorithms? Is there any way to assess which one works best?

Don't now, never seen such list or even heard about it. Probably doesn't exist, but it might be a good idea ..

Digishield is praised for handling multipools quite well, but I don't have any real world experience with any coin that uses it and is a multipool target

For SilentBit: How many miners are on your pool? Is it a good size of the Scrypt hashrate or is it a small pool? Just because your pool doesn't find a block in 10 hours does not mean other Scrypt miners are not finding blocks.

Went back there and checked: low hashrate indeed (about 5~6 MH/s), but my point wasn't that. I know that on those 10 hours a lot of blocks were found by scrypt algo and a few more by the other algos. Myr works just fine

The issue I was trying to raise (and maybe I wasn't any good at explain it ) is this:

1) when a multipool of considerable size decides to mine myr, on any algo (although I never heard of multipools on groestl, skein or qubit, so that's about SHA and scrypt only, afaik), it creates a considerable amount of distortion in the coin distribution, because most blocks on that algo will be found by that pool
2) Multipool miners (for the most part) don't really want to mine any of the actual coins, they just want the payout in BTC, DRK, BC or another small set of coins that negotiated with multipools like wafflepool. All those coins get dumped in large proportions and drive the price down
3) all the other miners that aren't in the multipool but are mining the selected algo get a considerable less amount of coin in that period, and that *might* lead them to stop mining myr (at least in that algo)
4) when the multipool leaves, because the price drop itself causes makes myr loose the profitability rank and another coin becomes the target, all that extra hashrate simply disappears, leaving the network with less hashrate that it started with in that algo
5) regular non-multipool miners get back at mining, slowly recovering the hashrate in that algo (although maybe not all that gave up might comeback), trying to recover the less efficient mining period
6) myr recovers (maybe) profitability and  ... bam! it's step 1 all over again

In the end, I'm afraid that this kind of cycle, most of the times, creates a negative/downward trend in the coins' value  But I might be dead wrong, not sure, not clear, to many variables to account for besides the multipool impact

So, if we're able to have a difficulty calculation scheme that enables this kind of impact to be tunned down, it would benefit the ecosystem and myr's value.

Again, all I wanted to say is that maybe it's time that this should be taken into account and analyzed. That's all.

[Zoella]

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.297
273749   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.45
273740   17:38:09   1623484.878
273739   17:38:08   24.388


There 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.661
273780   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.606
273773   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.592
273766   17:43:19   171.358
273765   17:43:18   24.1
273764   17:42:55   23.618
273763   17:42:47   23.145
273762   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.921
273755   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.691

That'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.

[foodies123]

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.297
273749   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.45
273740   17:38:09   1623484.878
273739   17:38:08   24.388


There 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.661
273780   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.606
273773   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.592
273766   17:43:19   171.358
273765   17:43:18   24.1
273764   17:42:55   23.618
273763   17:42:47   23.145
273762   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.921
273755   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.691

That'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.

[jdebunt]

A small new MYR article is up!

http://www.cryptoarticles.com/crypto-news/2014/5/27/myriadcoin-electrum-wallet-beta-android-wallet-beta-available-now#

[cryptapus]

All proceeds from the dice games will currently go towards Myriadcoin development. Play for a good cause!

Addresses, rules, results and proof can be viewed here:

http://cryptap.us/myr/dice/

Since this is currently for charity, the 500 MYR bounty for flaws is rescinded. If you do find a flaw I will gladly refund any lost coins, PM me.

Feedback is welcome.

There is a new game on the dice page, a coinbomb game (also known as "hot potato"). Please let me know if there are any issues.

Another new game has been added to the dice page, a transparent Ponzi game. Invest early to receive 110% of your investment (please read the link in the rules if you seriously do not know what a Ponzi scheme is).

As always, feedback is welcome.

From this week's donated dice, coinbomb, and Ponzi game proceeds (The games are back in positive balance territory):

2274.21274086 MYR donated to the Dev account ( MWShVDmRxWagXcrKHbBSDb2q7EsXxjApA4 ) , txid: 3b4206badd2d6287f375fcdd725db5a68e39d176d65f5683da30fb6ff622e0dd

Keep playing, remember that 90% of proceeds go to MYR development. Play for a good cause!

[Zoella]

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.297
273749   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.45
273740   17:38:09   1623484.878
273739   17:38:08   24.388


There 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.661
273780   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.606
273773   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.592
273766   17:43:19   171.358
273765   17:43:18   24.1
273764   17:42:55   23.618
273763   17:42:47   23.145
273762   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.921
273755   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.691

That'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.

[foodies123]

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.

[mfqrs3]

Android wallet looks great

[Zoella]

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/stats

That'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.

[foodies123]

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/stats

That'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.

[Zoella]

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/stats

That'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.

[evi_stale]

Is there any reason why MYR keeps going down? I bought in a few weeks ago at the peak 

[novag]

Who is sell coin so cheap?

[iamphoenix]

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/stats

That'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.

foodies I hold great respect for you and neuromode but no one has addressed what i have said. The 10 block lookback is futile. Why? Simple...

he reason i was given by mr AHMED was the weighted algo keeps the coin more fair and so on...
-- this is incorrect as now it is less fair then ever.

 ... may have also said that this prevents the coins difficulty from going impossibly high.


FAIR ENOUGH

BUT

that happens anyway

after 10 blocks the diff jumps to the thousands regardless.
---------------------------------------------------------------------------------------

now do you not agree SOMETHING must be done?

-------------------------------------------------------------------------------------------





LET US DISCUSS POSSIBLE SOLUTIONS OR AT THE VERY LEAST THINGS THAT CAN BE DONE / CODE AND OTHERWISE / TO REDUCE THIS
 SERIOUS PROBLEM before let me say this again before it gets out of hand.
25% scrypt algo allocation is where i draw the line.
the ENTIRE chain forking because of 10 blocks mined instantly is where i say goodbye.
--------------------------------------


NOW on to business and brainstorm ideas

------=CODE PROPOSAL
- increase the block time to 5 minutes
- decrease the difficulty retargeting to a 3 block look back

the 2 above can MINIMIZE the damage being done currently until we can attain a higher scrypt hashrate.
------= COMMUNITY PROPOSAL
-we hold a massive community rally for every available miner who has an asic-scrypt or other at their disposal to hash our scrypt algo difficulty up in order to make our injured scrypt algo less apatizing to the hungry multi-pool monsters...

----------------------------
let me be very clear the scrypt multipools have just begun to take advantage of and abuse our scrypt algo.


Coders are not gods of wisdom and foresight... just because one that is held to high esteem is not concerned with this

DOES BY NO MEANS WHATSOEVER

mean that this is not a serious issue that must be addressed with the up most seriousness and severity.

if we can find a solution that is new and innovative this may turn out to be our defining moment.
if not we MUST minimize this issue as much as physically possible.
-------------------------------------------------------------------------------------------

i have tried to bring attention to this issue for so long... I urge you to take me seriously. Now that this has finally .. finally .. become a topic of serious discussion. I may or may not participate for a while as finally I have been heard. I will continue to hold on to every coin I own.

remember this:
25% scrypt algo allocation is where i draw the line.
the ENTIRE chain forking because of 10 blocks mined instantly is where i say goodbye.

god damnit dont fuck this up...........


////////////

addition edit from reddit post

i own a smart car foodies.... the analogy is incorrect fyi.


why not a diff retargeting system that is per block. no lookback. and can either:

A- -- say hashrate is 1ghs and here comes fucking cex.io with 10ghs the diff retarget detects massive surge of hash and A 10 BLOCK LOOK FORWARD! will 1/10th at a time (1ghs per block) allow the increased hash to enter the algorythem with difficulty retargeting accordingly every block

B- --have difficulty per block no lookback and let the difficulty go IMPOSSIBLY HIGH... but wait... after 10 minutes of no block found the difficulty drops incrementally back to normal meanwhile the multipool has lost interest as it has only mined 1 block and moves on to another coin without a fair system in place

how about some more ideas like this or anything. you people are in crypto lets hear ideas and..

NEUROMODE PLEASE DOCUMENT THEM IN A LIST SO WE CAN VOTE LATER ON OR EXPAND ON IDEAS. I will reward you with a 50,000 MYR bounty if you can see this along effectively.
do what is needed to facilitate ideas and innovation document it and continue community discussion within an organized and detailed. that EVENTUALLY finds something really worth implementing which can be a multitude of community action and Code Reform.

only if your interested

 i see no better way. if there is someone else who wants to participate in this bounty i have proposed go for it. but we may need a donation address  once it takes shape in a manner with a high chance of actual code and other implementation I will, 10,000 at a time release the bounty. 8bitcoder may have to agree to this in advance as only he can make the change the community decides

[SlientBit]

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?

[Zoella]

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.