Topic: [ANN] [XMG] MAGI | CPU mining | mPoW | mPoS | [MagiPay] - page 218. (Read 2375617 times)
yep same thing here and can't get it to run now.
Mine just started crashing now as well.
My wallet just showed me passing the hardfork, but it keeps crashing... what's going on?
Correct me if I'm wrong, but I took a look at the change history for the code and based on what I know about the attack, we shouldn't be seeing the next block for another 1 hour and 55 minutes.
Since the window was changed from 2 hours to 5 minutes, I think that we need to wait for wallclock time to catch up to the last block (#1606949), which I guess is about 2 hours into the future.
Also, based on the 10 minute wait time between mined blocks, it would actually be 2 hours, 5 minutes.
-MK
(for a python coder, I've been reading way too much C lately)
Sound theory. Anyone verify this claim?Since the window was changed from 2 hours to 5 minutes, I think that we need to wait for wallclock time to catch up to the last block (#1606949), which I guess is about 2 hours into the future.
Also, based on the 10 minute wait time between mined blocks, it would actually be 2 hours, 5 minutes.
-MK
(for a python coder, I've been reading way too much C lately)
I just restarted my wallet (the new version). It caught up to 1606949, and is stuck there. I do see in my debug.log that some older wallets are publishing later blocks. I suspect that those are the blocks that will be orphaned when the timer runs out?
-MK
Evertime Im getting the following error the offset is getting lower. think we are in fact waiting for it to reach 0, its actually dropping really fast
23:35:38: ntime warning: value 1515214991 (5a50588f) offset -1653 secs from uid 131
Maybe the attacker was only mining 1 hour in the future. based on your log entry, we have about 25 minutes to go, until we start seeing new blocks on the official chain.
I hope you guys are right about this countdown. Any updated estimate? We are discussing it in Slack.
Correct me if I'm wrong, but I took a look at the change history for the code and based on what I know about the attack, we shouldn't be seeing the next block for another 1 hour and 55 minutes.
Since the window was changed from 2 hours to 5 minutes, I think that we need to wait for wallclock time to catch up to the last block (#1606949), which I guess is about 2 hours into the future.
Also, based on the 10 minute wait time between mined blocks, it would actually be 2 hours, 5 minutes.
-MK
(for a python coder, I've been reading way too much C lately)
Sound theory. Anyone verify this claim?Since the window was changed from 2 hours to 5 minutes, I think that we need to wait for wallclock time to catch up to the last block (#1606949), which I guess is about 2 hours into the future.
Also, based on the 10 minute wait time between mined blocks, it would actually be 2 hours, 5 minutes.
-MK
(for a python coder, I've been reading way too much C lately)
I just restarted my wallet (the new version). It caught up to 1606949, and is stuck there. I do see in my debug.log that some older wallets are publishing later blocks. I suspect that those are the blocks that will be orphaned when the timer runs out?
-MK
Evertime Im getting the following error the offset is getting lower. think we are in fact waiting for it to reach 0, its actually dropping really fast
23:35:38: ntime warning: value 1515214991 (5a50588f) offset -1653 secs from uid 131
Maybe the attacker was only mining 1 hour in the future. based on your log entry, we have about 25 minutes to go, until we start seeing new blocks on the official chain.
Correct me if I'm wrong, but I took a look at the change history for the code and based on what I know about the attack, we shouldn't be seeing the next block for another 1 hour and 55 minutes.
Since the window was changed from 2 hours to 5 minutes, I think that we need to wait for wallclock time to catch up to the last block (#1606949), which I guess is about 2 hours into the future.
Also, based on the 10 minute wait time between mined blocks, it would actually be 2 hours, 5 minutes.
-MK
(for a python coder, I've been reading way too much C lately)
Sound theory. Anyone verify this claim?Since the window was changed from 2 hours to 5 minutes, I think that we need to wait for wallclock time to catch up to the last block (#1606949), which I guess is about 2 hours into the future.
Also, based on the 10 minute wait time between mined blocks, it would actually be 2 hours, 5 minutes.
-MK
(for a python coder, I've been reading way too much C lately)
I just restarted my wallet (the new version). It caught up to 1606949, and is stuck there. I do see in my debug.log that some older wallets are publishing later blocks. I suspect that those are the blocks that will be orphaned when the timer runs out?
-MK
Evertime Im getting the following error the offset is getting lower. think we are in fact waiting for it to reach 0, its actually dropping really fast
23:35:38: ntime warning: value 1515214991 (5a50588f) offset -1653 secs from uid 131
Maybe the attacker was only mining 1 hour in the future. based on your log entry, we have about 25 minutes to go, until we start seeing new blocks on the official chain.
WAIT FRIENDS, PATIENCE 
You can use it from there. but you might need to use the full path if you are going to use it in scripts:
~/m-cpuminer-v2/m-minerd
~/m-cpuminer-v2/m-minerd
I ended up using the 'sudo make install' so now I can essentially run it from anywhere. I managed to get it going. However as I mentioned in a recent post, it struggles to maintain a connection to the BULL MINING pool.
[2018-01-06 16:17:52] thread 6: 26396 hashes, 1.66 khash/s
[2018-01-06 16:18:22] Stratum connection failed: Connection timed out after 30000 milliseconds
...and it didn't connect again until...
[2018-01-06 16:32:43] ...retry after 30 seconds
[2018-01-06 16:34:41] thread 4: 91742 hashes, 1.58 khash/s
It stayed up for about 7 minutes and then starting having Stratum connection issues again!? *sigh*
Interestingly enough, both my miners, that have worked with other pools in the past, are having issues getting work from the BullMining pool. They may be having issues. When it looks like they got some work, I get a `Stratum connection failed: Connection timed out after 30001 milliseconds` error message.
Correct me if I'm wrong, but I took a look at the change history for the code and based on what I know about the attack, we shouldn't be seeing the next block for another 1 hour and 55 minutes.
Since the window was changed from 2 hours to 5 minutes, I think that we need to wait for wallclock time to catch up to the last block (#1606949), which I guess is about 2 hours into the future.
Also, based on the 10 minute wait time between mined blocks, it would actually be 2 hours, 5 minutes.
-MK
(for a python coder, I've been reading way too much C lately)
Sound theory. Anyone verify this claim?Since the window was changed from 2 hours to 5 minutes, I think that we need to wait for wallclock time to catch up to the last block (#1606949), which I guess is about 2 hours into the future.
Also, based on the 10 minute wait time between mined blocks, it would actually be 2 hours, 5 minutes.
-MK
(for a python coder, I've been reading way too much C lately)
I just restarted my wallet (the new version). It caught up to 1606949, and is stuck there. I do see in my debug.log that some older wallets are publishing later blocks. I suspect that those are the blocks that will be orphaned when the timer runs out?
-MK
Evertime Im getting the following error the offset is getting lower. think we are in fact waiting for it to reach 0, its actually dropping really fast
23:35:38: ntime warning: value 1515214991 (5a50588f) offset -1653 secs from uid 131
Correct me if I'm wrong, but I took a look at the change history for the code and based on what I know about the attack, we shouldn't be seeing the next block for another 1 hour and 55 minutes.
Since the window was changed from 2 hours to 5 minutes, I think that we need to wait for wallclock time to catch up to the last block (#1606949), which I guess is about 2 hours into the future.
Also, based on the 10 minute wait time between mined blocks, it would actually be 2 hours, 5 minutes.
-MK
(for a python coder, I've been reading way too much C lately)
Sound theory. Anyone verify this claim?Since the window was changed from 2 hours to 5 minutes, I think that we need to wait for wallclock time to catch up to the last block (#1606949), which I guess is about 2 hours into the future.
Also, based on the 10 minute wait time between mined blocks, it would actually be 2 hours, 5 minutes.
-MK
(for a python coder, I've been reading way too much C lately)
I just restarted my wallet (the new version). It caught up to 1606949, and is stuck there. I do see in my debug.log that some older wallets are publishing later blocks. I suspect that those are the blocks that will be orphaned when the timer runs out?
-MK
>>> received block 0000051b7adc750dc706
>>> Block 1606950 BlockTime=1515215660 CurrTime=1515213147 AdjustedTime=1515213146 vtx[0].nTime=1515215656
>>> ERROR: AcceptBlock() : chain switch point reached
>>> ERROR: ProcessBlock() : AcceptBlock FAILED
>>> Misbehaving: 67.245.37.95:45844 (0 -> 100) DISCONNECTING
Correct me if I'm wrong, but I took a look at the change history for the code and based on what I know about the attack, we shouldn't be seeing the next block for another 1 hour and 55 minutes.
Since the window was changed from 2 hours to 5 minutes, I think that we need to wait for wallclock time to catch up to the last block (#1606949), which I guess is about 2 hours into the future.
Also, based on the 10 minute wait time between mined blocks, it would actually be 2 hours, 5 minutes.
-MK
(for a python coder, I've been reading way too much C lately)
Sound theory. Anyone verify this claim?Since the window was changed from 2 hours to 5 minutes, I think that we need to wait for wallclock time to catch up to the last block (#1606949), which I guess is about 2 hours into the future.
Also, based on the 10 minute wait time between mined blocks, it would actually be 2 hours, 5 minutes.
-MK
(for a python coder, I've been reading way too much C lately)
I just restarted my wallet (the new version). It caught up to 1606949, and is stuck there. I do see in my debug.log that some older wallets are publishing later blocks. I suspect that those are the blocks that will be orphaned when the timer runs out?
-MK
Historical moment friends we are in block 1606950 woooowwwwww HAPPY NEW MINING ROUND
Thank you God, I woke up just in time to witness the moment
Thank you God, I woke up just in time to witness the moment
[2018-01-05 22:22:19] Stratum connection interrupted
[2018-01-05 22:22:49] Stratum connection failed: Connection timed out after 30000 milliseconds
[2018-01-05 22:22:49] ...retry after 30 seconds
Correct me if I'm wrong, but I took a look at the change history for the code and based on what I know about the attack, we shouldn't be seeing the next block for another 1 hour and 55 minutes.
Since the window was changed from 2 hours to 5 minutes, I think that we need to wait for wallclock time to catch up to the last block (#1606949), which I guess is about 2 hours into the future.
Also, based on the 10 minute wait time between mined blocks, it would actually be 2 hours, 5 minutes.
-MK
(for a python coder, I've been reading way too much C lately)
Sound theory. Anyone verify this claim? Since the window was changed from 2 hours to 5 minutes, I think that we need to wait for wallclock time to catch up to the last block (#1606949), which I guess is about 2 hours into the future.
Also, based on the 10 minute wait time between mined blocks, it would actually be 2 hours, 5 minutes.
-MK
(for a python coder, I've been reading way too much C lately)
Correct me if I'm wrong, but I took a look at the change history for the code and based on what I know about the attack, we shouldn't be seeing the next block for another 1 hour and 55 minutes.
Since the window was changed from 2 hours to 5 minutes, I think that we need to wait for wallclock time to catch up to the last block (#1606949), which I guess is about 2 hours into the future.
Also, based on the 10 minute wait time between mined blocks, it would actually be 2 hours, 5 minutes.
-MK
(for a python coder, I've been reading way too much C lately)
Since the window was changed from 2 hours to 5 minutes, I think that we need to wait for wallclock time to catch up to the last block (#1606949), which I guess is about 2 hours into the future.
Also, based on the 10 minute wait time between mined blocks, it would actually be 2 hours, 5 minutes.
-MK
(for a python coder, I've been reading way too much C lately)
Historical moment friends we are in block 1606950 woooowwwwww HAPPY NEW MINING ROUND
Thank you God, I woke up just in time to witness the moment
Thank you God, I woke up just in time to witness the moment
Last block!! 🙈
We are there, getting rejected blocks still though....
Quote
magid walletpassphrase YOUR_PASSWORD 9999999 true
Is this a necessary step beyond getting the icon lit up in the Wallet GUI?
If you have the little miner tools lit up, you're minting. If you're in gui and the tools are not lit up, you can use the Mint menu. Else that cli command, above, will work.
Erm...Can anyone help me on enabling staking? I've put "staking=1" and "posii=1" (with out the " ") in the magi.conf but the wallet still shows not staking (only those 2 commands were input)... Can someone help me on where I've gone wrong? Thanks.
Have you specifically unlocked your wallet for staking?
magid walletpassphrase YOUR_PASSWORD 9999999 true
Is this a necessary step beyond getting the icon lit up in the Wallet GUI?
Jump to: