I've had to revert to using the v9 client on all my nodes now - the resource usage on the v11 client is just too high. I hope the devs reconsider forking v9 clients off the network....
Oh no.... Myriad Classic?
Topic: [ANN][XMY] Myriad | Multi-Algo, Fair, Secure - page 42. (Read 849993 times)
Oh no.... Myriad Classic?
I've had to revert to using the v9 client on all my nodes now - the resource usage on the v11 client is just too high. I hope the devs reconsider forking v9 clients off the network....
Who remembers this? 
IT'S BACK!! For free XMY, come to https://www.reddit.com/r/myriadcoin/comments/4u9u1e/sunday_tip_threads_are_back/
Quote
IT'S BACK!! For free XMY, come to https://www.reddit.com/r/myriadcoin/comments/4u9u1e/sunday_tip_threads_are_back/
Why not create a secondary myriad website so there are multiple versions and something to fall back on ? Isn't that the general idea of decentralization? 
the Russians do not believe in the Ethereum, and DAO
Not that I am a supporter of Ethereum or the DAO but how did you gain the authority to speak for all russians? You must be very powerful.
Most people don't know this, but pekacoin is actually Vova Putin.
On another note, if the fancier website is open source and published, I think it wouldn't hurt to use it and spiff up website a bit.
On another note, if the fancier website is open source and published, I think it wouldn't hurt to use it and spiff up website a bit.
the Russians do not believe in the Ethereum, and DAO
Not that I am a supporter of Ethereum or the DAO but how did you gain the authority to speak for all russians? You must be very powerful.
Please do not be silent, now you're close to a rise of its currency
The authority of the air falls, the Russians do not believe in the Ethereum, and DAO
Tell me what will you create, what are your plans, maybe there is a document
You just need to poach whales and you can continue stunning project
The authority of the air falls, the Russians do not believe in the Ethereum, and DAO
Tell me what will you create, what are your plans, maybe there is a document
You just need to poach whales and you can continue stunning project
design concept for Myriad Website http://etherdesign.io/myriadcoin.pdf
Developers will you update your site?
8bitcoder asked me to send him some comparison logs via PM. I'm posting a copy of them here in the hope that someone can shed some light on how to fix the issue:
OK, I've taken logs of 2 p2pool nodes - one is using the v9 client & one is using the v11 client. Both are running on the same OS (Xubuntu 14.04 64bit), both are merge mining using ZET as the primary chain & both have similar hash rate pointed at them.
First log is from the V9 client:
Everything fine there, accepted blocks, retarget, etc - and payments incoming.
Here is the log from the v11 client over the same time period:
No accepted blocks, no retarget, etc - and no payments incoming.
I'm not a dev or a coder, but it is clear that when comparing these two logs that something is definately amiss with the v11 client - what do you think?
Any & all suggestions/ideas are welcome.
OK, I've taken logs of 2 p2pool nodes - one is using the v9 client & one is using the v11 client. Both are running on the same OS (Xubuntu 14.04 64bit), both are merge mining using ZET as the primary chain & both have similar hash rate pointed at them.
First log is from the V9 client:
Code:
2016-07-20 13:16:15 ProcessBlock: ACCEPTED
2016-07-20 13:16:15 CreateNewBlock(): total size 1000
2016-07-20 13:16:15 nActualTimespan = 5638 before bounds 1469019930 1469014338
2016-07-20 13:16:15 nActualTimespan = 3120 after bounds 2880 3120
2016-07-20 13:16:15 GetNextWorkRequired RETARGET
2016-07-20 13:16:15 nTargetTimespan = 3000 nActualTimespan = 3120
2016-07-20 13:16:15 Before: 1b1080fa 000000000000006c890c00000000000000000000000000000000000000000000
2016-07-20 13:16:15 After: 1970e072 0000000000000070e072e147ae147ae147ae147ae147ae147ae147ae147ae147
2016-07-20 13:16:46 received block ba54823f8b7ca20d364614ce29c4352936f401cfd660d6fa3f0da957f23ab098
2016-07-20 13:16:46 AcceptBlock: BlockTime=1469020581
2016-07-20 13:16:46 nActualTimespan = 896 before bounds 1469020458 1469019805
2016-07-20 13:16:46 nActualTimespan = 2880 after bounds 2880 3120
2016-07-20 13:16:46 GetNextWorkRequired RETARGET
2016-07-20 13:16:46 nTargetTimespan = 3000 nActualTimespan = 2880
2016-07-20 13:16:46 Before: 1b1080fa 0000000004630100000000000000000000000000000000000000000000000000
2016-07-20 13:16:46 After: 1c043615 0000000004361570a3d70a3d70a3d70a3d70a3d70a3d70a3d70a3d70a3d70a3d
2016-07-20 13:16:47 UpdateTip: new best=ba54823f8b7ca20d364614ce29c4352936f401cfd660d6fa3f0da957f23ab098 height=1731905 log2_work=251.68825 tx=4476323 algo=4 date=2016-07-20 13:16:21 progress=0.999999
2016-07-20 13:16:47 ProcessBlock: ACCEPTED
2016-07-20 13:16:47 CreateNewBlock(): total size 1000
2016-07-20 13:16:47 nActualTimespan = 5638 before bounds 1469019930 1469014338
2016-07-20 13:16:47 nActualTimespan = 3120 after bounds 2880 3120
2016-07-20 13:16:47 GetNextWorkRequired RETARGET
2016-07-20 13:16:47 nTargetTimespan = 3000 nActualTimespan = 3120
2016-07-20 13:16:47 Before: 1c043615 000000000000006c890c00000000000000000000000000000000000000000000
2016-07-20 13:16:47 After: 1970e072 0000000000000070e072e147ae147ae147ae147ae147ae147ae147ae147ae147
2016-07-20 13:16:15 CreateNewBlock(): total size 1000
2016-07-20 13:16:15 nActualTimespan = 5638 before bounds 1469019930 1469014338
2016-07-20 13:16:15 nActualTimespan = 3120 after bounds 2880 3120
2016-07-20 13:16:15 GetNextWorkRequired RETARGET
2016-07-20 13:16:15 nTargetTimespan = 3000 nActualTimespan = 3120
2016-07-20 13:16:15 Before: 1b1080fa 000000000000006c890c00000000000000000000000000000000000000000000
2016-07-20 13:16:15 After: 1970e072 0000000000000070e072e147ae147ae147ae147ae147ae147ae147ae147ae147
2016-07-20 13:16:46 received block ba54823f8b7ca20d364614ce29c4352936f401cfd660d6fa3f0da957f23ab098
2016-07-20 13:16:46 AcceptBlock: BlockTime=1469020581
2016-07-20 13:16:46 nActualTimespan = 896 before bounds 1469020458 1469019805
2016-07-20 13:16:46 nActualTimespan = 2880 after bounds 2880 3120
2016-07-20 13:16:46 GetNextWorkRequired RETARGET
2016-07-20 13:16:46 nTargetTimespan = 3000 nActualTimespan = 2880
2016-07-20 13:16:46 Before: 1b1080fa 0000000004630100000000000000000000000000000000000000000000000000
2016-07-20 13:16:46 After: 1c043615 0000000004361570a3d70a3d70a3d70a3d70a3d70a3d70a3d70a3d70a3d70a3d
2016-07-20 13:16:47 UpdateTip: new best=ba54823f8b7ca20d364614ce29c4352936f401cfd660d6fa3f0da957f23ab098 height=1731905 log2_work=251.68825 tx=4476323 algo=4 date=2016-07-20 13:16:21 progress=0.999999
2016-07-20 13:16:47 ProcessBlock: ACCEPTED
2016-07-20 13:16:47 CreateNewBlock(): total size 1000
2016-07-20 13:16:47 nActualTimespan = 5638 before bounds 1469019930 1469014338
2016-07-20 13:16:47 nActualTimespan = 3120 after bounds 2880 3120
2016-07-20 13:16:47 GetNextWorkRequired RETARGET
2016-07-20 13:16:47 nTargetTimespan = 3000 nActualTimespan = 3120
2016-07-20 13:16:47 Before: 1c043615 000000000000006c890c00000000000000000000000000000000000000000000
2016-07-20 13:16:47 After: 1970e072 0000000000000070e072e147ae147ae147ae147ae147ae147ae147ae147ae147
Everything fine there, accepted blocks, retarget, etc - and payments incoming.
Here is the log from the v11 client over the same time period:
Code:
2016-07-20 13:10:12 keypool return 22
2016-07-20 13:12:32 UpdateTip: new best=f698f4f53bacdaed69a7a968a3db76303acc4318ea3492f16ccf93c044378e2f height=1731897 algo=1 (scrypt) log2_work=251.68825 tx=4476315 date=2016-07-20 13:10:12 progress=0.999995 cache=0.3MiB(1613tx)
2016-07-20 13:12:32 keypool reserve 22
2016-07-20 13:12:32 CreateNewBlock(): total size 1000
2016-07-20 13:12:32 keypool return 22
2016-07-20 13:12:51 UpdateTip: new best=3fa49ac3e011a739548e26dd3606e515bba4a94ce838a12d86c554cb9c2b959b height=1731898 algo=4 (qubit) log2_work=251.68825 tx=4476316 date=2016-07-20 13:12:33 progress=0.999999 cache=0.3MiB(1614tx)
2016-07-20 13:12:51 keypool reserve 22
2016-07-20 13:12:51 CreateNewBlock(): total size 1000
2016-07-20 13:12:51 keypool return 22
2016-07-20 13:13:33 UpdateTip: new best=ca2488f473c929806ab7504ddacf8a9766f73e2c791a135c1fa32988afc6627e height=1731899 algo=4 (qubit) log2_work=251.68825 tx=4476317 date=2016-07-20 13:12:52 progress=0.999999 cache=0.3MiB(1615tx)
2016-07-20 13:13:34 keypool reserve 22
2016-07-20 13:13:34 CreateNewBlock(): total size 1000
2016-07-20 13:13:34 keypool return 22
2016-07-20 13:14:10 UpdateTip: new best=cddca649d6cdea6136047efbe928d014ae44f1ffa1fea2f5df0c55eeaaeaf7ea height=1731900 algo=2 (groestl) log2_work=251.68825 tx=4476318 date=2016-07-20 13:13:33 progress=0.999999 cache=0.3MiB(1616tx)
2016-07-20 13:14:10 keypool reserve 22
2016-07-20 13:14:10 CreateNewBlock(): total size 1000
2016-07-20 13:14:10 keypool return 22
2016-07-20 13:14:24 UpdateTip: new best=ed956fa518d2b590cc16d13c8c65b8dcb6097961da05c74dc366728f603b7ecf height=1731901 algo=4 (qubit) log2_work=251.68825 tx=4476319 date=2016-07-20 13:14:18 progress=1.000000 cache=0.3MiB(1617tx)
2016-07-20 13:14:24 keypool reserve 22
2016-07-20 13:14:24 CreateNewBlock(): total size 1000
2016-07-20 13:14:24 keypool return 22
2016-07-20 13:15:29 UpdateTip: new best=c5b70c9faef30faf2e892b0ffa8b608c62158a4662c35f0bfe87c05f0e97ffd1 height=1731902 algo=2 (groestl) log2_work=251.68825 tx=4476320 date=2016-07-20 13:14:24 progress=0.999998 cache=0.3MiB(1618tx)
2016-07-20 13:15:30 keypool reserve 22
2016-07-20 13:15:30 CreateNewBlock(): total size 1000
2016-07-20 13:15:30 keypool return 22
2016-07-20 13:16:07 UpdateTip: new best=fe18dcd06d5fa134c0a9ba24c91efc3092bcf4117e6bee5920762b06bc8535f2 height=1731903 algo=1 (scrypt) log2_work=251.68825 tx=4476321 date=2016-07-20 13:15:29 progress=0.999999 cache=0.3MiB(1619tx)
2016-07-20 13:16:07 keypool reserve 22
2016-07-20 13:16:07 CreateNewBlock(): total size 1000
2016-07-20 13:16:07 keypool return 22
2016-07-20 13:16:19 UpdateTip: new best=72206c8ed556f3f710341b14f871c0a2ced637113b1e280f7c1665fc83ccadf4 height=1731904 algo=1 (scrypt) log2_work=251.68825 tx=4476322 date=2016-07-20 13:16:07 progress=1.000000 cache=0.3MiB(1620tx)
2016-07-20 13:16:19 keypool reserve 22
2016-07-20 13:16:19 CreateNewBlock(): total size 1000
2016-07-20 13:16:19 keypool return 22
2016-07-20 13:12:32 UpdateTip: new best=f698f4f53bacdaed69a7a968a3db76303acc4318ea3492f16ccf93c044378e2f height=1731897 algo=1 (scrypt) log2_work=251.68825 tx=4476315 date=2016-07-20 13:10:12 progress=0.999995 cache=0.3MiB(1613tx)
2016-07-20 13:12:32 keypool reserve 22
2016-07-20 13:12:32 CreateNewBlock(): total size 1000
2016-07-20 13:12:32 keypool return 22
2016-07-20 13:12:51 UpdateTip: new best=3fa49ac3e011a739548e26dd3606e515bba4a94ce838a12d86c554cb9c2b959b height=1731898 algo=4 (qubit) log2_work=251.68825 tx=4476316 date=2016-07-20 13:12:33 progress=0.999999 cache=0.3MiB(1614tx)
2016-07-20 13:12:51 keypool reserve 22
2016-07-20 13:12:51 CreateNewBlock(): total size 1000
2016-07-20 13:12:51 keypool return 22
2016-07-20 13:13:33 UpdateTip: new best=ca2488f473c929806ab7504ddacf8a9766f73e2c791a135c1fa32988afc6627e height=1731899 algo=4 (qubit) log2_work=251.68825 tx=4476317 date=2016-07-20 13:12:52 progress=0.999999 cache=0.3MiB(1615tx)
2016-07-20 13:13:34 keypool reserve 22
2016-07-20 13:13:34 CreateNewBlock(): total size 1000
2016-07-20 13:13:34 keypool return 22
2016-07-20 13:14:10 UpdateTip: new best=cddca649d6cdea6136047efbe928d014ae44f1ffa1fea2f5df0c55eeaaeaf7ea height=1731900 algo=2 (groestl) log2_work=251.68825 tx=4476318 date=2016-07-20 13:13:33 progress=0.999999 cache=0.3MiB(1616tx)
2016-07-20 13:14:10 keypool reserve 22
2016-07-20 13:14:10 CreateNewBlock(): total size 1000
2016-07-20 13:14:10 keypool return 22
2016-07-20 13:14:24 UpdateTip: new best=ed956fa518d2b590cc16d13c8c65b8dcb6097961da05c74dc366728f603b7ecf height=1731901 algo=4 (qubit) log2_work=251.68825 tx=4476319 date=2016-07-20 13:14:18 progress=1.000000 cache=0.3MiB(1617tx)
2016-07-20 13:14:24 keypool reserve 22
2016-07-20 13:14:24 CreateNewBlock(): total size 1000
2016-07-20 13:14:24 keypool return 22
2016-07-20 13:15:29 UpdateTip: new best=c5b70c9faef30faf2e892b0ffa8b608c62158a4662c35f0bfe87c05f0e97ffd1 height=1731902 algo=2 (groestl) log2_work=251.68825 tx=4476320 date=2016-07-20 13:14:24 progress=0.999998 cache=0.3MiB(1618tx)
2016-07-20 13:15:30 keypool reserve 22
2016-07-20 13:15:30 CreateNewBlock(): total size 1000
2016-07-20 13:15:30 keypool return 22
2016-07-20 13:16:07 UpdateTip: new best=fe18dcd06d5fa134c0a9ba24c91efc3092bcf4117e6bee5920762b06bc8535f2 height=1731903 algo=1 (scrypt) log2_work=251.68825 tx=4476321 date=2016-07-20 13:15:29 progress=0.999999 cache=0.3MiB(1619tx)
2016-07-20 13:16:07 keypool reserve 22
2016-07-20 13:16:07 CreateNewBlock(): total size 1000
2016-07-20 13:16:07 keypool return 22
2016-07-20 13:16:19 UpdateTip: new best=72206c8ed556f3f710341b14f871c0a2ced637113b1e280f7c1665fc83ccadf4 height=1731904 algo=1 (scrypt) log2_work=251.68825 tx=4476322 date=2016-07-20 13:16:07 progress=1.000000 cache=0.3MiB(1620tx)
2016-07-20 13:16:19 keypool reserve 22
2016-07-20 13:16:19 CreateNewBlock(): total size 1000
2016-07-20 13:16:19 keypool return 22
No accepted blocks, no retarget, etc - and no payments incoming.
I'm not a dev or a coder, but it is clear that when comparing these two logs that something is definately amiss with the v11 client - what do you think?
Any & all suggestions/ideas are welcome.
The CPU usage should calm down once 8 or more peers are found, please addnode some from http://myriad.nutty.one/home
Interesting though, to clarify you're saying that the Myriad 0.11.3.1 daemon using qubit is not using high cpu with only 4 peers?
I checked again and found that qubit's connection is now over 8. (I have modified net.cpp MAX_OUTBOUND to higher number)
Don't know why it consumed so low cpu at that time.
I added several nodes to groestl algo daemon manually and now it consumes low cpu.
Connection count was only 5 but increased. Maybe that daemon did have some trouble finding peers.
Seems like memory usage is the last problem.
myriad daemons are consuming more memory than even bitcoin. Is it related to multi algo structure?
That's my assumption, yes. A Myriad node has to confirm blocks for all algorithms, not just sha256d.
I restarted qubit, skein, myriad algo for each coin and found that only myriad algo daemon consumes much cpu before connection count reaches 8.
Almost 100%, but qubit, skein doesn't run like that.
Maybe it's not related to algo, but only that daemon. It is really weird that only one daemon is working differently.
One more different thing is that myriad algo daemon is built from empty data directory,
while other coins used previous data directory with "-reindex" parameter. Maybe skein, qubit is using old peers.dat
Any idea about it?
I understand about memory usage but it worked with smaller memory before this latest version.
Maybe transaction memory pool allocated per algo?
Seems like some memory space is wasted, duplicated which can be shared.
The CPU usage should calm down once 8 or more peers are found, please addnode some from http://myriad.nutty.one/home
Interesting though, to clarify you're saying that the Myriad 0.11.3.1 daemon using qubit is not using high cpu with only 4 peers?
I checked again and found that qubit's connection is now over 8. (I have modified net.cpp MAX_OUTBOUND to higher number)
Don't know why it consumed so low cpu at that time.
I added several nodes to groestl algo daemon manually and now it consumes low cpu.
Connection count was only 5 but increased. Maybe that daemon did have some trouble finding peers.
Seems like memory usage is the last problem.
myriad daemons are consuming more memory than even bitcoin. Is it related to multi algo structure?
That's my assumption, yes. A Myriad node has to confirm blocks for all algorithms, not just sha256d.
The CPU usage should calm down once 8 or more peers are found, please addnode some from http://myriad.nutty.one/home
Interesting though, to clarify you're saying that the Myriad 0.11.3.1 daemon using qubit is not using high cpu with only 4 peers?
I checked again and found that qubit's connection is now over 8. (I have modified net.cpp MAX_OUTBOUND to higher number)
Don't know why it consumed so low cpu at that time.
I added several nodes to groestl algo daemon manually and now it consumes low cpu.
Connection count was only 5 but increased. Maybe that daemon did have some trouble finding peers.
Seems like memory usage is the last problem.
myriad daemons are consuming more memory than even bitcoin. Is it related to multi algo structure?
Is there any way to reduce the CPU, memory usage from new version?
It consumes too much CPU at startup and eating more than 1GB of memory during running.
Do I have to tweak some numbers?
It consumes too much CPU at startup and eating more than 1GB of memory during running.
Do I have to tweak some numbers?
We have observed that CPU usage will be high until at least 8 nodes are connected. Once enough peers are found it seems to settle down. Memory use is high though, and I suspect that will be difficult to limit. You could try to set a ulimit on your daemon user and experiment though... Undoubtedly more work needs to be done on this front.
CPU usage is still high even I ran new myriadcoin daemon for more than 10 hours.
Surprisingly, connection count is 5 still.
This daemon's algo is set for "groestl".
Interest thing is, I have another daemon which runs for qubit algo.
I started few minutes ago, and it's connection is 4, CPU usage is quite small. Around 0.5%
I think it's normal.
...
Anyway, it's hard to maintain this kind of daemon on 24/7 server. It harms much.
The CPU usage should calm down once 8 or more peers are found, please addnode some from http://myriad.nutty.one/home
Interesting though, to clarify you're saying that the Myriad 0.11.3.1 daemon using qubit is not using high cpu with only 4 peers?
I use a few coins as the main chain: ZET, NEOS, TRC & XJO. Never had a problem up until v11.
I'm compiling v9 again now...
Edit: OK, I can confirm that when using the v9 client with p2pool merge mining I am once again seeing:
in my debug log, meaning everything is working fine again. Also, CPU usage is minimal & RAM usage is ~700mb, so everything is as it was again.
Whatever changes were made to XMY between v9 & v11 seem to have broken merge mining & increased resourse usage dramatically. At the risk of losing many miners & network hash rate/security - I would respectfully urge the devs to cancel the fork until the problem is resolved. I can supply any logs needed.
Merge mining is one of the many things that make XMY a great coin - to suddenly & needlessly discard it would be potentially devastating.
I'm compiling v9 again now...
Edit: OK, I can confirm that when using the v9 client with p2pool merge mining I am once again seeing:
Code:
2016-07-20 00:03:21 ProcessBlock: ACCEPTED
2016-07-20 00:03:22 CreateNewBlock(): total size 1000
2016-07-20 00:03:22 CreateNewBlock(): total size 1000
in my debug log, meaning everything is working fine again. Also, CPU usage is minimal & RAM usage is ~700mb, so everything is as it was again.
Whatever changes were made to XMY between v9 & v11 seem to have broken merge mining & increased resourse usage dramatically. At the risk of losing many miners & network hash rate/security - I would respectfully urge the devs to cancel the fork until the problem is resolved. I can supply any logs needed.
Merge mining is one of the many things that make XMY a great coin - to suddenly & needlessly discard it would be potentially devastating.
Update: After running v9 over night, I can once again see payments from merge mining XMY flowing into my wallet
I would urge anyone who is merge mining XMY NOT to upgrade, especially if you are using p2pool.
@ jwinterm: Is UNITUS using the same code base as XMY? If so, try reverting back to the v9 client also?
Is there any way to reduce the CPU, memory usage from new version?
It consumes too much CPU at startup and eating more than 1GB of memory during running.
Do I have to tweak some numbers?
It consumes too much CPU at startup and eating more than 1GB of memory during running.
Do I have to tweak some numbers?
We have observed that CPU usage will be high until at least 8 nodes are connected. Once enough peers are found it seems to settle down. Memory use is high though, and I suspect that will be difficult to limit. You could try to set a ulimit on your daemon user and experiment though... Undoubtedly more work needs to be done on this front.
CPU usage is still high even I ran new myriadcoin daemon for more than 10 hours.
Surprisingly, connection count is 5 still.
This daemon's algo is set for "groestl".
Interest thing is, I have another daemon which runs for qubit algo.
I started few minutes ago, and it's connection is 4, CPU usage is quite small. Around 0.5%
I think it's normal.
I don't know the difference between two daemon, but seems like one is doing something wrong.
Here's some log from groestl algo daemon.
......erased log since it includes ip addresses......
Actually both daemon's log is similar except kepool reserve, return number.
Anyway, it's hard to maintain this kind of daemon on 24/7 server. It harms much.
I use a few coins as the main chain: ZET, NEOS, TRC & XJO. Never had a problem up until v11.
I'm compiling v9 again now...
Edit: OK, I can confirm that when using the v9 client with p2pool merge mining I am once again seeing:
in my debug log, meaning everything is working fine again. Also, CPU usage is minimal & RAM usage is ~700mb, so everything is as it was again.
Whatever changes were made to XMY between v9 & v11 seem to have broken merge mining & increased resourse usage dramatically. At the risk of losing many miners & network hash rate/security - I would respectfully urge the devs to cancel the fork until the problem is resolved. I can supply any logs needed.
Merge mining is one of the many things that make XMY a great coin - to suddenly & needlessly discard it would be potentially devastating.
I'm compiling v9 again now...
Edit: OK, I can confirm that when using the v9 client with p2pool merge mining I am once again seeing:
Code:
2016-07-20 00:03:21 ProcessBlock: ACCEPTED
2016-07-20 00:03:22 CreateNewBlock(): total size 1000
2016-07-20 00:03:22 CreateNewBlock(): total size 1000
in my debug log, meaning everything is working fine again. Also, CPU usage is minimal & RAM usage is ~700mb, so everything is as it was again.
Whatever changes were made to XMY between v9 & v11 seem to have broken merge mining & increased resourse usage dramatically. At the risk of losing many miners & network hash rate/security - I would respectfully urge the devs to cancel the fork until the problem is resolved. I can supply any logs needed.
Merge mining is one of the many things that make XMY a great coin - to suddenly & needlessly discard it would be potentially devastating.
OK, this isn't good.
CPU = 20-25%
RAM = 1GB+
Merge mining broken.
I think I'll revert back to the older v9 client in order to get everything working again, as I'm seeing quite a few v9 clients still in use. Can someone tell me if I'll have to redownload the entire blockchain again - or can I use the one I'm using with v11?
Thanks.
CPU = 20-25%
RAM = 1GB+
Merge mining broken.
I think I'll revert back to the older v9 client in order to get everything working again, as I'm seeing quite a few v9 clients still in use. Can someone tell me if I'll have to redownload the entire blockchain again - or can I use the one I'm using with v11?
Thanks.
I'm not sure merge mining is broken, see:
http://insight-myr.cryptap.us/block/1bc76704452bae595989f60527519abcd9a718af6627a29aebe913844c4535a3
This is a sha256d block, appears to be aux-pow, and a version 4 block. That should be on 0.11.3.1
The fork will be done via consensus, 75% v4 blocks after block 1764000. But v 0.9.x can be forked before that block, if 75% v4 consensus is met.
edit: I'm keeping some status here: https://cryptap.us/myr/myrstat
0.11.3.1 miners are v4 miners
I think he was saying that merge mining using myriad as the parent coin on p2pool was broken, not the auxpow algos are broken. Could be wrong tho...
OK, this isn't good.
CPU = 20-25%
RAM = 1GB+
Merge mining broken.
I think I'll revert back to the older v9 client in order to get everything working again, as I'm seeing quite a few v9 clients still in use. Can someone tell me if I'll have to redownload the entire blockchain again - or can I use the one I'm using with v11?
Thanks.
CPU = 20-25%
RAM = 1GB+
Merge mining broken.
I think I'll revert back to the older v9 client in order to get everything working again, as I'm seeing quite a few v9 clients still in use. Can someone tell me if I'll have to redownload the entire blockchain again - or can I use the one I'm using with v11?
Thanks.
I'm not sure merge mining is broken, see:
http://insight-myr.cryptap.us/block/1bc76704452bae595989f60527519abcd9a718af6627a29aebe913844c4535a3
This is a sha256d block, appears to be aux-pow, and a version 4 block. That should be on 0.11.3.1
The fork will be done via consensus, 75% v4 blocks after block 1764000. But v 0.9.x can be forked before that block, if 75% v4 consensus is met.
edit: I'm keeping some status here: https://cryptap.us/myr/myrstat
0.11.3.1 miners are v4 miners
OK, this isn't good.
CPU = 20-25%
RAM = 1GB+
Merge mining broken.
I think I'll revert back to the older v9 client in order to get everything working again, as I'm seeing quite a few v9 clients still in use. Can someone tell me if I'll have to redownload the entire blockchain again - or can I use the one I'm using with v11?
Thanks.
CPU = 20-25%
RAM = 1GB+
Merge mining broken.
I think I'll revert back to the older v9 client in order to get everything working again, as I'm seeing quite a few v9 clients still in use. Can someone tell me if I'll have to redownload the entire blockchain again - or can I use the one I'm using with v11?
Thanks.
Might work now but I believe all v0.9.x clients are going to get forked off the network when new one activates.
When will that be - is it by consesus or block #? I think the fork should be cancelled until these problems are ironed out tbh, forking the network will result in merged miners no longer being able to mine - meaning XMY losing most of its hash rate, won't it?
Jump to: