Hi Jtoomin
I think it's good to be active but you could also have done things in a way that did not increase the variance of those who stayed in main P2pool
More dialogue and humility maybe
Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 14. (Read 2591630 times)
December 18, 2017, 07:25:37 PM
December 18, 2017, 06:23:11 PM
It looks like the Bitfury B8 does not support large stratum.notify messages. P2pool needs large stratum.notify messages in order to be able to transmit the large coinbase transactions. Large coinbases are fundamental to the security design of p2pool, so there's nothing that we can do about it on the pool end. You would need to take up this issue with Bitfury's software engineers.
December 18, 2017, 06:03:25 PM
Hello. It's a problem to connect to jtoomim/p2pool with asic "bitfury B8". may be you have a solution?
https://ibb.co/fU6G5R
https://ibb.co/fU6G5R
December 18, 2017, 06:02:17 PM
BLOCK! On jtoomimnet https://blockchain.info/ru/block-index/1654337
Worth noting: I had my bitcoin.conf configured to make blocks as large as possible:blockmaxweight=4000000
And the block was, indeed, quite close to the limit:
Size 1052.071 kB
Weight 3997.486 kWU
This was made possible and safe by the recent additions I made to my code that will factor in the estimated size of the coinbase transaction, and kick transactions out of the block template if necessary. My code is designed to stop 2000 WU before the absolute limit in order to allow for small differences between the estimated and actual block sizes, which is why this was a 3997486 WU block instead of a 3999486 WU block.
If anyone is curious, here is the log output from my node around the time this block was mined:
Code:
2017-12-18 04:32:23.764387 Generating a share with 1050601 bytes, 3991966 WU (new: 23794 B, 89938 WU) in 2066 tx (71 new), plus est gentx of 1396 bytes/5620 WU
2017-12-18 04:32:23.764556 Total block stripped size=981931 B, full size=1052077 B, weight: 3997826 WU
2017-12-18 04:32:23.843529 136.330 ms for data.py:generate_transaction(). Parts: 0.158 3.414 53.451 0.159 79.148
2017-12-18 04:32:23.844104 180.796 ms for work.py:get_work()
2017-12-18 04:32:23.925291 924.070 ms for 1 shares in handle_shares (924.070 ms/share)
2017-12-18 04:32:23.936384 Peer sent entire transaction 5ca0b9f11f3193f69d6b1687b43acfff5bbe3f1610a76ba37592ee07ba2188b4 that was already received
2017-12-18 04:32:23.939249 Peer sent entire transaction 5ca0b9f11f3193f69d6b1687b43acfff5bbe3f1610a76ba37592ee07ba2188b4 that was already received
2017-12-18 04:32:23.944456 2.968 ms for 1 shares in handle_shares (2.968 ms/share)
2017-12-18 04:32:23.948191 3.115 ms for 1 shares in handle_shares (3.115 ms/share)
2017-12-18 04:32:23.951570 2.821 ms for 1 shares in handle_shares (2.821 ms/share)
2017-12-18 04:32:23.954900 2.797 ms for 1 shares in handle_shares (2.797 ms/share)
2017-12-18 04:32:23.958251 2.812 ms for 1 shares in handle_shares (2.812 ms/share)
2017-12-18 04:32:23.961782 2.929 ms for 1 shares in handle_shares (2.929 ms/share)
2017-12-18 04:32:24.889698 Peer sent entire transaction 5ca0b9f11f3193f69d6b1687b43acfff5bbe3f1610a76ba37592ee07ba2188b4 that was already received
2017-12-18 04:32:25.370185 3.244 ms for 1 shares in handle_shares (3.244 ms/share)
2017-12-18 04:32:26.717241 Peer sent entire transaction 9bc2bafec43c0e3a9ffb9b10621ca6b77627e7a0f802e5df8c0b380245b8415c that was already received
2017-12-18 04:32:26.726678 2.934 ms for 1 shares in handle_shares (2.934 ms/share)
2017-12-18 04:32:26.836726 11.868 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:26.847821 10.891 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:26.860461 12.451 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:26.872352 11.701 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:26.885143 12.595 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:26.897314 11.985 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:26.911711 14.206 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:26.923997 12.071 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:26.937153 12.968 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:26.949496 12.135 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:27.680559 Peer sent entire transaction 5ca0b9f11f3193f69d6b1687b43acfff5bbe3f1610a76ba37592ee07ba2188b4 that was already received
2017-12-18 04:32:27.781446 10.656 ms for helper.py:getwork(). Cache: 2070 hits 47 misses, 2105 known_tx 12 unknown 2587 cached
2017-12-18 04:32:28.700326 Peer sent entire transaction b84a525c3e065c183b6b1a45ef98da80801cb554f8c309441c8646e30bbab413 that was already received
2017-12-18 04:32:30.514602 Peer sent entire transaction 0ec0033ba308dc006fc49f2b2c73c8467200ae846b2ba433c8092567c9e1fbd9 that was already received
2017-12-18 04:32:30.518152 Peer sent entire transaction b84a525c3e065c183b6b1a45ef98da80801cb554f8c309441c8646e30bbab413 that was already received
2017-12-18 04:32:30.521218 Worker 1GuDnEyYSE3Ra3pMar7311tx5poR5PGXR3 submitted share with hash > target:
2017-12-18 04:32:30.521346 Hash: 77e33ccb9b92cde64705f708be94525bb0e113deee3e6559bb0abf4b7a89f736
2017-12-18 04:32:30.521423 Target: 10c6f7a0b5ed8d36b4c7f34938583621fafc8b0079a2834d26f9
2017-12-18 04:32:36.972170 11.982 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:36.983925 11.557 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:36.994522 10.408 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:37.006029 11.315 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:37.018718 12.475 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:37.031845 12.939 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:37.043480 11.445 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:37.055306 11.626 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:37.069050 13.556 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:37.081041 11.803 ms for update_remote_view_of_my_known_txs
2017-12-18 04:32:38.301052
2017-12-18 04:32:38.301223 GOT BLOCK FROM MINER! Passing to bitcoind! https://blockchain.info/block/00000000000000000026d48abfeffa1359e5d8927a21c228b76ec2c5a93a6eee
2017-12-18 04:32:38.301306
2017-12-18 04:32:38.328740 GOT SHARE! 1GuDnEyYSE3Ra3pMar7311tx5poR5PGXR3 a93a6eee prev bfda9584 age 14.70s
2017-12-18 04:32:38.341776 6.076 ms for data.py:generate_transaction(). Parts: 0.212 3.215 0.555 0.152 1.942
2017-12-18 04:32:38.592832 Generating a share with 1050601 bytes, 3991966 WU (new: 23794 B, 89938 WU) in 2066 tx (71 new), plus est gentx of 1351 bytes/5440 WU
2017-12-18 04:32:38.593057 Total block stripped size=981886 B, full size=1052032 B, weight: 3997646 WU
2017-12-18 04:32:38.690612 167.634 ms for data.py:generate_transaction(). Parts: 0.381 3.611 65.694 0.165 97.783
2017-12-18 04:32:38.793265
2017-12-18 04:32:38.793431 GOT BLOCK FROM PEER! Passing to bitcoind! a93a6eee bitcoin: https://blockchain.info/block/00000000000000000026d48abfeffa1359e5d8927a21c228b76ec2c5a93a6eee
2017-12-18 04:32:38.793493
2017-12-18 04:32:38.794405 0.678 ms for 1 shares in sendShares (0.678 ms/share)
2017-12-18 04:32:38.795381 0.886 ms for 1 shares in sendShares (0.886 ms/share)
2017-12-18 04:32:38.796027 0.533 ms for 1 shares in sendShares (0.533 ms/share)
2017-12-18 04:32:38.796640 0.503 ms for 1 shares in sendShares (0.503 ms/share)
2017-12-18 04:32:38.797336 0.589 ms for 1 shares in sendShares (0.589 ms/share)
2017-12-18 04:32:38.797920 0.497 ms for 1 shares in sendShares (0.497 ms/share)
2017-12-18 04:32:38.798605 0.599 ms for 1 shares in sendShares (0.599 ms/share)
2017-12-18 04:32:38.799251 0.560 ms for 1 shares in sendShares (0.560 ms/share)
2017-12-18 04:32:38.799855 0.517 ms for 1 shares in sendShares (0.517 ms/share)
2017-12-18 04:32:39.030351 0.239 ms for 0 shares in sendShares (0.239 ms/share)
2017-12-18 04:32:39.030705 0.162 ms for 0 shares in sendShares (0.162 ms/share)
2017-12-18 04:32:39.030962 0.145 ms for 0 shares in sendShares (0.145 ms/share)
2017-12-18 04:32:39.031259 0.169 ms for 0 shares in sendShares (0.169 ms/share)
2017-12-18 04:32:39.031492 0.141 ms for 0 shares in sendShares (0.141 ms/share)
2017-12-18 04:32:39.031717 0.137 ms for 0 shares in sendShares (0.137 ms/share)
2017-12-18 04:32:39.031934 0.134 ms for 0 shares in sendShares (0.134 ms/share)
2017-12-18 04:32:39.032164 0.136 ms for 0 shares in sendShares (0.136 ms/share)
2017-12-18 04:32:39.032380 0.135 ms for 0 shares in sendShares (0.135 ms/share)
2017-12-18 04:32:39.136983 Generating a share with 1052184 bytes, 3991977 WU (new: 14994 B, 55605 WU) in 2117 tx (47 new), plus est gentx of 1351 bytes/5440 WU
2017-12-18 04:32:39.137163 Total block stripped size=981362 B, full size=1053615 B, weight: 3997657 WU
2017-12-18 04:32:39.225390 148.685 ms for data.py:generate_transaction(). Parts: 0.200 3.971 55.902 0.187 88.425
2017-12-18 04:32:39.254714 New work for 1GuDnEyYSE3Ra3pMar7311tx5poR5PGXR3! Diff: 999984.74 Share diff: 42865139.65 Block value: 16.55 BTC (2117 tx, 1052 kB)
2017-12-18 04:32:39.255033 222.373 ms for work.py:get_work()
2017-12-18 04:32:39.361077 Generating a share with 1052184 bytes, 3991977 WU (new: 14994 B, 55605 WU) in 2117 tx (47 new), plus est gentx of 1351 bytes/5440 WU
2017-12-18 04:32:39.361249 Total block stripped size=981362 B, full size=1053615 B, weight: 3997657 WU
2017-12-18 04:32:39.442562 140.161 ms for data.py:generate_transaction(). Parts: 0.183 3.693 54.630 0.169 81.486
2017-12-18 04:32:39.443181 185.006 ms for work.py:get_work()
Consequently, I think it is now safe to set blockmaxweight=4000000 on jtoomimnet.
Note: the block weight checking code is completely absent on mainnet, and mainnet's coinbase transaction is larger than jtoomimnet's, so if you're using github.com/p2pool/p2pool, you MUST use blockmaxweight=3950000 or lower. (If mainnet gets more users, then it will need to be lowered.) Otherwise, blocks mined on mainnet will frequently be invalid for violating the block size/weight limits and your revenue will be nil.
December 18, 2017, 05:36:24 PM
They are separate p2p networks. If you mine on jtoomimnet, you will not get a reward when mainnet mines a block, and vice versa.
p2pool/p2pool is sorta the official one, but it's not actively maintained. forrestv, the originator of the project, is no longer actively maintaining it. I am actively maintaining my fork of p2pool, at least for the Bitcoin and Bitcoin Cash networks, but have not yet merged my code into p2pool/p2pool and do not currently have any control over that repository.
jtoomimnet has much more hashrate than mainnet does (mostly because I'm on jtoomimnet -- we alone have about 5.5 PH/s). Consequently, jtoomimnet should find blocks far more often. We're currently looking at about 15 days per block average for jtoomimnet (jtoomim/p2pool) and 83 days per block average on mainnet (p2pool/p2pool).
jtoomimnet also has lower RAM usage, better fairness (efficiency will be closer to 100%), and I think slightly lower CPU usage than mainnet, and makes larger blocks with more fee revenue.
Mainnet has a larger number of unique miners, but a smaller hashrate per miner and smaller total hashrate. In theory, because I control more than 51% of the hashrate on jtoomimnet, I could perform a 51% attack on jtoomimnet and get 100% of the rewards. However, I have enough hashrate to do that on mainnet too. At least on jtoomimnet, nobody else can perform a 51% attack unless they have 7 PH/s of hashpower, whereas someone only needs 1.3 PH/s of hashpower to perform a 51% attack on mainnet.
Obviously, I'm biased, but I think that using jtoomimnet is a better choice for all Bitcoin p2pool users.
p2pool/p2pool is sorta the official one, but it's not actively maintained. forrestv, the originator of the project, is no longer actively maintaining it. I am actively maintaining my fork of p2pool, at least for the Bitcoin and Bitcoin Cash networks, but have not yet merged my code into p2pool/p2pool and do not currently have any control over that repository.
jtoomimnet has much more hashrate than mainnet does (mostly because I'm on jtoomimnet -- we alone have about 5.5 PH/s). Consequently, jtoomimnet should find blocks far more often. We're currently looking at about 15 days per block average for jtoomimnet (jtoomim/p2pool) and 83 days per block average on mainnet (p2pool/p2pool).
jtoomimnet also has lower RAM usage, better fairness (efficiency will be closer to 100%), and I think slightly lower CPU usage than mainnet, and makes larger blocks with more fee revenue.
Mainnet has a larger number of unique miners, but a smaller hashrate per miner and smaller total hashrate. In theory, because I control more than 51% of the hashrate on jtoomimnet, I could perform a 51% attack on jtoomimnet and get 100% of the rewards. However, I have enough hashrate to do that on mainnet too. At least on jtoomimnet, nobody else can perform a 51% attack unless they have 7 PH/s of hashpower, whereas someone only needs 1.3 PH/s of hashpower to perform a 51% attack on mainnet.
Obviously, I'm biased, but I think that using jtoomimnet is a better choice for all Bitcoin p2pool users.
December 18, 2017, 05:06:51 PM
Hi All, I've be mining on and off for a couple of years now and only recently become aware of p2pool. I have installed the software from https://github.com/p2pool/p2pool and after a few tweaks its up and running.
I installed the p2pool/p2pool version as I figured it was the official one. I've since found jtoomim/p2pool on Git also (it is discussed on this thread back on August 28th). They mention that the jtoomim version has a significant speed advantage and potentially larger payouts.
Could someone please tell me which is the one I should be using? Are they the same network, or have the different forks become separate peer2peer networks in their own right?
Any information regarding the differences in the versions would be appreciated.
Thank you.
James.
I installed the p2pool/p2pool version as I figured it was the official one. I've since found jtoomim/p2pool on Git also (it is discussed on this thread back on August 28th). They mention that the jtoomim version has a significant speed advantage and potentially larger payouts.
Could someone please tell me which is the one I should be using? Are they the same network, or have the different forks become separate peer2peer networks in their own right?
Any information regarding the differences in the versions would be appreciated.
Thank you.
James.
December 18, 2017, 01:41:20 PM
@jtoomim, please check the code, something is causing this error:
Oh, that's the error that is preventing p2pool from displaying recently found blocks. Cool. Nice find. Now that I know what to look for, I can reproduce it on my node. Shouldn't be too hard to fix. Edit: Fixed, and changes pushed to my github (1mb_segwit branch).
Changes:
* Use port 9348, 9349 for bitcoincash worker port, p2p port (avoid litecoin conflict)
* Make p2pool show any blocks found within the entire share chain length (i.e. 3 days for most networks)
* Fix the displaying of recently found blocks
* Cap the number of "My shares:" to be displayed by the default UI to 50 shares.
December 18, 2017, 10:18:16 AM
@jtoomim, please check the code, something is causing this error:
on python
on pypy
on python
Code:
Error in DeferredResource handler:
2017-12-18 16:52:41.353847 > Traceback (most recent call last):
2017-12-18 16:52:41.353947 > File "/home/admin/p2pool/p2pool/util/deferred_resource.py", line 24, in render
2017-12-18 16:52:41.354048 > defer.maybeDeferred(resource.Resource.render, self, request).addCallbacks(finish, finish_error)
2017-12-18 16:52:41.354149 > File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 139, in maybeDeferred
2017-12-18 16:52:41.354269 > result = f(*args, **kw)
2017-12-18 16:52:41.354370 > File "/usr/lib/python2.7/dist-packages/twisted/web/resource.py", line 250, in render
2017-12-18 16:52:41.354466 > return m(request)
2017-12-18 16:52:41.354561 > File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1237, in unwindGenerator
2017-12-18 16:52:41.354654 > return _inlineCallbacks(None, gen, Deferred())
2017-12-18 16:52:41.354749 > —-—-
2017-12-18 16:52:41.354841 > File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1099, in _inlineCallbacks
2017-12-18 16:52:41.354933 > result = g.send(result)
2017-12-18 16:52:41.355027 > File "/home/admin/p2pool/p2pool/web.py", line 198, in render_GET
2017-12-18 16:52:41.355116 > res = yield self.func(*self.args)
2017-12-18 16:52:41.355208 > File "/home/admin/p2pool/p2pool/web.py", line 233, in
2017-12-18 16:52:41.355302 > ) for s in node.tracker.get_chain(node.best_share_var.value, min(node.tracker.get_height(node.best_share_var.value), 24*60*60//node.net.SHARE_PERIOD)) if s.pow_hash <= s.header['bits'].target]))
2017-12-18 16:52:41.355419 > File "/home/admin/p2pool/p2pool/data.py", line 17, in parse_bip0034
2017-12-18 16:52:41.355513 > _, opdata = script.parse(coinbase).next()
2017-12-18 16:52:41.355605 > File "/home/admin/p2pool/p2pool/bitcoin/script.py", line 36, in parse
2017-12-18 16:52:41.355694 > while pack.size(f):
2017-12-18 16:52:41.355784 > exceptions.AttributeError: 'module' object has no attribute 'size'
on pypy
Code:
Error in DeferredResource handler:
Traceback (most recent call last):
File "/opt/sha256d/p2pool-btc-fork/p2pool/util/deferred_resource.py", line 24, in render
defer.maybeDeferred(resource.Resource.render, self, request).addCallbacks(finish, finish_error)
File "/usr/local/lib/pypy2.7/dist-packages/twisted/internet/defer.py", line 150, in maybeDeferred
result = f(*args, **kw)
File "/usr/local/lib/pypy2.7/dist-packages/twisted/web/resource.py", line 250, in render
return m(request)
File "/usr/local/lib/pypy2.7/dist-packages/twisted/internet/defer.py", line 1532, in unwindGenerator
return _inlineCallbacks(None, gen, Deferred())
------
File "/usr/local/lib/pypy2.7/dist-packages/twisted/internet/defer.py", line 1386, in _inlineCallbacks
result = g.send(result)
File "/opt/sha256d/p2pool-btc-fork/p2pool/web.py", line 198, in render_GET
res = yield self.func(*self.args)
File "/opt/sha256d/p2pool-btc-fork/p2pool/web.py", line 233, in
) for s in node.tracker.get_chain(node.best_share_var.value, min(node.tracker.get_height(node.best_share_var.value), 24*60*60//node.net.SHARE_PERIOD)) if s.pow_hash <= s.header['bits'].target]))
File "/opt/sha256d/p2pool-btc-fork/p2pool/data.py", line 17, in parse_bip0034
_, opdata = script.parse(coinbase).next()
File "/opt/sha256d/p2pool-btc-fork/p2pool/bitcoin/script.py", line 36, in parse
while pack.size(f):
exceptions.AttributeError: 'module' object has no attribute 'size'
December 18, 2017, 09:19:37 AM
BLOCK! On jtoomimnet https://blockchain.info/ru/block-index/1654337
December 15, 2017, 01:13:59 PM
In 24h occurred 13 p2pool blackouts ! 
https://imgur.com/a/1trmo
My mining machines are going crazy !
https://imgur.com/a/1trmo
My mining machines are going crazy !
It's not p2pool "blacking out" it's the p2pool.org node, the pool itself has had zero down time since inception.
While I do what I can to keep things up and running smoothly, I'm just one guy, and the expenses of operating p2pool.org far outweigh the financial reward, so please don't beat me up to badly
That being said, as suggested on the site, it's important to find at least 1, and preferably 2 backup p2pool nodes for your miners. One of the huge strengths of p2pool is it's resistance to downtime and DDoS through decentralization, that decentralization only works if miners mining on another persons node have back p2pool nodes configured...
December 14, 2017, 04:37:38 PM
In 24h occurred 13 p2pool blackouts !
https://imgur.com/a/1trmo
My mining machines are going crazy !
https://imgur.com/a/1trmo
My mining machines are going crazy !
December 14, 2017, 04:36:24 PM
also maybe you have recommendation ofr non EOM firmware for S7?
No, sorry. The only firmware that I tested for the S7 was hosted by Nicehash, and their website has been down since the hack. You'll have to search on your own.e.g. the pool can switch you to mine shares somewhere else, then back again, and you'd never know.
It's a major risk for miners to use the nicehash firmware ... as I've stated ever since they came up with that hack.
December 14, 2017, 02:18:05 PM
also maybe you have recommendation ofr non EOM firmware for S7?
No, sorry. The only firmware that I tested for the S7 was hosted by Nicehash, and their website has been down since the hack. You'll have to search on your own. December 14, 2017, 01:41:25 PM
Please add to BOOTSTRAP_ADDRS: crypto.office-on-the.net siberia.mine.nu
Done.Edit: Uh-oh. I just noticed that 9338 conflicts with the LTC p2pool p2p port of 9338 (which is nowhere near the worker port of 9327, grr!). I'm going to have to change the Bitcoin Cash ports. Sorry!
December 14, 2017, 11:57:12 AM
Please let me know if you plan on running a BCH node with high uptime so I can add you to the DNS seeds list.
Please add to BOOTSTRAP_ADDRS: Code:
crypto.office-on-the.net siberia.mine.nu
My nodes of the BCH p2pool:
http://crypto.mine.nu:9338
http://siberia.mine.nu:9338
I use different internet channels for the WORKER_PORT and P2P_PORT. Therefore, crypto.mine.nu need not be added to BOOTSTRAP_ADDRS
December 13, 2017, 10:48:06 PM
Great I currently looking to buy one S9 to replace my s7
I will look into p2pool with the S9 later
also maybe you have recommendation ofr non EOM firmware for S7?
I will look into p2pool with the S9 later
also maybe you have recommendation ofr non EOM firmware for S7?
December 13, 2017, 09:33:31 PM
S7s have a firmware bug that causes them to have about 10-20% lower hashrate on p2pool than on ordinary pools. If you mine on p2pool with a S7 with Bitmain-supplied firmware, you will experience lower revenue than you would get on a good centralized pool. (The bug was fixed in the S9.)
...
It exists in the earlier miners they made before the S7 also....
I pointed it out to them many times, MANY years ago, when I fixed the Bitmain drivers and put that in the main cgminer git - but they only did something about it finally in the S9.
What it does is throw away shares it thinks are stale, rather than pass them to the pool to decide if they are stale or not.
However, this has another rather drastic issue of throwing away blocks they think are stale, but may not be stale ...
The problem exists on all pools, but since p2pool changes work (on average) every 30 seconds, the effect is 20 times what it has on a normal pool.
December 13, 2017, 09:15:35 PM
S7s have a firmware bug that causes them to have about 10-20% lower hashrate on p2pool than on ordinary pools. If you mine on p2pool with a S7 with Bitmain-supplied firmware, you will experience lower revenue than you would get on a good centralized pool. (The bug was fixed in the S9.)
The payout frequency does not depend on your hashrate. The payout frequency depends on the amount of hashrate that p2pool has as a whole. Currently, the jtoomimnet btc p2pool has about 5.75 PH/s and is expected to find a block about once every 14 days on average. In contrast, the mainnet btc p2pool has a hashrate of 1.12 PH/s, and is expected to find a block about once every 70 days on average.
If you have low hashrate, the size of each payout that you receive will fluctuate a bit, but the frequency of payouts will be no different.
The payout frequency does not depend on your hashrate. The payout frequency depends on the amount of hashrate that p2pool has as a whole. Currently, the jtoomimnet btc p2pool has about 5.75 PH/s and is expected to find a block about once every 14 days on average. In contrast, the mainnet btc p2pool has a hashrate of 1.12 PH/s, and is expected to find a block about once every 70 days on average.
If you have low hashrate, the size of each payout that you receive will fluctuate a bit, but the frequency of payouts will be no different.
December 13, 2017, 07:32:25 PM
quick question
what are the current Hashrate required to have regular payout (bitcoin)?
I run 2 S7 (10Th total)
is it enough or should I stick to regular pool
what are the current Hashrate required to have regular payout (bitcoin)?
I run 2 S7 (10Th total)
is it enough or should I stick to regular pool
December 13, 2017, 07:05:12 AM
Cryptonomist, your node is handing out a difficulty of around 300k to your miners. The expected number of hashes needed to find a 300k diff pseudoshare is 300000*2**48/0xffff = 1.28 PH. With a hashrate of 80 GH/s, it's expected that would take about 4.47 hours per pseudoshare. Since p2pool needs to switch jobs every 30 seconds or so, that means that 99.82% of the time, p2pool would switch jobs before your miner found a (pseudo)share.
I suggest you manually set a lower pseudoshare difficulty (e.g. 256, for about 14 sec per) by putting address+256 as your stratum username. This will only affect your stats, not your revenue. You can also put address+256/32768 to set your share difficulty target to either 32768 or the network's minimum share difficulty (whichever is higher) if you want to have a better chance of mining an actual share.
Ideally, I would tweak my p2pool code so that it would adjust pseudoshare difficulty more quickly and intelligently to miners with different hashrates. However, that's pretty low on my priority list right now, since it does not affect revenue or resource requirements at all.
I suggest you manually set a lower pseudoshare difficulty (e.g. 256, for about 14 sec per) by putting address+256 as your stratum username. This will only affect your stats, not your revenue. You can also put address+256/32768 to set your share difficulty target to either 32768 or the network's minimum share difficulty (whichever is higher) if you want to have a better chance of mining an actual share.
Ideally, I would tweak my p2pool code so that it would adjust pseudoshare difficulty more quickly and intelligently to miners with different hashrates. However, that's pretty low on my priority list right now, since it does not affect revenue or resource requirements at all.
Hello,
@jtoomim: It was indeed just a difficulty issue. I've lowered the difficulty and now I get the local statistics in the p2pool output. Everything seems to work as expected. So thank you for the info.
Jump to: