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

I'm sure this has been discussed before but this thread is very large and hard to search, and the other discussion I found didn't answer.



What are the downsides to increasing the PPLNS windows/length of the sharechain? The only ones I can think of are a bigger coinbase transaction and more dust outputs (because more individual miners would get rewarded).

Everyone's been thinking about Lightning Network lately, I wonder if there's a way to have p2pool mine directly to a LN payment channel and have LN payments trustlessly made (somehow) to pay all the individual miners. This would avoid the problem of a large coinbase tx and many dust outputs. The backout transaction in case of a unilateral close could be paying to all the individual p2pool addresses similar to the coinbase today.

I'm thinking of ways to reduce variance of p2pool.

You could also reduce variance by reducing the share interval, but its already 30 seconds and reducing it further would increase stales more I suppose.

Although now right p2pool's variance is probably more caused by it's low hashrate compared to other pools, so it's a bit of a chicken-and-egg situation.

Is there somewhere to check whether larger miners are setting their share difficulty too high? That it negatively affects small miner's variance.

In the btc1 code the HF codepath was activated by bit 1, bit 4 was used only for BIP91.

Segwit2x has wipeout protection for full nodes(but not SPV wallets) so technically it can be a minority fork.

If a miner don't uses Bitcoin Core client to set up his p2pool node, witch client should he use and where to download it?

I've pushed two changes to https://github.com/jtoomim/p2pool/commits/1mb_segwit:

1. Allow mining with clients that do not support all locked-in or active forks (e.g. Bitcoin Core which does not support segwit2x) if p2pool is run with the --allow-obsolete-bitcoind command-line option.
2. Switch back to using time.time() in order to hopefully fix Xantus's "exceptions.OverflowError: mktime argument out of range" error on Windows

Yes Segwit2x is an example of knowing the major fork in advance, it won't activate until it is the major fork, so should be no issue for miners on p2pool ... unless they want to back a centrally controlled minor fork ...

I generally agree with what Kano wrote above.

The percentage of blocks signing /NYA/ is currently floating around 89% to 92%. This is why I think that Segwit2x is the future of Bitcoin. The percentage supporting BIP91 was similar when BIP91 was active.

According to the NYA, bit 4 was intended to be a signal for Segwit2x, and when btc1 is queried for the required softforks via GBT, btc1 has included segwit2x since bit 4 was triggered. Bit 4 is also supposed to be BIP91, so bit 4 is ambiguous. /NYA/ is unambiguous, but non-binding.

It's worth mentioning that Segwit2x can only exist if it has a majority of the hashrate. If your definition of Bitcoin is the post-fork chain with the most hashrate, then Segwit2x will either be Bitcoin or it won't exist. It's only if your definition of Bitcoin is Bitcoin Core that Segwit2x can be an altcoin.

Whatever. It shouldn't be too hard to get p2pool to support all three Bitcoins. It looks like I'll have a little bit of time later tonight, so I'll see what I can get done.

The answer is actually pretty straight forward, but doesn't always allow for a decision before-hand.

Bitcoin is a Peer2Peer system.
If someone wants a centrally controlled system, by Core, Ver, or some other minority, then they are the altcoin.
What this forum advocates has nothing to do with that either.

Bitcoin is what the majority of hash rate is mining.
If an ambiguous fork comes along - like BCH - where you don't know in advance who is switching to it, then that will become quite clear, soon after the fork, what is still Bitcoin - again, the majority.

The problem with the upcoming 2x is actually BIP91.
Some believed BIP91 was the /NYA/ agreement, but instead it was simply a lock in for segwit, and nothing more.
Yeah it's not hard to fool people

While most blocks show /NYA/ in their coinbase transaction, that doesn't affect the upcoming 2x change.

Since I'm a small pool, I'm sitting in the rafters waiting to see what happens, I can't affect Bitcoin in any significant way

I am a newbie here and am running on widows as well Frodocooper was very helpful to me when I started

Duce, there is disagreement about what will be Bitcoin and what will be the altcoin. I think SegWit2x will be the branch that survives and will be called Bitcoin. Others (including the owner of this forum, who often disallows dissenting opinions) think that No2x will be the branch that survives. Simply asking for the branch that is not the altcoin is ambiguous.

