Topic: Not using P2Pool? Why? (Read 1286 times)

integrate it in Bitcoin core. do an active development. solve the issues with ASIC.

if you mean the same as mine to mine solo p2pool
I am confused whether it is more advantageous to use mine solo or join a pool

I don't know how possible of a solution this would be, but could someone create a subp2pool?  It would work just like P2Pool, but it could mine against the P2Pool chain in stead of the Bitcoin chain.  I know this would create additional over head because you'd probably have to run a regular P2Pool node to check against and then bitcoind to check the P2Pool node against too.  I also don't know if it's possible to do this due to any limits there might be on the generation transaction as to the number of payouts that can be included during the bitcoin generation transaction. 

The only other solution I could see would be to run separate pools, much like what vertcoin does with the vertcoin, vertcoin2, and vertcoin3 networks, each network having a hashrate threshold limit in their so you're only mining against similarly sized miners for generate P2Pool shares.  But I believe each individual network works on the blockchain separately and each submits their own blocks, which would cause a huge payout variance on the low hashrate network and still favor the large network.  Unless there is a way to join the networks and the pool awards payouts to each network based on that network's hashrate and then that network would split based on it's chains shares.  Maybe join the networks, then multiply the share value of each network by that network's hashrate, then do the generation transaction based on that.  The advantage would be that it would bring small and medium sized miners to P2Pool, and possibly decrease the variance to everyone involved due to the increased hashrate.

Not sure how viable any of these ideas are, but figured I'd put them out there. 

You can't include shares that you're describing as transactions since they have no intrinsic value and are not building on the existing blockchain the way bitcoin transactions do - and the risk for not propagating them is they just all start to accumulate in a massive transaction list that then spirals out of control due to entropy which would then exponentially increase the cpu usage of processing these transactions in p2pool (as if it doesn't use enough cpu already). Then you'd have to find a cutoff minimum diff share that qualifies as a transaction and once again you have the mini-solo mining problem only made slightly smaller but made the potential workload tend towards infinity.

If such transactions are used, why even include them in a secondary sharechain? Why not allow nonces to be submitted to the blockchain as txns directly? A minimum difficulty could be set to target 250 such nonces per block.

In addition, regarding your concern with the multiple tiers and a high-power one spoofing a bunch of low-power ones, the address to pay to might be included as part of the transaction, so, for example, the person with the high-power rig would mine 1ImmaMineALotiubygbubfg97b3.nonce1, 1ImmaMineALotiubygbubfg97b3.nonce2, etc... while the smaller miner would mine to their own address. Thus, nonce-spaces wouldn't collide. Or am I misunderstanding something?

I see it.  You can't make the blocks much faster without creating a buncha internal-chain orphans.

It's a design issue, and fixing it will require some redesign.  This isn't just a tweaking-the-parameters problem.

The block rate of p2pool is 20x the block rate of bitcoin, and it awards one share per p2pool block.  That makes the share difficulty of a particular instance of p2pool 5% of the Bitcoin difficulty divided by the ratio of in-pool hashing to total Bitcoin hashing. 

The internal blocks can't be made much faster but they can be made bigger.  Instead of just recording who gets each 30-second block, it could be forming a block every 30 seconds and also recording in each of those 30-second blocks 100 transactions (bitcoin hashes meeting a lower share threshold) per block.  That would move the people on the chain from mining against 5% of the bitcoin difficulty to mining  against 0.05% of the bitcoin difficulty, and smooth it out by a factor of 100.  Not the best solution possible, but certainly one that would be relatively easy to implement.

The best solution possible would be for p2pool servers to participate in peering with other servers of approximately equal hashing power; then you'd have 100 guys with 50Mhash rigs in one pool, and the host playing the part of a 5Ghash peer in a pool of 99 other 5 Ghash peers, which constitutes a 500Ghash peer, etc.

I thought last night about having multiple thresholds, so that someone with a 5Ghash rig could be aiming for one to five hits of a deeper threshold and someone with a 50Mhash rig could be aiming for one to five hits of a shallower one - but the problem with that is that the guy with the 5 Ghash rig is also going to be getting all the hashes to hit the shallower thresholds a really stupid number of times. If he takes all the profits possible he would completely defeat the measure because he'd be pretending to be one 5Ghash rig, *and* 100 50Mhash rigs, *and* etc.... so that won't work at all.

It's a design issue you won't be able to work around. The transactions from true shares in p2pool have to be propagated as an effective block change, and it's designed to average a block change every 30 seconds. As the total pool hashrate rises, the share difficulty rises to maintain that block change at 30 second intervals. In essence it's just a miniature version of the main bitcoin blockchain and you are solo mining to a 30 second block change instead of to a 10 minute block change. You cannot work around that constraint in a distributed form. If shares don't get propagated to everyone and become part of the next block solve then there is no way to trust how much work each user has done... without a centralised trusted repository that stores the state - which is what a regular pool is.

Okay, wait.  Why is that?  

It sounds like a "policy" issue that can be fixed easily.

If I were to hack P2Pool to fix that, or create a workalike that didn't have that problem, would that get people the hell off Ghash.io?

Edit:  Okay, I see in the source code why that happens.

It's all about how often you can reach the "share threshold" that you get paid for.   And it looks like it was probably introduced by the same blockchain-based demand-payout system that addressed the "dust" problem.  

There's a technical constraint in the number of "transactions" that will fit in each block in their internal blockchain, and the software is regulating the threshold so that you don't have more miners reaching that threshold, per block, than there's room to record.  So it's bumping up the share difficulty until the number of shares awarded per block is less than the number it can record.  

I see a way to fix it so it doesn't affect the system as badly as it does now; it looks like it's recording single "share threshold" hashes as transactions, and with some tinkering about how transactions propagate and which ones can displace others in the pool of uncommitted transactions, it could easily be recording single transactions containing many instances of someone hitting the share threshold.  That ought to smooth things out by a factor of at least twenty, depending on the variance of hashing power in the pool.  

There may be a better fix; I'll have to think 'bout it.

Something worth pointing out is that with regular pools, the larger the pool is, the less the variance is for the miner, whereas p2pool has exactly the opposite effect. The larger p2pool gets, the closer it starts to resemble solo mining and the more variance miners experience.  If everyone mined on p2pool, it would be like they were solo mining at 1/20th of the total network diff. While the significance of variance is grossly exaggerated by miners and some meaningful variance makes no difference, this level of variance would be unmanageable.

As I understand it, there was a problem where people with hash rates that were very low would get lots of "dust" payments that would take a lot of fees to spend. 

But that got fixed, now that P2Pool has its internal hash chain that stores amounts due a particular miner until the miner draws them.  P2Pool users don't get dust anymore unless they draw their earnings so often that they haven't earned more than dust since last time they drew their earnings. 

And there has never been an issue with people having "too much hash power" using P2Pool. 

That said, I'm not a miner myself; there could be issues I'm unaware of. 

I just see all these pool operators raking money off the top and threatening decentralization, and I'm asking

'Miners!  What do we need to fix for P2Pool to serve your needs???'

How would P2Pool handle a pile of large-scale ASICs join? It would appear to my (uninformed) self that the P2pool internal share chain's difficulty would skyrocket, pressuring the last few medium-scale miners there by increasing variance due to a decreased "share" rate. Am I wrong?

How did it fail you?  

Why doesn't it meet your needs?

We have P2Pool available; why is it still possible for pools to even get traction, let alone come close to 50% of the network?!

What do we have to fix?