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

[BTCMiners.net]

I have a question in regards to the pseudo difficulty set by the client.

Being that the share difficulty is 3x higher than it was before and I'm mining between 5,500 MH/s and 6,000 MH/s with my Jalapeno and having a poor connection at the current moment; would increasing the difficulty factor to say 4-8:

A.) Find shares more quickly?
B.) Raise my income vs running it at the default '1' difficulty

Thanks!

Anyone happen to know? /bump

[1714164714]

1714164714

[1714164714]

1714164714

[1714164714]

1714164714

[1714164714]

1714164714

[1714164714]

1714164714

[1714164714]

1714164714

[Krak]

I have a question in regards to the pseudo difficulty set by the client.

Being that the share difficulty is 3x higher than it was before and I'm mining between 5,500 MH/s and 6,000 MH/s with my Jalapeno and having a poor connection at the current moment; would increasing the difficulty factor to say 4-8:

A.) Find shares more quickly?
B.) Raise my income vs running it at the default '1' difficulty

Thanks!

Anyone happen to know? /bump

Neither one. Pseudo shares are only there to keep track of your hashrate. Increasing the difficulty will just decrease the bandwidth between your miner and p2pool.

[BTCMiners.net]

I have a question in regards to the pseudo difficulty set by the client.

Being that the share difficulty is 3x higher than it was before and I'm mining between 5,500 MH/s and 6,000 MH/s with my Jalapeno and having a poor connection at the current moment; would increasing the difficulty factor to say 4-8:

A.) Find shares more quickly?
B.) Raise my income vs running it at the default '1' difficulty

Thanks!

Anyone happen to know? /bump

Neither one. Pseudo shares are only there to keep track of your hashrate. Increasing the difficulty will just decrease the bandwidth between your miner and p2pool.

So, being that for the next 2 weeks I have a really bad internet connection; I should set my pseudo difficulty share to a higher amount so that it's not killing my internet speeds?

Also, thank you for answering my first question!

[Krak]

So, being that for the next 2 weeks I have a really bad internet connection; I should set my pseudo difficulty share to a higher amount so that it's not killing my internet speeds?

Also, thank you for answering my first question!

A higher share difficulty won't hurt anything; it'll just make your graphs go all over the place. I personally use difficulty 8 on my Jalapeno just to save some bandwidth. If you're mining on a node on your local network, however, the only thing you're really saving is maybe a tiny amount of CPU power.

[BTCMiners.net]

So, being that for the next 2 weeks I have a really bad internet connection; I should set my pseudo difficulty share to a higher amount so that it's not killing my internet speeds?

Also, thank you for answering my first question!

A higher share difficulty won't hurt anything; it'll just make your graphs go all over the place. I personally use difficulty 8 on my Jalapeno just to save some bandwidth. If you're mining on a node on your local network, however, the only thing you're really saving is maybe a tiny amount of CPU power.

I'm mining on someone else's p2pool node, which is relatively close, 1 state away.  But I have a pathetic 2Mbps and 1Mbps up until next week or two tops when I get the 75Mbps and 20Mbps up.

At that point, my RAID-1 2x2TB HDD, PCI-e 16x dual network card, 32GB of DDR3 memory and my 3.66GHz AMD Hex Core will be hosting it's own P2Pool node.  CAN'T WAIT!

I might charge a small fee, but then if funds allow I'll be placing it within a data center in the Midwest as it doesn't seem to have a lot of nodes in this general region with a good, quality connection.

[gyverlb]

This has been already discussed here. Current share "punishing" mechanism is broken. I hope forrestv will eventually notice and fix it. Until then, I just comment out those three lines which "jump" to previous share and I don't really care if anyone suffers from it.

Broken how? There's not even a bug on the bugtracker related to share punishing.

Devs don't dig in forum posts for bug descriptions unless they happen to be involved in it...

Last time I found a bug with zvs, I created an entry in the bugtracker with detailed explanations and forrestv designed a solution in a couple of weeks (which is now in place).

