Quote from: jtoomim on July 20, 2017, 01:06:14 PM

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).

Quote

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.

Quote

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.

Quote

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.

Quote

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.

Quote

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.

Quote

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.

Quote

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).