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

Additionally Semaster has been tracking = amounts of ants on 3 pools from the beginning of this year https://bitcointalksearch.org/topic/benchmark-p2pool-vs-btcguild-vs-eligius-416933
TL;DR P2pool has generated more coin, but this was also when Eligius and BTCG was being block-withhold attacked.

J 

Yes you can. Consequently you can also gain money. Contrary to what people will insist on, it does NOT even out in the end because difficulty keeps rising. However luck determines if you're ahead long term or behind long term in an irretrievable way. If diff did not continually rise and rose-and-fell or stayed the same it would even out.

No, I don't think you will loose money. Now this has grown a lot and I don't think you have to do a long run and will the difficulty go up by 30% ? I don't think so. It will not go all of a sudden. Everything is risky, there is an equal chance for both profit and lose.
Kindly,
       MZ

I'm wondering,  with high variance on p2pool or another somewhat smaller pool,  is it possible to actually lose money?  Like in the long run luck is irrelevant,  but what if you have really bad luck and then the difficulty goes up 30%?

In this situation do you lose money because of high variance?

I don't understand the math well enough to answer this question but I am sure many of you can

Juan from 112bit put up screenshots of his S3 mining on GHash.io yesterday and had an average of 450GH/s.  If the S3 is reporting 439GH/s on p2pool, that's pretty much right on target for Bitmain's claimed specs of 441.  Looks like I'll be plugging mine into my local node after all

Not really.  My S2s lose ~10% of their hashrate local or not on p2pool.

This is good news indeed for p2pool.

M

+1

You make me want to host a node too haha
Listen thanks for your help guys.  I wish I would have jumped on p2pool ages ago.

I think you should add that 3 day PPLNS period to your site though (maybe on a faq "why are my payouts so low?") .  That was very confusing to me why my payouts were so low in the first day of so. I almost dropped out thinking I'm gonna lose half my income if I stay here.  Glad I hung out long enough to get past that

Also another challenge for noobs is lack of down notifications (I handled this via a cron job now) .  One way I've seen this handled on other pools is you use your email address as your worker password and then the pool can email you when it goes down.  Thoughts?

very good, although, it is as would be expected, since it's a local node.

Chinese friends on the 1st order, on the 17th of arrival.
Here is the actual situation of ants running P2POOL S3, and much better than expected







 

Yeah, I've already had a dedicated server for years, p2pool doesn't take much resources.  I ran a bitcoin one for a long time, now it's on doge for the last 3 or 4 months.  (nogleg.com:9555, hoho)  Oh, I did put a 0.1% fee, 'cause of several people thinking there must be shenanigans going on

There is still a chain.  It's just not a chain as we know it today.

The current round is based upon the last Bitcoin block + the payout data for all the work submitted up to that point.  That work comes from the share chain, as it does today.  So the current round is STILL based upon all prior work, and can still be verified as such.  Hence each share submitted for that round can be verified, as it has to be based upon that round, which is based upon all the prior work.

With holding shares won't accomplish anything, as far as I can tell.  Remember, a round is until the next Bitcoin block is found on the Bitcoin chain, nothing else.  It's not x number of shares, it's not x minutes, it's until the next Bitcoin block is found.  Maybe I didn't clarify that it's the next Bitcoin block found on the main Bitcoin chain, NOT the p2pool chain? 

M

I think I understand your proposal, but how do you verify shares in a proposed "round", their order, and their validity for that round without including some data from the (immediately) previous share?

In other words, if I understand you right, miners would be able to throw shares in during a round with the only proof being shares from the previous round, and not including shares already in the current round... So the question becomes how do verify the validity of the existing shares in the current round? How can you stop a single miner from withholding round shares until just before the end of a round, and then pushing out a longer or larger round just before the round end and taking the whole round?

I'm running a 0% fee node because it cost me a pittance to run it.  I can contribute that pittance to keeping the network going.

M

Shares would still be distributed and verified.  Those that are invalid would be rejected, as they are today.  The difference is, instead of each share being built upon the prior one, each share is built upon the prior work round, and the prior work round is based upon the prior Bitcoin block + shares in chain prior to that block.

