Thank you kindly, sirs.


I wasn't sure if I might make it tonight. But it's getting rather late now. I want to test things out a bit before making the actual switch. I also don't want to switch just before going to bed in case something goes wrong.

So most likely tomorrow evening, european time.


Doing kind of a "practice move" right now. If it works ok then the actual move should be as fast as possible.

This is perfectly correct. There are two forms of ntime rolling support, with different messages from the server:

X-Roll-NTime: Y
X-Roll-NTime: expire=N

The second form is more flexible and allows the server to tell the client how many seconds (N) forward it is allowed to increment the timestamp (ntime). The first form is the original roll-ntime which gives the client permission to increment ntime without limit. I recently looked at the source code of the latest version of a few miners and only DiabloMiner supported the "expire=N" form. Most miners will interpret the second form to mean they can roll ntime without limit, ignoring the N value.


Don't dismiss >1 difficulty. It is quite obvious that it is a useful concept. Also, both fetching new work and delivering proofs of work you found are done through the "getwork" JSON-RPC function. It's a very bad API design, but "getwork" refers to both fetching new work AND handing in results. So yes, higher difficulty does mean fewer "getwork" requests, unless miners ignore the target they are given.

Yes, using >1 difficulty WILL reduce bandwidth and CPU load on the server. Coupled with ntime rolling you can reduce the load coming from the fastest miners by a lot.

It is true that getting new work takes a few bytes more bandwidth and some CPU cycles more than delivering work results. But that doesn't mean the second is insignificant. Take a look at this thread for examples of both types of request and response: https://bitcointalk.org/index.php?topic=51281.0

Luke-jr. and I set up a wiki page showing what the different miners and servers support: https://en.bitcoin.it/wiki/Getwork_support. Hassle your favorite developer to get better support. I added "expire=N" (2nd generation roll ntime) and ">1 difficulty" columns just now.

So yes, you can optimize the hell out of fast miners. The problem is slow miners. The noncerange extension could at least help a bit on the server CPU usage they cause, but it is not widely supported as you can see in the feature tables at the wiki page.

We have had downtime and a high number of rejected proofs of work (stales) in the last days. The old server is on its last legs now. It can no longer keep up with the load produced by so many miners. There's a new server standing by to take over.

I wanted to implement support for backup pools in the BitMinter client, and I wanted to announce the move ahead of time. Sadly the situation is now that we are running out of time. The old server is almost constantly slightly overloaded. This is producing high stales and a little more load could cause more downtime again. Therefore it appears the best move is to get over to the new server as quickly as possible. I will make the switch after I have prepared everything the best I can so that the switch can be done quickly.

You may want to set up a backup pool so you don't lose any mining time during the server switch or if the old server has any more problems before the switch. I understand not everyone will be able to set up a backup and I will try to make the switch as quick as possible to minimize downtime for miners.

Sorry for the inconvenience. Things should be much smoother on the new server.

Thanks, added your thoughts to my existing plans for messages.


Welcome!

It's because the old server is still struggling to keep up.

I spent yesterday preparing the new server while at the same time trying to keep the old one afloat.

Unfortunately the new code had a rare deadlock in it, so I had to restart the back end 2-3 extra times yesterday because it would seize up. I did not want to go back to the old code because it gave higher stales. Luckily I quickly located the problem and the new version seems to have helped a lot with stales. At one point we were over 3% BTC stales. Now with the new version it seems to manage to keep it around 1%. It should be lower stales than ever on the new server.

In the middle of all that I got the new server almost ready. Now the question is, when it is ready, is there any point waiting until saturday? The old server is barely limping along, giving high stales and making miners unhappy. Not sure how long it will take to make the switch. But I don't think it should take long. Stop everything on the old server, dump the database, copy over database and wallets to new server, import database on new server, then start everything up.

Yes. And I think it's obvious >1 difficulty can reduce the number of requests delivering proofs of work from fast miners. To reduce the number of requests fetching new work for fast miners you can use X-Roll-NTime.

Dealing with slow workers (CPU miners) is much harder. Perhaps noncerange could help, but I suspect it won't do that much. The noncerange extension is also just supported by 1 miner that noone is using.

There's strong support for this from the miners in my pool, so BitMinter is now running BIP-16 enabled bitcoind + BIP-16 votes in block generation.

