tazzz013
Newbie
Offline
Activity: 118
Merit: 0
|
|
April 23, 2018, 02:03:27 PM |
|
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
Newbie
Offline
Activity: 53
Merit: 0
|
|
April 23, 2018, 02:23:38 PM |
|
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
|
|
April 23, 2018, 02:27:50 PM |
|
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
Newbie
Offline
Activity: 82
Merit: 0
|
|
April 23, 2018, 02:58:21 PM |
|
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
Legendary
Offline
Activity: 1484
Merit: 1029
|
|
April 23, 2018, 03:24:57 PM |
|
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
Newbie
Offline
Activity: 118
Merit: 0
|
|
April 23, 2018, 03:32:54 PM |
|
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
Newbie
Offline
Activity: 18
Merit: 0
|
|
April 23, 2018, 03:37:55 PM |
|
Before was minerclaim :s
|
|
|
|
earl3000
Newbie
Offline
Activity: 82
Merit: 0
|
|
April 23, 2018, 03:40:35 PM |
|
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
Newbie
Offline
Activity: 23
Merit: 0
|
|
April 23, 2018, 04:47:07 PM Last edit: April 23, 2018, 05:10:51 PM by 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
Newbie
Offline
Activity: 82
Merit: 0
|
|
April 23, 2018, 06:37:20 PM |
|
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
Member
Offline
Activity: 98
Merit: 11
|
|
April 23, 2018, 07:25:41 PM |
|
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.
|
My XMG Address: 9LzxHqsxrRPMCyBffjMc3cLuB5hwEG5Ufq "Un pour tous, tous pour un" - The Three Musketeers, 1844
|
|
|
DatsunPatrol
Newbie
Offline
Activity: 22
Merit: 0
|
|
April 23, 2018, 08:30:29 PM |
|
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
Newbie
Offline
Activity: 10
Merit: 0
|
|
April 23, 2018, 11:04:54 PM |
|
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
Newbie
Offline
Activity: 118
Merit: 0
|
|
April 23, 2018, 11:06:58 PM |
|
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
Newbie
Offline
Activity: 154
Merit: 0
|
|
April 23, 2018, 11:28:31 PM |
|
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 belowhttp://jemisp.com/screen5.png
|
|
|
|
Jeremy450
Newbie
Offline
Activity: 154
Merit: 0
|
|
April 23, 2018, 11:36:16 PM |
|
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
Newbie
Offline
Activity: 23
Merit: 0
|
|
April 24, 2018, 12:17:11 AM |
|
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
Newbie
Offline
Activity: 22
Merit: 0
|
|
April 24, 2018, 02:09:14 AM |
|
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
Newbie
Offline
Activity: 82
Merit: 0
|
|
April 24, 2018, 04:41:55 AM |
|
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
Newbie
Offline
Activity: 102
Merit: 0
|
|
April 24, 2018, 05:11:14 AM |
|
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.
|
|
|
|
|