Topic: Public P2Pool, how? (Read 6399 times)

I'm not sure how you could handle payouts on the merged mine chain.  Some sort of monitoring of the workers would be needed to do this I think.

I guess wou could trade the merged coins for BTC and then donate that to all the p2pool miners, but that doesn't reward just the people on your node.

+1

You are asking for things that are way too complicated.  What you want already exists.

Setup p2pool and add a "--fee 1" to take a 1% fee from anyone using your node.  "$ ./run_p2pool.py --help"

Others have already said that anyone can connect with their username being their payment address if you just open a port.  I used to have my address (p2pool.stitthappens.com:8336) in my sig, but I just point to the wiki now.  I also run p2pool2.stitthappens.com:8336 as my backup.   You can even tell the fee by visiting http://:/fee

Right now p2pool doesn't have much monitoring.  It would be nice to have worker stats available in a few more formats.

I think it will happen organically.  Trying to do it now would likely just cause frustration and confusion.  As p2pool grows difficulty will rise.  Eventually it will reach a point that a solution will need to be found because difficulty is too high for small miners.

At that point the simplistic aproach would be to make a second instance of p2pool.  Maybe we will do that but that limits us forever to 300-500GH/s per instance and we never make it into that low variance that happens at 1TH/s+.

Instead once p2pool is larger we "could" update p2pool to have longer share time (say 60 seconds vs 10 second target).  Which will raise the high difficulty even higher.  From p2pool point of view pools, mining farms, and subpools are simply shares being submitted.  Nothing really needs to change except a longer share time.

Major hashing farms and conventional pools can continue to mine the very high efficiency p2pool (which has now formed the decentralized backbone).    I am trying to convince the operator of BitMinter to join p2pool.  That would add ~120GH/s of hashing power.  If it can be done I would imagine many other smaller pools would to reduce their variance.

As long as a protocol for "sub-p2pool" is implemented there will be no/minimal change to miners.  One or more "subp2pool" instance can be started for smaller miners who need the lower variance of lower difficulty shares. 

Hopefully this weekend I can write a whitepaper which fleshes out the protocol concept to show that a migration from a single p2pool to a backbone & sub-pool network would be that hard.  At this point is is more academic.  There is no need now what we need is more hashing power not fragmenting it.  It is more something to keep in mind for the "what happens if we get to 1 TH/s?".

Precisely.

We just need to implement it! LOL

like today?

god variance can be frustrating

This is why I think the optimal solution would be p2pool forming a backbone network to connect pools, large farms, and sub-p2pools.

Then any number of sub-p2pools could form.  Some with lower difficulty (for smaller miners), some with higher difficulty/hash rate for larger miners.

I prefer a pool with minimal of 600GHash at the current difficulty level... So, 600-800GHash would be a good point to split...

Sometimes with 200-300GHash we spend almost 24H without earning nothing... 

Right. I think a p2pool size of 200-300 GH/s is about right. On average that's 3-4 blocks found per day at the current Bitcoin difficulty level. That's smooth enough variance for someone with a single GPU. If the current p2pool starts reaching 400 GH/s, we should plan on splitting it in half.

Surely it will be almost trivially simple to start a p2paltpool, a p2paltpool2 and so on from time to time as needed to keep each p2pool network within reasonably nice share-difficulty range?

It looks as if p2pool might, unlike bitcoin and the altcoins based on it, be succeeding in talking my router into opening its incoming port.

It would be nice if someone could check that, if it is so then my merged mining, no-fee p2pool should be reachable at CrossCiv.no-ip.org:10332

If it is opening the port maybe I can get the UPNP folk to look at its code to try to make UPNP also able to talk to this type of router.

If mining a whole bunch of altcoins in a multiple merge can pay for the load on the bandwidth and machine there should never be any fees and might even end up being kickbacks in various altcoins or maybe in DeVCoins since all the others can likely be used to buy DeVCoins...

-MarkM-

You are centralizing in that way, that everyone mining over your node agrees to include whatever transactions you include (=merged mining, other transactions) but has no way of confirming this until a block pops from it (which is quite hard to detect).

Regular pools built on top of P2Pool (for example to provide PPS payments) would need centralized systems again, where the poolop gets paid and you get paid from that money - or you eat the variance of P2Pool and just share an "entry node" and its rules.

Maybe it could be possible to do something like a "miner specific blockchain" that is only shared between the pool and the miner? Every 2 minutes or even slower, the miner gets an updated list of payouts that need to be in the generation transaction to be accepted by the pool (slower would mean slower payouts but less communication with the pool about this - it would still be a traffic spike every x minutes for the pool though) and the whole blocks created are shared with the pool instead of just getworks. Pool then verifies + confirms these blocks, so the miner still can choose what transactions go into each block, while the pool only needs to be trusted to publish the correct amount for each miner to pay. To eliminate the need for this trust, all "miner sharechains" could be verified by publishing to anyone interested their mined blocks too - maybe even to fellow miners, so they can verify someone else did the correct amount of work. Depending on how much you trust the poolop and your bandwidth, you could then for example request the sharechains for random 10% (or 1% or 50% or 99%...) of these other miners and also verify that they did the work they claimed and the poolop didn't cheat.

If you get all other sharechains too, you'd need (depending on poolsize) quite some bandwidth, but you could verify down to the Satoshi if the pool is calculating payouts correctly - for ANY payout scheme, not only PPLNS/PPLNSintimewindow like P2Pool does atm.


