Topic: Defending against Selfish pools with BFGMiner and GBT (Read 3144 times)

Dweebs 

Not heard that word for years.....

I can't comment on the KnC I know there have been an assortment of firmware issues there, but a significant fraction of the total p2pool hashrate is asicminer blades. The asicminer blades are getwork only and violate the getwork protocol by always returning diff 1 shares no matter what you ask for, this doesn't goof up most centralized pools since they only return diff1 getwork.  On p2pool you can tell p2pool to fix the pseudoshare diff to 1 (add +1 to the miner username) or you can run the asicminer blades through a proxy (e.g. bfgminer) that actually fixes the protocol.

[Also: you dweebs have totally taken this thread off-topic, shame on you.  I posted about some decenteralization improvements that you can do _other_ than P2pool and you flood it with complaints about P2pool]

I've been mining on p2pool since autumn 2011 with GPUs, FPGAs and now ASICs...

spiccioli

Ah, another armchair miner.    

So it's all slush's stratum proxy's fault?  So explain, Brianiac, how p2pool STILL doesn't work when you run the ASICMiner Blade on p2pool's getwork interface.  Or how it still doesn't work when using BFGMiner's getwork proxy?   Or how the Blades work on every other pool without issue?   No?  No answer?  Thought not.

A thousand times. And I'm an ex-p2pool user & die hard fan.

If half as much effort was put into R&D of p2pool as is put into blindly defending it & blaming everybody else for its faults - p2pool would be THE Bitcoin mining pool.

BS,

the problem is not on p2pool's end but on the way asicminer blades (and more in general slush's stratum-proxy) and KnC units before 0.9.6 (or .7) firmware behave when a new block comes in.

spiccioli

This a hundred times.  Thread over.

I don't own any blades or KNC, but with BFL and few USB erupters it's working pretty fine.
And I'm running it on an old laptop. Uptime of the machine is 88 days now, bfgminer 39 days.

Setting up the p2pool itself was easy, most complicated part for me was the automation (like auto-restart of all mining related processes), and if anything happens (long term power outage for example), all I need to do is push the button and everything will start itself in the right order.
The only drawback is my crappy and unstable DSL connection. As soon as enough peers connect to me, it crash and come up with new IP address.

To get back on topic, I wasn't aware of this feature of GBT protocol in combination with solo fallback. It's brilliant .
Disadvantage of GBT is higher load on both sides (pool and miner), so I'm not sure that pools will support it if significant part of the miners switch to it.

I came to this conclusion from experience - not "data". I too ran p2pool for a long time back in the days of gpu minig & recently with the newer ASICS hardware, but gave up on it because it simply is not compatible - a quick read through of the p2pool thread tells you this. I managed to get my node working very well on a low powered rig, but was unable to use most of my hardware on my own node - it's false economy, so I shut it down.

P2pool is a brilliant idea that works badly I'm afraid. Having said that, I'd use it tomorrow if it was fixed/updated/developed a bit quicker, simply because of it's decentralised nature as you mentioned.

Peace.

Well, no.  He's right, p2pool doesn't work on ASICMiner Blades, on the KnC machines...

p2pool also doesn't work for shit unless you're running it on a beast of a machine.  I'm talking fast i3 at the bare minimum.  I ran a p2pool node for a long time, and I just couldn't be bothered with it.  I had to run a dedicated machine using ~80W to host the node.  I was only putting 30GH though it, if I were running decent hashrates I don't know what sort of machine I'd have to run.  I tried it on lower powered machines, and the latencies were totally off the charts.  The 3.3GHz i3 with SSD drive was the only machine that would run it properly.

I loved the idea of p2pool, it's just a shame it hasn't kept up with the hardware people are using.  That's why p2pool is only running around 30-40TH.  If it worked better, more people would use it.  Out of all the people mining, how come there's only about 40 nodes that have any decent hashrate going though them?  Heck, the top hashing node is only 4TH...that's low.

You're high if you think p2pool is a good for option for those mining with ASICs. 

Most modern hardware works absolutely fine with it, your data is outdated. I have multiple avalons on it and am slightly ahead of expectation. Were it not so it wouldn't have 28TH/s right now— significantly more hashrate than the whole network had at the beginning of the year, with an expected two blocks per day.

But indeed, it's a smaller pool and has its own setup costs (including the cost of cutting through misinformation like the claim that it doesn't work well with most modern hardware... which is why I'm posting about _other_ things you can do.

P2pool is a no-go for small miners & most modern hardware does not work well with it - that's why people don't use it. Hopefully that will change within the next  3 6 8 months or so. Until then, there are plenty of other pools to use.

I wish it were so, but people have odd pool preferences... and there are bunch of people who run a local bitcoind/bitcoin-qt as a wallet. But want to stay on some pool
Perhaps, but small pools are a different tradeoff, and the authors of the paper argue that it works for any size (Eh. no comment on the merit of that claims). Really the only cure for misbehaving is to control your own mining (e.g. with P2Pool) but local announcement is nice. BFGMiner will also detect pools trying to mine forks on themselves and prevents that. In any case, people have diverse preferences and I thought it was important that there were things you could do to improve the situation without going all the way to P2Pool.

Just having a bitcoind running and having solo mining setup as a fallback would be good for the network's security, since DOS attacking pools would have less effect and if several started misbehaving you'd be ready to switch.

Nice, but you have to have a bitcoind running somewhere, which most of the miners don't have or they would already be going the p2pool route...

An even easier solution is to stop being a lemming and start mining on a smaller pool, it does not really matter which one, just avoid mining on the PH one...

spiccioli

So you've seen the much hyped "Selfish miner" attack paper, and like a good Bitcoiner you're not falling for the hype...  But, maybe it has you a little concerned... after all, we've got massive hashpower consolidation and the risk that mining becomes more consolidated in the future is a real risk, though a distant and general one, which concerns most of the Bitcoin technical experts even if the paper isn't all the media hypes it to be. You think Bitcoin is an independent good regardless of your short term income and you don't want a pool you're using engaging in secret strategic mining that ultimately harms Bitcoin.

Ideally, for the long term health of Bitcoin, you should be on a more decentralized pool like P2Pool (or solo mining) but perhaps that is too big of a change for you today, or you prefer a PPS or quasi-PPS pool.

Fortunately, you can make it much harder for a getblocktemplate supporting pool to participate in block-delaying without your knoweldge and consent:

All you have to do is configure BFGMiner for failover to solo-mining like:

This will make your miner also submit any blocks you find to your local bitcoin node, which will undermine any attempt to delay the announcement. It should also help your pool get a lower orphan rate, since it'll start the exponential spread of the block one round-trip-time earlier.