Check the times of the blocks: 2016-04-15 02:57:19.832312 UpdateTip: new best=0000000000000000052e336f67c1b0d339d5e7423595c60f169cd17bd24e5306 height=407354 log2_work=84.48832
tx=122495865 date=2016-04-15 02:57:07 progress=1.000000 cache=4.7MiB(5564tx)
2016-04-15 03:21:13.214595 UpdateTip: new best=000000000000000003828fbc61ad281aa2e298ed4a299abf36209a4725d51930 height=407355 log2_work=84.48836
1 tx=122495866 date=2016-04-15 03:20:49 progress=1.000000 cache=51.3MiB(16114tx)
Doesn't look like it was immediately after a new block... So, what do you think happened? Someone configured their coin daemon that feeds their p2pool instance to do so. @-ck That is a problem. I am not sure how you could enforce this at the node to node level based on how the p2pool software and the coin daemon interact. P2pool is written in a language that I can only describe as trash.
Not interested in going near it at all.
@kano Speaking of languages, why on earth is Bitcoin written in C++? I thought C would have been the first and better choice. |
|
|
|
What is the point of debating GPU mining for MMC2?
Why not debating? Or you think that this forum is only for your "facts"? I previously stated only that GPU mining is possible, not that it should be done.
You can claim anything you want. If you claim that it is possible, prove it. CPU mining with YAM is far more efficient hashes/W than GPU mining ever was for MMC2. That is an actual fact.
Let me decide what more efficient for me, ok? @mycoinsstore I am not trying to tell you what to do. You can use whatever you want. If you want to GPU mine, I would be more than happy to try and help you figure it out. I would like to note that I have been unable to locate the source code for any of the GPU miners as I believe all of them were closed source. Let me know if you have any of their source code. oh guys, calm down. I just shared my experiences. I'd seen that MMC was GPU mineable before delinquency took over.
afterwards, he forked to v3 and implemented below. Afterwards, I haven't seen/heard any GPU miners. There were actually a few miners just to keep the blockchain healthy.
@mycoinsstore I believe what coaex is trying to say is that he never intended to definitively say GPU mining is no longer possible. @coaex Would my assertion be correct? I'm not a coder, nor a code-analyst. Maybe, Memorycoin just changed into a real CPU/RAM-dependant coin after AES-CBC implementation.
I also remember that difficulty readjustment has changed from Kimoto Gravity Well to Dark Gravity Wave but I'm not sure of that, I might be mistaken.
So far I remember, I was getting 10-11 HPM with i5-2500k 3.3Ghz (~125W) while a strong GPU in 2015 was getting 20-22 HPM (~300W). Maybe that would be reason why GPU miners were not around. Settings I remember - yam-miner sandy bridge - hugepages on
edit: oh, that DGW has never been implemented, sorry. I should have confused it with something else.
@coaex Yes, I have been saying this all along. GPU mining stopped because it was no longer energy efficient when compared to CPU mining with YAM. You are correct, Kimoto Gravity Well (KGW) is still used. I found where Delinquency fixed the critical bug in the source code. I'm an mmc bagholder, and who you are?
I offered to community to run mmc pool (if someone needs this), and what is your interest in this thread?
And the main question - are you interested in the future of mmc or just come to argue?
@mycoinsstore To answer your first question, I have a large stake in MMC2. I have been mining since the beginning of 2014 and I have been following the project since mid-2013. I also currently represent ~40% of the MMC2 network hashrate and I can easily increase my hashrate by at least 300%. I think that should answer your remaining questions about my interest in MMC2 and whether or not I am here to argue. Now, can we move on to a more productive conversation? I would like to get p2pool working again, but we need to coordinate our pools and properly bootstrap the sharechain. I am prepared to host a node that will function as a bootstrap address. I think that I can fork KillerByte's p2pool code and make the necessary changes to get things working. However, one problem might still remain. Did Delinquency and KillerByte ever solve the grant block issue with regard to p2pool? I am still looking over both Delinquency's and KillerByte's work to determine if the problem still exists, but I have been unsuccessful so far in identifying if it was actually resolved. I would also like to get the wallet updated. At a minimum, we need to update the seed nodes so that new folks can sync their blockchains without manually adding nodes. We will also need to compile new binaries for both Windows and OS X. I think that we need to put-off any discussion of updating the wallet to current Bitcoin sources. The final issue we have is with YAM. After we get p2pool back on track, we need to contact yvg1900 and request that he update our p2pool addresses in his next update. I have a working hack that enables me to use YAM now, but I would prefer to get it properly fixed so that yvg1900 gets his 2%. Any thoughts? |
|
|
|
HEY!!!!!!! Only talk about BTC Bitfury chips here!!!!!!!!!!!!!! Mikestang will start reporting all those who don't comply!!!!!!!!!!!!!!!!! You have been warned!!!!!!!!!!!!!!!!!
I chuckled at that. |
|
|
|
What is the point of debating GPU mining for MMC2? I previously stated only that GPU mining is possible, not that it should be done. CPU mining with YAM is far more efficient hashes/W than GPU mining ever was for MMC2. That is an actual fact. Hi, in2tactics !
Unfortunately I have no time to go so deep into the mmc sources, but I believe to coaex and my own eyes.
GPU mining stopped working exactly after one of the Delinquency mandatory mmc code and wallet updates.
I have looked through the source code and I am saying that your claims are incorrect. Show me in the source code where I am wrong or stop spread FUD. And this Delinquency's post is not true: The only GPU miners that have ever come out were only supported by specific pools. Those pools have discontinued accepting shares for Memorycoin. They were closed source and only supported a specific amount of Video Cards (over 2G VRAM).
Pools discontinued accepting shares for Memorycoin AFTER changes to mmc code and wallet, not before. Ask yourself - why should pools kill GPU mining of mmc? They had a good fees from this mining, because of a big amount of GPU miners. I am positive that Delinquency is not a liar. Show me in the source code where I am wrong. Correlation does not imply causation! Also, GPU miners supported not only pool mining, but solo mining too. I mined mmc with my 2 R9 270x 2GB cards, using mc2miner and other miners (that supports GPU and CPU mining). But now, even solo GPU and CPU mining not working. Only yam miner working now. The question is why?  Btw: I remember time when GPU miners worked even with p2pool mmc pools. I have a working code of such p2pool, but it no longer accept shares from GPU miners. I was there too and I remember well what did and what did not work. There are other possible reasons for things to not be working correctly. Without seeing your error messages and knowing your setup, it is too hard to conjecture. |
|
|
|
An S3 uses only like 340Watts so 500W PSU should be sufficient. However it probably only has 2 PCIe connectors.
I am assuming that the heartburn people have with the OP's statement is that the post appears to imply that two S3+ are being powered by one 500W PSU. I've got a couple of S3+ units and a 500W power supply (been running them both for a month or so) that I'm selling, if anyone's interested.
|
|
|
|
...
Now, if we increase the shift size or the number of shifts while holding the other value constant, the number of shares paid will be greater than the average number of shares to find a block and the amount paid per share will be less. You appear to be advocating for this type of change.
...
It's best to explain that statement since the way you've written it implies that you'd be rewarded less, which is false. The way I have written it is correct. I was explaining from the pool's point of view not the miner's. If we hold the number of shifts constant and increase the shift size, the payout for each shift will remain the same. If the payout remains the same for each shift, an increase in the number of shares paid per shift will result in a decrease in the amount paid per share. I will admit that I can see how a change in point of view could lead someone to falsely assume that they would be rewarded less. You left out the point that each share will, on average, be paid more than once ... so result, on average, with the same reward.
I think the first part of your clarification may still be confusing for some folks. The number of shares contributed by the miner will increase proportionally with the number of shares paid during a shift because the percentage of contributed shares by the miner should remain the same, pool variance over a different sampling window of a different sampling size notwithstanding. Increasing the N reduces variance, not reward.
Agreed |
|
|
|
Believe me, mmc code was changed and GPU mining was blocked. You can see this changes in mmc sources.
I spent the last few days going over all of the commits and merges made to the source code by Delinquency on GitHub. I went as far back as December 2013 and I found no changes to the algorithm or more specifically no changes to the implementation of momentum. I did find changes to the protocol with respect to difficulty re-targeting and fork handling. Delinquency also added copyright notices and changed bitcoin to memorycoin in all variables, functions, and file names. Additionally, I found significant updates to the Qt interface. Have you even gone through the source code? https://github.com/memorycoin/memorycoinhttps://github.com/Delinquency/memorycoinI also found the following post from Delinquency where he failed to confirm that GPU mining is no longer possible. He only stated that the pools supporting GPU mining for MMC2 discontinued it. 2 little questions to devs,
certainly not urgent but when you have time if you don't mind,
1) To compile are you using cmake or qt or what exactly to make the windows binary wallets you are distributing ?
I only tried to compile it 2x quickly the other day and got some weird errors , was using qt 4.8.6 i believe , with boost 1_55_0 , open ssl1.0.1j and the most recent qr code libraries and miniiupnpc. I was tied up at the time and figured I would have another go at it again this week.
2) Has there been any additional releases of open sourced miners with more optimizations /open cl support ect.. in the past few months. While I did not see any on the thread I still felt it worth asking. Thanks guys.
Windows Binary Libraries are compiled under nitrogenetic's tutorial. If you need help with the compile, you can post here. The most optimized miner is closed source, by yvg1900. (YAM) The only GPU miners that have ever come out were only supported by specific pools. Those pools have discontinued accepting shares for Memorycoin. They were closed source and only supported a specific amount of Video Cards (over 2G VRAM). Now back to my original post... But some of this clever guys (I don't know who exactly), was able to modify original mmc code to make it impossible (now) mine mmc with GPU.
The coding for MMC2 was not changed. If I remember my early months of 2014 correctly, the Radeon HD 7970 or Radeon R9 280X produced ~20HPM at around 350W. The i7-4770K initially produced ~3HPM at less than 90W. When yvg1900 released YAM, the i7-4770K jumped to ~13HPM. GPU miners simply could not compete with the power efficiency of CPU miners when they are between 2 and 3 times more efficient. AES-NI FTW!!! On a similar note, it is normal to see a dual socket Xeon servers pushing 40 HPM when using YAM. The problem right now is that all the default pools are down and YAM stops mining when it is unable to submit shares for the developer. I think that the facts I have previously mentioned vindicate my original statement. Additionally, I would like to add the following as further evidence concerning YAM's performance. Yeah, the new CPU miner is better than GPU mining. I'm getting a 320% performance boost with my i7 3770k. Infact, my 3770k is outperforming my 7950 GPU, while using around 33% of the power. Amazing. |
|
|
|
Check the times of the blocks: 2016-04-15 02:57:19.832312 UpdateTip: new best=0000000000000000052e336f67c1b0d339d5e7423595c60f169cd17bd24e5306 height=407354 log2_work=84.48832
tx=122495865 date=2016-04-15 02:57:07 progress=1.000000 cache=4.7MiB(5564tx)
2016-04-15 03:21:13.214595 UpdateTip: new best=000000000000000003828fbc61ad281aa2e298ed4a299abf36209a4725d51930 height=407355 log2_work=84.48836
1 tx=122495866 date=2016-04-15 03:20:49 progress=1.000000 cache=51.3MiB(16114tx)
Doesn't look like it was immediately after a new block... So, what do you think happened? |
|
|
|
I wasn't necessarily advocating for longer shifts ( I don't think I was, or not in the way I'm thing about it). Maybe I was and didn't even know it  . I was looking at something like increase the number of payable shifts from say the current 10, to maybe 12 or 15. I don't know if that would be considered making the shifts longer or how that would effect payouts. I'm a newbie to all of this, so I don't really understand how changing one part of the system would have an effect on another part of the system or the users of the pool. If someone has a few minutes, and could enlighten me in simple-mans English and in just few paragraphs or two, I would greatly appreciate it. When I hear the term "lengthening the shifts", I think of increasing the time it takes for one complete shift (which currently has been hovering around 5 to 6 hours depending on the hash being put it to the shift) being increased to 8 or 10 hours or something like that to hit 100%. That wasn't what I was talking about or intending. The thoughts I'm having is to leave the 5-6 hours it takes to complete a shift untouched so you are still completing the shift counter in the same amount of time as before (until the shift counter reads 100%.) (And at ~5-6 hours) BUT, Instead of completed shift work being rolled off the "Still eligible for pay" table after 10 shifts (~55-65 hours), we keep those shifts eligible for pay for, maybe, 2 or 5 more shifts. Is that what you mean when you say "lengthening the shifts" (because the wording confuses me) and I'm just looking at it in some weird, odd way?? Or, does it make a difference if that is done and does it take longer for payouts or cause lower amounts of payouts? Please, someone in the know please enlighten me as what the damages would be and why what I propose is such a bad idea. I'm just trying to understand. Please explain in simple English, (please) as it has taken me 30 minutes or more to type out what I think I'm trying to say. LOL As I'm not sure if what I typed out was what I have meant to type say anyway!  Thanks for any and all insights!!! It is common for pools that use PPLNS to set N equal to the network difficulty. That is because the average number of shares to find a block is equal to the network difficulty. BitMinter uses the PPLNS with shifts method and the number of shares paid over all shifts is approximately equal to the current difficulty. Now, if we increase the shift size or the number of shifts while holding the other value constant, the number of shares paid will be greater than the average number of shares to find a block and the amount paid per share will be less. You appear to be advocating for this type of change. Is there any particular reason you want to increase the number of shifts? I believe that there are valid arguments for a pool to set the number of shares paid to a value greater than, less than, and equal to the network difficulty. In our case, a pool with low overall network hashrate, I believe we should set N equal to or less than the network difficulty. I refrained from explaining PPLNS with shifts further as it adds nothing to the overall discussion, but if you wish we can discuss that as well. As an aside, PPLNS with shifts is also sometimes referred to as Pay Per Last N Groups (or shifts) PPLNSG. Yes, I know the acronym looks wrong. It is not my acronym. |
|
|
|
so try it with a powered usb hub or ask jat if hell look into it.?.
The USB port is supposed to provide 2A max. It should supply more than enough power to provide ~1 MH without needing a powered USB hub. |
|
|
|
im wondering if its just the little thing doesnt have enough cpu to keep bfgminer happy?
basically the stick sits idle, its getting work, but not sending any.
I have tried posting this in the R1 support thread? https://bitcointalk.org/index.php?topic=1196852.0 |
|
|
|
That could mean there's a possible leak of Bitmain customers info...  That was my first thought. |
|
|
|
|
@chikenfeed That is the same message I received.
|
|
|
|
Hi guys..i run bfgminer with following comand: bfgminer -S opencl:auto -o http://flo.suprnova.cc:3210 -u Students.students -p ***** Please tell why im getting 0.0 kb/s Here is my screenshot:  Thanks! Did you enable scrypt and pass the --scrypt command when you launched BFGMiner? You do appear to be hashing from what I can tell and from your screenshot it has only been 6 minutes and 22 seconds. However, you have yet to submit any shares and it could be due to the pool difficulty being too high for your hardware. |
|
|
|
Code was changed. This is a fact.
Exactly after that all major pools (mmcpool.com and 1gh.com) delisted mmc.
And people lost interest to mmc, because ask yourself - how many people has Xeon servers?
Also, yam-miner main problem is a proprietary closed-source code with hardcoded (dead now) pools.
I know there was a code change when MemoryCoin Beta and ProtoShares transitioned to MemoryCoin 2.0 (MMC2). After Delinquency took over MMC2, I remember a hard fork sometime in the second half of 2014, but I did not realize that was a major algorithm change. I also remember dwarfpool.com and 1gh.com delisting MMC2 around that same time-frame. It was never my understanding that GPU mining was dead due to code changes, but I could be wrong. I just remember the GPU mining discussion dying when yvg1900 released YAM with MMC2 support. |
|
|
|
But some of this clever guys (I don't know who exactly), was able to modify original mmc code to make it impossible (now) mine mmc with GPU.
The coding for MMC2 was not changed. If I remember my early months of 2014 correctly, the Radeon HD 7970 or Radeon R9 280X produced ~20HPM at around 350W. The i7-4770K initially produced ~3HPM at less than 90W. When yvg1900 released YAM, the i7-4770K jumped to ~13HPM. GPU miners simply could not compete with the power efficiency of CPU miners when they are between 2 and 3 times more efficient. AES-NI FTW!!! On a similar note, it is normal to see a dual socket Xeon servers pushing 40 HPM when using YAM. The problem right now is that all the default pools are down and YAM stops mining when it is unable to submit shares for the developer. |
|
|
|
I got one too!, aside from the funny link and domain, the rest of the message was in Chinese
I was able to copy and paste the Chinese into google translate. It said something to the effect of "Welcome to Bitmain!" |
|
|
|
I think I can setup a pool for mmc. I have a working prototype.
You going to use the p2pool code from early 2015? or uNOMP? |
|
|
|
So, whats next?
I hope the guy did not drop dead. At this point, we have to just keep going and hopefully we can enlist some folks that want to work on the development side of things. |
|
|
|
|
Show Posts
