Main net update: Updated the main source code (v1.4.3.1): 1) fix sync issue 2) protocol ver 71062 https://github.com/magi-project/magiProtocol ver 71062 will get us to where once we get on the latest revisions, we'll disconnect all prior versions. Pls update to this version. I'm compiling binaries and will post links once available.
http://coinmagi.org/bin/m-wallet-1.4.3.1/The plan of merging fixes, that is v1.4.4: 1) Get another test wallet tomorrow 2) On Wednesday, 9/13, v1.4.4 source code finalizing; depending on how much time to compile the complete set of binaries as well as documentation, we might be able to make post until 9/14 The difficulty adjustment gets little tricky since we're disturbing the way blocks are accepted by enforcing block checking. The thing is that what happens to PoW difficulty that is adjusted based on block time will make corresponding influence on the block value, that's the center of the question. |
|
|
|
ok so those coming on now the reason we closed our wallets and arent staking or solo mining is joe released 1.4.3.1 but thats source and linux we are still waiting for windows version
so we shut our wallets and solo mining down because the new 1.4.3.1 wallet nodes probably will not accept our pos and pow blocks.
the pools run linux therfore have updated to 1.4.3.1 so there fine. if u solo mine or pos on 1.4.3 ur blocks probably wont be accepted by the new 1.4.3.1 so
we shut our pos and pow solo down not to waste energy or mess up the chain i personaly pool mine so im fine as long as the pool has the update which it does
I'm not sure of what's happening right now.
The main peer if v1.4.3 and many people (namely pools) are already upgrading to v1.4.3.1, which if I understood correctly disconnects older peers (also the main peer running v1.4.3!).
So what will happen in the next hours? Are we following the main peer or the upgraded wallets? I'm not sure what to do at this point. Not even sure if mining at the pools is doing any good.
Mining with pools having wallet 1.4.3.1 is ok. But, what if your wallet using old version is stacking?
Since Joe made the announcement I shut down my wallet.
This version is with protocol version greater than the prior; it connects both new and old versions. The idea is to elevate protocol version, so once we have the new wallet (with fixes), we are able to cut off all of the old version prior to 71062. This wallet is not yet having fixes. It's totally unnecessary to close / turn off staking / mining / wallet. Even with the new wallet with fixes, one should be able to keep staking / mining 24/7. |
|
|
|
passed 22 hours, but nothing on my wallet. each computer (14 pcs) shows about this [2017-09-11 19:13:54] CPU #3: 35.24 kH, 7238.50 H/s
[2017-09-11 19:13:54] CPU #1: 31.11 kH, 6278.00 H/s
[2017-09-11 19:13:54] CPU #0: 33.66 kH, 6530.36 H/s
[2017-09-11 19:13:55] CPU #2: 42.58 kH, 7514.24 H/s
[2017-09-11 19:13:56] m7m block 1475146, diff 3.41, net 76.80 MH/s
[2017-09-11 19:14:01] CPU #1: 31.39 kH, 6524.55 H/s
[2017-09-11 19:14:01] CPU #3: 36.19 kH, 6971.89 H/s
[2017-09-11 19:14:01] CPU #0: 32.65 kH, 6237.93 H/s
[2017-09-11 19:14:01] CPU #2: 37.57 kH, 6921.67 H/s
[2017-09-11 19:14:08] CPU #1: 32.62 kH, 6720.57 H/s
[2017-09-11 19:14:08] CPU #3: 34.86 kH, 7040.89 H/s how can I see that they work and my wallet setuped correctly? At this moment pool mining will work better, or you'll need much more time to succeed in solo mining. There are formula to estimate mining time by taking into account individual vs network hashrates. |
|
|
|
Main net update: Updated the main source code (v1.4.3.1): 1) fix sync issue 2) protocol ver 71062 https://github.com/magi-project/magiProtocol ver 71062 will get us to where once we get on the latest revisions, we'll disconnect all prior versions. Pls update to this version. I'm compiling binaries and will post links once available. |
|
|
|
|
The test wallet checks blocks to make sure PoW and PoS following a pattern: 1) at least two PoS between PoW blocks, and 2) for any continuous five blocks contains at least one PoW block. When the above conditions are not satisfied, blocks come out at about every 15min. Blocks found before 15min is up will then be rejected, along with error "block violations".
The waiting time "15min" rule might be a concern when PoS blocks not coming out as expected; it would be necessary to rely on the PoS thing which is the main force in the future. By the time when the whole network is staking and PoS becomes a major force pushing forward the chain, we won't see the 15min rule. The 15min is somehow a random number I come up with, that was made to differ from the regular PoW block time (3min). Reducing the waiting time would recover things back to normal faster.
Thanks all for the test in both PoW and PoS. I believe the chain moves as expected, and I don't see particular concerns, except for the block time, which is 3.17min by averaging the past 100 blocks at #1451764. The longer block time is mainly due to limited PoS blocks; the situation shall get changed once on the mainnet that has more in PoS staking.
I'll update the way that difficulty adjustment works by taking into account the "15min" rule. Once we're done that, we will make changes to the main source code. I hope we get it done in next week.
Pls let me know if you see a fork in test.
|
|
|
|
Looks like the tests are almost finished.
If i read the posts correct wallet is working good.
Pls give Joe feedback about what worked good & what did not or worked after adding some things. Thanks guys!
Nothing to complain. Pow did work and have read post is doing okay as well. Perhaps an idea to put number of confirmation back to 120? Believe that was done to avoid forking and still it did fork on last time. It might be better that we remain the current setup. We'll make updates to the main source code soon. |
|
|
|
I would like information, the Magi are being excluded from Cryptopia and on Bittrex the wallet is under maintenance. What is the future of the currency?
We're recovering the wallet. |
|
|
|
I have put a test chain on node 45.35.251.73. This is only for test; mining won't be valid:
Download the wallet and blockchain from the following:
http://coinmagi.org/bin/test/
(I'm away from my compiling setup so only 64bit binaries are available at the moment)
source: https://github.com/magi-project/magi/tree/v1.4.3-test
* v1.4.3.1
* v1.4.3.2
Updated protocol version so that prior version will be disconnected"version" : "v1.4.3.2"
"protocolversion" : 71070
The chain will proceed when PoS and PoW both are mined or in a pace of about 15minutes when block conditions aren't met. If you have coins in the official chain, you might be able to use that on the test chain for PoS minting (make sure backup wallet.dat).
Node: Prior versions will be disconnected by using v1.4.3.2. If you can't sync with the new wallet, re-download blockchain. addnode=45.35.251.73 is recommended for the new version. |
|
|
|
I have put a test chain on node 45.35.251.73. This is only for test; mining won't be valid:
Download the wallet and blockchain from the following:
http://coinmagi.org/bin/test/
(I'm away from my compiling setup so only 64bit binaries are available at the moment)
source: https://github.com/magi-project/magi/tree/v1.4.3-test
* v1.4.3.1
* v1.4.3.2: Updated protocol version so that prior version will be disconnected
* v1.4.3.3
Difficulty adjustmentPls help the test (PoW & PoS mining). We'd see if this test comes out without forks.
The chain will proceed when PoS and PoW both are mined or in a pace of about 15minutes when block conditions aren't met. If you have coins in the official chain, you might be able to use that on the test chain for PoS minting (make sure backup wallet.dat).
Node:
|
|
|
|
1. let magi reward fluctuate and be random to some degree but following an average depending on network hash for the last 12 hrs or so. The randomness of the reward but with a target average would benefit miners who mine long term and not botnets who only jump when reward is high and leave as soon as it is low. Because rewards go up and down they are left with one choice. Continuously farm or not to farm at all.
This is really a jolly good idea. Maybe just thinking a bit (or byte) more, but this can be the start of a definite solution, great. Actually, I like the idea too. Sometimes a complicated problem can have a very simple answer. What if the block reward will be a number between 1.00 and 11.99? Doesn't matter what was happening in the last 2,3 or 12 hours. It cannot be predicted. i thought about that also. it would be the simplest fix. but joe still like to control the numbers based on hash. And i kinda like the idea that hash affects the coins as well. If the numbers were anywhere in 1-11. those who deem it profitable will just stay and mine. botnets or not. This is just a partial solution. Joe was on the right track with the hash rate adjustment. But it just needs to be unpredictable to be a more complete solution. with that said its really up to Joe. But i really think adding a randomizer will make this coin truly stand out and become closer to a coin for everyone. No need to make it solo mine only or whatever. The randomizer will at least deter those flash miners who jump in and out with high hashrate. Not sure if this is feasible. It's not possible to gather network consensus on a random number. All nodes would have to blindly accept the block rewards "suggested" by the miner. It would be easy for someone with less good intentions to change the source code to give one the maximum possible block reward within the limited validations other peers can make. But Joe is master  on this and maybe can tell us if this is so? EDIT: ...unless the random number is not so random, e.g., deterministically derived from the last 2-4 hexadecimal digits in the mined block hash. Randomness can be optional, while I'm wondering if randomness is mainly served to make block value guess be difficult? However, if we go patterning the average reward following a rule, I bet people can make use of the average rule. And yet, I wouldn't go complete random blocks at this point, as in the case big miners jump in who will actually control majority reward; the reward must make connections to parameter(s) that reflects the actual mining scene. Other than the mentioned solution, I actually in part put efforts on the PoW mining that, in the case of big hashrate, put aside block reward to benefit people, who remains in nodes, PoS mode, or some other services. |
|
|
|
I guess every coin should have something more than only algoritm, what really magi coin does? I read about magi pay, is this works? Where can I pay by magi coin?
Before coin have no real value - it is not a coin and just an air.
I hope devs will do more in real life with this coin after fix fork issue.
That's why we have magipay (it works at this point), and I was pursuing all along, however things came out upon limits when the coin relies on few people. I wish we have a community-surrounded involvements in creating various services / developments which will absolutely lead to more technical stuffs than just the team. |
|
|
|
Is this still where we are?
Why not a diff adjustment like DigiShield or DGW (Dark Gravity Wave), everything slows down as hashrate rises, a vice versa, and let it be?
Yes, trying on the diff adjustment that would be ideal as solution in part to the issue. |
|
|
|
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.
This is just for testing, right? The main chain still operates with the "old" rules (plain v1.4.3)... Yes, it's on a test, no touch of the main chain. Once we confirm no forks, we'll migrate to main chain. |
|
|
|
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.
|
|
|
|
Hi All, I have another response back from topia,I'm sure they wont mind me sharing it 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.
Thanks, we will carry out test ASAP; pls message them the status. |
|
|
|
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.
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. |
|
|
|
|
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.
|
|
|
|
- when blockchain fix and returning to normal transferring/trading is expected?
No ETA yet, but will try to update asap. - is there any risk to lose my XMG if I have stable functioning wallet (which works fine for me with downloaded blockchain)?
No. I'm mining and keeping my Magis on pools right now to avoid any unexpected loses.
I suggest keep coins in your wallet. Backup wallet.dat. Before transfer (receive / send), make sure you're on the right track: Checkout the following for info of best chain: https://chainz.cryptoid.info/xmg/http://178.17.174.27:8280/m-chainhttps://bitcointalk.org/index.php?topic=735170.msg21365060#msg21365060As some people mentioned above, delisting from Cryptopia doesn't look good so what's coming in nearby future?
I've contacted them. Let's see what they gonna say. I wouldn't agree if they simply delist because of the forks and no clear reasons. I'll fully understand if the fork gets lots of maintenance efforts; either way there should be a response to the consequence from them. Other than that, I'm keeping in touch with Bittrex so far in a controllable shape. |
|
|
|
|
Show Posts
