The source code for test is updated here:
https://github.com/magi-project/magi/tree/v1.4.3-test
I have to rebuild the chain which has been taking one day long; as soon as I get the chain, I'll post a link for download and then we can start the test.
At this time, this test takes care of 1) and 2). Depending on the time available, we'll see when 3) is to be merged.
Topic: [ANN] [XMG] MAGI | CPU mining | mPoW | mPoS | [MagiPay] - page 373. (Read 2375972 times)
Hi All,
I have another response back from topia,I'm sure they wont mind me sharing it
I have another response back from topia,I'm sure they wont mind me sharing it
Quote
We understand your position and share your pain. It's always disappointing when we decide to delist a coin for reasons that are outside the coin-dev's control. We have enjoyed having Magi listed, it's always been a bit of a special coin.
If XMG managed to stabilize its network before we finish the delisting process, please get in contact and we may re-evaluate our delisting decision. No promises though.
If XMG managed to stabilize its network before we finish the delisting process, please get in contact and we may re-evaluate our delisting decision. No promises though.
Thanks, we will carry out test ASAP; pls message them the status.
Hi All,
I have another response back from topia,I'm sure they wont mind me sharing it
I have another response back from topia,I'm sure they wont mind me sharing it
Quote
We understand your position and share your pain. It's always disappointing when we decide to delist a coin for reasons that are outside the coin-dev's control. We have enjoyed having Magi listed, it's always been a bit of a special coin.
If XMG managed to stabilize its network before we finish the delisting process, please get in contact and we may re-evaluate our delisting decision. No promises though.
If XMG managed to stabilize its network before we finish the delisting process, please get in contact and we may re-evaluate our delisting decision. No promises though.
I like your temporary solution to the global hash. Thank you!!!
E
HEY -- Does anyone have what is required to do a NOMP correctly? I do not know how to get it to do the hashing because it doesn't seem to recognize the M7m Algo.>...
Pool owners of NOMP pools can someone help me install my own pool? I am completely confused now because I can't get P2pool to work due to some kind of p2p port lock up in the running of the P2Pool and the NOMP don't seem to have the config settings needed.
how did you guys get XMG working on NOMP or otherwise? Trying to get a ready-made server for linux or windows set up that I can just install, I am lost up to my chin in json and config file confusion. Please help? Thanks!
Enoch
I had the same problems with NOMP. Edward helped me out though. You have to add the algorithm, to the algroproperties.js file. I don't have access to the server right now but its under the node-multi-hashing/libs folder IIRC
I got NOMP running but ran into problems creating the Stratum. I'm going to work on it again later this week
B
Bitcoin is growing because hashrate and difficulty are growing. This way magi hashrate and diff could grow too.
I don't agree.
This results in only people with big, bigger, biggest hashrate could mine XMG coin.
That's absolutely not the way.
the whole thing doesn't make any sense ans there is no logic in it. It is only hurting miners with standard hash rates who will be punished for those of very high rates.
Mining at low Kh (20...100) and helping the network will barely generate coins.
check the net hashrate and how it jumped!!
Mining at low Kh (20...100) and helping the network will barely generate coins.
check the net hashrate and how it jumped!!
This is the reason why i think magi has to come up with a better solution than decreasing reward according to hashrate.
I think magi should implement some kind of better anti farm mechanics.
For example solo only mining where the system is able to detect big miners so they would receive smaller rewards. (yes pools would become obsolete but heck it pools are for other coins)
Bitcoin is growing because hashrate and difficulty are growing. This way magi hashrate and diff could grow too.
AFAIK, it is not possible for the network, to distinguish a pool from a solo miner.
Anyway, is it possible to manage the block reward, based on the finder's hashrate?
the whole thing doesn't make any sense ans there is no logic in it. It is only hurting miners with standard hash rates who will be punished for those of very high rates.
Mining at low Kh (20...100) and helping the network will barely generate coins.
check the net hashrate and how it jumped!!
Mining at low Kh (20...100) and helping the network will barely generate coins.
check the net hashrate and how it jumped!!
This is the reason why i think magi has to come up with a better solution than decreasing reward according to hashrate.
I think magi should implement some kind of better anti farm mechanics.
For example solo only mining where the system is able to detect big miners so they would receive smaller rewards. (yes pools would become obsolete but heck it pools are for other coins)
Bitcoin is growing because hashrate and difficulty are growing. This way magi hashrate and diff could grow too.
2) PoS & PoW blocks will be checked to make sure they follow a pattern, for example, in-between two PoW block are at least two PoS blocks; within continuous five blocks must be the occurrence of a PoW block.
3) Regarding PoW mining, I strongly believe the way we should be heading is the way we are right now. We might need to stick to the big vision, and fulfill the task as much as possible, by getting around the issues, or mitigating the impacts, but not by just turning off the source. From what I can see, without PoW will lead MAGI to nowhere. I propose a check on the PoW blocks on the overall network mining hashrate, say a total of 40MH/s will make all PoW blocks being rejected; in other words, PoW is turned off once network hashrate exceeds the limit, and back to life once below the limit. Until we figure out a better solution, this might help. Let me know the maximum hashrate you'd like.
2) and 3) are contradictable if hashrate >40MH for some time with more than 5 blocks? Or reject both PoW and PoS after 4 blocks until hashrate decline below 40MH. I think the limit should be adjusted dynamically to 2x or 1 1/2 x the normal hashrate(maybe 6 hour average hashrate) with an upper hard limit 90Mh.
3) Regarding PoW mining, I strongly believe the way we should be heading is the way we are right now. We might need to stick to the big vision, and fulfill the task as much as possible, by getting around the issues, or mitigating the impacts, but not by just turning off the source. From what I can see, without PoW will lead MAGI to nowhere. I propose a check on the PoW blocks on the overall network mining hashrate, say a total of 40MH/s will make all PoW blocks being rejected; in other words, PoW is turned off once network hashrate exceeds the limit, and back to life once below the limit. Until we figure out a better solution, this might help. Let me know the maximum hashrate you'd like.
2) and 3) are contradictable if hashrate >40MH for some time with more than 5 blocks? Or reject both PoW and PoS after 4 blocks until hashrate decline below 40MH. I think the limit should be adjusted dynamically to 2x or 1 1/2 x the normal hashrate(maybe 6 hour average hashrate) with an upper hard limit 90Mh.
Once PoW is halted, there shall be coming pure PoS blocks about 1.5 min / block. With elevated limit might not guarantee the PoS block rule within continuous five blocks must be the occurrence of a PoW block is met, as there can be possible attack with hashrate higher than the limit to intentionally cease the network. A getaround is to compromise the PoS block rule during the over-hashrate situation.
This sounds like a very good solution. I hope it should prevent the flash mining problem and forks plus even out the block reward for PoW. Good job coming up with this, I hope you can test code soon. Thank you for your work!
the whole thing doesn't make any sense ans there is no logic in it. It is only hurting miners with standard hash rates who will be punished for those of very high rates.
Mining at low Kh (20...100) and helping the network will barely generate coins.
check the net hashrate and how it jumped!!
Mining at low Kh (20...100) and helping the network will barely generate coins.
check the net hashrate and how it jumped!!
As I'm not able to read through all the prior pages at this moment, let me be aware of the issues I missed. The forks that occurred recently turned out to be the IP banning associated with the check of difficulty in an unexpected occasions. Once that happens, nodes connect to each other and construct local networks; from what can be seen, such a check is even unnecessary; rather than a complete removal, it is to be remained within the limited situation. Regarding the fixes,
1) We will go with checkpoints and that is expected to remove the IP banning mostly by being avoided from check from time to time. In the meantime, we will restore the checkpoint master keys at this point, and nodes from the team, such as 104.128.225.215 will be responsible for checkpoints. Checkpoint master keys should be removed in the future.
2) PoS & PoW blocks will be checked to make sure they follow a pattern, for example, in-between two PoW block are at least two PoS blocks; within continuous five blocks must be the occurrence of a PoW block.
3) Regarding PoW mining, I strongly believe the way we should be heading is the way we are right now. We might need to stick to the big vision, and fulfill the task as much as possible, by getting around the issues, or mitigating the impacts, but not by just turning off the source. From what I can see, without PoW will lead MAGI to nowhere. I propose a check on the PoW blocks on the overall network mining hashrate, say a total of 40MH/s will make all PoW blocks being rejected; in other words, PoW is turned off once network hashrate exceeds the limit, and back to life once below the limit. Until we figure out a better solution, this might help. Let me know the maximum hashrate you'd like.
I'll pull out a 2nd test on the node and post corresponding instructions shortly. Once we get rid of the forks, we will get the fix into main source and then request exchanges to recover the wallets.
1) We will go with checkpoints and that is expected to remove the IP banning mostly by being avoided from check from time to time. In the meantime, we will restore the checkpoint master keys at this point, and nodes from the team, such as 104.128.225.215 will be responsible for checkpoints. Checkpoint master keys should be removed in the future.
2) PoS & PoW blocks will be checked to make sure they follow a pattern, for example, in-between two PoW block are at least two PoS blocks; within continuous five blocks must be the occurrence of a PoW block.
3) Regarding PoW mining, I strongly believe the way we should be heading is the way we are right now. We might need to stick to the big vision, and fulfill the task as much as possible, by getting around the issues, or mitigating the impacts, but not by just turning off the source. From what I can see, without PoW will lead MAGI to nowhere. I propose a check on the PoW blocks on the overall network mining hashrate, say a total of 40MH/s will make all PoW blocks being rejected; in other words, PoW is turned off once network hashrate exceeds the limit, and back to life once below the limit. Until we figure out a better solution, this might help. Let me know the maximum hashrate you'd like.
I'll pull out a 2nd test on the node and post corresponding instructions shortly. Once we get rid of the forks, we will get the fix into main source and then request exchanges to recover the wallets.
I like your temporary solution to the global hash. Thank you!!!
E
HEY -- Does anyone have what is required to do a NOMP correctly? I do not know how to get it to do the hashing because it doesn't seem to recognize the M7m Algo.>...
Pool owners of NOMP pools can someone help me install my own pool? I am completely confused now because I can't get P2pool to work due to some kind of p2p port lock up in the running of the P2Pool and the NOMP don't seem to have the config settings needed.
how did you guys get XMG working on NOMP or otherwise? Trying to get a ready-made server for linux or windows set up that I can just install, I am lost up to my chin in json and config file confusion. Please help? Thanks!
Enoch
Seeing actual net hashrate... I do think a cap of hashing would be in order.
Lets see what happens. I think the only way to test this is by trail and error.
When will you start testing?
When will you start testing?
sounds good joe 
2) PoS & PoW blocks will be checked to make sure they follow a pattern, for example, in-between two PoW block are at least two PoS blocks; within continuous five blocks must be the occurrence of a PoW block.
3) Regarding PoW mining, I strongly believe the way we should be heading is the way we are right now. We might need to stick to the big vision, and fulfill the task as much as possible, by getting around the issues, or mitigating the impacts, but not by just turning off the source. From what I can see, without PoW will lead MAGI to nowhere. I propose a check on the PoW blocks on the overall network mining hashrate, say a total of 40MH/s will make all PoW blocks being rejected; in other words, PoW is turned off once network hashrate exceeds the limit, and back to life once below the limit. Until we figure out a better solution, this might help. Let me know the maximum hashrate you'd like.
2) and 3) are contradictable if hashrate >40MH for some time with more than 5 blocks? Or reject both PoW and PoS after 4 blocks until hashrate decline below 40MH. I think the limit should be adjusted dynamically to 2x or 1 1/2 x the normal hashrate(maybe 6 hour average hashrate) with an upper hard limit 90Mh.
3) Regarding PoW mining, I strongly believe the way we should be heading is the way we are right now. We might need to stick to the big vision, and fulfill the task as much as possible, by getting around the issues, or mitigating the impacts, but not by just turning off the source. From what I can see, without PoW will lead MAGI to nowhere. I propose a check on the PoW blocks on the overall network mining hashrate, say a total of 40MH/s will make all PoW blocks being rejected; in other words, PoW is turned off once network hashrate exceeds the limit, and back to life once below the limit. Until we figure out a better solution, this might help. Let me know the maximum hashrate you'd like.
2) and 3) are contradictable if hashrate >40MH for some time with more than 5 blocks? Or reject both PoW and PoS after 4 blocks until hashrate decline below 40MH. I think the limit should be adjusted dynamically to 2x or 1 1/2 x the normal hashrate(maybe 6 hour average hashrate) with an upper hard limit 90Mh.
Once PoW is halted, there shall be coming pure PoS blocks about 1.5 min / block. With elevated limit might not guarantee the PoS block rule within continuous five blocks must be the occurrence of a PoW block is met, as there can be possible attack with hashrate higher than the limit to intentionally cease the network. A getaround is to compromise the PoS block rule during the over-hashrate situation.
[...snip...]
3) Regarding PoW mining, I strongly believe the way we should be heading is the way we are right now. We might need to stick to the big vision, and fulfill the task as much as possible, by getting around the issues, or mitigating the impacts, but not by just turning off the source. From what I can see, without PoW will lead MAGI to nowhere. I propose a check on the PoW blocks on the overall network mining hashrate, say a total of 40MH/s will make all PoW blocks being rejected; in other words, PoW is turned off once network hashrate exceeds the limit, and back to life once below the limit. Until we figure out a better solution, this might help. Let me know the maximum hashrate you'd like.
[...snip...]
Just a quick note regarding that third point: if I saw and remember correctly, as it is now, the network hashrate is extrapolated from the last 120 PoW blocks. If PoW is halted at a specific hashrate limit, then the last 120 PoW blocks will always be the same on subsequent checks (no new PoW blocks from mining) and hence yield the same extrapolated network hashrate above the set limit. Mining will be in a standstill it won't be able to come out of.
Just a thing to keep in mind upon implementation.
Basically the network hashrate is nailed down to a specific value since hashrate info is read from the past blocks; the situation only changes until there are new PoW blocks generated. The proper process will be halting PoW for a certain period, after that a new PoW is generated, along with rechecking hashrate; it will be like a slow-pace PoW generation during the over-hashrate situation.
2) PoS & PoW blocks will be checked to make sure they follow a pattern, for example, in-between two PoW block are at least two PoS blocks; within continuous five blocks must be the occurrence of a PoW block.
3) Regarding PoW mining, I strongly believe the way we should be heading is the way we are right now. We might need to stick to the big vision, and fulfill the task as much as possible, by getting around the issues, or mitigating the impacts, but not by just turning off the source. From what I can see, without PoW will lead MAGI to nowhere. I propose a check on the PoW blocks on the overall network mining hashrate, say a total of 40MH/s will make all PoW blocks being rejected; in other words, PoW is turned off once network hashrate exceeds the limit, and back to life once below the limit. Until we figure out a better solution, this might help. Let me know the maximum hashrate you'd like.
2) and 3) are contradictable if hashrate >40MH for some time with more than 5 blocks? Or reject both PoW and PoS after 4 blocks until hashrate decline below 40MH. I think the limit should be adjusted dynamically to 2x or 1 1/2 x the normal hashrate(maybe 6 hour average hashrate) with an upper hard limit 90Mh.
3) Regarding PoW mining, I strongly believe the way we should be heading is the way we are right now. We might need to stick to the big vision, and fulfill the task as much as possible, by getting around the issues, or mitigating the impacts, but not by just turning off the source. From what I can see, without PoW will lead MAGI to nowhere. I propose a check on the PoW blocks on the overall network mining hashrate, say a total of 40MH/s will make all PoW blocks being rejected; in other words, PoW is turned off once network hashrate exceeds the limit, and back to life once below the limit. Until we figure out a better solution, this might help. Let me know the maximum hashrate you'd like.
2) and 3) are contradictable if hashrate >40MH for some time with more than 5 blocks? Or reject both PoW and PoS after 4 blocks until hashrate decline below 40MH. I think the limit should be adjusted dynamically to 2x or 1 1/2 x the normal hashrate(maybe 6 hour average hashrate) with an upper hard limit 90Mh.
[...snip...]
3) Regarding PoW mining, I strongly believe the way we should be heading is the way we are right now. We might need to stick to the big vision, and fulfill the task as much as possible, by getting around the issues, or mitigating the impacts, but not by just turning off the source. From what I can see, without PoW will lead MAGI to nowhere. I propose a check on the PoW blocks on the overall network mining hashrate, say a total of 40MH/s will make all PoW blocks being rejected; in other words, PoW is turned off once network hashrate exceeds the limit, and back to life once below the limit. Until we figure out a better solution, this might help. Let me know the maximum hashrate you'd like.
[...snip...]
Just a quick note regarding that third point: if I saw and remember correctly, as it is now, the network hashrate is extrapolated from the last 120 PoW blocks. If PoW is halted at a specific hashrate limit, then the last 120 PoW blocks will always be the same on subsequent checks (no new PoW blocks from mining) and hence yield the same extrapolated network hashrate above the set limit. Mining will be in a standstill it won't be able to come out of.
Just a thing to keep in mind upon implementation.
As I'm not able to read through all the prior pages at this moment, let me be aware of the issues I missed. The forks that occurred recently turned out to be the IP banning associated with the check of difficulty in an unexpected occasions. Once that happens, nodes connect to each other and construct local networks; from what can be seen, such a check is even unnecessary; rather than a complete removal, it is to be remained within the limited situation. Regarding the fixes,
1) We will go with checkpoints and that is expected to remove the IP banning mostly by being avoided from check from time to time. In the meantime, we will restore the checkpoint master keys at this point, and nodes from the team, such as 104.128.225.215 will be responsible for checkpoints. Checkpoint master keys should be removed in the future.
2) PoS & PoW blocks will be checked to make sure they follow a pattern, for example, in-between two PoW block are at least two PoS blocks; within continuous five blocks must be the occurrence of a PoW block.
3) Regarding PoW mining, I strongly believe the way we should be heading is the way we are right now. We might need to stick to the big vision, and fulfill the task as much as possible, by getting around the issues, or mitigating the impacts, but not by just turning off the source. From what I can see, without PoW will lead MAGI to nowhere. I propose a check on the PoW blocks on the overall network mining hashrate, say a total of 40MH/s will make all PoW blocks being rejected; in other words, PoW is turned off once network hashrate exceeds the limit, and back to life once below the limit. Until we figure out a better solution, this might help. Let me know the maximum hashrate you'd like.
I'll pull out a 2nd test on the node and post corresponding instructions shortly. Once we get rid of the forks, we will get the fix into main source and then request exchanges to recover the wallets.
1) We will go with checkpoints and that is expected to remove the IP banning mostly by being avoided from check from time to time. In the meantime, we will restore the checkpoint master keys at this point, and nodes from the team, such as 104.128.225.215 will be responsible for checkpoints. Checkpoint master keys should be removed in the future.
2) PoS & PoW blocks will be checked to make sure they follow a pattern, for example, in-between two PoW block are at least two PoS blocks; within continuous five blocks must be the occurrence of a PoW block.
3) Regarding PoW mining, I strongly believe the way we should be heading is the way we are right now. We might need to stick to the big vision, and fulfill the task as much as possible, by getting around the issues, or mitigating the impacts, but not by just turning off the source. From what I can see, without PoW will lead MAGI to nowhere. I propose a check on the PoW blocks on the overall network mining hashrate, say a total of 40MH/s will make all PoW blocks being rejected; in other words, PoW is turned off once network hashrate exceeds the limit, and back to life once below the limit. Until we figure out a better solution, this might help. Let me know the maximum hashrate you'd like.
I'll pull out a 2nd test on the node and post corresponding instructions shortly. Once we get rid of the forks, we will get the fix into main source and then request exchanges to recover the wallets.
H/s limit seems to be a good workaround. But I'm not sure aboute the number.
Keep in mind that actual networks hashrate is 90MH/s. Just one pool has 30MH/s, at this very moment.
As I'm not able to read through all the prior pages at this moment, let me be aware of the issues I missed. The forks that occurred recently turned out to be the IP banning associated with the check of difficulty in an unexpected occasions. Once that happens, nodes connect to each other and construct local networks; from what can be seen, such a check is even unnecessary; rather than a complete removal, it is to be remained within the limited situation. Regarding the fixes,
1) We will go with checkpoints and that is expected to remove the IP banning mostly by being avoided from check from time to time. In the meantime, we will restore the checkpoint master keys at this point, and nodes from the team, such as 104.128.225.215 will be responsible for checkpoints. Checkpoint master keys should be removed in the future.
2) PoS & PoW blocks will be checked to make sure they follow a pattern, for example, in-between two PoW block are at least two PoS blocks; within continuous five blocks must be the occurrence of a PoW block.
3) Regarding PoW mining, I strongly believe the way we should be heading is the way we are right now. We might need to stick to the big vision, and fulfill the task as much as possible, by getting around the issues, or mitigating the impacts, but not by just turning off the source. From what I can see, without PoW will lead MAGI to nowhere. I propose a check on the PoW blocks on the overall network mining hashrate, say a total of 40MH/s will make all PoW blocks being rejected; in other words, PoW is turned off once network hashrate exceeds the limit, and back to life once below the limit. Until we figure out a better solution, this might help. Let me know the maximum hashrate you'd like.
I'll pull out a 2nd test on the node and post corresponding instructions shortly. Once we get rid of the forks, we will get the fix into main source and then request exchanges to recover the wallets.
1) We will go with checkpoints and that is expected to remove the IP banning mostly by being avoided from check from time to time. In the meantime, we will restore the checkpoint master keys at this point, and nodes from the team, such as 104.128.225.215 will be responsible for checkpoints. Checkpoint master keys should be removed in the future.
2) PoS & PoW blocks will be checked to make sure they follow a pattern, for example, in-between two PoW block are at least two PoS blocks; within continuous five blocks must be the occurrence of a PoW block.
3) Regarding PoW mining, I strongly believe the way we should be heading is the way we are right now. We might need to stick to the big vision, and fulfill the task as much as possible, by getting around the issues, or mitigating the impacts, but not by just turning off the source. From what I can see, without PoW will lead MAGI to nowhere. I propose a check on the PoW blocks on the overall network mining hashrate, say a total of 40MH/s will make all PoW blocks being rejected; in other words, PoW is turned off once network hashrate exceeds the limit, and back to life once below the limit. Until we figure out a better solution, this might help. Let me know the maximum hashrate you'd like.
I'll pull out a 2nd test on the node and post corresponding instructions shortly. Once we get rid of the forks, we will get the fix into main source and then request exchanges to recover the wallets.
It would be gerat if devs define terms what they need to bring transfers back to life, at least like some weeks(s) or month(s).
Not talking about precise ETA but some info/updates would be appreciated.
Understand what you mean. At this moment the first tests are looking good. But before bringing Magi 100% back its must be for sure that the fix is perfect. Magi learned from a fast fix and will not make that mistake again.Not talking about precise ETA but some info/updates would be appreciated.
Magi dev is doing what he can and needs to have faith in the fix so it will not happen again.
It will not take months thats for sure!
Excellent.. thanks
And price is holding well on Bittrex, with decent volume too.
Jump to: