[ANN] [XMG] MAGI | CPU mining | mPoW | mPoS | [MagiPay]

[111magic]

Last block!! 🙈

[trader03]

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

[mkropinack]

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)

[jjude80]

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?

[stevr59]

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

[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

[mkropinack]

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?

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

[mkropinack]

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?

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

[jjude80]

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?

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

[jonathin.r]

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 <arguments>

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.

[trader03]

WAIT FRIENDS, PATIENCE

[mkropinack]

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?

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.

[trader03]

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?

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 so be friend, I'm holding the dream, just to see what happens

[Redrover]

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?

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 so be friend, I'm holding the dream, just to see what happens

I hope you guys are right about this countdown.  Any updated estimate?  We are discussing it in Slack.

[dury10]

Boom!
http://https[Suspicious link removed]W.jpg

[jonathin.r]

My wallet just showed me passing the hardfork, but it keeps crashing... what's going on?

[ibgeek]

Mine just started crashing now as well.

[Redrover]

yep same thing here and can't get it to run now.

[joelao95]

m-wallet version v1.4.5.2

Not mandatory, but recommended in order to reject version earlier than 1.4.5.1.

Windows x32 binary is available as well.

m-wallet version v1.4.5.1

Hard fork will take place at block #1606950. See below for the details of hard fork.

Qt-Wallet and Daemon:

https://github.com/magi-project/magi/releases
http://m-core.org/download/
http://m-core.org/bin/m-wallet-1.4.5.1/

Source code: https://github.com/magi-project/magi/

Windows: http://m-core.org/bin/m-wallet-1.4.5.2/m-wallet-1.4.5.2-win.zip
Linux: http://m-core.org/bin/m-wallet-1.4.5.2/m-wallet-1.4.5.2-linux.tar.gz
FreeBSD: http://m-core.org/bin/m-wallet-1.4.5.2/m-wallet-1.4.5.2-freebsd.tar.gz

Windows: http://m-core.org/bin/m-wallet-1.4.5.1/m-wallet-1.4.5.1-win.zip
Linux: http://m-core.org/bin/m-wallet-1.4.5.1/m-wallet-1.4.5.1-linux.tar.gz
Mac OS X: http://m-core.org/bin/m-wallet-1.4.5.1/m-wallet-1.4.5.1-osx.dmg
FreeBSD: http://m-core.org/bin/m-wallet-1.4.5.1/m-wallet-1.4.5.1-freebsd.tar.gz

Block chain: http://m-core.org/bin/block-chain/

v1.4.5.2
=============
Minimum protocol version 71063

v1.4.5.1
=============
This release schedules a hard fork at block #1606950 as a solution to the current mining issue that miners cannot mine blocks:

- The PoW / PoS block generation rule is disabled.

- Difficulty adjustment algo switches back to MQW at #1606948.

- Block drift time is limited within 5 min.

- Remove IRC and add DNS seeds.

Quick guide:

- Windows: unpack the files and run the wallet directly;
- Mac OS: unpack the files and copy to the Application folder, and then run the wallet directly;
- Linux: unpack the files and run the wallet directly.

Quick startup I (without touching the block-chain):

0) Backup wallet.dat;
1) Launch the new wallet.

Quick startup II (replacing the block-chain):

0) Backup wallet.dat;
1) Download block-chain data from here: http://m-core.org/bin/block-chain;
2) Delete all of the contents under the .magi (unix-like system) or Magi (OS X or Windows) folder, except for wallet.dat and magi.conf;
3) Unzip the file and copy the folders under "m-block-chain" into the .magi (unix-like system) or Magi (OS X or Windows) folder;
4) Launch the new wallet.

Note to v1.4.5.1
---------------------
v1.4.5.1 is compatible with the current block chain.

Things explained..

Firstly, I admit what's going on isn't good to the situation, and I do see there are needs of further works to fulfill the purpose of the coin.

There is no rollback. I learned few requests about actions on the miners who mined (future) blocks that the generic miners can't mine, and for that, rollback is one of the approaches. However, taking into account the overall situation that time to time transactions are involved, especially exchanges, there will be more damage to the coin when we cease the chain or perform a rollback.

As explained shortly in previous post, what happens is associated with the PoW / PoS rule in combination with the fact that 2-hour future blocks allowed as in the original design. I do see in this rule weakness because of the PoW block generation capable of being on a 10-min pattern without the PoS blocks. The another feature of MAGI's network that is intentionally kept at low hash rate comes a likability that one with a reasonable amount hash can launch a future block attack, the chance of this is increased by a fact that generic users can't make valid blocks owing to the PoW / PoS rule; these blocks are supposed to reset the block time.

By overviewing the situation, I see there is a difficulty in maintaining low-hash rate network, as individuals can always acquire big hash rate. In contrast, advantage lies in a network with huge amount of hash that individuals can't compete with. Nevertheless, it's not our intention to compromise the purpose because of the weakness. The PoS is supposed to dilute such weakness; I'm seeing the merit of the PoW / PoS rule when used beautifully. We shall make efforts on this aspect.

Let us know any questions / suggestions.

[orcan1ce]

keeps crashing

[s0litaire]

My wallet just showed me passing the hardfork, but it keeps crashing... what's going on?

Don't enable PoS!

It's crashing the wallet for now!