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

[jonnybravo0311]

Always nice to get one of those "surprise" blocks 

Seems to be a lot of miners panicking on other pools due to bad luck recently, which makes it even sweeter 

Yes it is .  You take a look at your front end and say, "Well, that sucks, we haven't found a block in a while." Then take a look at your wallet and see a new mined transaction and say, "Oh... somebody's orphaned/dead share found a block!"

[1715368334]

1715368334

[1715368334]

1715368334

[1715368334]

1715368334

[K1773R]

Was reviewing the code and came across this one part:

https://github.com/forrestv/p2pool/blob/master/p2pool/data.py#L152

Question: Why limit it to "50 kB of new txns/share"?

i even contacted you about that bug months ago was asking forrestv about it, but he didnt respond. created a hackish fix in my repo.

[jonnybravo0311]

And then p2pool goes and finds two blocks more.  That's a nice feeling as well .

[p3yot33at3r]

And then p2pool goes and finds two blocks more.  That's a nice feeling as well .

GET IN THERE!! 

Nomnom.......

[CartmanSPC]

Was reviewing the code and came across this one part:

https://github.com/forrestv/p2pool/blob/master/p2pool/data.py#L152

Question: Why limit it to "50 kB of new txns/share"?

i even contacted you about that bug months ago was asking forrestv about it, but he didnt respond. created a hackish fix in my repo.

Hehehe, I wasn't in a right "state of mind" back then...still questionable now.

I see that you increased it to 500 kB in your fork and imagine it was the solution to mining those "stuck" ANC transactions.

Like zvs said...probably done to avoid an orphan due to block size.

[windpath]

4 blocks in less than 24 hours, best day we have had in a very long time

[idonothave]

is there anywhere any list of hardware miners with optimal firmware and settings to be used with p2pool node?
as far as I know the only hw miner I know capable to be used with p2pool without any changes are spondoolies but I can be wrong.
is it better to let hw miners alone to mine to their own address or is it more efficient to let them mine to just one address using -a parameter?
actually I am using ubuntu node with bitcoin core v0.11.0.0-gd26f951 (I have tried some bitcoin.conf restrictive options but finaly I do not use them, I only let some addnode list) with gbt latency 0.326s (daily average), p2pool node forrests https://github.com/forrestv/p2pool (only restrict to 5 incomming nodes, adding some low latency nodes using -n) and run 3 sp20s there mining each to its own btc address. My sp20s are with fw 2.6.14 and cgminer 4.8.0 using extranonce option.

[windpath]

is there anywhere any list of hardware miners with optimal firmware and settings to be used with p2pool node?
as far as I know the only hw miner I know capable to be used with p2pool without any changes are spondoolies but I can be wrong.
is it better to let hw miners alone to mine to their own address or is it more efficient to let them mine to just one address using -a parameter?
actually I am using ubuntu node with bitcoin core v0.11.0.0-gd26f951 (I have tried some bitcoin.conf restrictive options but finaly I do not use them, I only let some addnode list) with gbt latency 0.326s (daily average), p2pool node forrests https://github.com/forrestv/p2pool (only restrict to 5 incomming nodes, adding some low latency nodes using -n) and run 3 sp20s there mining each to its own btc address. My sp20s are with fw 2.6.14 and cgminer 4.8.0 using extranonce option.

Pretty sure I was the last one to update this when the S3 came out...

https://en.bitcoin.it/wiki/P2Pool#Interoperability_table

[Duce]

is there anywhere any list of hardware miners with optimal firmware and settings to be used with p2pool node?
as far as I know the only hw miner I know capable to be used with p2pool without any changes are spondoolies but I can be wrong.
is it better to let hw miners alone to mine to their own address or is it more efficient to let them mine to just one address using -a parameter?
actually I am using ubuntu node with bitcoin core v0.11.0.0-gd26f951 (I have tried some bitcoin.conf restrictive options but finaly I do not use them, I only let some addnode list) with gbt latency 0.326s (daily average), p2pool node forrests https://github.com/forrestv/p2pool (only restrict to 5 incomming nodes, adding some low latency nodes using -n) and run 3 sp20s there mining each to its own btc address. My sp20s are with fw 2.6.14 and cgminer 4.8.0 using extranonce option.