Just restarted the back end with a new version, with better long polling (priority for faster miners, and some tweaks), plus X-Roll-NTime support to reduce load from fast miners. Load is still high on the server, but hopefully the other changes can help hold the stales down.

Edit: Forgot to mention another important change: We are now running with BIP-16 voting. The discussion here seemed pretty unanimous in supporting Gavin and his BIP-16, so that is now in effect. We already had BIP-16 support in the server's bitcoind for a couple days, but we weren't voting until now because I had to update the block generation code.

Slow miners totally crashed the server. Getting things up again now. Please don't run more than a handful of CPU miners until we get moved over on the new server.

It's a shame so many pools are closing lately. But have fun with your son and good luck with everything.

It was funny reading your blog post. So many times I went to bed thinking I sure hope that when I wake up we have finished this long block. I hadn't thought about it before but I guess all small pool operators have it the same way.

This is certainly a good idea. I think the reason it has only been talked about in the past and never actually done is lack of support in software. I think most pool software always send a difficulty 1 target, and some/most miners ignore the target and pretend it is always difficulty 1?

Perhaps we can add a new column "variable difficulty" to this wiki page https://en.bitcoin.it/wiki/Getwork_support

Does anyone know which miners and pool programs support this?

High load causing high stales this morning. Please be careful with connecting too many CPU workers. It will be smoother after switching to the new server.

ZodiacDragon84 and DeathAndTaxes, I think those are some very good ideas about advertisements. I don't like ads much, but as long as bitcoin is small I think this could be very interesting for both audience and advertisers. I may not have time to create an automated system for some time, but if someone wants to advertise just contact me and it can be done manually.

P4man, lots of good ideas there. All noted.


BTC and NMC rounds are not always the same, starting at the same point in time. Sometimes a lone NMC block is created and the current BTC round is longer than the NMC round. It can be confusing when looking at the worker stats.


Yeah, that song is right. There's a balance to strike though between so complex it's confusing and so simple it loses its flexibility. I think just 2-3 levels is too simple. On the other hand, multiple coin types add to complexity, maybe the perks can require minimum donations of both BTC and NMC to activate.

I think http://www.humblebundle.com/ does it well. Unfortunately there's no bundle on sale as I write this so you can't play with the payment options right now.

What I'm thinking so far: A new page under "my account" -> "donations and perks" working as follows.

Perks are listed saying what they do and what they cost. There's a button to toggle them on/off. The "VIP" perk turns everything else on in addition to itself.

Donations are listed by cause. There's a + button to add more causes to donate to ("block bonuses", "bitcoin core developers", "bitcoin miners union", and so on). One cause is always listed, the bitminter main donations that give you perks, cover the expenses of running the service, and can maybe one day help me break even.

