Yesterday my wallet was synced n working.
As of ~8am Central Time 08/12/2017 my wallet started to disconnect/connect. Been using the 2 nodes Paul posted via connect.
It appears I have yet again split/forked.
@joe ..... any suggestions??
Could you try resync and make connections to the nodes by using "connect", as suggested in prior posts? Let us know. |
|
|
|
is the update coming for a 32bit wallet?
If not, any advise on how move the coins from a 32 wallet to 64 bit wallet?
I'm on it. |
|
|
|
Please provide all the binaries. There is no deamon, only qt-wallet provided in version 1.4.0. Please make this release professional like other serious coins. Thanks.
When the deamon exe for Windows will be available?
This isn't as normal but a quick fix to bring things back. By limited source for binary compilation, I'll need some extra time unfortunately. Bear with me... I'm expecting tomorrow. |
|
|
|
10 minute analyzing defferense in code between old version of client and current 1.4 on github result:
NOTHING was done to prevent splitting in future.
lol
I figured a fix to avoid future splitting won't be able to be done in less than two days, but we need to sort out the network issues ASAP including pools, minings and exchanges (already PMed Bittrex). To be frank, root cause wasn't clear to me yet as I barely got chance to dig down at the time of bringing us back. I do see this is tough as we never got this happen in past years, while that doesn't mean there isn't a weakness. We'll need to look into further more particularly the source of the cause, and will definitely increase the possibility of avoiding this issue to happen again. I would expect the update on this issue would be no later than or along with the scheduled update as specified in roadmap. |
|
|
|
We updated the wallet version to v1.4 to enable a fix to the splitting. I'll give more description regarding the fix. There is splitting around block 1443980; it wasn't confirmed that is necessary a fork from pool, as the inconsistent block is a PoS block based on a comparison of two chains available. Given that, the fix is to start from that point. Procedure to startup on a clean chain:
1) Download the wallet v1.4.0 (will push other versions into that):
http://coinmagi.org/bin/m-wallet-1.4.0/
2) Backup wallet.dat;
3) The prior blockdata must be removed before launching the new wallet:
Remove everything under the Magi or .magi folder except for wallet.dat:
Windows: %appdata%\Magi
Linux: ~/.magi
4) If you wish to redownload blockchain from scratch, skip to 7)
5) Download block chain from:
http://coinmagi.org/bin/block-chain/
and unzip the file;
6) Place all of the contents under "m-blockchain" into Magi or .magi;
7) Launch the new wallet.
Source:
https://github.com/magi-project/magi
I'll update relevant docs and web once I get a chance back on the stuffs, and some more descriptions.
Nodes: connect=104.128.225.215
connect=216.189.151.56
|
|
|
|
Personally I am strongly against a hard fork to revert the split in principle. Is there no way just to role out the fix on top of the current chain? F/D: I mined a few of those 43 XMG blocks  That seems the way to go for a reverse. I'll post updates soon. |
|
|
|
Something happened at block 1444278 it seems.
My daemon and backup daemon crashed at that block, likely someone is trying to fool around which a manipulated (stake) block
I can/will reopen the pool once the daemon is fixed
Thanks, we'll get back ASAP. Please post some info what is the plan. Thx. There was a splitting in the chain. We'll reverse to where it happened. The reason is that after splitting, there are local network mining within which coin generation has been raised up quite a lot since the difficulty cannot catch up the global network that should be excluded. We're testing the fix and should be able to post it out soon. To All, Let me know your concern regarding the above plan. |
|
|
|
Something happened at block 1444278 it seems.
My daemon and backup daemon crashed at that block, likely someone is trying to fool around which a manipulated (stake) block
I can/will reopen the pool once the daemon is fixed
Thanks, we'll get back ASAP. |
|
|
|
Good day.
I'm trying to build a pool for our lovely coinmagi but stratum seems to fail. Hashrate is showing wrong in mpos. Now trying p2pool buy I'm missing coin info.
Can you help me as magi-stratum on github.com isn't much help.
Many thanks for help
Edward0181
magi-stratum is basically working as m-hash is relying on that. p2pool is much helpful, but it's probably not an easy go. MPOS should be the one straightforward; the guide on MPOS itself is actually good and enough for having the pool up. It might also be helpful to google MPOS. |
|
|
|
Awesome. I like your post and development. Wish i had those skills! Oeps only the last picture has a little issue. Website is www.m-core.org  Its ok it will redirect to from coinmagi to m-core so no worries. Looks great! Thanks! I'm was enthusiastic about Magi, so I've decided to make my own poker chip for collecting. Since a physical Magi coin didn't exist, I wanted to have a physical representation of Magi and made own of my own. About the site, I've forgot to add the new one instead, but focused on the old link which was the one that I could recall. But other than that, I think it makes it a great piece of collection, and I may consider to make more if there is enough demand for it in the future. I'm looking forward to help spread the awareness and popularity of Magi, by desigining physical items that people would want to buy and keep for the long term. I like the design. Thanks for the efforts. How would be the pricing? |
|
|
|
|
I don't want to be conclusive but one may notice mining with 100kH/s will be a real drop in the ocean ultimately in the general case. For MAGI is like 100kh/s versus 30 ~ 90 Mh/s total network as I observed today. The number would be varying and would be different in another day. But the overall hashrate is definitely under a certain control. I'm not talking every moment but by average. It is nearly impossible that a super rig comes super rewards. Well it's possible when one mines ahead of the rest who are with low hashrate. That's why Knc miner gets into the space, and its story is known to public. Actually I am glad no one want to special hardwares for mining, so Knc miner the like won't be case. But I do encourage increasing hashrate up to some point, and one can use the miner with automatically adjusted hashrate.
We do understand the big hash causes the reduction in the rewards which has been one of the issues causing overall drop of individual rewards, and this is where we try to improve as scheduled on the roadmap. We'll reveal more facts by the time when it's necessary and we can say so. Bear with us.
|
|
|
|
Thank you for the answer deztroyr1!
I'm not trying to do a moneybench here. I use the Xeon usually for other stuff of course... I am a scientist and usually I do simulations of atomic nuclei, if you're curious, so let's say that I got them for free. But ATM I don't have the time to lunch other simulations since I'm busy writing/reading/vacationing... so my hardware sits in idle...
I do not do it for the money either... I mainly do it to understand the hashing, the performance/compilation, the blockchain and cryptocurrency economy from the scientific perspective, and how it has evolved in this years so to speak.
So from the purely performance point of view my
two E5-2630v4, 10 core HT 2.2GHz, 3.1GHz turbo, and 25 MB cache each with DDR4 2666GHz should pulverize a
i5-6600 3.30 GHz, turbo 3.90 GHz, with DDR3 1666GHz or similar, and 6MB cache as it happens for physics simulations...
Unless hashing algo is severly single core.
If that's the case, running two workers should give me a factor two improvement on my dual socket (?), and running 40 threads should give me not much improvements, that's not what currently happens.
even if scaling is not linear there is definetely some scaling, while running two workers instead of one decreases the performances.
I can try some tests. Do you have some guidance or guide to link me to?
I'm not on a status of experimenting the mining, but probably recall the scaling question that won't be linearly increasing with increasing number of threads, likely due to heats. For testing and also the safe side to avoid burning too much heating to your computing rigs, I recommend the "-e flag" to suppress the CPU percentage of usage, and then see how much increase with threads. Here are some info: http://m-core.org/download/#mining-softwareshttp://m-core.org/resources/mining.html#mpow-miningLet me know whichever on the site is confusing. |
|
|
|
... But I can't have the wallet open all the time. Is there a CLI tool that I can run on a server to stake?
...
For stake, there must be a whole blockchain locally which means running a full node like the wallet. There is option to use VPS to stake; hopefully others can recommend something else. ... So I have... stakesplitthreshold=1000
stakecombinethreshold=500
... and I've split the coins into 1000 per address (the site said to split over addresses, so I just did that rather than re-blocking on one address) The weight is now slowly increasing minute by minute, which I guess is how mPoS is supposed to work. Does this sound good, or can you offer any updated advice? Cheers! Looks good to me, but I leave this to others who are staking often may have more effective suggestions. |
|
|
|
Uhm guys... I got a problem. My share count are just too low. It's okay when I start the miner, then just drop after hour. I run with 3 CPUs now, 1 G3450T and 2 G3930, and I got more earnings with just a single G3450T when I started mining.
That might be explained by the varying blockrewards, and I hope docs on the new site can make it clearer. http://www.m-core.org/PoW-II-v2/ |
|
|
|
i like the new site its very responsive and have nice layout, new site have great potential  great work Joe i tried to contact historical few weeks ago about multipool but no response i don't think he is active on bct anymore. Can i ask you a question what do you think about masternodes would they be beneficial for magi in future or some sort of anon payment and could that be implemented in magi coding or you don't want to go that road ? Tnx I had a contact with Historical some time ago about the hash.com pool and was able to get response from him. I'll see if I can reach him again. Yes, I think anonymity is the option we should go which is on the roadmap now. Masternodes are not fully anonymous solutions, and I don't like the fact that a non-trivial amount of coins are required for being a node. There are some features of Masternodes which seems actually better than the anonymity itself, but I guess this won't be our direction anyways. I vote for something better, and any future implementations won't require hard rules that prevent general users from participation. |
|
|
|
I am having 450kh/s... how much XMG can i expect per hour?
 {
"hashrate (kh/s)" : 450.00000000,
"difficulty" : 2.36706981,
"difficulty(aver)" : 3.74858850,
"blockvalue" : 2.35424415,
"mining (XMG)" : {
"1 hour" : 0.23688572,
"1 day" : 5.68525733,
"1 week" : 39.79680133
}
}
It might be noted blockvalue is varying from time to time. |
|
|
|
|
Show Posts
