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

Segwit dev here.

Who is maintaining the p2pool for litecoin? As segwit will activate in 2 weeks, p2pool upgrade is needed

My forked sharechain has switched to v32 shares. When I did this, I forgot to upgrade one of my nodes, which resulted in that node downloading shares from my upgraded nodes, rejecting them due to an unknown share version, and then downloading them. Eventually, it disconnects from the peers due to the perceived misbehavior, but since I had the connections hardcoded with an -n command line option, it reconnected again immediately. It seems p2pool could use a temporary ban feature for misbehaving peers as well as a blacklist for share hashes that are known to be invalid according to the node's ruleset. That should be done before p2pool gets too big in order to prevent DoS attacks.

I just bumped the protocol version up to 3200 and now require peers to have that protocol version. I think we're now ready to start testing with other people's nodes. I'd like to set up a chain of nodes connected via the internet at large (each with one incoming, one outgoing peer) so that I can get an idea how long full shares will take to propagate over many hops. Any volunteers? A chain of 5 or so nodes would be sufficient. See the bottom for instructions.

After this test has been finished, I can add some new DNS seed peers to the code to make it easier for people to join the fork. (Currently, you have to use the -n command line option to manually specify someone to connect to whom you know to be using my code.)

By the way, some rough performance numbers I've observed on my LAN using pypy and fast CPUs: it appears to take around 200 ms per hop to transmit and parse a 1MB share, even when the share is being sent to localhost (i.e. infinite bandwidth). It then takes about 80-120 ms per worker (i.e. per mining address, not per mining rig) to generate and assign new work. After new work has been assigned, it seems to take Antminer S9s around 300 ms before they stop working on the old work and switch to new work (or maybe that's just additional latency on the node side from serialized processing of network input causing delays in the processing of returned work). All told, this seems to add around 600 ms of latency. Over the last week of operation, the forked pool is showing total orphan and DOA rates of 0.59% and 1.2%, respectively, or about 1.8% total, which is pretty much equal to what we'd expect based on the observed latency (0.6 s / 30 s = 2%). This indicates that the changes I made to address the "Block-stale share punished!" and "Tried to broadcast a share without all of its transactions" issues appear to be resolved in this code. The old fork probably would get a DOA+orphan rate above 10%, and certainly no less than 5%, even on a LAN. Most of that high orphan rate was purely random and shouldn't adversely affect revenue, but it could still create unnecessary orphan races which benefit larger miners like me.

It will be interesting to see how high DOA+orphan rates end up being once this fork has more mining nodes. I'm guessing we'll probably be a little under 10%, but maybe 5% is possible. We'll see.

Due to the share chain holding about 2x as many transactions per share, the memory consumption is about 2x higher. Expect about 1.5 GB with CPython and close to 4 GB with pypy. I'm sure this can be improved if it's a major problem for people, but it's not the top of my priority list. (Do we even need all the transactions for old shares? Wouldn't the merkle root + coinbase be enough for shares that are too old to have reused transactions?)

---

If you want to contribute to the networked chain for share propagation testing, please clone https://github.com/jtoomim/p2pool/commits/1mb_hardforked, then configure your node to point to the previous poster's node (e.g. python run_p2pool.py -n previous_node), then list your node IP, what it's connected to, what type and speed of CPU you're using, how fat your pipe is, and whether you're using pypy or CPython (the regular python). Example, and to start us off:

Node IP: ml.toom.im (default ports)
Connected to: ml.toom.im:9334 and :9336 (or :9335 and :9337 for p2p ports)
To connect to me: run_p2pool.py -n ml.toom.im:9333
CPU: Core i7 4790k 4.0 GHz
Pipe: 100m/100m fiber
Using: pypy 2.4.0

8 hrs ago Block!!! https://blockchain.info/block-height/463189

Yes, I'll take the test. ;-)

Use the node speed, P2Pool.org only estimates based on how many shares you have currently.

Very grateful friend to clarify. I'm still doing some testing. I'll be right back to your node.

I'm fine.
Here's your graph for a month: http://crypto.office-on-the.net:9332/static/classic/graphs.html?Month

You mined unstable, and the average hashate on the node is 8.17TH/s
In addition a large percentage is DOA = 1.24TH / s
You need to select a near-by node from the list http://www.p2pool.org/stats/node_scanner.php
This will reduce the percentage of DOA and increase the efficiency of mining.

It's the same node. You need to specify different nodes:  primary and secondary

My speed on the node shows 11.7 ~ 13.5. However
Here http://www.p2pool.org/stats/ shows 5598.03 GH / s
There is something wrong, this is fact.

Hi friend, how are you?
Take a look, please.
I am logged into this node as a primary crypto.office-on-the.net:9332
E this as secondary 82.200.205.30:9332
The address I use is this one 1FTjZNDMV3TxdUM776cnZLTtyxeJzicZFu

Thank you for your attention and response. I will check with certainty.

This is my node. Can you tell which address are you mining on?
I'll take a look at your charts.

You were answered right:

Here is a graph of the global p2pool hashrate increasing for a month:

It can be seen that the global hashrate has significantly increased. This confirms what frodocooper said

Dear mining friends, excuse me a bit of ignorance in mining in p2pool. Actually I started 1 month ago, and I have some doubts.
I am mining on 82.200.205.30:9332 and the first time I called it gave 0.034
This number has been decreasing as the month ends. It is currently mining at 0.0002. Does this number go up again? There is something wrong? My hardware is a S9 12.5

 What a tide of bad Luck 

Fixed

It's Get Block Template (GBT) not Get Work Template.

The new node scanner is live!

http://p2pool.org/stats/node_scanner.php

It's different from previous scanners in that they only included peers the node had seen and stored, this version actually crawls from peer to peer checking each of a given peers peers to build a complete picture of the network, I'll update the network visualization next week to include the real time data.

Cool, I cant wait!  It seems all the other scanners have given up :\

Thank you for pointing that out. While the attack you implemented could be defended against by checking all transactions to see if they're in bitcoind's mempool, and if they're not, passing the transaction to bitcoind for validation (thereby incurring the tx validation cost in the critical path only for rare cases when the transaction is heard through a share before bitcoind has received it), and then checking that the coinbase reward is no more than the sum of the transaction fees and the block subsidy, but you're right that this proposed change increases the attack surface area too much for now.

At some time in the future, transaction fees will exceed the block subsidy, and we will likely need to have p2pool shares be weighted by fees at that time to keep the incentives aligned properly. However, it seems to make only a 1% difference in the reward assigned per user right now, this change is probably premature at the moment.

That's looking great be good to see it in action!

I mined a share with almost 10M BTC in fees, WHY AM I NOT COMPENSATED PROPERLY??? /s