For each cause there are separate settings for each coin type (BTC, NMC). You have a box where you can type the percentage to donate and a slider you can drag if you prefer that instead. - and + buttons could go down and up 0.5%. Perhaps also a "max" button to automatically set the value+slider to the rest of your income of that coin type (that you haven't already set to donate to a different cause). Also a button to remove the cause from your list.

Turning on perks will make the BitMinter cause adjust up its value and sliders to cover the price of that perk if the setting isn't already high enough. Not sure if turning perks off should auto-adjust down. Maybe adjust down if the donation was set to exactly cover the perks. Also need to auto-disable perks if the donation is manually adjusted too low.

Perks could require X percent donation on one coin type or all. To keep it simple maybe a "pay unconfirmed blocks immediately" perk should require donations on all types and work on all types. Having one for each coin type may be more screen clutter and complexity than it is worth? At least if there are many perks and all are duplicated for each coin type. May have to think of something smart to make everyone happy there.

Mining is up. Was giving out work very slowly for a bit, but seems to be stable now.

Update: It was a dead disk on the server causing the problems. Then after things were back up the load was rather high, and still is. Still, the server seems to be coping with higher than normal load and work looks to be coming out to miners fast. Very sorry about this. Not the best of mornings.

Hmm, server went down, not sure why yet. On its way back up now but something is slooooow. I will be happy after getting over to the new server.

Hehe, funny but very true. It's a good point. I should add features like that to better leverage the existing newbie-friendly features of the pool.


If you are not deepbit it may be the only way to make a profit.

I was planning to add donation perks that activate depending on how high you set your donation percentage.


1% isn't much when you see how the bitcoin markets constantly fluctuate. The price for a bitcoin is very unstable, and if I pay out in dollars then I'm taking a considerable risk. Best bet is probably to look at how volatile the markets have been and try to find some semi-safe markup. Two possible places to collect: require donation to activate paypal payout + use the latest market exchange rate minus a percentage.


I don't think miners would want to pay $5 per SMS. But probably much more than the price I'd have to pay to send one.

This is probably best done not by donation but a feature you activate and it works as long as it can subtract the necessary sum from your balance each time a message is triggered. With a selectable limit for max messages per day.


Instant payment and paying invalid blocks is really the same feature. I was planning to activate that at perhaps 3% donation. Donate enough BTC and you get it on BTC blocks. Donate enough NMC and it works on NMC blocks.


I sometimes consider adding PPS at some high donation percentage. Maybe 7%. But PPS is very risky. Variance can cause big losses. And block withholding attacks are entirely free for the attacker if he gets paid through PPS.

Pooling PPS funds sounds a bit like SMPPS? Something like that might be doable. Block withholding could empty the pooled funds though.


Interesting. Maybe instead of different perks activating at different donation levels, you would "buy" perks with your donations. Each perk would require X percent donation, and you can freely pick the ones you prefer. And then there is the VIP package that gives you all features and costs less in donation than all the individual features added together.

Good news. New server is ready. Moving will cause a little downtime though. It's probably best to schedule this ahead of time, so people can set a backup pool or manually move to another pool during the downtime. Saturday in a week might be good?

Also, there seems to be strong support for BIP 16, so I will put those votes in. Just going to test new bitcoind + the vote change + other changes in new mining pool software. But coming soon...


Yay! Good points, I updated the subject and contents of the original post a bit, maybe it helps attract more miners.


Nicely done, sir.


Hmm. SMS notifications. Paypal payout. Added to my list.


It's a race! Will their 0.5% fee or their bonuses decide? Or maybe that old hairy monster called Variance?

This is a pretty scary thing with BIP 17.


For pools using "getwork" to create blocks this is true. Since BitMinter uses "getmemorypool" (which means it creates the generation transaction itself) to create blocks, the upgrade to a bitcoind version supporting certain features and putting /P2SH/ or similar in the generation transactions are two separate things. I just have to remember to do both.

Looks like pretty strong support for BIP 16 in this pool so far.

Actually there should also be "no vote". "Blank" meaning "I want the pool to create blank votes", and "no vote" meaning "I don't care, let the other miners decide".

I've been reading up on this now. Here are some threads I looked through:

BIP 16: https://en.bitcoin.it/wiki/BIP_0016
BIP 17: https://en.bitcoin.it/wiki/BIP_0017

Gavin Andresen (Lead Core Bitcoin Developer) trying to explain the matter in layman's terms: https://bitcointalk.org/index.php?topic=61125.0

Luke Jr (Eligius Pool Operator) explaining his side: https://bitcointalk.org/index.php?topic=58579.0

Discussion about BIP 17, Luke Jr's suggestion: https://bitcointalk.org/index.php?topic=60433.0

I think they were right to drop OP_EVAL (BIP 12) for being too risky (potential security problems). I also think bitcoin needs the increased security, escrow and other fancy stuff that comes with multisig transactions.

So, BIP 16, BIP 17, or postpone? Not sure yet.

It's very difficult to understand the different results we get from choosing BIP 16 or BIP 17. It's very technical. My pool software creates its own generate transaction, so I have at least looked at bitcoin transactions a little bit before. It seems totally confusing to me. I can only imagine how it looks to the average miner. I think only people who have been working on core bitcoin code can actually understand the issues well.

About voting with hash power, I think that can be the right way to do such changes, but pools complicate that a bit. It's a bit late now, but if there will be more such voting in the future, then perhaps it would be an idea to implement some sort of voting inside BitMinter. Say you vote on the website and the pool creates votes in the blocks we make to match how much hash power in our pool voted for the one or other option. The choices in this case would be "BIP16", "BIP17" or "blank". This would allow each miner to use their hash power the way they want.

I will get a better server and set up a donation system. I think we are large enough now that donations can at least pay part of the server costs.


To be honest I haven't had time to read up on P2SH yet. But I will do so ASAP.

Also, I don't like using other people's hash power to do something they don't like. So if you have an opinion on P2SH please let's hear it.