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

[gyverlb]

getblocktemplate latency isn't noticeable unless the CPU usage generated when it is called is enough to slow your p2pool node.

In short, unless your efficiency suffers (measured over hundreds of shares), it's fine to allow these transactions in.

A potential solution here would be to mine empty blocks.  When there is a new block, your miners immediately switches to a coinbase only block.  Once getblocktemplate returns a block, p2pool can switch over to that.

I believe this is what happens already.

In fact if I understood a recent exchange here correctly p2pool doesn't use the getblocktemplate result as-is but builds a new template itself and then use this kind of optimization.

[maqifrnswa]

The amount of lost shares in p2pool are normal. And every p2pool miner has the same. So its fair among the p2pool users.
Theory: But that means that a certain amount of hashpower is lost compared to solo mining. The shares maybe were good but they are lost and so is the amount of time invested in them.
Solution?: Am i right that this is no disadvantage to solo mining because the real bitcoin block that is found in p2pool is directly put into the network via solomining? So the lost shares does not affect in the end because for the real found block those lost shares dont exist. Correct? Then p2pool would be even better than normal pools because they have to receive the found share first and from there propagate it.

Sorry for the many questions...

no problem, they are good questions - some are answered in other places but it can be hard to find.

Yes, p2pool's internal share chain has lots of stales. But the p2pool network DOES NOT produce more bitcoin chain orphans (and thus wasted work) than solo mining.

Work is not lost using p2pool, those stale p2pool shares can still solve a block and still be submitted to the bitcoin network for reward. The time and work invested in them is not lost. Those shares just don't show up in the p2pool sharechain, but will show up in the bitcoin blockchain. The rewards for those blocks are paid out normally to p2pool users and are not wasted.

Theoretically, a 100% efficient p2pool miner that has ~5-10% stale/DOA rate will have the exact same expected value as a solominer with the < 0.5% orphan rate.

[TierNolan]

Work is not lost using p2pool, those stale p2pool shares can still solve a block and still be submitted to the bitcoin network for reward. The time and work invested in them is not lost. Those shares just don't show up in the p2pool sharechain, but will show up in the bitcoin blockchain.

Doesn't a winning (bitcoin) block not override the share chain?  Otherwise, that block couldn't actually be paid (by the share-chain)

[maqifrnswa]

Work is not lost using p2pool, those stale p2pool shares can still solve a block and still be submitted to the bitcoin network for reward. The time and work invested in them is not lost. Those shares just don't show up in the p2pool sharechain, but will show up in the bitcoin blockchain.

Doesn't a winning (bitcoin) block not override the share chain?  Otherwise, that block couldn't actually be paid (by the share-chain)

Well, it depends on what you mean by "override."

