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.

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.

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.

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.

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 .

Jonny's Pool - Mine with us and help us grow! Support a pool that supports Bitcoin, not a hardware manufacturer's pockets! No SPV cheats. No empty blocks.

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

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.

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.

Jonny's Pool - Mine with us and help us grow! Support a pool that supports Bitcoin, not a hardware manufacturer's pockets! No SPV cheats. No empty blocks.

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.

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.

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.

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.

Jonny's Pool - Mine with us and help us grow! Support a pool that supports Bitcoin, not a hardware manufacturer's pockets! No SPV cheats. No empty blocks.

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.