[baloo_kiev]

This has been already discussed here. Current share "punishing" mechanism is broken. I hope forrestv will eventually notice and fix it. Until then, I just comment out those three lines which "jump" to previous share and I don't really care if anyone suffers from it.

Broken how? There's not even a bug on the bugtracker related to share punishing.

Devs don't dig in forum posts for bug descriptions unless they happen to be involved in it...

Last time I found a bug with zvs, I created an entry in the bugtracker with detailed explanations and forrestv designed a solution in a couple of weeks (which is now in place).

Sorry for misunderstanding here. When saying "broken", I mean not broken code but wrong algorithm/strategy.

One of principal rules of mining, as I understand it, is "A miner who breaks a rule must be punished." For example, if you mine not on the latest block but its parent, or mine invalid blocks, your work will be orphaned by the rest of network.

Now consider the rule defined by those 3 lines I was talking about. It states "If a share (S) is based on stale block, mine on its parent (P)." (That's what "Punishing for block-stale / Jumping to ..." log message is about.) If a miner (either intentionally or because of slow bitcoind) disrespects this rule, not only he loses nothing, but may also eventually profit from it! Really, his share A (a child of block-stale share S, which is punished by the rest of the network) is 1 share ahead of "proper" miner's share B, which is P's child. As a result, A will have priority over B even if B is found earlier!

Should I report a bug on GitHub?

[maqifrnswa]

Sorry for misunderstanding here. When saying "broken", I mean not broken code but wrong algorithm/strategy.

One of principal rules of mining, as I understand it, is "A miner who breaks a rule must be punished." For example, if you mine not on the latest block but its parent, or mine invalid blocks, your work will be orphaned by the rest of network.

Now consider the rule defined by those 3 lines I was talking about. It states "If a share (S) is based on stale block, mine on its parent (P)." (That's what "Punishing for block-stale / Jumping to ..." log message is about.) If a miner (either intentionally or because of slow bitcoind) disrespects this rule, not only he loses nothing, but may also eventually profit from it! Really, his share A (a child of block-stale share S, which is punished by the rest of the network) is 1 share ahead of "proper" miner's share B, which is P's child. As a result, A will have priority over B even if B is found earlier!

Should I report a bug on GitHub?

I think it should be reported, at least to start the discussion

[forrestv]

P2Pool release 13.2  - commit hash: a7e081924e8bd1f3a7b57dc34499475b8cd458a5

Windows binary: http://u.forre.st/u/xypigdde/p2pool_win32_13.2.zip
Windows binary signature: http://u.forre.st/u/vuopsaei/p2pool_win32_13.2.zip.sig
Source zipball: https://github.com/forrestv/p2pool/zipball/13.2
Source tarball: https://github.com/forrestv/p2pool/tarball/13.2

Changes:
* Out-of-the-box Avalon device support - simply point Avalon devices to http://P2POOL_HOST:9332/

[lenny_]

P2Pool release 13.2  - commit hash: a7e081924e8bd1f3a7b57dc34499475b8cd458a5

Windows binary: http://u.forre.st/u/xypigdde/p2pool_win32_13.2.zip
Windows binary signature: http://u.forre.st/u/vuopsaei/p2pool_win32_13.2.zip.sig
Source zipball: https://github.com/forrestv/p2pool/zipball/13.2
Source tarball: https://github.com/forrestv/p2pool/tarball/13.2

Changes:
* Out-of-the-box Avalon device support - simply point Avalon devices to http://P2POOL_HOST:9332/

Well done!

[zvs]

i have it running now if someone wanted to test before setting up local node or something

Now consider the rule defined by those 3 lines I was talking about. It states "If a share (S) is based on stale block, mine on its parent (P)." (That's what "Punishing for block-stale / Jumping to ..." log message is about.) If a miner (either intentionally or because of slow bitcoind) disrespects this rule, not only he loses nothing, but may also eventually profit from it! Really, his share A (a child of block-stale share S, which is punished by the rest of the network) is 1 share ahead of "proper" miner's share B, which is P's child. As a result, A will have priority over B even if B is found earlier!

Exactly 

[gyverlb]

Now consider the rule defined by those 3 lines I was talking about. It states "If a share (S) is based on stale block, mine on its parent (P)." (That's what "Punishing for block-stale / Jumping to ..." log message is about.) If a miner (either intentionally or because of slow bitcoind) disrespects this rule, not only he loses nothing, but may also eventually profit from it! Really, his share A (a child of block-stale share S, which is punished by the rest of the network) is 1 share ahead of "proper" miner's share B, which is P's child. As a result, A will have priority over B even if B is found earlier!

Should I report a bug on GitHub?

You should. But read below why I think it's not high priority.

2 cases in your example:

• local bitcoind lagging: miner is punished most of the time so it is prevented to benefit from worthless work as intended and is motivated to upgrade his/her configuration
• node trying to make his share more resilient by avoiding to build on the parent share

In the "more resilient attack" the node can only attack after one out of 20 shares (30s share interval with 10mn block interval) if and only if it is from a slow node producing a stale share (assuming we don't have nodes more than 30-60s behind the Bitcoin network able to make 2 successive stale shares).

• if another node finds a share before him he will automatically switch to it as building on either fork doesn't give him any benefit anymore
• if he finds a share before the rest of the network, he won't have gained anything (he has as much chances of that happening when mining on the parent share)
• the only gain is when he finds a share that collides with another : there he will be sure to win instead of having ~50% chances

.

So someone trying this attack will get benefit for less than 5% (1 in 20 at most, probably far less) of his expected DOA+Orphan rate (which seems to be ~10% since we switched to a 30s share interval) and this benefit will be ~50%.

So in the most pathological case where 100% of the network produces stale shares (built with the previous block), the expected benefit is only 50% of 10% of 5% : 0.25%.

Most nodes probably don't produce stale shares, so this is more likely a ~0.1% advantage.

Now what is the attacker losing? If you don't punish slow nodes you are hurting yourself as much as the rest of the network by validating wasted work. The exception is the slow node which is grateful to be paid for worthless work.
For every gained share you are validating one worthless share. If everyone did this, everyone would lose money to worthless shares producers instead of gaining 0.1%. Now it's too late for me to try to estimate how much is lost but disabling the protection might not be a good idea, especially if many are doing it. It probably would end in a "tragedy of the commons": you can gain a bit by doing it, but when everyone does it, everyone loses.

Allowing worthless work allows it to rise without limits: if there are very slow bitcoinds with very high hashrate they could make 2 or more consecutive stale shares a frequent occasion and rise the worthless hashrate to 10 or more percent of the whole pool.

One solution might be to ignore stale shares when comparing the different sharechain forks. People disabling the protection would get no benefit at all.

In the meanwhile, advocating to remove the protection is an attack on P2Pool, please stop doing it unless you want to participate in your own reduced income.[/list]

[zvs]

Uh, you've got it as the exact opposite of what the reality is

Slow nodes aren't being punished... furthermore, if they found a block while generating these useless shares, then it'd be an orphaned block

[zvs]

OK, I started using the fork again to get more examples.  Not so difficult there since I get about 10-15% of the shares.

Anyway, here you go:

2013-07-20 23:37:10.117273 Skipping from block 8fb150619665d3e8d31395239d90fa377275479c6322072a76 to block 3b02efd60769dd972d8c9473a16396a47c3d4181fcdf216258!
2013-07-20 23:37:10.121500 New work for worker! Difficulty: 0.999985 Share difficulty: 64.059627 Total block value: 25.000000 BTC including 0 transactions
2013-07-20 23:37:10.284908 New work for worker! Difficulty: 0.999985 Share difficulty: 64.071125 Total block value: 25.000000 BTC including 0 transactions
2013-07-20 23:37:11.055484 Punishing share for 'Block-stale detected! 8fb150619665d3e8d31395239d90fa377275479c6322072a76 < 3b02efd60769dd972d8c9473a16396a47c3d4181fcdf216258'! Jumping from 5cfa46a1 to 1d667ebf!
2013-07-20 23:37:11.070429 New work for worker! Difficulty: 0.999985 Share difficulty: 64.059627 Total block value: 25.000000 BTC including 0 transactions
2013-07-20 23:37:11.085102 GOT SHARE! General.Butt.Naked 9036b0e9 prev 5cfa46a1 age 0.80s DEAD ON ARRIVAL
2013-07-20 23:37:11.112115 New work for worker! Difficulty: 0.999985 Share difficulty: 64.151483 Total block value: 25.000000 BTC including 0 transactions
2013-07-20 23:37:11.268987 Peer sent entire transaction 0946744912e4b00dd29396dc7a63d3fb3b46e8a7915cbdffcc02b8ea8272dcc5 that was already received
2013-07-20 23:37:12.249095 Peer sent entire transaction 0946744912e4b00dd29396dc7a63d3fb3b46e8a7915cbdffcc02b8ea8272dcc5 that was already received
2013-07-20 23:37:12.439025 Peer sent entire transaction 0946744912e4b00dd29396dc7a63d3fb3b46e8a7915cbdffcc02b8ea8272dcc5 that was already received
2013-07-20 23:37:14.459965 P2Pool: 17353 shares in chain (17357 verified/17357 total) Peers: 22 (0 incoming)
2013-07-20 23:37:14.460087  Local: 2562MH/s in last 10.0 minutes Local dead on arrival: ~3.4% (1-6%) Expected time to share: 1.8 minutes
2013-07-20 23:37:14.460151  Shares: 35 (0 orphan, 0 dead) Stale rate: ~0.0% (0-10%) Efficiency: ~128.6% (115-129%) Current payout: 0.1031 BTC

-------

Notice something wrong in this picture?  Heh.

Well, again, it would have been my first DOA/orphan... except, well, it wasn't a DOA.  This time I was slow, but my share that arrived about 950ms after my bitcoind picked up the new block and built off of 5cfa46a1 instead of 1d667ebf...  became undead....  because, well, someone else had a slow bitcoind.

I'd say this occurs maybe 5% of the time, the other 95% of the time is when I get a legit shit that's orphaned... probably a few of them by ^^ zombies like that

... i think it must have been between me and that other share that got punished 300ms earlier.  maybe the 150ms between the punish and the 'new work for worker' is where my miner picked up the share based on the 5cfa46a1 parent. 

[Searinox]

What do I need to do to set a custom difficulty? At 200MH/s mining at current difficulty's gonna get awfully spiky.

[mdude77]

What do I need to do to set a custom difficulty? At 200MH/s mining at current difficulty's gonna get awfully spiky.

Um.  At 200MH/s you might want to give up or use an alt coin.

M

[bitpop]

It seems I get a lot of rejects just due to constant difficulty changes. Should I make it static or do these changes coincide with the 30 second cycles?

[gyverlb]

Uh, you've got it as the exact opposite of what the reality is

Care to explain this? I have several steps in my explanation, are they all wrong or only some of them?

Slow nodes aren't being punished...

If you mean slow bitcoind nodes, of course they are (until you remove the 3 lines that punish them when they generate stale shares), seems pretty obvious to me as it's the goal of this code.

furthermore, if they found a block while generating these useless shares, then it'd be an orphaned block

Hum? I don't get what this has to do with the current discussion and it seems it should be pretty obvious to everyone.

[gyverlb]

OK, I started using the fork again to get more examples.  Not so difficult there since I get about 10-15% of the shares.

Anyway, here you go:

2013-07-20 23:37:10.117273 Skipping from block 8fb150619665d3e8d31395239d90fa377275479c6322072a76 to block 3b02efd60769dd972d8c9473a16396a47c3d4181fcdf216258!
2013-07-20 23:37:10.121500 New work for worker! Difficulty: 0.999985 Share difficulty: 64.059627 Total block value: 25.000000 BTC including 0 transactions
2013-07-20 23:37:10.284908 New work for worker! Difficulty: 0.999985 Share difficulty: 64.071125 Total block value: 25.000000 BTC including 0 transactions
2013-07-20 23:37:11.055484 Punishing share for 'Block-stale detected! 8fb150619665d3e8d31395239d90fa377275479c6322072a76 < 3b02efd60769dd972d8c9473a16396a47c3d4181fcdf216258'! Jumping from 5cfa46a1 to 1d667ebf!
2013-07-20 23:37:11.070429 New work for worker! Difficulty: 0.999985 Share difficulty: 64.059627 Total block value: 25.000000 BTC including 0 transactions
2013-07-20 23:37:11.085102 GOT SHARE! General.Butt.Naked 9036b0e9 prev 5cfa46a1 age 0.80s DEAD ON ARRIVAL
2013-07-20 23:37:11.112115 New work for worker! Difficulty: 0.999985 Share difficulty: 64.151483 Total block value: 25.000000 BTC including 0 transactions
2013-07-20 23:37:11.268987 Peer sent entire transaction 0946744912e4b00dd29396dc7a63d3fb3b46e8a7915cbdffcc02b8ea8272dcc5 that was already received
2013-07-20 23:37:12.249095 Peer sent entire transaction 0946744912e4b00dd29396dc7a63d3fb3b46e8a7915cbdffcc02b8ea8272dcc5 that was already received
2013-07-20 23:37:12.439025 Peer sent entire transaction 0946744912e4b00dd29396dc7a63d3fb3b46e8a7915cbdffcc02b8ea8272dcc5 that was already received
2013-07-20 23:37:14.459965 P2Pool: 17353 shares in chain (17357 verified/17357 total) Peers: 22 (0 incoming)
2013-07-20 23:37:14.460087  Local: 2562MH/s in last 10.0 minutes Local dead on arrival: ~3.4% (1-6%) Expected time to share: 1.8 minutes
2013-07-20 23:37:14.460151  Shares: 35 (0 orphan, 0 dead) Stale rate: ~0.0% (0-10%) Efficiency: ~128.6% (115-129%) Current payout: 0.1031 BTC

-------

Notice something wrong in this picture?  Heh.

Yes, you are complaining about one share being reported DOA but your estimated efficiency is ~128.6%.

Well, again, it would have been my first DOA/orphan... except, well, it wasn't a DOA.  This time I was slow, but my share that arrived about 950ms after my bitcoind picked up the new block and built off of 5cfa46a1 instead of 1d667ebf...  became undead....  because, well, someone else had a slow bitcoind.

Any proof of that or is it speculation?

I'd say this occurs maybe 5% of the time

You'd say many things but you wouldn't back it up with useful data would you? If you want to get someone else interested, copy your logs, find out the precise percentage of whatever you think is wrong is happening instead of guessing and if you still think there is a problem push it somewhere with your findings. If you manage to prove that your efficiency is changed by more than 1% over 3 days I'd be surprised, heck, I even would raise an eyebrow if it was changed by more than 0.25%.

Repeatedly claiming there's a bug affecting income of normal miners when these 'victims' always have above normal efficiency is becoming old and tired. Isolated events are meaningless: statistics on at least 3 days worth of data and 1000 self-produced shares (if you want to prove a 1% change, 10000 if you want to prove a 0.1% change) or GTFO.

[gyverlb]

It seems I get a lot of rejects just due to constant difficulty changes. Should I make it static or do these changes coincide with the 30 second cycles?

"A lot of" isn't useful a number so I don't know.

What is your efficiency ? If it's >=100% don't change anything. If it's bellow, describe your setup.