A winning bitcoin block is sent to the bitcoin network and to the p2pool network. Bitcoin will payout the reward normally for the found block (including the finder's share). However, if the winning block isn't on the longest chain of the p2pool sharechain, it will get orphaned by the p2pool network.

In that case, the winning block is paid out and the solver will get credit for it for the current block (in addition to the 0.5% bonus for finding it), but the person that solved it won't get a credit for the share it for future blocks on the p2pool chain. This is fair because everyone has the same chance of it happening, and it does not mathematically affect expected payout for anyone. Additionally, this is extremely rare (<0.1% of blocks found will have this).

[Ghost of USD]

Work is not lost using p2pool, those stale p2pool shares can still solve a block and still be submitted to the bitcoin network for reward. The time and work invested in them is not lost. Those shares just don't show up in the p2pool sharechain, but will show up in the bitcoin blockchain.

Doesn't a winning (bitcoin) block not override the share chain?  Otherwise, that block couldn't actually be paid (by the share-chain)

Well, it depends on what you mean by "override."

A winning bitcoin block is sent to the bitcoin network and to the p2pool network. Bitcoin will payout the reward normally for the found block (including the finder's share). However, if the winning block isn't on the longest chain of the p2pool sharechain, it will get orphaned by the p2pool network.

In that case, the winning block is paid out and the solver will get credit for it for the current block (in addition to the 0.5% bonus for finding it), but the person that solved it won't get a credit for the share it for future blocks on the p2pool chain. This is fair because everyone has the same chance of it happening, and it does not mathematically affect expected payout for anyone. Additionally, this is extremely rare (<0.1% of blocks found will have this).

Ironically this just happened to me on the last block.

[maqifrnswa]

Well, it depends on what you mean by "override."

A winning bitcoin block is sent to the bitcoin network and to the p2pool network. Bitcoin will payout the reward normally for the found block (including the finder's share). However, if the winning block isn't on the longest chain of the p2pool sharechain, it will get orphaned by the p2pool network.

In that case, the winning block is paid out and the solver will get credit for it for the current block (in addition to the 0.5% bonus for finding it), but the person that solved it won't get a credit for the share it for future blocks on the p2pool chain. This is fair because everyone has the same chance of it happening, and it does not mathematically affect expected payout for anyone. Additionally, this is extremely rare (<0.1% of blocks found will have this).

Ironically this just happened to me on the last block.

holy crap:
https://blockchain.info/tx/270d0e76ac7bbe95720b95651a427bb75112005c4be8e57e3be14dadffc6ea9d

what are the chances of that!?  

This is perfectly the example of how p2pool doesn't waste more work than solo mining! This counted as a p2pool "reject" but it still paid out!

I will admit that my math was wrong, it's > 0.1% of blocks. It should be ~ the DOA/stale rate, which is pretty high actually. See your stats:
"Note that blocks may have been orphaned from the P2Pool chain and so not be here."

[zvs]

The amount of lost shares in p2pool are normal. And every p2pool miner has the same. So its fair among the p2pool users.
Theory: But that means that a certain amount of hashpower is lost compared to solo mining. The shares maybe were good but they are lost and so is the amount of time invested in them.
Solution?: Am i right that this is no disadvantage to solo mining because the real bitcoin block that is found in p2pool is directly put into the network via solomining? So the lost shares does not affect in the end because for the real found block those lost shares dont exist. Correct? Then p2pool would be even better than normal pools because they have to receive the found share first and from there propagate it.

Sorry for the many questions...

no problem, they are good questions - some are answered in other places but it can be hard to find.

Yes, p2pool's internal share chain has lots of stales. But the p2pool network DOES NOT produce more bitcoin chain orphans (and thus wasted work) than solo mining.

Work is not lost using p2pool, those stale p2pool shares can still solve a block and still be submitted to the bitcoin network for reward. The time and work invested in them is not lost. Those shares just don't show up in the p2pool sharechain, but will show up in the bitcoin blockchain. The rewards for those blocks are paid out normally to p2pool users and are not wasted.

Theoretically, a 100% efficient p2pool miner that has ~5-10% stale/DOA rate will have the exact same expected value as a solominer with the < 0.5% orphan rate.

except sometimes those stales that solve blocks... are, well, a stale right after a block was found.  re the shenanigans that go on when switching from one block to another

not sure if p2pool would proceed along it's own chain or not?  either way, it's a block that'll most likely be orphaned.  that's when the slow getblocktemplate matters

[gyverlb]

except sometimes those stales that solve blocks... are, well, a stale right after a block was found.  re the shenanigans that go on when switching from one block to another

not sure if p2pool would proceed along it's own chain or not?  either way, it's a block that'll most likely be orphaned.  that's when the slow getblocktemplate matters

Bullshit.

After heaps of messages on this subject on this very thread (last was mine a few messages ago) you still don't understand that p2pool doesn't rely on getblocktemplate result being available to build the coinbase miners are working on.
p2pool is connected to the bitcoin P2P network and detects blocks before a getblocktemplate result is available for the new block and present a valid coinbase to miners ASAP. So there's absolutely no reason a "stale p2pool share" block would have more chance of being orphaned than any other block.

[rav3n_pl]

Share is every 30 seconds, block in network every 10 minutes.
Even if ALL of your shares will be DOA for share chain only 1 per 20 will be DOA for network block.
So if you will be REALLY lucky, you can find VALID block 20 times from DOA share ;]

[TierNolan]

p2pool is connected to the bitcoin P2P network and detects blocks before a getblocktemplate result is available for the new block and present a valid coinbase to miners ASAP. So there's absolutely no reason a "stale p2pool share" block would have more chance of being orphaned than any other block.

I assume getblocktemplate is used to build up the actual block transactions?  So, there is a window where p2pool miners mine against a block that only contains coinbase?

[zvs]

except sometimes those stales that solve blocks... are, well, a stale right after a block was found.  re the shenanigans that go on when switching from one block to another

not sure if p2pool would proceed along it's own chain or not?  either way, it's a block that'll most likely be orphaned.  that's when the slow getblocktemplate matters

Bullshit.

After heaps of messages on this subject on this very thread (last was mine a few messages ago) you still don't understand that p2pool doesn't rely on getblocktemplate result being available to build the coinbase miners are working on.
p2pool is connected to the bitcoin P2P network and detects blocks before a getblocktemplate result is available for the new block and present a valid coinbase to miners ASAP. So there's absolutely no reason a "stale p2pool share" block would have more chance of being orphaned than any other block.

I think you're the one that doesn't understand, lol.

Maybe you should look at the specifics presented.

Listen, there's a reason why so many shares  get 'punished'.  

ed:  since I've disabled the 'punish' feature you'll be able to see all the orphans.  most of the time it's just one, the person unfortunate enough to have the share right before the new block, but just wait for a block where you have 2 or 3 orphans coming off of it,  some will have a received time after the new block, but still be working on old block.

[TierNolan]

since I've disabled the 'punish' feature you'll be able to see all the orphans.  most of the time it's just one, the person unfortunate enough to have the share right before the new block, but just wait for a block where you have 2 or 3 orphans coming off of it,  some will have a received time after the new block, but still be working on old block.

What is the punish feature?

[gyverlb]

p2pool is connected to the bitcoin P2P network and detects blocks before a getblocktemplate result is available for the new block and present a valid coinbase to miners ASAP. So there's absolutely no reason a "stale p2pool share" block would have more chance of being orphaned than any other block.

I assume getblocktemplate is used to build up the actual block transactions?

I'm not sure how this part works as I'm not familiar with how a block template can be manipulated. I assume that getblocktemplate is called to get the transactions to confirm in the block and the reward transaction (the one distributing the reward to p2pool miners) is added.

So, there is a window where p2pool miners mine against a block that only contains coinbase?

With 0 transactions in the block, yes.
In fact when I was worried about getblocktemplate latencies I asked if such a mechanism (using an empty block built on top of the just found new block until getblocktemplate returned a result) would make sense and explored alternatives like workarounds/hacks in bitcoind's getblocktemplate. The reply from more knowledgeable people including Bitcoin devs was that there was no need for workarounds as pools were expected to implement this for ages to avoid producing orphans and forrestv confirmed that p2pool was using this technique too.

[gyverlb]

except sometimes those stales that solve blocks... are, well, a stale right after a block was found.  re the shenanigans that go on when switching from one block to another

not sure if p2pool would proceed along it's own chain or not?  either way, it's a block that'll most likely be orphaned.  that's when the slow getblocktemplate matters

Bullshit.

After heaps of messages on this subject on this very thread (last was mine a few messages ago) you still don't understand that p2pool doesn't rely on getblocktemplate result being available to build the coinbase miners are working on.
p2pool is connected to the bitcoin P2P network and detects blocks before a getblocktemplate result is available for the new block and present a valid coinbase to miners ASAP. So there's absolutely no reason a "stale p2pool share" block would have more chance of being orphaned than any other block.

I think you're the one that doesn't understand, lol.

Maybe you should look at the specifics presented.

Listen, there's a reason why so many shares  get 'punished'.  

ed:  since I've disabled the 'punish' feature you'll be able to see all the orphans.  most of the time it's just one, the person unfortunate enough to have the share right before the new block, but just wait for a block where you have 2 or 3 orphans coming off of it,  some will have a received time after the new block, but still be working on old block.

If you want to be taken seriously present your case clearly "a block that'll most likely be orphaned" is not the same than an orphaned p2pool share. It's a misleading statement at best FUD at worst, don't be surprised to see "bullshit" in response.

I usually don't read your posts in details anymore as I can't understand much of it without disproportionate efforts, but what reads like a risk of orphaned blocks with no basis is enough to catch my attention...

[astutiumRob]

You will get paid more for the higher difficulty shares.  It will reduce your bandwidth usage if you are putting out a lot of hash power.

Could just be anecdotal rather than consequential, but since adjusting my miners' difficulty the number of orphaned shares has dropped significantly:
to 23/August: Shares: 54 total (10 orphaned, 1 dead)
as at 28/August: Shares: 85 total (11 orphaned, 2 dead)

So only 1 orphan, 1 dead in 5 days compared to 10 orphan and 1 dead in previous 8

I've set (local) difficulty to nearest power of 2 up from actual ghs/2 (after doing some testing with a few pps pools and comparing 24h earnings at various difficulties - 30 Gh/s @ 32 actually earned more (2.1%) than 30Gh/s @ 16, but 30Gh/s @ 64 earned 17% less.

[rav3n_pl]

It is useless to compare P2pool to any other pool after 24h mining...
See p2pool.info - if luck >100% you are earning more than 0% PPS, if <100% you earning less.

[CartmanSPC]

Have received this error twice now. This is on a DGC p2pool with 30 Mh/s. When the error occurs it stops all mining until the pool is restarted.



Based off of p2pool 13.3. 6 nodes with one having 98% of the hashrate. Any help would be appreciated.

[zvs]

If you want to be taken seriously present your case clearly "a block that'll most likely be orphaned" is not the same than an orphaned p2pool share. It's a misleading statement at best FUD at worst, don't be surprised to see "bullshit" in response.

I usually don't read your posts in details anymore as I can't understand much of it without disproportionate efforts, but what reads like a risk of orphaned blocks with no basis is enough to catch my attention...

Everything is "FUD", misleading, or needs more data...  go ahead, present yourself as the resident p2pool 'guru', solicit more donations

my pool is public and I make shit all from it, but it is fun to tinker with.  like the change regarding punishing shares, it's 35/35 since then.  ofc that's too small a sample to make a conclusive opinion, but it's promising

i don't read your posts either, unless they're directed towards me.  obvious, right?  otherwise I wouldn't be spewing all the FUD as I'd already know all the answers

Based off of p2pool 13.3. 6 nodes with one having 98% of the hashrate. Any help would be appreciated.

I wouldn't have a clue how to fix it, but it'd probably be helpful to (someone) to know if you're the node that's contributing the 98%

[CartmanSPC]

Based off of p2pool 13.3. 6 nodes with one having 98% of the hashrate. Any help would be appreciated.

I wouldn't have a clue how to fix it, but it'd probably be helpful to (someone) to know if you're the node that's contributing the 98%

Yes. The node contributing 98% is the one that got the error.

[forrestv]

Have received this error twice now. This is on a DGC p2pool with 30 Mh/s. When the error occurs it stops all mining until the pool is restarted.

Based off of p2pool 13.3. 6 nodes with one having 98% of the hashrate. Any help would be appreciated.

Where's the source for DGC-P2Pool? This seems like it should be impossible with vanilla P2Pool.