[ANN] [XMG] MAGI | CPU mining | mPoW | mPoS | [MagiPay]

[tazzz013]

Yup,  it going on again.  Really getting old now.


ID    Date    TX Type    Status    Payment Address    TX #    Block #    Amount
321830    2018-04-23 15:33:20    Fee    Orphaned          1774351    0.00295492
321829    2018-04-23 15:33:20    Credit    Orphaned          1774351    0.59098474
321735    2018-04-23 15:33:12    Fee    Orphaned          1774350    0.00360525
321734    2018-04-23 15:33:12    Credit    Orphaned          1774350    0.72104929
321699    2018-04-23 15:20:14    Fee    Orphaned          1774323    0.01407756
321698    2018-04-23 15:20:14    Credit    Orphaned          1774323    2.81551264
321601    2018-04-23 15:20:05    Fee    Orphaned          1774322    0.00500826
321600    2018-04-23 15:20:05    Credit    Orphaned          1774322    1.00165103
321504    2018-04-23 14:38:21    Fee    Orphaned          1774257    0.00271731
321503    2018-04-23 14:38:21    Credit    Orphaned          1774257    0.54346278
321407    2018-04-23 14:25:09    Fee    Orphaned          1774263    0.00439900
321406    2018-04-23 14:25:08    Credit    Orphaned          1774263    0.87979971
321305    2018-04-23 14:20:06    Fee    Orphaned          1774244    0.00306613
321304    2018-04-23 14:20:06    Credit    Orphaned          1774244    0.61322566

[Filkus]

So this is new.  In the last 5 hours, my minting has has a rash of unconfirmable hits.  Five in a row, once an hour, that is new.  I have had bad hits before here or there, but always followed by  good one.  Anyone else having this problem?

[edward0181]

So this is new.  In the last 5 hours, my minting has has a rash of unconfirmable hits.  Five in a row, once an hour, that is new.  I have had bad hits before here or there, but always followed by  good one.  Anyone else having this problem?

No, even though I have a few orphans, most PoS blocks gets accepted.

[earl3000]

So this is new.  In the last 5 hours, my minting has has a rash of unconfirmable hits.  Five in a row, once an hour, that is new.  I have had bad hits before here or there, but always followed by  good one.  Anyone else having this problem?

No, even though I have a few orphans, most PoS blocks gets accepted.

Well the Network Hashrate is again 270+ MH/s so probably a massiv attack, since some miners left/pause some days ago(judging by the nethashrate). (if you can trust the netHash calculations)

[starmman]

So this is new.  In the last 5 hours, my minting has has a rash of unconfirmable hits.  Five in a row, once an hour, that is new.  I have had bad hits before here or there, but always followed by  good one.  Anyone else having this problem?

No, even though I have a few orphans, most PoS blocks gets accepted.

I've had 8 PoS blocks unconfirmed out of 24 so far today, a bit higher than normal

check your blockheight against https://chainz.cryptoid.info/xmg/ to make sure the chain hasn't forked

[tazzz013]

So this is new.  In the last 5 hours, my minting has has a rash of unconfirmable hits.  Five in a row, once an hour, that is new.  I have had bad hits before here or there, but always followed by  good one.  Anyone else having this problem?

No, even though I have a few orphans, most PoS blocks gets accepted.

Well the Network Hashrate is again 270+ MH/s so probably a massiv attack, since some miners left/pause some days ago(judging by the nethashrate). (if you can trust the netHash calculations)

BullMining at 300,019.59 KH/s

[WaifusAreLove]

Before was minerclaim :s

[earl3000]

Yup,  it going on again.  Really getting old now.


ID    Date    TX Type    Status    Payment Address    TX #    Block #    Amount
321830    2018-04-23 15:33:20    Fee    Orphaned          1774351    0.00295492
321829    2018-04-23 15:33:20    Credit    Orphaned          1774351    0.59098474
321735    2018-04-23 15:33:12    Fee    Orphaned          1774350    0.00360525
321734    2018-04-23 15:33:12    Credit    Orphaned          1774350    0.72104929
321699    2018-04-23 15:20:14    Fee    Orphaned          1774323    0.01407756
321698    2018-04-23 15:20:14    Credit    Orphaned          1774323    2.81551264
321601    2018-04-23 15:20:05    Fee    Orphaned          1774322    0.00500826
321600    2018-04-23 15:20:05    Credit    Orphaned          1774322    1.00165103
321504    2018-04-23 14:38:21    Fee    Orphaned          1774257    0.00271731
321503    2018-04-23 14:38:21    Credit    Orphaned          1774257    0.54346278
321407    2018-04-23 14:25:09    Fee    Orphaned          1774263    0.00439900
321406    2018-04-23 14:25:08    Credit    Orphaned          1774263    0.87979971
321305    2018-04-23 14:20:06    Fee    Orphaned          1774244    0.00306613
321304    2018-04-23 14:20:06    Credit    Orphaned          1774244    0.61322566

