Author

Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 701. (Read 2591919 times)

legendary
Activity: 2576
Merit: 1186
There are hundreds of P2Pool nodes (my node has heard of 292 active in the past day). Does any pool have a network link that can sustain multiple gigabits per second?
Eligius's last DDoS was over 30 gbit/sec. It didn't stop until we overcame it.
hero member
Activity: 516
Merit: 643
It's trivial to get the IPs of every p2pool miner, and spread the DDoS across them. Many (most?) mining pools can withstand far more bandwidth being thrown at them, than the equivalent in miners' connections, so the DDoS will require less bandwidth to pull off. Furthermore, since such a DDoS takes out the miners' connection, it effectively prevents any failover including solo mining.

To contrast, not only do other pools have higher DDoS resistance in terms of bandwidth, but they generally keep their miners' IPs private, so when/if the pool goes down, the miners are free to failover to another pool.

There are hundreds of P2Pool nodes (my node has heard of 292 active in the past day). Does any pool have a network link that can sustain multiple gigabits per second?
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Though ... the IP address of a non-p2pool pool is even less than trivial and doesn't require running p2pool and waiting and hoping to get everyone on p2pool to connect to you.
You get the IP address pretty much immediately when you want to start your DDoS attack and thus leave no pre DDoS trail ...
legendary
Activity: 2576
Merit: 1186
Quote from: Luke-Jr
Uh, what? p2pool is more susceptible to DoS than other pools...

Would you mind explaining how/why?  I usually think of a typical DDoS attack against a public mining pool address, perhaps you are referring to a different DoS method that I'm not considering.
It's trivial to get the IPs of every p2pool miner, and spread the DDoS across them. Many (most?) mining pools can withstand far more bandwidth being thrown at them, than the equivalent in miners' connections, so the DDoS will require less bandwidth to pull off. Furthermore, since such a DDoS takes out the miners' connection, it effectively prevents any failover including solo mining.

To contrast, not only do other pools have higher DDoS resistance in terms of bandwidth, but they generally keep their miners' IPs private, so when/if the pool goes down, the miners are free to failover to another pool.
donator
Activity: 362
Merit: 250
Quote from: Luke-Jr
Uh, what? p2pool is more susceptible to DoS than other pools...

Would you mind explaining how/why?  I usually think of a typical DDoS attack against a public mining pool address, perhaps you are referring to a different DoS method that I'm not considering.
hero member
Activity: 516
Merit: 643
The bug I discovered in Bitcoin has no affect on or relationship to P2Pool. (:
legendary
Activity: 1540
Merit: 1001
Wonder if he "discovered" it by having p2ppol do something that essentially dos'ed itself and causes some of those long block problems?

You mean the 33 hour one? 

Horrible luck for 300+ g/h.
hero member
Activity: 682
Merit: 500
hero member
Activity: 658
Merit: 500
Wonder if he "discovered" it by having p2ppol do something that essentially dos'ed itself and causes some of those long block problems?
donator
Activity: 362
Merit: 250
https://bitcointalksearch.org/topic/ann-critical-vulnerability-denial-of-service-attack-81749

I hope everyone has upgraded to 0.6.2.  If not, do so right away!

And thanks for Forrest for finding and reporting this issue!


+1 thanks Forrest!
staff
Activity: 4284
Merit: 8808
https://bitcointalksearch.org/topic/ann-critical-vulnerability-denial-of-service-attack-81749

I hope everyone has upgraded to 0.6.2.  If not, do so right away!

And thanks for Forrest for finding and reporting this issue!
legendary
Activity: 2912
Merit: 1060
Pull: https://github.com/forrestv/p2pool/pull/24
Test: http://bitpoppool.geekgalaxy.com:9332/static/

Hi
Is it possible to add the http://p2pool.info/favicon.ico from p2pool.info to the actual p2pool gitgub fork? Allso i like the way the actual hashrate can be reviewed for any timeperiod there, would be great to have that for a p2pool node aswell..

Thanks in advance
hero member
Activity: 585
Merit: 501
Hi
Is it possible to add the http://p2pool.info/favicon.ico from p2pool.info to the actual p2pool gitgub fork? Allso i like the way the actual hashrate can be reviewed for any timeperiod there, would be great to have that for a p2pool node aswell..

Thanks in advance
hero member
Activity: 504
Merit: 500
Scattering my bits around the net since 1980
Is there any way to identify which rig, or even better which gpu is responsible for my orphans/stales ?

which miner?  cgminer and guiminer both list the accepted and rejected blocks per gpu.

phoenix 2.0 doesn't seem to be as friendly.
You could set each miner up with a different deposit address as the username. Then they would show up seperately on the graphs.

-- Smoov
legendary
Activity: 1540
Merit: 1001
Is there any way to identify which rig, or even better which gpu is responsible for my orphans/stales ?

which miner?  cgminer and guiminer both list the accepted and rejected blocks per gpu.

phoenix 2.0 doesn't seem to be as friendly.
hero member
Activity: 682
Merit: 500
That seems to be right. The stales will be higher with a higher intensity, but the hashrates will be too. Typically I use a little lower to cut the orphans.
I'm pretty sure that a lower intensity doesn't do anything to help lower orphans; it's simply to reduce your DoA rate so that you're not wasting as many hashes.

I coulda sworn it was the other way around. Oh well. Either way, it helps keep rejects down, and my payrate up. Wink
hero member
Activity: 686
Merit: 500
I'm loving this day long round! (Yes, I went there)
hero member
Activity: 591
Merit: 500
That seems to be right. The stales will be higher with a higher intensity, but the hashrates will be too. Typically I use a little lower to cut the orphans.
I'm pretty sure that a lower intensity doesn't do anything to help lower orphans; it's simply to reduce your DoA rate so that you're not wasting as many hashes.
hero member
Activity: 682
Merit: 500
That seems to be right. The stales will be higher with a higher intensity, but the hashrates will be too. Typically I use a little lower to cut the orphans.
hero member
Activity: 697
Merit: 500
I just redirected a pair of rigs @ p2pool as a trial run to monitor bandwidth consumption and BTC throughput. Does the below output look ok?

2012-05-12 20:39:29.682525 P2Pool: 17410 shares in chain (9724 verified/17414 total) Peers: 10 (0 incoming)
2012-05-12 20:39:29.682617  Local: 4445MH/s in last 10.0 minutes Local dead on arrival: ~2.6% (1-5%) Expected time to share: 11.8 minutes
2012-05-12 20:39:29.682643  Shares: 13 (2 orphan, 0 dead) Stale rate: ~15.4% (4-43%) Efficiency: ~95.2% (64-108%) Current payout: 0.0798 BTC
2012-05-12 20:39:29.682673  Pool: 353GH/s Stale rate: 11.1% Expected time to block: 5.9 hours


Just synced the server running p2pool with ntp and have ntpd running, not sure if that was the cause of the orphans. I think my intensity is set too high(9) on one of my boxes which might explain the stale rate?
Jump to: