There is a major lack of coherent communication in regards to merged mining. I'm willing to implement it if there were some central location that information were able to be found... but so far you have to comb through various posts and forums that are disjointed and inaccurate.
But as of right now, it seems that the only information that I have found is that it's unstable, untested and almost unusable without a lot of trial and error.
Ill parrot part what some of the other ops have said as well. Mainframe is looking into this but not jumping in with both feet for the following reasons: 1) unsure of demand for this from miners 2) same reasons Inaba mentions (lack of coherent and centralized information) 3) same reasons Luke-Jr mentions. Im also not willing to jeopardize a stable BTC pool with unproven merged mining code (unproven in a live full scale production environment) If some of these issues are addressed im happy to look at implementing it as well. |
|
|
|
Any of the major (top 10) pools planning on doing merged mining when it starts?
Im willing to at least consider it. Can anyone provide me some links that will give me a consice overview of the issue so i can begin research ? |
|
|
|
|
Oh and i forgot to mention - We had a pool record this month of 13 blocks in 2 days!
|
|
|
|
Hi All, Just thought I would take a moment to update anyone who cares with a summary of the recent developments over at the Mainframe MC pool in the last month or so. If this turns out to be of interest to anyone i might continue to do this each month. So of course the biggest news for us us that in less than 2 months time we have grown to 230-300gh/s which places us solidly in the top 10 largest public pools list (our rank hovers around 8-9th place). Big thanks to all our miners who saw something in what we were doing and came over to join us. Two other major changes were implemented over the last month as well. 1) We implemented a PPLNS reward method of scoring and payout as an anti-poolhopper measure 2) We did away with the mandatory donation amount to charity. It had originally been set at a fixed rate for all miners which didnt allow them to choose if they wanted to donate to charity or not. This was done away with this month and a system put in place to allow miners to choose if they donate and how much they donate. Some of the less notable but certainly worth mentioning changes include: - A pretty major facelift and redesign of the frontend layout and design. - Implementation of some really spiffy charts library (probably the best out there) resulting in very cool new charts for statistics visualization (if you havent seen them its worth making an account just to check them out) - Many new features added to the user interface to make sure miners can get the information they want and are looking for - we "integrated" bitcoin.org.uk forums into the pool website so you can browse the forums without leaving the pool website - We added an IRC channel (#mainframe.nl @ freenode - come join us!) - Twmz added cool forum/signature banners for the MMC pool ( check them out here: http://btcstats.net/?mmc ) - added a !stats bot to the irc channel And of course, to coincide with breaking into the top 10, our main support thread got sticky'd @bitcointalk.org! Additionally, we have had 5 more 10gh/s or larger miners join our pool and are mining with us 24/7 (alot of smaller miners as well, of course). This means Vladimir is no longer the "king of Mainframe". His hashing capacity now accounts for only about 21% of the entire pool's capacity. Random interesting fact : - In only 2 months, Mainframe MC has generated and paid out ~4,040 BTC to its miners Warm thanks again to everyone who has joined over the last 2 months and if you havent checked us out in awhile (or ever) now is a good time to give us a second look! Kind Regards, AnnihilaT MMC Pool Operator |
|
|
|
twmz added support for MMC today.... looks nice, eh? http://btcstats.net/?mmcGo get yours today before they run out.... first come first served... (raw materials needed to craft banners are getting scarce these days so i wouldnt wait too long on this) They look something like this:  Thanks also to gigavps for help on this.... |
|
|
|
Is there a way to change my username within your website? I signed up a while back to get the 0% fee account and would like to come over and test it out but can't find a way to change the username.
sent you a pm  Also, we are on freenode irc btw: channel #mainframe.nl if anyone ever wants real time support. |
|
|
|
Currently using bitcoin.lc and bitminter.com, both are pretty awesome pools and i especially like bitminter with their own miner as well as the statistic interface Mmmh. That basically means that if the pool decides to cheat you, you now have absolutely no way of knowing (since they also control the client). Fishy. Yeah be careful here... |
|
|
|
|
I think its going to take a bit longer for most miners to start unplugging... the price fluctuates so wildly that many i think keep hope that by the time it matter the price will have come up again.
Then you have the ones who will keep mining regardless of the price just because they like to and are fascinated by bitcoin.
But you do see an effect for sure on deepbits hashrate. I find it most noticeable there. They are down ~800GH/s from normal.
|
|
|
|
Very nice!!!
I would however suggest that the "effective difficulty in the second chart should be a moving average (so datapoint no. 1 in the chart should be the average of blocks -99 to -50, supposing that block 0 is the latest block, block -1 is the last but one block, and so on). So, even if you don't have data older than 50 blocks behind on the chart, this line should be affected by this older data.
This would normalize the curve, instead of it starting at a low point when the -49 block was a lucky one and starting at a high point when the -49 block was unlucky.
I hope I'm making myself clear.
Also, a bigger y-scale (double it maybe) will show the fluctuations of effective difficulty more pronounced and clear.
Keep up the good work.
This questions is furthur addressed here: https://bitcoin.org.uk/forums/topic/214-replies-to-questions-asked-in-other-forums/ |
|
|
|
I've tested both latest stable and trunk. Still hunting the bug...
anything in error logs from the webserver? What happens if after the 10th block you run pool_update.sh by hand from the command line. Does this give any errors? |
|
|
|
Hmmm... the link doesnt work for me... maybe you can quote the important parts of the text ? Out of curiosity... what would be the point of you hopping PPLNS or PPS variant pools (hypothetically speaking) ? |
|
|
|
Nice graphs... looking forward to it...
Something strange happend when running this frontend. After 10 blocks it stops payout to miners and doesnt show transaction history. I've done two fresh installs and get same result after 10 blocks.
Any ide what can be wrong?
Keep up the good work.
which version are you running? Hard to say really what the problem might be without knowing your exact setup... |
|
|
|
Hoppers steal money from other miners is a MYTH shouts one of the most well known hoppers on this forum...  If everyone leaves hopper friendly pools but hoppers you guys are kinda screwed arent you? You will end up mining like everyone else for a fair and ethical payout you deserve instead of exploiting the system for your own benefit at the expense of others. |
|
|
|
Very nice!!!
I would however suggest that the "effective difficulty in the second chart should be a moving average (so datapoint no. 1 in the chart should be the average of blocks -99 to -50, supposing that block 0 is the latest block, block -1 is the last but one block, and so on). So, even if you don't have data older than 50 blocks behind on the chart, this line should be affected by this older data.
This would normalize the curve, instead of it starting at a low point when the -49 block was a lucky one and starting at a high point when the -49 block was unlucky.
I hope I'm making myself clear.
Also, a bigger y-scale (double it maybe) will show the fluctuations of effective difficulty more pronounced and clear.
Keep up the good work.
Y scale is now selectable by zoom method... click and drag your mouse on the graph to soom in on the y axis. |
|
|
|
Might check it out. Just brought a 1.21 jiggahash rig online today.
Please do... you are more than welcome! |
|
|
|
Can charities donate some hash power for a day to help people with experiments,maybe? Just curious :-)
 err nevermind  .I guess this isn't really the place to discuss such matters.Sorry for any confusion caused by my query.I've dropped the idea as this isn't the proper place to ask.I can't find anywhere to help that I know of so I just assumed that a charity could somehow help (thats whats made me ask the question in the first place). oh sorry... was just meant to be three question marks since i didnt really understand what you were asking what kind of help were you looking for ? |
|
|
|
Can charities donate some hash power for a day to help people with experiments,maybe? Just curious :-)
|
|
|
|
Just thought i would share some of the new graphs ive been working on and just implemented in the pool. Screenshots below:   More to come... I promised eye candy... well this is the start of it. Login to your account to check these graphs out live. |
|
|
|
Software, hardware, and network failures do not follow the binomial distribution of solving bitcoin blocks. Lumping them in as if they were recurring phenomena subject to a known distribution is just pseudo-math.
Without having precise details and reports on failure dates, times, and durations for each pool its impossible to do anything other than lump them in. As long as this is done for ALL pools, its fair, isnt it? The point im trying to make is that removing REAL occurences that affect availability and earnings only because they cant be predicted or determined to be recurring isnt really the right way to determine where to mine (or not to mine) either. Your method suggests to completely abandon meaningful data simply because it may be phenomena (at least if if understand you correctly). It could also be incompetence, you know (which does tend to be recurring and probably even with a known distribution) |
|
|
|
|
Show Posts
times have shown that PROP pool are what ppl like if you sum all prop pools is a large part of the network, if there was no PROP pool then i will hopp PPLNS/SMPPS pools 