I checked the Stat pages from some pools around the block 1774146 Orphans starts , difficulty is under 1 and Rewards are around 40. except on m-hash they have the past 2days almost only orphans. (I wonder why the miners stay there)  I think many pools are suffering, the attacker seems to be rotating the pools. Man why do hackers and scammer have to destroy everything new and fun.  

[hemidart]

Yup,  it going on again.  Really getting old now.


ID    Date    TX Type    Status    Payment Address    TX #    Block #    Amount
321830    2018-04-23 15:33:20    Fee    Orphaned          1774351    0.00295492
321829    2018-04-23 15:33:20    Credit    Orphaned          1774351    0.59098474
321735    2018-04-23 15:33:12    Fee    Orphaned          1774350    0.00360525
321734    2018-04-23 15:33:12    Credit    Orphaned          1774350    0.72104929
321699    2018-04-23 15:20:14    Fee    Orphaned          1774323    0.01407756
321698    2018-04-23 15:20:14    Credit    Orphaned          1774323    2.81551264
321601    2018-04-23 15:20:05    Fee    Orphaned          1774322    0.00500826
321600    2018-04-23 15:20:05    Credit    Orphaned          1774322    1.00165103
321504    2018-04-23 14:38:21    Fee    Orphaned          1774257    0.00271731
321503    2018-04-23 14:38:21    Credit    Orphaned          1774257    0.54346278
321407    2018-04-23 14:25:09    Fee    Orphaned          1774263    0.00439900
321406    2018-04-23 14:25:08    Credit    Orphaned          1774263    0.87979971
321305    2018-04-23 14:20:06    Fee    Orphaned          1774244    0.00306613
321304    2018-04-23 14:20:06    Credit    Orphaned          1774244    0.61322566

I checked the Stat pages from some pools around the block 1774146 Orphans starts , difficulty is under 1 and Rewards are around 40. except on m-hash they have the past 2days almost only orphans. (I wonder why the miners stay there)  I think many pools are suffering, the attacker seems to be rotating the pools. Man why do hackers and scammer have to destroy everything new and fun.  

Since there seems to be no consensus around here, or any feedback from a dev, is there any point in continuing to mine XMG?  I can't help the situation with development because I have zero training or experience.  But I am supporting XMG right now by consuming and paying for electricity by mining, so I think that it's reasonable for me to expect at least some kind of answer back from a developer as to whether or not there is a solution being worked on for these attacks.

Is there another coin you would recommend that can be mined with reasonable results by cpu?

Like I said in my prior posts, I don't expect to have any net income from this, but it seems pointless to continue mining XMG with questionable results, unless as you've been investigating, we are farther ahead even with all of the problems.

[earl3000]

Yup,  it going on again.  Really getting old now.


ID    Date    TX Type    Status    Payment Address    TX #    Block #    Amount
321830    2018-04-23 15:33:20    Fee    Orphaned          1774351    0.00295492
321829    2018-04-23 15:33:20    Credit    Orphaned          1774351    0.59098474
321735    2018-04-23 15:33:12    Fee    Orphaned          1774350    0.00360525
321734    2018-04-23 15:33:12    Credit    Orphaned          1774350    0.72104929
321699    2018-04-23 15:20:14    Fee    Orphaned          1774323    0.01407756
321698    2018-04-23 15:20:14    Credit    Orphaned          1774323    2.81551264
321601    2018-04-23 15:20:05    Fee    Orphaned          1774322    0.00500826
321600    2018-04-23 15:20:05    Credit    Orphaned          1774322    1.00165103
321504    2018-04-23 14:38:21    Fee    Orphaned          1774257    0.00271731
321503    2018-04-23 14:38:21    Credit    Orphaned          1774257    0.54346278
321407    2018-04-23 14:25:09    Fee    Orphaned          1774263    0.00439900
321406    2018-04-23 14:25:08    Credit    Orphaned          1774263    0.87979971
321305    2018-04-23 14:20:06    Fee    Orphaned          1774244    0.00306613
321304    2018-04-23 14:20:06    Credit    Orphaned          1774244    0.61322566

I checked the Stat pages from some pools around the block 1774146 Orphans starts , difficulty is under 1 and Rewards are around 40. except on m-hash they have the past 2days almost only orphans. (I wonder why the miners stay there)  I think many pools are suffering, the attacker seems to be rotating the pools. Man why do hackers and scammer have to destroy everything new and fun.  

Since there seems to be no consensus around here, or any feedback from a dev, is there any point in continuing to mine XMG?  I can't help the situation with development because I have zero training or experience.  But I am supporting XMG right now by consuming and paying for electricity by mining, so I think that it's reasonable for me to expect at least some kind of answer back from a developer as to whether or not there is a solution being worked on for these attacks.

