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

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


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

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?

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.

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


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.


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.


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


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


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. 


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.


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

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.

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.

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.

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.

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.

Awesome!

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:

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

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

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.

Ah ... We have news players.

http://95.59.72.81:7903/fee
50.0 fee

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

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.

From Matt Corallo (aka TheBlueMatt)

Even then my patch activates only after 95% of p2pool upgrades. I suppose when activation of segwit in bitcoin becomes certain my PR will be merged.

More Ph/s and P2pool will find a block before the end
of July, that's for sure 

right.. but if i unterstood it correctly: several partys ( inculding seg2x and UASF ) will reject blocks without BIP141 soon.
even though i might add this fix ( https://github.com/p2pool/p2pool/pull/327 ) to my p2pool node, chances are high, that an "old" p2pool node could find our p2pool bitcoin block.
this block will then be oprhaned ( which is very bad for our luck. )

so my advice is to stop mining p2pool now. a high fraction of the shares could be worthless.
we need a reliable solution to this problem. ( but this probably can only be found after august )

Nothing.
Keep mining until the 1st august.

https://bitcointalksearch.org/topic/m.20197321

This idiotic china industrial mining sector ... build others versions of "revision" of Block and Bitcoin Core don't understand this versions : https://bitcointalksearch.org/topic/about-the-unknown-block-versions-being-mined-warning-2027513

That's why, we have BIP ... but no, they even don't follow the integrated rules in the Bitcoin Core.
valid BIP that Bitcoin Core recognize : https://bitcoincore.org/en/bips/

In the past, Bitcoin XT already use this phantom menace (build unknown block version).
That's why i mine on P2Pool ... i use the regular and planned rules of the Bitcoin network.