Correct me if i am wrong, but mmc is a hoppable pool no?
Ill jump in here briefly to correct you. No its not. We implemented PPLNS 1 week ago. No longer hoppable.  |
|
|
|
Instead we can look at how close each pool comes to the expected block solves for a perfect pool with zero hardware, software, and network failures. Then we can have a degree of confidence about expected performance in practice. Wasnt that the whole point of this exercise anyway (and the original post for that matter?) And if not, why not? What do I, as a miner, care about your hardware, software, or network failures? I want a return on my electricity costs + margin and the rest is your problem and why i pay you a fee/donation. I dont care about normalized statistical calculations about the probability of x and y happening if the end result is the pool solving less blocks than expected or hoppers stealing a share of my earnings. Judging from the growth we have seen at Mainframe, im guessing we arent the only ones with this viewpoint. I think we need to remember that whether or not Vladimir's math and methods are 100% agreeable to everyone, the basic point of what he was trying to say is valid and sound, good advice for miners. Beware pools which appear to under earn and pools which allow hopping (unless you plan to hop yourself). Not because they are evil or cheating or anything else (while its possible they could be) but because it eats into your earnings. This is just common sense and good advice and all the math in the world cant replace it. |
|
|
|
I realy like mmcFE becouse its so clean. But i have a suggestion to get rid of all hardcodes stuff for bitcoin, maybe a drop down in Admin panel where admin can choose from diffrent coins (BTC, NMC, SC) and according to the choice it will load a special include for that coin. Keep up the good work To be honest i dont really have any interest in other blockchains but as this is open source anyone can help to grow the project and add functionality. |
|
|
|
just the Includes Path in api.php has to be set  Oh yes! forgot about that one... |
|
|
|
All credit should go to AnnihilaT really. Thanks for the kind words, Vladmir! But we've gotten this far together and with the support of the miners who believed in us. All credit goes to all of us in an equal share (thats fitting). Viribus Unitis! This just proves Vladimirs technique works (injecting massive hash rates into startup pools)
critics who were doubting the sanity of people who would buy such a service, should rethink their position
Top 10 pool in a bit over a month, from absolute zero to near 200ghash/s. Thank you for the kind words. I would like to shout this from a rooftop! Vindicated! jk  |
|
|
|
v2.1.23-stable released. Notable changes include:
- style and layout updates
- changes in terminology
- expanded ledger and record keeping
- automatic shares per block count
- paginated transaction history
- !! new site reward system. Cheat Proof PPLNS implemented !!
- better sanitation of some user definable variables
- new stats and graphs
- better handling of orphaned blocks
- minor bugfixes affecting implementation on different linux distros
Anything changed with the database? As in, whats required for a server already running v2.1 to upgrade to the latest greatest? nothing afaik. should be plug and play. save your templates folder and the rest should be able to be overwritten. Make a backup to be sure! |
|
|
|
you two should get a room ! |
|
|
|
yes anni, curl is installed and located in usr/bin/curl but the error appears on line 28 means: if (intval($ticker_obj->ticker->last) > 0) {thanks for the update Oh thats not really an error. Thats mtgox blokcing you because you are hammering their webserver too often probably. How often are you calling ticker.php? Should be at most once per 60 secs. If you get that error it means a failure communicating with mtgox. mtgox api did not return a value greater than 0 in time. Run the curl command by hand and see if it works and what message you get. This is trivial and must be something simple. |
|
|
|
|
v2.1.23-stable released. Notable changes include:
- style and layout updates
- changes in terminology
- expanded ledger and record keeping
- automatic shares per block count
- paginated transaction history
- !! new site reward system. Cheat Proof PPLNS implemented !!
- better sanitation of some user definable variables
- new stats and graphs
- better handling of orphaned blocks
- minor bugfixes affecting implementation on different linux distros
|
|
|
|
do you have curl installed ? and is the curl binary where the script expects it to be $mtgox_ticker = exec("/usr/bin/curl -q -s --connect-timeout 3 'https://mtgox.com/code/data/ticker.php'"); |
|
|
|
|
oh yes thanks for that... i have two threads to maintain and sometimes forget about this one when i update the main one.
|
|
|
|
So if I assume a rate of 6 blocks found per hour, I should see my balance increase when about 20 hours have passed? Eagerly awaiting my first bitcoins on Mainframe MC Yes thats exactly how it works (and pretty standard practice btw because the pool doesnt actually receive the coins until 120 confirms are made so unless it bankrolls the payouts itself it doesnt have the funds to pay you until it gets paid). Welcome to the pool, btw! |
|
|
|
yes that's correct I have some mining equipment for sale if you are in holland pm if you need more ... cheers! |
|
|
|
|
To all: if you plan on running a pool publicly i would kindly ask that you replace the header background image with nothing or something of your own. This is in your own interest as well. We dont want a buncha pools out there all having the same "branding"
|
|
|
|
Any plans to add MMC to the list (see sig.)
If you can post the info for me using the terminology of my table, I'll add it. No disrespect intended here, it's simply that I've found that trying to track down the information individually for so many pools, and then translating it into the standard language of my table is MUCH more time consuming than is necessary. I simply don't have the time to join every pool to figure out the features or read all the pages and pages of pool threads to track down the most up to date answers. However, if each pool expert can simply come here occasionally and give me their information in an organized post, I can easily add it, and everyone benefits. Here you go! Location: Europe Type: PPLNS (proportional per last N shares) Fee: 0.5% Transaction fee: kept by pool Transaction fee on withrawal: .005 BTC (instant payment) .0005 BTC (auto pay) Decimal places paid out: 8 wenpage ui: yes long polling: yes auto payout threshold: yes, configurable instant payout button: yes share validation: 120 multiple workers per user account/address: yes e-mail isn't username: yes e-mail notification on idle: coming soon JSON API: yes HTTPS (SSL): yes IPv6: no wallet address change security features: yes GUI preset support: no additional features: cheat proof, graphs, embedded forum address:port - mining.mainframe.nl:8343 |
|
|
|
Not entirely accurate. WIthout going into details, there are things which can be done to minimize and practically eliminate a block your pool has found from being orphaned (strictly speaking about BTC here and not other shitcoin chains).
Yes, what I said was entirely accurate, and I'll re-word it in case I wasn't clear enough. You cannot eliminate invalids. You can, at best, reduce them. fair enough. |
|
|
|
Yep that is, "you treat invalid blocks incorrectly" stance. I got it. But how am I supposed to handle it? From my point of view, if a pool got invalid block it is pool operator's fault
No pool can eliminate invalid blocks. Invalids are expected and are a direct consequence of the 10-minute target and network propogation effects because solved blocks do not propogate instantly to every node on the network. Another blockchain with a lower target speed, say 3-minutes, would expect to have more invalid blocks. Your spreadsheet is slightly inaccurate because you are including invalids in the 'actual' column, but not in the 'expected' column. Until you can compensate correctly for the 'expected' number of invalids, it's best to leave them out of the 'actual' column calculations. Is there any non-falsifiable proof that a given block *was* actually invalid? Yes. Although it could take some research, i should think that it should be able to be verified by collating data from other pools and blockexplorer if a pool has falsely marked a block invalid/orphaned. |
|
|
|
Yep that is, "you treat invalid blocks incorrectly" stance. I got it. But how am I supposed to handle it? From my point of view, if a pool got invalid block it is pool operator's fault
No pool can eliminate invalid blocks. Invalids are expected and are a direct consequence of the 10-minute target and network propogation effects because solved blocks do not propogate instantly to every node on the network. Another blockchain with a lower target speed, say 3-minutes, would expect to have more invalid blocks. Not entirely accurate. WIthout going into details, there are things which can be done to minimize and practically eliminate a block your pool has found from being orphaned (strictly speaking about BTC here and not other shitcoin chains). In very simple terms its just making sure that you arrange very good connectivity between your pool and as many other nodes on the net as possible (especially the other largest nodes and especially geographically well spaced out). To see some effects of doing this, have a look at this post: https://bitcoin.org.uk/forums/topic/117-mmc-one-of-the-fastest-bitcoin-mining-pool-in-the-world-with-a-proof/You can see that in many cases Mainframe is the first to announce a new block to the network even when we didnt even find it. Of course this can depend on the location from which these measurements are taken but i think it illustrates my point that measures can be taken and gives evidence that those measures can be effective. |
|
|
|
|
I actually didnt follow the whole solidcoin thing much at all... Did anyone make any substantial money from it (other than 3phase) ?
|
|
|
|
|
Show Posts