I tried the extranonce one time when I came back from westhash after the "great spike" on my SP20's and they "seemed" to be getting less shares. As we all know this could have just been bad timing. I run them without the extranonce, doing so puts the unit back to cgminer 4.7.0. I have the same F/W as well. I run these two at around 1100 GHs with a start voltage of .62 and a max of .625. My fans are set to auto and run at "6", this might be different for you depending on you ambient room temp. The S5 I have running at the default 350 setting but with the Kano cgminer 4.9 version, the original version is crap. I average between .07 - .05 for a payout with ~3.33 TH for reference. I have got up to .1 before when people bailed on the pool in February. I point these to one address. If you are getting higher payouts please let me know.

[K1773R]

Was reviewing the code and came across this one part:

https://github.com/forrestv/p2pool/blob/master/p2pool/data.py#L152

Question: Why limit it to "50 kB of new txns/share"?

i even contacted you about that bug months ago was asking forrestv about it, but he didnt respond. created a hackish fix in my repo.

Hehehe, I wasn't in a right "state of mind" back then...still questionable now.

I see that you increased it to 500 kB in your fork and imagine it was the solution to mining those "stuck" ANC transactions.

Like zvs said...probably done to avoid an orphan due to block size.

the problem is, per default p2pool cant include a tx that is bigger than 50kB, which is a shame! usually the big txs pay very well (if they arent dust). when i was mining BTC on p2pool i was prefering big txs which paid more than smaller ones. i never included one of the big ones, but i didnt wonder back then. until i hit it again when mining ANC.

[p3yot33at3r]

the problem is, per default p2pool cant include a tx that is bigger than 50kB, which is a shame!

Is there a reason for this, & if so what is it? Would it be possible to change it & would it be worthwhile doing so?

Sorry for the rapid-fire questions......

[jonnybravo0311]

No clue why the limit... maybe it made sense when forrestv wrote the code... bandwidth limitations and transaction/share propagation speed... would be nice to hear forrest's view.  Can it be changed?  Absolutely... just add a zero to the end of it and make it 500,000.  Not sure how well the rest of the p2pool network would react to you doing that, though .

[nreal]

Its as easyer to find a block with btc conf 1000000 than nothing less, dead and orphan shares rise their heads with that setting. But im feeling that bitcoind works somehow better with stock settings or even + something. Ive found 5 or 6 blocks after may - and bfore that with 0.05 fees and so none. 182x is lucky number maybe

Stock settings might be the best?

[forrestv]

Was reviewing the code and came across this one part:

https://github.com/forrestv/p2pool/blob/master/p2pool/data.py#L152

Question: Why limit it to "50 kB of new txns/share"?

i even contacted you about that bug months ago was asking forrestv about it, but he didnt respond. created a hackish fix in my repo.

It's limited to prevent DoS attacks on P2Pool by e.g. making a bunch of fake transactions and then forcing them to be relayed across the entire P2Pool network. With this limit, an attacker can only force every other P2Pool node to download, at most, 50kB per share the attacker mines.

Given that 100kB transactions are possible, it should probably be 100kB, not 50kB, but it doesn't have much of an effect otherwise, since 50kB/share is comparable to the maximum transaction throughput allowed by Bitcoin (500kB/block).

K1773R, your "hackish fix" will result in your shares being orphaned if it ever results in differing behavior. The contents of the generate_transaction function are used to determine consensus, so if your version acts different, other nodes will see your shares as invalid.

[jonnybravo0311]

Thanks for the detailed reply, forrestv!  I appreciate that you've become more active in this thread again.  It's always nice to have the guy who wrote the code explaining it, rather than the rest of us trying to reverse engineer it in an effort to provide an explanation.

[K1773R]

Was reviewing the code and came across this one part:

https://github.com/forrestv/p2pool/blob/master/p2pool/data.py#L152

Question: Why limit it to "50 kB of new txns/share"?

i even contacted you about that bug months ago was asking forrestv about it, but he didnt respond. created a hackish fix in my repo.

It's limited to prevent DoS attacks on P2Pool by e.g. making a bunch of fake transactions and then forcing them to be relayed across the entire P2Pool network. With this limit, an attacker can only force every other P2Pool node to download, at most, 50kB per share the attacker mines.

Given that 100kB transactions are possible, it should probably be 100kB, not 50kB, but it doesn't have much of an effect otherwise, since 50kB/share is comparable to the maximum transaction throughput allowed by Bitcoin (500kB/block).

K1773R, your "hackish fix" will result in your shares being orphaned if it ever results in differing behavior. The contents of the generate_transaction function are used to determine consensus, so if your version acts different, other nodes will see your shares as invalid.

