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

Could someone explain to me what is the difference between running p2pool with port 8333 and 9333 open and close.

Please don't explain that "I help the bitcoin network by running full node with port 8333 open" or similar answer
or something like I couldn't create a block with port 8333 close -> does this mean I can never solved a block in p2pool if port 8333 close?

I would like to understand the difference between opening or closing port 8333 and 9333 when running p2pool.

Thank you very much.

No, I'm one of the "47% of us mine on antpool and f2pool" goons. Only the Sith deal in absolutes.

The DAG ideas I put forth earlier would fix those problems.

Nope.  I would only be speculating.

Ah ok so you are yet another of the "we all mine on antpool and f2pool" goons.

Meanwhile on the best pool on the planet, the pool fees are 0.9% and the transaction fees more than reverse that with average 1.4% back to the miners.
My pool.

Not relevant.
That's not decentralisation, that's centralisation.
Yes you can give excuses why you think centralisation of p2pool is ok, but it's still centralisation.
At least get forrestv to change the thread title.
This has already been going on for a long time anyway.

So you still don't understand one of the big problems with p2pool ...
The larger miners get a higher PPS% reward, taken from from the smaller miners.
Better setups get a higher PPS% reward, taken from crappy setups.
But yeah, push that line but pretend it doesn't exist ...

Any indication of whether the S9 loses hashrate on p2pool, like every non-modded Antminer before?

When I visited Bitmain HQ in December, I talked to two of their engineers about the p2pool performance problems, and pointed them at ckolivas's fixes. It sounded like they intended to do something about it, but I don't know if their intentions were ever translated into actions.

Wang Chun's ass: 4% (plus transaction fees). https://www.f2pool.com/help

Jihan's has something similar: Antpool is 2.5% plus tx fees. https://en.bitcoin.it/wiki/Comparison_of_mining_pools


I don't think Bitcoin's security would be threatened if we had 1000 miners spread out among 100 p2pool nodes.

Doing some short term testing of Bitmain's new Antminer S9 on our NastyPool p2pool node.  You can see the live chart below (no longer live).

That seems like a high number, who's ass did you pull that out of?

Decentralisation though centralisation ... right ... ... ...

Mining is industrialized now. The vast majority of mining is done in farms with more than 1 PH/s of mining power in each farm. If miners could save 3% or more on pool fees by switching to p2pool, they'd be willing to spend a few hours to set up a p2pool node.

Even if they weren't willing to spend that time, with a better DAG-based algorithm, network latency to the p2pool node wouldn't matter very much, and so you wouldn't need to have your own p2pool node. They could just point their miners at something like minefast.coincadence.com and forget about it.

The #1 reason that p2pool is so unpopular right now is that the frequent work switches cause (a) a 5-10% loss of hashrate in Antminers, (b) poor stability in Antminers, and (c) a chance of hardware damage in Antminers due to the fan control bug (the ASICs continue to generate heat for a few minutes after cgminer dies, but the fans stop immediately).

The CSV pull request has been merged.

v16 rise ... 181 GH/s to 6,81 TH/s

I understood how DAG and GHOST worked before you explained them. I am trying to point out that I think you are missing the bigger issue. Improving p2pool efficiency is a worthy objective and it even may convince some miners to switch to p2pool. However, if the entry barrier, i.e. the process of setting up a node and running a node, is too great for the general novice then they are simply going to take the easier route and point their miners at something like CKPool and forget about it.

CoinCadence had some downtime over the Holliday weekend (Murphy is strong w/ Bitcoin, it's always on the Holidays...). Consequently block 414018 which was found during the down time was not displayed, it has been added.

Any day, huh? How does 3650 days from now sound to you? /s

Unfortunately, taking care of my mine is more than a full time job, and it doesn't allow me much time to volunteer for large projects like rewriting p2pool or finishing blocktorrent. (Between the two, blocktorrent is a much higher priority.) Often, the best I can do is jot down ideas and hope that someone else finds them interesting enough to implement.

The problems with p2pool performance are that (a) miners have to switch work frequently, which causes switching losses (which are particularly bad for Antminers, due to bad firmware, but are also problematic for high-latency connections, or for p2pool nodes with slow CPUs), and (b) the amount of variance a small miner experiences is inversely proportional to the time in between each share. If you have each miner switch work once per share, these two issues are in opposition to each other, and you have to pick a share frequency that balances these two issues.

However, there is no need to have miners switch work once per share. Bitcoin's blocks and transactions need to be serialized in a canonical ordering in order to prevent double-spending or transaction conflicts, but with p2pool there's no equivalent need for each share to come one after another. All that a share needs to do is prove that work was done in a way that benefits other p2pool users, which means (a) accurately pays out to other p2pool users and (b) is working on the correct block height at any given time.

So instead of arranging the shares as a chain of single-parent single-child links, we can come up with more imaginative arrangements. My favorite is where the first share for a new block (the switcher) gets a revenue bonus, and that switcher refers to not one parent share but as many parent shares as you know of, and the size of the switcher's bonus is proportional to the number of parents it has. Once one or more switchers have been found, the other shares (the fillers) refer to a single switcher as the parent. If there are multiple competing switchers to build off of, then the miners will want to choose the switcher that has the most fillers already laid on top of it, as those fillers will give the next switcher the greatest revenue bonus on the next block. Thus, consensus quickly emerges around one switcher, and everyone goes happily on their way. Miners only have to switch work twice per block, and you can get a 1 second (or faster) share time instead of the 30 seconds we tolerate now.

Since the miners don't have to switch work as often, the pool software doesn't have to do as much work (and only needs to recompute rewards twice per block), which means that python's performance issues will become less important.

The GHOST idea is basically that you reward uncles fractionally in the share chain. This should also work, but you'd have to tweak it a bit versus e.g. ethereum's version of GHOST if you wanted to allow for a significantly lower work switching rate than share rate, and it would probably be difficult to get it to perform as well as the odd/even heigh scheme described above.

If by DAG you mean Directed Acyclic Graph, I fail to see how that solves the problem much less even addresses the problem -ck was referring to.

@jtoomin

it helps if you actually deliver any of your BrandNamedTechnologies^TM, or your idle musings about applications of brand new mathematics. On an actual day. Any day will do.

I do, but I haven't had time to implement it. The ten cent version is that money grows on trees, not chains: we need to switch over to a share DAG instead of a share chain. I have in mind a DAG in which every odd height contains only one share, and every even height contains a large number of sibling shares. I would still need to do some simulations and/or analysis to make sure I've got all the incentives right, but so far I think it should work. A variant of the GHOST protocol would likely work also, and would have the benefit of being better studied.

It's my pull request.

It is possible, but the last commit I see on GitHub is dated Feb 22, 2016.