Edit:
This kind of pool could be standalone or on top of P2Pool.
To be able to use the P2Pool hash rate as a boost, popping blocks at the rate of P2Pool instead of your (initially meager) pool hash rate, you'd need to scale your pool payouts down to P2Pool standards, publish blocks to the P2Pool chain instead of mainline Bitcoin and make sure you only consider a successful payout, if a Bitcoin block shows up and is confirmed. Your payout scheme also should support some lag (as it takes time to make sure a block is confirmed) or be able to recompute/reset to previous values in case a block gets stale.

Anyways, PPS metapools with 0 trust on top of P2Pool _are_ possible, as long as blocks pop in max. expected time (which is completely unlikely). If they take longer, you'd need an escrow for the money that comes in on shorter rounds to be used on longer rounds, turning it into a scheme like SMPPS or similar.
Prop. metapools are 100% possible, but would be hopped of course, screwing all constant miners in your metapool but not affecting other P2Pool users at least (it doesn't affect mainline Bitcoin if prop pools are hopped too).
PPLNS metapools would have the advantage of being able to discard sharechains after some fixed amount of blocks (PPLNS) or time (P2Pool payout model).
Other payout schemes would of course also be possible, as the only real difference is to let miners assemble full blocks instead of just getworks. These can be (as said) P2Pool blocks or Bitcoin mainline blocks, depending on that, you get different payout speeds (to the Bitcoin network you are either a miner within P2Pool or a solo miner with x GH/s)

Until pooled merged is in p2pool, you will need to somehow record a namecoin (/i0/ix/dev coin) address against each bitcoin address, & work it out by hand (or similar). You could just say that you're merged mining, and that those alt coins are used to fund the pool. I expect most people would only use this kind of p2pool pool as a tester, and after a day or 2, seeing that it works & isn't too scary, will set it up locally (perhaps following your guide). They can then reap the benefits of all those alt coins!

Perhaps loads of these "tester" nodes, spread around the globe, would be good - try one that is geographically close. Mine (176.31.24.238) is France, I think. Also, people's local nodes can connect to these (-n option).

If it helps people give it a try, it miust be good, yes?

Okay!

 Thank you for your support thirdlight! I'll do it!

 But, I want to complicate this a little bit... lol

 How can the miners of my P2Pool node receive the benefits of Merged Mining?!

 Because the P2Pool node that I'll provide will have merged mining enabled but, since the miners will use its own bitcoin address as a login to use P2Pool, how they can get the other coins?!

 Or, do I need to wait until P2Pool have full support for merged mining within it (instead solo-mining)?

Thanks!
Thiago

If the idea is to make it easier for people to try p2pool, then why not?

Thiago, run a p2pool instance & open the port!

Example: If you want to try p2pool, but don't want to set it up on a local machine, simply point your miner to http://176.31.24.238:9332 . Use a valid bitcoin address as the user name, and anything for the password. If you use "graph" for the password, you will see your worker at http://176.31.24.238:9332/graphs . This pool takes 0.5% fee (http://176.31.24.238:9332/fee).

Look for your bitcoin address at http://yat.uukgoblin.net/p2pool-stats/current_payouts.html after a couple of hours.

After 24 hours you should have a good feel for p2pool, and probably some "generated" in your wallet. Remember it takes 120 confirms (nearly a day) for generated's to mature.

http://176.31.24.238:9332 is a live p2pool instance. Anyone can do it!

Cross posting to answer the cross posting.

So think about this slowly and rationally.

As p2pool grows the share difficulty will grow.  At 1 TH it will take a 200 MH/s miner on average 1 day to earn a share.  And with intra-share variance there will routinely be 5-7 day stretched with no shares and every few blocks the "unlucky streak" lasting 7-10 days with no shares.

No shares = no revenue.  It is naive to think small miners will stick w/ p2pool under growing variance.

As p2pool grows its popularity for small and casual miners will wane as rising difficulty becomes higher and higher variance.   So those miners WILL leave.  Now they could go to:
a) a front end which uses p2pool and thus can't be used for 51% attack and preserves the core decentralized nature (albeit with some centralization).
b) deepbit or so other major pool.

So which is a superior solution?

Again... No, you didn't get the idea.
I want to help.

Posting that here again: You are planning to centralize P2Pool?

Wasn't its main advantage over traditional pools that P2Pool was decentralized?

I think it was added to make debugging miners easier.  instead of having to wait ages for your miner to find shares just to see if your miner is working correctly, you can see pretty quickly if your miner is working because it is finding shares at a fairly normal pace.  it doesn't cost p2pool much processing power to just filter those low difficulty shares out when they get submitted.

It also made it possible for p2pool to report and graph a reasonably accurate local hashrate with lower variance.

All that said, I agree with you that a front to p2pool for smaller miners would be useful.  But to not completely defeat the purpose of p2pool it would be better if there were many dozens of these that get setup instead of only a few large ones.  Otherwise, we just end up with what we have today--a handful of large centralized pools.

I stand corrected.  Seems a useless "feature".  Those lower shares are worthless.  Completing them doesn't get you into the share chain thus when block is found you will not be compensated for anything less than share difficulty shares.

Thanks for that correction although I do wonder why it doesn't just hand out 619.66 difficulty shares?

Still front-ends can provide a service by reducing variance for smaller miners. 

One way to look at it.

solo mining = 1.3 million difficulty "share".
p2pool = 619 difficulty share
front end = 1 difficulty share

as share difficulty rises so does the effect of variance in the short run.  Eventually direct mining p2pool will be very difficult for small/casual miners.  Rather than have those miners go to traditional pools having "p2pool frontends" act as variance buffers would be preferable.