Is there a maven repo I need to add to build the java client? It's not finding the required bitcoinj version.

Donation requirements for perks have been reduced.

They are now as follows:

API: 0.20% (was 0.25%)
Easy Mode: 0.40% (was 0.50%)
Non-stop Minting: 0.10% (no change)
Prepay: 1.20% (was 1.50%)
Team Effort: 0.10% (was 0.50%)
Pro Minter: 1.75% (was 2.00%)

I would have thought stratum on port 443 would pass the firewall, but it's possible it will notice that stratum is not TLS (https). However getblocktemplate on port 80 I'm pretty sure will work, because getblocktemplate IS http. You'll probably need to force your mining client to use getblocktemplate and not try to switch to stratum on port 3333 though.

That said, mining at work is not a good idea unless you have permission.

stratum+tcp://mint.bitminter.com:443
http://mint.bitminter.com:80 (add options to force getblocktemplate or disable stratum, so your client won't switch when the server says "by the way, we have stratum on 3333")

Some clients/hardware today may only support stratum.

Of course you can. It's a game of probabilities. The probability that your mining effort produces a block that ends up on the blockchain versus the probability that you produce a block that does not (orphaned, invalid, doesn't matter). If you reduce the orphan rate a little at the cost of possibly increasing the invalid rate an extremely tiny bit, then the end result improves. Mining invalid data and orphaned blocks is the same: you end up with nothing.

But even a big pool will only save a couple blocks per year, so it is perhaps not worth discussing further.

I didn't mean to derail the thread.

If a big pool got hacked you might be mining on invalid data from the time you submit their block to your local bitcoind and until you get the response back that it rejects the block. After that you switch to building on the previous parent block and mark this pool as untrusted so it won't be repeated.

About 100 times per day you get a sub-second advantage to avoid creating an orphan race. And very rarely, probably less often than once a year or maybe never, you mine invalid data for a sub-second. For every invalid block you mine, you have avoided 36 500 orphan races, of which you would have lost more than half because the other guy had a head start. Sacrifice one block (or likely zero) to save 20 000.


In the rare event that an invalid block might be created, it's not going to reach SPV clients.

Verification doesn't need to be 100%. You can check that the difficulty (bits) is correct, that the generation transaction pays to a known address used by a "trusted" pool, and that the block hash is valid at this difficulty. So an attacker could mine an invalid block and cause you to mine invalid data for less than a second. That's a cost of over 25 BTC to them. They could repeat it for every trusted payment address you have, but no more than that.

Say you trust 4 sources. An attacker could spend over 100 BTC to make you mine invalid data for maybe one second in total. A smarter attacker would use blockwithholding instead, making you lose not 1 second of mining but 4 blocks (average) worth of mining effort, which is much much more than any pool does in 1 second.


I don't see how it undermines the security model of Bitcoin. If you mine a block before the parent is verified by your own bitcoind you could wait until that happens before sending your new block to the relay network. That way an invalid block never leaves your pool. This way others on the relay network will only see the first invalid block from someone else. You will never add another invalid that they will see.

Say you get blocks from trusted sources 100 times per day and it saves you a total of 25 seconds of mining where you would have entered an orphan race and the other guy has a head start. Maybe 15 seconds where you would have lost an orphan race if you had gotten a block. That's an hour and a half of worthless mining saved per year.

You are right there isn't much to save. For most pools 1.5 hours of mining per year isn't a lot of blocks. While I'm pretty sure this would be of help and not do any harm, the benefit probably doesn't outweigh the effort of implementing this, which is why it has just stayed an idea.

Would something similar to this relay network be useful for the p2pool share chain?

I'm still just using addnode. I was planning to build the client into my mining server code. But since it is taking me a while to get around to it, I should probably just set up the standard client in the meantime.

Here's how I think a last bit of performance can be squeezed out of this:

Identify blocks coming from the biggest pools, by coinbase address and/or signature. If not recognized consider the source unknown and untrusted.

For known sources, keep track of how many times your local bitcoind accepts and rejects blocks from this source. Sources with 10+ accepted blocks and zero rejected are considered trusted. Other sources are untrusted.