Good that we talk about it now. When i was still mining BTC with p2pool, i wondered why not all of my (sometimes bigger than 100kB) would be included in p2pool blocks. It didnt really bother me back then, as some other pool would mine them.
I think raising it (not as high as my hackish fix) would be a good addition to a future hardfork.

Im absolutely aware that i would get my shares rejected. I wasnt using it for BTC.
I wanted to mine the huge ANC stuck txs, so i had to create my own p2pool and set the limit higher.

[yslyung]

i see only 1 worker in the cmd window but i have 3 other workers total of 4 different btc addy mining at my node. if i do not set diff manually, all of the 4 different miners diff will be the same following the btc add with the highest hashrate/diff.

eg.

"New work for worker! Difficulty: 12192.630174 Share difficulty: 5341839.751636 Total block value: 25.019255 BTC including 100 transactions"

this started since the update. before it will show 4 workers work in the cmd window & their individual diff assigned automatically.

before eg.

New work for worker! Difficulty: xxx Share difficulty: 5341839.751636 Total block value: 25.019255 BTC including 100 transactions
New work for worker! Difficulty: xxx Share difficulty: 5341839.751636 Total block value: 25.019255 BTC including 100 transactions
New work for worker! Difficulty: xxx Share difficulty: 5341839.751636 Total block value: 25.019255 BTC including 100 transactions
New work for worker! Difficulty: xxx Share difficulty: 5341839.751636 Total block value: 25.019255 BTC including 100 transactions

"xxx" = to p2pool auto assigned diff to respective miner's hashrate, obviously higher hashrate higher diff & vice versa.

anyone else experiencing/noticed the same issue ?

running on core v0.11 64 bit win 7 64 bit

[rav3n_pl]

P2Pool node is regulating own diff to not get more that 1 response per second.
If all your workers have set lower diff that this - it will raise it anyway.

[jonnybravo0311]

i see only 1 worker in the cmd window but i have 3 other workers total of 4 different btc addy mining at my node. if i do not set diff manually, all of the 4 different miners diff will be the same following the btc add with the highest hashrate/diff.

eg.

"New work for worker! Difficulty: 12192.630174 Share difficulty: 5341839.751636 Total block value: 25.019255 BTC including 100 transactions"

this started since the update. before it will show 4 workers work in the cmd window & their individual diff assigned automatically.

before eg.

New work for worker! Difficulty: xxx Share difficulty: 5341839.751636 Total block value: 25.019255 BTC including 100 transactions
New work for worker! Difficulty: xxx Share difficulty: 5341839.751636 Total block value: 25.019255 BTC including 100 transactions
New work for worker! Difficulty: xxx Share difficulty: 5341839.751636 Total block value: 25.019255 BTC including 100 transactions
New work for worker! Difficulty: xxx Share difficulty: 5341839.751636 Total block value: 25.019255 BTC including 100 transactions

"xxx" = to p2pool auto assigned diff to respective miner's hashrate, obviously higher hashrate higher diff & vice versa.

anyone else experiencing/noticed the same issue ?

running on core v0.11 64 bit win 7 64 bit

Your node adjusts the share difficulty dynamically.  As your node hash rate increases, the share difficulty also increases.  Because your shares are of a higher difficulty, they are weighted more, and thus are worth more BTC each than the minimum difficulty share.  Conversely, as your node's hash rate decreases, the share difficulty decreases until it hits the network share minimum difficulty.

You can avoid this by manually setting your share difficulty using the "/" parameter:

Code:

BTC_ADDRESS/xxx

where xxx is some number.  If you want to guarantee minimum share difficulty, you can set that to 1 - which will in turn mean your worker will submit network minimum difficulty shares.

[yslyung]

hmmm, i know about the p2pool share diff which adjust dynamically if i dont add the "/" after btc add.

i'm saying that p2p does not adjust individual worker diff not the share diff.

i have more than 1 miner mining at the node but p2p cmd window shows only 1 worker not like before the update, it shows individual workers. logically it should show the number of workers with their individual stats.

for now i'm setting the worker diff manually as it does not adjust it automatically & share diff to minimum.

eg. "btc_add/1=1000" according to the miners hashrate output.


what i shappening now is that all other workers are at different hashrate so p2p should be adjusting them individually for the workers diff & share diff if left on default. but it is only showing 1 worker doing it's job and all of the workers are at the same worker diff & share diff. all workers are using different btc add & their hashrate are different too.


sorry for the confusion if there's any.