Is there another coin you would recommend that can be mined with reasonable results by cpu?

Like I said in my prior posts, I don't expect to have any net income from this, but it seems pointless to continue mining XMG with questionable results, unless as you've been investigating, we are farther ahead even with all of the problems.

Your request is totally reasonable. I hope a fix will be release soon and that the network hashRate will increase again.

[jonathin.r]

Okay, message received. Bad idea, but you want to hear an ever worse one that could possibly work and not require any changes to the current MagiCoin infrastructure?

Hand-approved pool registrations in conjunction with pool-side hashrate limits, where users would need to disclose their estimated hashrate upon registration. That way, if a user goes over their registered hashrate (or if their registered hashrate is exactly the pool limit, then the pool limit), then they will be kicked from the pool. Sure, it adds more work to the pools, but it ensures the fairness of the rest of the miners who are actually following the rules. You could just solo-mine with a botnet, but at least that's less unfair to pool miners because you're not invalidating the blocks of miners who did nothing wrong. You're just lowering the block reward for everyone on the network, which is still unfair.

[DatsunPatrol]

Okay, message received. Bad idea, but you want to hear an ever worse one that could possibly work and not require any changes to the current MagiCoin infrastructure?

Hand-approved pool registrations in conjunction with pool-side hashrate limits, where users would need to disclose their estimated hashrate upon registration. That way, if a user goes over their registered hashrate (or if their registered hashrate is exactly the pool limit, then the pool limit), then they will be kicked from the pool. Sure, it adds more work to the pools, but it ensures the fairness of the rest of the miners who are actually following the rules. You could just solo-mine with a botnet, but at least that's less unfair to pool miners because you're not invalidating the blocks of miners who did nothing wrong. You're just lowering the block reward for everyone on the network, which is still unfair.

Seems fine but how do you get all pools onboard? You can't - and whichever one is the holdout will be the one used for the attacks.

I don't know what the actual solution is though. What is the feasibility of a protocol side upper limit on hashrate for any one mining device?  If that upper limit is a carefully selected value it might solve a lot of problems. But this is probably not that easy to actually implement.

[paul30003]

Okay, message received. Bad idea, but you want to hear an ever worse one that could possibly work and not require any changes to the current MagiCoin infrastructure?

Hand-approved pool registrations in conjunction with pool-side hashrate limits, where users would need to disclose their estimated hashrate upon registration. That way, if a user goes over their registered hashrate (or if their registered hashrate is exactly the pool limit, then the pool limit), then they will be kicked from the pool. Sure, it adds more work to the pools, but it ensures the fairness of the rest of the miners who are actually following the rules. You could just solo-mine with a botnet, but at least that's less unfair to pool miners because you're not invalidating the blocks of miners who did nothing wrong. You're just lowering the block reward for everyone on the network, which is still unfair.

So I've been a programmer for several years now, I am quite fluent in C, but not so much with C++ for the last couple of weeks, I have been going over the Magi code and the m7m algo in the hope I could suggest some ideas and fixes to the dev, problem is without knowing the exact method the attacker is using, its hard to suggest a fix.  How the attacks are happening, I would expect is being kept very secretive as if this information was to make it into the wild, then many crooks would be jumping onboard and hitting the network hard.

Aside from building wallets and custom miner code, I have been looking at starting a pool.

I'm not sure if I will yet, but if I did I would be enforcing strict hash rate limits, a place to answer queries and complaints from pool members.  Email and or support tickets.  One of my biggest problems with mining pools, has been little to no communication or reply from pool owners.

Another feature that I have thought about, could be a weekly random draw with prizes in XMG.  The prize fund would come from 100% of donations.  All who donate would automatically be in the draw.

I have a wealth of experience with running servers, web applications, including CMS portals, databases, forums, live chat, support ticket systems.

If I do go ahead with this, then I will obtain a paid SSL cert from a trusted CA, a reliable dedicated server, rather than a shared VPS.  Low server latency would be key.

Maybe if I got a lot of interest from sub 150Khps miners who are sick of the whales killing the pool rewards, I could get something started.  If mining could be more rewarding for people with lower hashrates, maybe It could give Magi a small boost in popularity and value.

Just thought I would put this idea out there for opinion. 

[tazzz013]

Okay, message received. Bad idea, but you want to hear an ever worse one that could possibly work and not require any changes to the current MagiCoin infrastructure?

Hand-approved pool registrations in conjunction with pool-side hashrate limits, where users would need to disclose their estimated hashrate upon registration. That way, if a user goes over their registered hashrate (or if their registered hashrate is exactly the pool limit, then the pool limit), then they will be kicked from the pool. Sure, it adds more work to the pools, but it ensures the fairness of the rest of the miners who are actually following the rules. You could just solo-mine with a botnet, but at least that's less unfair to pool miners because you're not invalidating the blocks of miners who did nothing wrong. You're just lowering the block reward for everyone on the network, which is still unfair.