If you want to mine Segwit with Bitcoin Core, that is fine with me, as long as you are aware of the risks of choosing the chain with a hashrate minority. We have about 2 months until the fork happens. When I get a chance (this weekend? earlier?), I'll modify the commit from veqtrus that makes p2pool require that bitcoind have the same softforks flags set as p2pool (i.e. segwit and/or segwit2x) and change it so that it only displays a warning message or give it a command-line override or something. I'll do what I can to make sure that the share chain splits cleanly with or before the splitting of the Bitcoin blockchain.

For now, the lowmem branch will work fine for mining with Bitcoin core. lowmem does not support segwit, so you will need to upgrade before Segwit is activated next week, but after I submit the changes that allow non-segwit2x clients to run on 1mb_segwit.

It is, when each and every P2Pool node operator is free to edit (and even disable) this percentage with the --give-author parameter.


I don't see how disparaging P2Pool's volunteer developers helps anyone.


Not entirely. Provided that whichever fork of P2Pool you are on does not hard-fork into a new segwit-only sharechain, and that your P2Pool node is connected to a segwit-supporting Bitcoin full node (e.g., Bitcoin Core 0.13.1 or later), your P2Pool node should still continue to work without issues even after segwit activates on the Bitcoin network, as the segwit soft-fork does not require miners to produce segwit-style blocks.

"1Meg"+segwit requires 2x which will be an altcoin. "1Meg"+segwit is based on my PR against the main p2pool repo so when it will be merged that will be the correct version for bitcoin.

So which version will work with segwit, the one that is supported by Bitcoin core? Is that 1Meg now lowmem version? I would like to stay with P2P for Bitcoin and not fork to an alt coin. After reading the post in the link provided this again makes sense to me https://bitcointalksearch.org/topic/just-confriming-segwit-or-segwit2x-is-going-ahead-on-btc-2090805.

It seems that there is a divide on which direction P2P will take. We have the old fork still running that will not be compatible when segwit is implemented around August 23rd, true? Then the the 1Meg or lowmem version that would be the correct version for segwit, true? Then we have segwit 2 which will be an alt coin.

i using this version : http://u.forre.st/u/wanckfqm/p2pool_win32_16.0.zip found on http://p2pool.in. is an Windows Executabe file (simpel .exe)

You misunderstood, I have been running from source on windows and made my own exe using py2exe.

me too, usind p2pool_win32_V16. on Windows 10. But Old version, Segwit2x is an problem for me up to now.

p.s. found Block 

I have been running p2pool on windows only and had no problem.

frodocooper  lick boots number one WINNER
A lot of people stopped mining here a long time ago because there is no non-linux OS support.
Now people can not express their opinion and shake things up a bit because frodocooper do not let.
Who receives percentage for running the p2pool code (forrestv) is not called voluntary.
Show you some respect for a member with many posts helping newbies with his problems in this forum.

I think that is a reasonable and simple approach.

I also think we do not want P2Pool nodes operating on different forks to talk to each other. If a node is sending shares that do not apply to my fork then I want to drop the connection. Shares of stale blocks can keep connection with punishment. A stale block is different than a foreign block.

If P2Pool nodes are dropping forked connections I think the P2Pool networks will align themselves automatically realtive quick.


I will look into this as I have staked interest. If you want to send or post guidance it would certainly help. I also have little time available.

If you don't know what a blockchain and a Bitcoin client is, then I suggest you take a good, long, hard look at whether you ought to be mining in the first place.


And what have you done for P2Pool so far, besides running your mouth? forrestv, veqtrus, and jtoomim have done more for P2Pool than the rest of us combined, and on a voluntary basis too. Please show some respect.


The next reward halving is projected to be on May 17, 2020. That's 3 years from now. Not exactly what most of us here would call "around the corner."

All this indicisions around p2pool bother me.
What blockshain?
What bitcoin client?
Who started this p2pool mess doesn't have time to
finish it!
And we are loosing time because the next bitcoin halving is around the corner and p2pool is not full throtle yet...