[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[sawa]

Hi.Welcom p2pool dashcoin algo X11 stratum+tcp://95.59.72.81:7903

http://95.59.72.81:7903/fee
50.0 fee

[1714057697]

1714057697

[1714057697]

1714057697

[1714057697]

1714057697

[1714057697]

1714057697

[1714057697]

1714057697

[Meuh6879]

Ah ... We have news players.

[jtoomim]

I just finished a beta version of a merge of veqtrus's SegWit code with my 1mb_hardforked+lowmem code. I've also added a couple of things that should improve the likelihood of it working with altcoins. I'm testing with Bitcoin right now. I'll try to have the testing done and the Bitcoin code ready for others to use within a couple of days, and then I'll work on the altcoin stuff and test it with Litecoin.

[Xantus]

Questions:
Running bitcoin 14.2 with the -addnode=.location.fibre.bitcoinrelaynetwork.org, is this correct? I have been whitelisted.

Running 16.0-4-gde 1be30, is there another version I should be running for BIP 91?

If not then what is the version as I would like to add the BIP 91 nodes as stated above.

If these have been answered can you please provide the links? I have search here and the web and can’t seem to put my finger on it.

my question is nearby,

is there a way to see the aktual sign/bits for bip´s my node / my miner has set ?
And can i change this for my miner or for my p2pool node or is that p2pool wide fixed ? and if yes how can i do that ?

my wich is to support PIB91 (perhaps to late for 91 but i could switch in that case to BIP141)

p.s. hi there ;-)

[jtoomim]

is there a way to see the aktual sign/bits for bip´s my node / my miner has set ?
And can i change this for my miner or for my p2pool node or is that p2pool wide fixed ? and if yes how can i do that ?

Using a web browser, navigate to your node's status page, and click on one of the links in My Shares. Then look for a section that looks like this:

Code:

Header

Version (dec): 536870930

Version (hex): 20000012

(I recently switched my node over to btc1 too.)