Seems fine but how do you get all pools onboard? You can't - and whichever one is the holdout will be the one used for the attacks.

I don't know what the actual solution is though. What is the feasibility of a protocol side upper limit on hashrate for any one mining device?  If that upper limit is a carefully selected value it might solve a lot of problems. But this is probably not that easy to actually implement.

At least we can agree on on thing,  Its need to be fixed sooner than later.

[Jeremy450]

All of this talk is useless/pointless the devs wont do any of this that we are crying/begging/desperately needing for OUR COIN because it decentralizes their idea!!! all of this was all talked about in January its total pointless the devs said it them selves they wont implement any of this 111magic said it himself.

mean while we are being kicked in the balls by big whales like below
http://jemisp.com/screen5.png

[Jeremy450]

they aren't listening or talking about the situation, theres no communication, theres no reinsurance. its all hush hush we have something big happening. Instead of focusing on the problem instead of telling the community they are working on a solution. Actions speak 5 times more then words and so far we are seeing nothing.

almost 4 months of no actions. i'm a software developer if i had my community/clients complaining about an issues i would of dam fixed it already. That way i know they would have faith in me and my software.

[hemidart]

they aren't listening or talking about the situation, theres no communication, theres no reinsurance. its all hush hush we have something big happening. Instead of focusing on the problem instead of telling the community they are working on a solution. Actions speak 5 times more then words and so far we are seeing nothing.

almost 4 months of no actions. i'm a software developer if i had my community/clients complaining about an issues i would of dam fixed it already. That way i know they would have faith in me and my software.

+1

[DatsunPatrol]

Maybe if I got a lot of interest from sub 150Khps miners who are sick of the whales killing the pool rewards, I could get something started.  If mining could be more rewarding for people with lower hashrates, maybe It could give Magi a small boost in popularity and value.

I am interested in this for sure. Since you have studied the code a bit maybe you can clarify to me how the hashrate affects the block reward. If you have a perfectly moderated mining pool that actively kicks off users with >250kh/s does that gaurantee a larger reward when the pool atually finds a block or are bad actors on the global network still going to spoil it for us?

[earl3000]

Okay, message received. Bad idea, but you want to hear an ever worse one that could possibly work and not require any changes to the current MagiCoin infrastructure?

Hand-approved pool registrations in conjunction with pool-side hashrate limits, where users would need to disclose their estimated hashrate upon registration. That way, if a user goes over their registered hashrate (or if their registered hashrate is exactly the pool limit, then the pool limit), then they will be kicked from the pool. Sure, it adds more work to the pools, but it ensures the fairness of the rest of the miners who are actually following the rules. You could just solo-mine with a botnet, but at least that's less unfair to pool miners because you're not invalidating the blocks of miners who did nothing wrong. You're just lowering the block reward for everyone on the network, which is still unfair.

Seems fine but how do you get all pools onboard? You can't - and whichever one is the holdout will be the one used for the attacks.

I don't know what the actual solution is though. What is the feasibility of a protocol side upper limit on hashrate for any one mining device?  If that upper limit is a carefully selected value it might solve a lot of problems. But this is probably not that easy to actually implement.

One thing we should not forget, what if the attacker sets up his own pool (it is pretty easy), with the hashrate that he seems to have, it might even work,

[Iame3]

Okay, message received. Bad idea, but you want to hear an ever worse one that could possibly work and not require any changes to the current MagiCoin infrastructure?

Hand-approved pool registrations in conjunction with pool-side hashrate limits, where users would need to disclose their estimated hashrate upon registration. That way, if a user goes over their registered hashrate (or if their registered hashrate is exactly the pool limit, then the pool limit), then they will be kicked from the pool. Sure, it adds more work to the pools, but it ensures the fairness of the rest of the miners who are actually following the rules. You could just solo-mine with a botnet, but at least that's less unfair to pool miners because you're not invalidating the blocks of miners who did nothing wrong. You're just lowering the block reward for everyone on the network, which is still unfair.

Seems fine but how do you get all pools onboard? You can't - and whichever one is the holdout will be the one used for the attacks.

I don't know what the actual solution is though. What is the feasibility of a protocol side upper limit on hashrate for any one mining device?  If that upper limit is a carefully selected value it might solve a lot of problems. But this is probably not that easy to actually implement.

One thing we should not forget, what if the attacker sets up his own pool (it is pretty easy), with the hashrate that he seems to have, it might even work,

Would it be possible to hardcode mining only from registered pools?  I was also thinking about limiting hashrate of everything to, say, 3mh/s, but then one can set multiple pools.