Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 747. (Read 2591916 times)

Try use cgminer and diablominer as a kernel. This is the best solution.

Try: cgminer.exe -u user -p pass -o http://127.0.0.1:9332 --auto-fan --gpu-engine 450-1195 --gpu-memdiff -150 --gpu-powertune 0 --temp-target 75 -q -g 1 -I 8 -k diablo -v 1 -w 256

Panda Mouse

Just thinking out loud...

I'm not sure how the subpool would be notified of share difficulty changes and submit shares to the parent p2pool : each subpool node should be notified of the share difficulty changes so could probably maintain a connection to the parent p2pool to get it (or can it trust other subpool nodes to forward the information and only have a subset of the subpool in charge of broadcasting it?). If having "proxies" is a security problem and mandates a direct parent p2pool connection for each subpool node, is the p2pool protocol scalable enough to support this diff broadcast to thousands of nodes or even more (assuming we want every miner to be able to join p2pool) instead of the current 200+ nodes?
I can see how the share submission could be efficient : it's supposed to be low traffic.

Another problem would be to make sure one subpool node would have to reward other nodes having successfully found low-diff shares while having a valid p2pool share. I'm not familiar enough with Bitcoin to be sure it is doable.

If p2pool can scale to an arbitrary large number of nodes, and still get low latencies for broadcasting diff changes, the first class of problems don't really exist : just make all subpool nodes join both p2pool and the subpool and submit information to both according to the difficulty having been resolved. I suppose it should work, I'm only worried about latencies on large scale p2p nets (raising the target LP interval would help).

For the second problem, sorry no clue.

That's the problem. I was able to see some shares even if they wen't getting submitted to the pool itself, but my pool wont even show those shares.

Thats it.

Simple version.

1) Increase LP interval of p2pool to 60 seconds (and increase difficulty by factor of 6).
2) Expand protocol from 1 share = 1 address to 1 share = multiple addresses and weighted split
3) Build sub p2pool protocol which creates its own share chain (unknown and invisible to main p2pool).

When p2pool find a block it payouts as normal with the exception of the fact that 1 share may be paid to more than one address.

When subpool find a low diff share it adds it to its internal share chain.
When subpool finds a p2oool diff share it submits it to p2pool (which updates p2pool split)
When subpool finds a block it submits it to Bitcoin network.

Hmm - well I guess it could be possible?

But certainly people opening up their own p2pool as a pool is no different to a normal pool.

However, I'm not sure how the sub-p2pool would pay out the earnings.
Either the master p2pool share chain would have to know every sub-p2pool address and pay them their micro-payments in the master p2pool block or there would have to be some centralised non p2p control to handle that ... or

I think you misunderstand the concept of a sub-p2pool.  Everything would be completely decentralized just as p2pool is now.

However, as soon as you have sub-p2pools - they are no different to normal pools.
So why not use a normal pool with 1 difficulty instead and solve the whole issue up front?

Yes it has been discussed.  There are a couple of methods of providing multiple layers to p2pool with the highest layer (highest difficulty, possibly 6000+ per TH/s) forming a backbone for major farms, sub p2pools and conventional pools.

Makes me think... Could P2Pool protocol be setup to allow "super nodes" that have this good connectivity?  Users would then connect to those on a random or geographical basis.  That would give the benefit of allowing lower difficulty shares but still have a decentralized "core".  Kind of like TOR does with multiple entry/exit points on the network.  Anyone could setup a P2Pool super node, and the clients could decide if they want to keep using it based on latency, hops, etc...

As the popularity of P2Pool grows, the difficulty is only going to get higher and turn off small miners.  If this is indeed the future of BTC mining, and I hope it is, something needs to be done to address this.

Yes.  I guess I should say work can be verified.  It is possible for p2pmining to provide software which would allow user to create work locally.  No idea if the operator plans on implementing something like that.

Isn't the work generation centralized too? p2pmining runs bitcoind and namecoind and then gives you the work.

Just to be precise.  A higher sampling frequency (lower diff shares) does provide a better estimate (less variance in short run).  This is why all traditional pools use a diff 1 shares.  

It just happens to be that given the limits of internet connectivity, latency, and node response times p2pool has a semi-unique restriction in that it needs to keep LP interval at ~ 10 seconds.  That puts an lower limit on difficulty of shares.  Hypothetically if all the nodes of p2pool were on internet backbone and had sub 100ms latency with every other node you could use a smaller LP window and thus a lower difficulty.

As indicated above you can support p2pool w/ 1 difficulty shares by using p2pmining.com.  It works as a "front end".  It records diff 1 shares submitted by miners and submits p2pool dif shares to p2pool.  When a block is found it splits any revenue by the diff 1 shares.  It is semi-centralized (in rewards not work generation).

Thanks DAT,

I was missing (I didn't completely understand) this issue.

I was thinking that using a higher "sampling frequency" could give a better estimate of miner contribution to the pool.

I was wrong

spiccioli.

No.

First high difficulty shares aren't used to solve a block.  They aren't used for anything other than payouts.  They need to be high to keep avg time between shares ~ 10 seconds.  For example if p2pool uses 1 difficulty shares instead of 0.1 shares per second it would have 60 shares per second.  The sharechain would simply collapse under the weight of dozens of forks a second.

Shares are completely worthless (in terms of real value).  This applies to any pool.  You don't work towards a block.  You either solve it or you don't.  If you don't the hash produced is worthless.  Pools simply use shares to record how much work was attempted and thus determine a fair split.

This has also been discuseed on previous pages.  If you are a small miner, you should try out p2pmining.com.  They use p2pool, but pay diff 1 shares.

twmz,

question: could p2pool use difficulty 1 shares to calc miner payout instead of using high difficulty ones? This should lower miner's variance and still be able to use high difficulty shares to solve blocks.

spiccioli

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

Q: Why does my miner say it has found a lot of shares but p2pool say I have only found a few?!

A: The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

The miner sees the difficulty 1 shares to make it easy to tell if your miner is working. P2Pool sees the higher difficulty shares.  This seems to get covered every other page of this thread...

Yes, I understand the percentage of actually seeing some if not any shares are; the thing that confuses me is how am I able to show accepted on the miner when my pool doesn't show any shares, unless it's mining so low that the pool already is on another block. :\

Anyone that doesn't want to bother running bitcoind or p2pool locally, use my public p2pool with zero fees
https://bitcointalksearch.org/topic/closed-8-ghs-bit-pop-p2pool-zero-fee-auto-payments-oregon-usa-68743