When you receive a block from a trusted source, start building on top of it immediately. Still submit the block to local bitcoind for full verification. If bitcoind rejects the block, push new work data to miners to immediately go back to building on the previous parent block.

Possible issue: some getwork clients will get confused about what is old vs. new work when you send work data it has previously seen. They will get stuck DoSing the pool requesting new work over and over as fast as they can until there is a new block change. I'm not sure if any getblocktemplate clients have issues with going back to "old" work. Maybe they can get stuck mining on the invalid block, thinking it is the latest work? They'll probably be fine, but I need to find out for sure. Stratum clients, using only a single TCP connection, should be fine.

Thoughts?

Thanks for this great service, Matt.

I've been using the relay network since it was first announced. The only problem I can report is that I began getting the blocks so quickly that blockchain.info marked a lot of blocks as coming from my pool when they did not. 

I don't think the focus should be on blaming anyone at all. I think the focus should be on finding the problem and fixing it. I think the best way forward is to let the pool op figure it out. That's probably the only person(s) who can.


I do fix my own pool when bugs are found. I've been running Bitminter for over 3 years, written all the software myself, including a mining client. Of course there have been bugs. Of course this pool will also have bugs. Finding and fixing them is a good thing.


This is why I posted. People are saying that while Multipool mined here all users were paid less for their work. That's not possible in a PPS pool without the pool having an issue. Anyone who don't believe me, now is a good time to read up on what PPS means.

There will be some bugs along the way. That goes for all pools. It's not necessarily "shotty coding" as you call it. All code has bugs.

I don't know what ratio of hardware errors is normal on S1. But zero is a good thing.

You may need to run it longer than 14-15 minutes to see how it performs, though.

Bitminter has stratum on port 443 and getblocktemplate on port 80.

I had no issues when Multipool was on Bitminter. CPU load on the server didn't move at all. Nothing.

If the pool has a bug where it stops paying users, then the bug needs to be fixed. That's where the focus should be, not on blaming people who were there at the time because it could be them that tripped over the bug.

Yes, the more work you do the more you get paid. But the pay for each proof of work is the same. There's no bonus for doing lots of work, or punishment for doing little work.

Why do you need the shifts filled? Each proof of work in a shift is paid the same amount. The pay per proof of work is not affected by how much you mine in a shift or how many shifts you mine. All work is paid the same fair way. It's easy to get tricked by the payout per block to think you get bad pay until you mined 10 shifts. But this is incorrect.

That said, I am thinking of reducing the length of each shift.

The problem is that there are two psychological issues with shift lengths. The one above is what you get with long shifts. With short shifts you increase the chance of a shift with zero pay. Seeing a shift with zero pay triggers some very strong reactions with some people - even to the extent of claiming they got ripped off and leaving the pool. In reality it's just a little more variance. High paying and zero paying shifts even each other out just the same way shifts with high payouts and tiny payouts do.

Then there are the real issues of shift length: how long does it take from I do some work until I get paid, and how is the short-term variance affected? But in reality I think the two perceived issues above are more important than these two real issues. If people perceive them to be important and real problems, then that's what they become.

We have to strike a balance between long and short shifts. Currently the work in 10 shifts equal 4x difficulty. Should we go to 2x diff or 1x diff?


Cheaper perks are coming soon.

What does the blue screen say? Does it mention a driver?

I take no responsibility for this


Same as any pool but connect to stratum+tcp://mint.bitminter.com:3333

I hope those don't need a proxy, like older ASICminer machines.

So new drivers are not causing it.

Probably overheating, if you are mining on the graphics card.

Did you install new graphics drivers? Maybe they are not working right.

Or your graphics card is overheating.

CPU mining became obsolete in 2011 and GPU mining in 2013. People use ASICs now.

The client actually still supports OpenCL-capable graphics cards. But you will spend more on electricity than what you earn, so the more you mine the more money you lose. And it is also so incredibly slow that you will never earn enough to actually cash out. I should probably disable GPU mining in the next version.

Apparently your graphics card doesn't support OpenCL. No big loss as it wouldn't make sense anyway.

There's a list of ASIC bitcoin mining hardware you can buy here:

https://en.bitcoin.it/wiki/Mining_hardware_comparison#ASIC