I wasn't looking to compromise the trust no one principle.

M

I'm not seeing how it's trustless.  Each node can verify the blockchain, and how it was derived.  Each share can be verified as being a legitimate share for that round of work, and each round of work can be verified as coming from the prior round + shares.  Am I missing something?

M

Thanks.

My short term goals are pretty similar to many others here:

1. Grow the p2pool network; first through the addition of new nodes run by active miners, and second by providing access to reliable fast nodes for those without the time or inclination to set up their own.

2. Complete transparency; p2pool is in the unique position to be the first completely transparent pool. The data is all there, its just a matter of collecting, storing and presenting it to users.

3. Hardware compatibility; Work towards getting as much existing and new hardware to play well with the pool. New generations of HW are particularly important, as without them the pool will eventually dwindle.

4. Solve the variance/small miner challenges facing the pool so that it can grow and scale while remaining an attractive option to all.

To be honest, right now the "end game" is so far in the future its not even really a concern... At some point, if both Coin Cadence and p2pool are running strong, I do plan to implement some sort of revenue stream to support the operation of my node(s), and maybe even make a small profit, but for now and the foreseeable future working towards the challenges above takes priority, and I'm happy to host my node(s) on my own dime...

Entire idea of p2pool share chain is, that noone can forge hash power and everyone can check who is mining, like in bitcoin block chain.
I not see, HOW you want to collect and VERIFY data collected by miners across entire POOL?
Only way I see, is kind of MOPS node, which is NOT sending LP/WR signals every share and collecting shares on share diff 256 or something.
This way NODE payout can be split between node miners, but because no fast lp/wr signals node efficiency will be compromised.

This is the kicker, as it would require an entire new trustless proof-of-work system... Right now each p2pool share is built on the existing shares in the chain, and includes the previous shares payouts to each miner. Without a blockchain-like system the proof of work for p2pool (and trustless  payouts for previous shares to miners) breaks.

I was thinking about the whole S2/S3 problem with p2pool.  Do we know if other ASICs have the same problem, they can't respond quick enough to the 30s or less "drop everything you're doing and start over" requests?  Assuming so, is this a possible solution?

The basic requirement is changing p2pool to stop having to send those job restart requests every 30 seconds.  We know if we change the share time to more than 30s, share difficulty increases accordingly.

What if p2pool only sends the job restart request when a new Bitcoin block is found, roughly every 10 minutes?  

For that to work, it'd require a fundamental change in the p2pool "alt" share chain.

Instead of it being a chain, make a sequence of rings.  Each ring is composed of shares submitted by miners built upon the last Bitcoin block and the payout data of shares in the p2pool altchain.  They are _not_ built upon the last share submitted.

This has a few immediate consequences:

1 - When a p2pool block is found, payment is based entirely upon shares submitted up to the last Bitcoin block.  Every share submitted after that gets bundled into the next "ring".  That means payments are roughly 10 mins behind your shares, which I feel is of no consequence.
2 - Share orphans will drop significantly, since each share is no longer attempting to build upon the prior share, but the prior job p2pool submitted.  Again, that job is based upon the last Bitcoin block + the payout data of the p2pool altchain up to that last Bitcoin block.
3 - Share verification has to change, as it's no longer a chain, but a sequence of rings connected by Bitcoin blocks.  I'm not seeing how this is a show stopper, as each node should be able to verify the share's legitimacy and confirm the current job we're working on is legit.
4 - Job restarts are submitted on average once every 10 minutes, according the Bitcoin chain.
5 - We're talking a fork of the p2pool chain.
6 - Alt chain share size can not be arbitrarily set, presumably lower to solve the "low hash rate miner eligibility" problem.  However the lower it gets, the bigger the rings get for each round, which means a longer share chain.  However we could keep less than 3 days worth to compensate if need be.  (I would argue it'd be better to lose some private nodes that don't have the bandwidth and get more miners than it would be to have more smaller nodes but a less secure "chain".)  Lastly, it could be based on the number of shares submitted per 10 minutes, so the difficulty could still adjust each round if need be.

Thoughts?

M

EDIT: Added point 6.

As long as it's not an exchange address, yes.

M