[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[twmz]

Go to http://p2pool.info/ and go through each block and look for your payout address, or go to blockchain.info and put your payout address in the search box.

I guess I'll have to dig through p2pool to see if there is a way to dump the individual user generated BTC to the logs. I'd hate to have to curl and scrape that page.

The following output gives an URL
GOT BLOCK FROM PEER! Passing to bitcoind! 74b22adc bitcoin: http://blockexplorer.com/block/00000000000000b8fea2523bd5ba56ab32e6cd6e0a1068d6f983e92074b22adc

Historically, not all blocks get announced in every p2pool node with a message like you listed there.  That has recently changed, in theory.  Once you have the block hash, you can get details of the block either from bitcoind using the getblock RPC call or from blockchain.info's or blockexplorer.com's JSON APIs.

Also, you don't need to scrape p2pool.info to get the list of p2pool block.  There is a JSON API you can just call to get the raw data if you want it:  http://p2pool.info/blocks  Of course you have to do some post processing if you are wanting to confirm that your address was paid in any given block.

[1714300736]

1714300736

[1714300736]

1714300736

[1714300736]

1714300736

[twmz]

Is there any way by crawling the p2pool logs to see when a block is found by p2pool and the reward distributed to my wallet? I'm not seeing any notifications in the p2pool logs. Trying to automate a report email so I can start gathering some mining stats with p2pool.

Another alternative to the suggestions already made is to go create a wallet at blockchain.info.  Then add your payment address to that wallet.  You can add it as a public-key-only address and just have blockchain.info monitor the address for transactions without it worrying about having it fully enabled with the private key.  They have an email notification system that can notify you when you receive a payment at that address.

[Gomeler]

Go to http://p2pool.info/ and go through each block and look for your payout address, or go to blockchain.info and put your payout address in the search box.

I guess I'll have to dig through p2pool to see if there is a way to dump the individual user generated BTC to the logs. I'd hate to have to curl and scrape that page.

The following output gives an URL
GOT BLOCK FROM PEER! Passing to bitcoind! 74b22adc bitcoin: http://blockexplorer.com/block/00000000000000b8fea2523bd5ba56ab32e6cd6e0a1068d6f983e92074b22adc

Historically, not all blocks get announced in every p2pool node with a message like you listed there.  That has recently changed, in theory.  Once you have the block hash, you can get details of the block either from bitcoind using the getblock RPC call or from blockchain.info's or blockexplorer.com's JSON APIs.

Also, you don't need to scrape p2pool.info to get the list of p2pool block.  There is a JSON API you can just call to get the raw data if you want it:  http://p2pool.info/blocks  Of course you have to do some post processing if you are wanting to confirm that your address was paid in any given block.

Thanks for the info on the JSON output from p2pool.info. I'll use that + blockexplorer to start pulling my btc output and various shares stats.

[Krak]

They have an email notification system that can notify you when you receive a payment at that address.

Blockchain.info's email notifications have always been kinda weird with generated coins for me.

[bitpop]

http://bitping.net/

[organofcorti]

I don't know if this has been covered before, but going through the results on http://p2pool.info/blocks I've noticed a few rounds with negative round shares and negative round duration. Can anyone explain this for me? Most recently occurred on block 179106.

[twmz]

I don't know if this has been covered before, but going through the results on http://p2pool.info/blocks I've noticed a few rounds with negative round shares and negative round duration. Can anyone explain this for me? Most recently occurred on block 179106.

Round duration = Timestamp of the block that was just found - Timestamp of the block before that

As previously discussed "round shares" is actually a calculated value that is derived from the round duration and hashrate during that round.

Block timestamps are not precise.  First, they are based on miner's clocks which may not be accurate.  Second, with ntime rolling, they may have been arbitrarily adjusted.  Sometimes when a block that comes very shortly after another block ends up having a timestamp earlier than the block it came after.  When both blocks happen to be p2pool blocks, that makes the round duration (and therefore, also the round shares) negative.

The p2pool.info UI just hides this oddity.  

The small variations in block timestamp go both ways.  Sometimes a block's timestamp will be a little bit ahead and sometimes it will be a little bit behind.  So these small variations average out in the long term.  They are left in the raw data so that the luck calculations will be unaffected.  For example, some rounds will be 100 shares to high while other rounds will be 100 shares too low.  Since luck is basically "SUM(shares in some rounds) / SUM(expected shares for those rounds)" it doesn't matter if the rounds are 105 + 95 or 100 + 100.  As long as the average variation in timestamp is "0", it doesn't affect luck calculations.

And yes, as has been suggested in the past, it would be more accurate to count the actual hashes in the share chain to know exactly how many hashes went into finding a block.  But there are a number of technical challenges to making that work and the improvement in accuracy isn't enough to make it worth it to me to do that work.

[organofcorti]

Thanks twmz - I thought it was something like that, and I knew I'd seen something along those lines before, but I wanted to be sure, plus your explanation was very clear.

So: 

Code:

sum(totalRoundShares)/sum(roundDuration) /10^9*2^32

should give a reasonably accurate hashrate estimate?

[twmz]

Thanks twmz - I thought it was something like that, and I knew I'd seen something along those lines before, but I wanted to be sure, plus your explanation was very clear.

So: 

Code:

sum(totalRoundShares)/sum(roundDuration) /10^9*2^32

should give a reasonably accurate hashrate estimate?

Yes, that is the reverse of what I did to get the totalRoundShares in the first place.  I take a weighted average of the hashrate data points (taken every 5 minutes) and use that with round duration to calculate the round shares.  If you are looking for the hashrate, it would be easier to just get them directly from http://p2pool.info/stats instead of reverse engineering them from the block data

[check_status]

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.

If there is consistently below average (10%) block solutions is this indicative of a possible attack?

In an attack, what would be targeted to disuade people from using p2pool? Of course, something that would effect Bitcoin generation, but what ways specifically could p2pool be attacked that would reduce coin generation?

Would an intermittent DDoS be more difficult to notice but enough to reduce coin generation?

[Clipse]

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.

If there is consistently below average (10%) block solutions is this indicative of a possible attack?

In an attack, what would be targeted to disuade people from using p2pool? Of course, something that would effect Bitcoin generation, but what ways specifically could p2pool be attacked that would reduce coin generation?

Would an intermittent DDoS be more difficult to notice but enough to reduce coin generation?

I would think that if you can get a major public list of p2pool miners you could DDOS them individually at the same time.

[streblo]

As someone who is enduring a very long sharechain download time (I'm running p2pool on a slow HD), I was curious if this patch which greatly increases blockchain verification speed has been implemented in p2pool for its sharechain?  https://github.com/bitcoin/bitcoin/pull/964

Cheers

[Tittiez]

Uh... Earthquake?

[Frizz23]

No earthquake. It's me

I started using p2pool again exactly on the day bad luck began. Not joking.

[check_status]

Something else to note Tittiez, if you check the chart times and dates at the peaks and troughs, you will see numerology. More often than not, the changes in the graph occur on 3, 6 or 9 combinations. Could it be satanic mischief? 
Ooh...Ancient Aliens is coming on UFOTV, got to go. 

[ChanceCoats123]

[Krak]

Found my first block today with only 600 MH/s.

Code:

2012-05-17 14:33:54.427996 GOT BLOCK FROM MINER! Passing to bitcoind! http://blockexplorer.com/block/000000000000039a5385626f2104f4f926df278286494eacfc29d9da90d2b2f8
2012-05-17 14:33:54.428034 
2012-05-17 14:33:54.450908 GOT SHARE! Kraken 90d2b2f8 prev 2d21468b age 6.81s
2012-05-17 14:33:54.479671 
2012-05-17 14:33:54.479814 GOT BLOCK FROM PEER! Passing to bitcoind! 90d2b2f8 bitcoin: http://blockexplorer.com/block/000000000000039a5385626f2104f4f926df278286494eacfc29d9da90d2b2f8

[Smoovious]

[/glow]

Found my first block today with only 600 MH/s.

Code:

2012-05-17 14:33:54.427996 GOT BLOCK FROM MINER! Passing to bitcoind! http://blockexplorer.com/block/000000000000039a5385626f2104f4f926df278286494eacfc29d9da90d2b2f8
2012-05-17 14:33:54.428034 
2012-05-17 14:33:54.450908 GOT SHARE! Kraken 90d2b2f8 prev 2d21468b age 6.81s
2012-05-17 14:33:54.479671 
2012-05-17 14:33:54.479814 GOT BLOCK FROM PEER! Passing to bitcoind! 90d2b2f8 bitcoin: http://blockexplorer.com/block/000000000000039a5385626f2104f4f926df278286494eacfc29d9da90d2b2f8

Woohoo! \o/

-- Smoov

[Aseras]

getting a lot of this tonight

this is someone else screwed up right?

2012-05-17 20:53:31.996000  Local: 4710MH/s in last 10.0 minutes Local dead on arrival: ~0.
2012-05-17 20:53:31.996000  Shares: 6 (1 orphan, 0 dead) Stale rate: ~16.7% (3-57%) Efficie
2012-05-17 20:53:31.996000  Pool: 320GH/s Stale rate: 10.4% Expected time to block: 6.5 hou
2012-05-17 20:53:32.163000 > Share check failed:
2012-05-17 20:53:32.164000 > Traceback (most recent call last):
2012-05-17 20:53:32.164000 >   File "p2pool\util\variable.pyc", line 34, in happened
2012-05-17 20:53:32.164000 >
2012-05-17 20:53:32.165000 >   File "p2pool\main.pyc", line 217, in <lambda>
2012-05-17 20:53:32.165000 >
2012-05-17 20:53:32.165000 >   File "p2pool\main.pyc", line 183, in set_real_work2
2012-05-17 20:53:32.166000 >
2012-05-17 20:53:32.166000 >   File "p2pool\data.pyc", line 403, in think
2012-05-17 20:53:32.166000 >
2012-05-17 20:53:32.166000 > --- <exception caught here> ---
2012-05-17 20:53:32.167000 >   File "p2pool\data.pyc", line 353, in attempt_verify
2012-05-17 20:53:32.167000 >
2012-05-17 20:53:32.167000 >   File "p2pool\data.pyc", line 247, in check
2012-05-17 20:53:32.168000 >
2012-05-17 20:53:32.168000 > p2pool.p2p.PeerMisbehavingError: Share can't follow NewShare
2012-05-17 20:53:32.170000 > Share check failed:
2012-05-17 20:53:32.170000 > Traceback (most recent call last):
2012-05-17 20:53:32.170000 >   File "p2pool\util\variable.pyc", line 34, in happened
2012-05-17 20:53:32.171000 >
2012-05-17 20:53:32.171000 >   File "p2pool\main.pyc", line 217, in <lambda>
2012-05-17 20:53:32.171000 >
2012-05-17 20:53:32.171000 >   File "p2pool\main.pyc", line 183, in set_real_work2
2012-05-17 20:53:32.172000 >
2012-05-17 20:53:32.172000 >   File "p2pool\data.pyc", line 403, in think
2012-05-17 20:53:32.172000 >
2012-05-17 20:53:32.173000 > --- <exception caught here> ---
2012-05-17 20:53:32.173000 >   File "p2pool\data.pyc", line 353, in attempt_verify
2012-05-17 20:53:32.173000 >
2012-05-17 20:53:32.173000 >   File "p2pool\data.pyc", line 247, in check
2012-05-17 20:53:32.174000 >
2012-05-17 20:53:32.174000 > p2pool.p2p.PeerMisbehavingError: Share can't follow NewShare

[Krak]

getting a lot of this tonight

this is someone else screwed up right?

I've been getting that also. Been dropping a lot of connections for a while too. Is it because we finally hit the 95% target for the protocol switch?

Noticed something else weird; my node doesn't even know about the block I found.