111magic
Legendary
Offline
Activity: 1750
Merit: 1005
|
|
January 06, 2018, 04:07:54 AM |
|
Last block!! 🙈
|
bitcoin: bc1qyadvvyv29z08ln2ta7g3uqwzkscr7wq4p09wuz
|
|
|
trader03
Newbie
Offline
Activity: 56
Merit: 0
|
|
January 06, 2018, 04:15:26 AM |
|
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
Newbie
Offline
Activity: 5
Merit: 0
|
|
January 06, 2018, 04:17:14 AM |
|
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
Newbie
Offline
Activity: 48
Merit: 0
|
|
January 06, 2018, 04:21:21 AM |
|
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
Newbie
Offline
Activity: 21
Merit: 0
|
|
January 06, 2018, 04:23:59 AM |
|
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
Newbie
Offline
Activity: 5
Merit: 0
|
|
January 06, 2018, 04:29:00 AM |
|
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
Newbie
Offline
Activity: 5
Merit: 0
|
|
January 06, 2018, 04:36:48 AM |
|
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
Newbie
Offline
Activity: 48
Merit: 0
|
|
January 06, 2018, 04:37:47 AM |
|
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
Member
Offline
Activity: 98
Merit: 11
|
|
January 06, 2018, 04:39:36 AM |
|
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/sIt 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.
|
My XMG Address: 9LzxHqsxrRPMCyBffjMc3cLuB5hwEG5Ufq "Un pour tous, tous pour un" - The Three Musketeers, 1844
|
|
|
trader03
Newbie
Offline
Activity: 56
Merit: 0
|
|
January 06, 2018, 04:44:20 AM |
|
WAIT FRIENDS, PATIENCE
|
|
|
|
mkropinack
Newbie
Offline
Activity: 5
Merit: 0
|
|
January 06, 2018, 04:47:12 AM |
|
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
Newbie
Offline
Activity: 56
Merit: 0
|
|
January 06, 2018, 04:57:47 AM |
|
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
|
|
January 06, 2018, 05:00:32 AM |
|
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
Newbie
Offline
Activity: 28
Merit: 0
|
|
January 06, 2018, 05:05:47 AM |
|
|
|
|
|
jonathin.r
Member
Offline
Activity: 98
Merit: 11
|
|
January 06, 2018, 05:06:10 AM |
|
My wallet just showed me passing the hardfork, but it keeps crashing... what's going on?
|
My XMG Address: 9LzxHqsxrRPMCyBffjMc3cLuB5hwEG5Ufq "Un pour tous, tous pour un" - The Three Musketeers, 1844
|
|
|
ibgeek
Newbie
Offline
Activity: 25
Merit: 0
|
|
January 06, 2018, 05:07:30 AM |
|
Mine just started crashing now as well.
|
|
|
|
Redrover
|
|
January 06, 2018, 05:07:48 AM |
|
yep same thing here and can't get it to run now.
|
|
|
|
joelao95 (OP)
Legendary
Offline
Activity: 1190
Merit: 1009
Coin of the Magi!
|
|
January 06, 2018, 05:07:54 AM |
|
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
Newbie
Offline
Activity: 9
Merit: 0
|
|
January 06, 2018, 05:11:56 AM |
|
keeps crashing
|
|
|
|
s0litaire
Member
Offline
Activity: 133
Merit: 15
|
|
January 06, 2018, 05:12:57 AM |
|
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!
|
|
|
|
|