The bitcoind version you're using (Unlimited/Core/btc1/etc) will include a version bits suggestion which gets passed to your p2pool node in the getblocktemplate response. Depending on which version of the p2pool code you're using, your p2pool node may either use the version bits it receives from bitcoind, or it may override it (see https://github.com/jtoomim/p2pool/blob/lowmem/p2pool/work.py#L386 for an example -- I've never liked that max() line, but haven't changed it in my branch yet). If you want to force particular version bits even though the bitcoind you're using doesn't make those version bits, you can do so by editing that line in your p2pool source code. Each p2pool node can use different version bits, so the final block version bits that you see depends on which p2pool node actually mined the block.

[windpath]

I just finished a beta version of a merge of veqtrus's SegWit code with my 1mb_hardforked+lowmem code. I've also added a couple of things that should improve the likelihood of it working with altcoins. I'm testing with Bitcoin right now. I'll try to have the testing done and the Bitcoin code ready for others to use within a couple of days, and then I'll work on the altcoin stuff and test it with Litecoin.

Awesome!

[veqtrus]

I just finished a beta version of a merge of veqtrus's SegWit code with my 1mb_hardforked+lowmem code. I've also added a couple of things that should improve the likelihood of it working with altcoins. I'm testing with Bitcoin right now. I'll try to have the testing done and the Bitcoin code ready for others to use within a couple of days, and then I'll work on the altcoin stuff and test it with Litecoin.

My patch is already running successfully on vertcoin's p2pool. In fact after segwit's activation p2pool's hashrate rose so much that the devs made a second network for smaller miners.

[TierNolan]

Each p2pool node can use different version bits, so the final block version bits that you see depends on which p2pool node actually mined the block.

Are you planning to enforce BIP-91 for p2pool (assuming it locks in)?

If someone produces a share without the segwit bit set, then that share is effectively worthless (at least until segwit is locked in).

An easy rule would be that the bit must be set until August 1st and then while at least 750 of the last 1000 blocks have it set.  That saves you needing to add code to figure out if segwit has been locked in.

[jtoomim]

Are you planning to enforce BIP-91 for p2pool (assuming it locks in)?

This is a complicated question. Currently, there's an incompatibility between p2pool and BIP91 in that p2pool will mine a transaction-free block on top of the longest chain seen if p2pool hears about a new block but bitcoind does not inform p2pool about this block. While I think this is the correct behavior during normal operation, it is clearly incorrect behavior during chainsplit conditions, so it will need to be disabled for the next month or so. I will be including that change in the new branch I'm working on that merges SegWit and large block generation capability.

If someone produces a share without the segwit bit set, then that share is effectively worthless (at least until segwit is locked in).

I am not convinced that this is the correct action to take. P2pool generally does not validate the blocks that other nodes are trying to mine except to ensure that the payouts are fair. I'm not sure that we should start now. On one hand, it serves as an added incentive for people to ensure that they are BIP91 compatible. On the other hand, it disincentivizes miners using p2pool as a tool to vote their conscience. I tend to believe that the latter objective is generally more important, but I'm not sure in this particular case. It may be that people would want to exploit p2pool to mine minority-chain blocks while still getting paid on the majority chain, which could be a problem. Perhaps the best solution is just to fork the share chain again, and let anyone who wants to disobey BIP91 do so on their own minority sharechain. However, that approach would require the most work of any.

An easy rule would be that the bit must be set until August 1st and then while at least 750 of the last 1000 blocks have it set.  That saves you needing to add code to figure out if segwit has been locked in.

That would actually be a difficult rule, since p2pool does not store a copy of the blockchain anywhere, and is unable to evaluate whether 750 of the last 1000 blocks have it set.

[TierNolan]

While I think this is the correct behavior during normal operation, it is clearly incorrect behavior during chainsplit conditions,

If BIP-91 goes into effect, then BTC1 connectivity is going to be an issue, agreed.

Even nodes with the btc1 client aren't safe, since they could be surrounded by non-BIP-91 nodes and not get the updated block (since it counts as a tie).

so it will need to be disabled for the next month or so. I will be including that change in the new branch I'm working on that merges SegWit and large block generation capability.

How will that work?  You can't build non-empty blocks if your local bitcoin node doesn't have the tip block. 

You could poll the local node.  If it has it, then it might send it even if it isn't the longest chain (as far as it is concerned).

I think BIP-91 nodes will preferentially connect to at least a few BIP-91 other nodes (or maybe they didn't bother with that).  That means that if the local node is btc1, then you would be ok.

I am not convinced that this is the correct action to take. P2pool generally does not validate the blocks that other nodes are trying to mine except to ensure that the payouts are fair.

That is because p2pool cannot verify without lots of overhead (distribute the full block for each share).

If BIP-91 locks in, then it is guaranteed that blocks which don't flag segwit are invalid and that info is in the header which (I assume) is shared between p2pool nodes.

I'm not sure that we should start now

It would definitely be an emergency fix and has a risk/reward profile.  Network-wise, it is a soft fork.

On one hand, it serves as an added incentive for people to ensure that they are BIP91 compatible.

Shares which are invalid are basically draining the network of earning potential.  They get paid, but provide nothing.

On the other hand, it disincentivizes miners using p2pool as a tool to vote their conscience.

I am not suggesting that you should force people to vote for BIP-91.

However, if BIP-91 does lock in, then that counts as a soft fork and a change to the bitcoin rules.

You would be enforcing the (new/soft forked) Bitcoin protocol. 

Perhaps the best solution is just to fork the share chain again, and let anyone who wants to disobey BIP91 do so on their own minority sharechain. However, that approach would require the most work of any.

You could soft fork it.  If 75% agree, then activate the change.  As you say, it is a judgement call.  Maybe people would like to preserve the ability to create their own blocks.

That would actually be a difficult rule, since p2pool does not store a copy of the blockchain anywhere, and is unable to evaluate whether 750 of the last 1000 blocks have it set.

Fair enough.  You could just make it time based (all blocks from now until 15 August).

[jtoomim]

The point I was trying to make is that btc1 and other BIP91 clients will blacklist certain blocks, and the current version of p2pool will ignore and violate that blacklisting. This needs to be fixed. P2pool should not assume that blocks that it hears about over the network and not via bitcoind are valid when chainsplits are occurring.

Basically, the tip that p2pool sees will often be the wrong tip. P2pool needs to trust its bitcoind for the next month.

Making sure that btc1/bitcoind always has the best block is a separate issue. All btc1 miners need to ensure that they have used addnode or one of Matt Corallo's relay networks to connect to other btc1 miners, but that is not something that p2pool can control.

[windpath]

BIP91 clients will blacklist certain blocks, and the current version of p2pool will ignore and violate that blacklisting

Since we are forking anyway would it not be cleaner for p2pool to do a simple version check on blocks it receives from other p2pool nodes, or would further validation be required?

[TierNolan]

The point I was trying to make is that btc1 and other BIP91 clients will blacklist certain blocks, and the current version of p2pool will ignore and violate that blacklisting. This needs to be fixed. P2pool should not assume that blocks that it hears about over the network and not via bitcoind are valid when chainsplits are occurring.

I guess it is an inherent part of p2pool that you trust the other miners aren't throwing their hashing power away.

Basically, the tip that p2pool sees will often be the wrong tip. P2pool needs to trust its bitcoind for the next month.

Well if bitcoind is core, then it is "wrong" since it is not checking the new soft-forking rule.

No matter what side someone is on the debate, miners need to update to the latest locked-in soft fork or they can lose money.

Assuming that 20% of the mining power is not segwit2x compatible, then for about 1 in 5 blocks, non-btc1 clients will be on an invalid tip.

If only 50% of p2pool miners are updated, then that represents a pool efficiency drop of around 10%.

What will likely happen is that most miners will quickly become compatible, if 95% of miners are compatible, then only 1 in 20 blocks will have a problem.  That means that the efficiency cost (assuming 50% updated) is only a 2.5% and is probably not worth the hassle.

I think producing empty blocks if the node is trying to build on a non-BIP91 chain is reasonable and would virtually eliminate the efficiency cost (but mean no transactions).

[-ck]

A lot of this discussion may be a non-event now. Since the BIP91 support is overwhelming now, the chance of the network being partitioned is getting smaller by the minute. Very shortly even those pools that haven't been supporting BIP91 will reluctantly convert to the code to avoid having their blocks being orphaned. In which case there really will only be segwit compatible blocks generated once BIP91 being activated except for some very small minority miners that may not have updated. If p2pool runs BIP141 segwit compatible that will likely be enough to avoid building on a dead end chain because it looks like there won't be any dead end chain...

[jtoomim]

Since we are forking anyway would it not be cleaner for p2pool to do a simple version check on blocks it receives from other p2pool nodes, or would further validation be required?

It's not a simple version check for p2pool, unfortunately, because the duration of the version check is very specific, and it requires a copy of the blockchain (which p2pool does not have) in order to know what that duration is.

-ck, the question is whether p2pool should allow BIP91-incompatible shares, not blocks. I'm fine with people mining BIP91-incompatible blocks if they want to, but it's not clear that they should get rewarded by other p2poolers for their folly.

[TierNolan]

If p2pool runs BIP141 segwit compatible that will likely be enough to avoid building on a dead end chain because it looks like there won't be any dead end chain...

Ironically, the problem is that bitcoin-core doesn't reject blocks that don't flag segwit.  That means that p2pool miners who are using core will build on the wrong block whenever a non-segwit block is found.

If p2pool built empty blocks when bitcoind is building on a non-segwit block, then almost all the inefficiency goes away.

[-ck]

If p2pool runs BIP141 segwit compatible that will likely be enough to avoid building on a dead end chain because it looks like there won't be any dead end chain...

Ironically, the problem is that bitcoin-core doesn't reject blocks that don't flag segwit.  That means that p2pool miners who are using core will build on the wrong block whenever a non-segwit block is found.

If p2pool built empty blocks when bitcoind is building on a non-segwit block, then almost all the inefficiency goes away.

The thing is there is virtually no one left mining non-BIP91 (connectbtc and any solo miners out there who haven't changed as far as I can see) so you'd have to be ultra-unlucky to build on one block in 100 that isn't signalling segwit AND find a block. Possible, yes, but extremely unlikely. I think anyone left will probably change to signal segwit anyway before then.

[TierNolan]

The thing is there is virtually no one left mining non-BIP91

Xbt is showing SW + BIP91 = 99.3% so agreed the point is moot anyway.

[kano]

The thing is there is virtually no one left mining non-BIP91

Xbt is showing SW + BIP91 = 99.3% so agreed the point is moot anyway.

Moot? No. It's not zero. Not likely, is not zero.

When you next find a block, if it's rejected because p2pool 'will' mine on invalid blocks, you know it's because no one fixed it.
Damn shame.

[TierNolan]

When you next find a block, if it's rejected because p2pool 'will' mine on invalid blocks, you know it's because no one fixed it.
Damn shame.

Now that I think about it more, there are actually 3 percentages that matter.

1) Total miners who are signalling segwit (that is around 99.3%)
2) P2pool miners who are not signaling segwit
3) P2pool miners who are using non-BIP-91 compatible code

The cost of 3) depends on the 1).  If almost all blocks signal segwit then the fact that sometimes p2pool miners build on the wrong block doesn't have much effect.

2) is a direct cost.  If 80% of p2pool miners are flagging segwit, then 20% of the blocks that p2pool finds will be invalid.  In that case, mining on p2pool is like mining on a pool that has 20% fees (except that nobody actually gets the fees).

A rule that that marks shares that don't flag segwit as invalid would be justified.