BLOCK: https://blockchain.info/block/000000000000000001a1a36ada43fb03b4eb05f30cbe94a206a4a457fb4d71e5
http://crypto.office-on-the.net:9332/static/classic/share.html#000000000000000001a1a36ada43fb03b4eb05f30cbe94a206a4a457fb4d71e5
Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 72. (Read 2591919 times)
December 05, 2016, 03:07:44 AM
November 29, 2016, 10:25:02 AM
I was asked by a user on Reddit to update the P2Pool Network Visualization at http://p2pool.org/nodes/
I did this morning...
I did this morning...
| Date Scanner Run | Total Nodes | Public Nodes | Private Nodes |
| 11-29-2016 | 103 | 58 | 45 |
| 10-14-2016 | 91 | 47 | 44 |
November 28, 2016, 06:04:42 AM
Sweet! We got another block. As usual, we received next to zero transaction fees.
November 27, 2016, 10:58:29 AM
I agree.
I use an E7500 ( http://ark.intel.com/products/36503/Intel-Core2-Duo-Processor-E7500-3M-Cache-2_93-GHz-1066-MHz-FSB ) and the whole process of full node & P2Pool need 20-25% of dual processor at any time.
Look the MOY. indicator on the bottom-right of this screen :
I use an E7500 ( http://ark.intel.com/products/36503/Intel-Core2-Duo-Processor-E7500-3M-Cache-2_93-GHz-1066-MHz-FSB ) and the whole process of full node & P2Pool need 20-25% of dual processor at any time.
Look the MOY. indicator on the bottom-right of this screen :
November 23, 2016, 05:08:28 PM
p2pool needs a high power PC. Running it on RPi would be real bad.
Concur. CPU performance aside, the RPi does not have the raw I/O performance necessary to cope with reading/writing both the blockchain and the sharechain. The getwork latency would be astronomical.4 cores in the pi 3, as long as you'rE not stuffing phs down its throat it should be fine.
Per CPU core performance is everything for p2pool, especially since it's python which is mostly single threaded.
November 23, 2016, 04:57:58 PM
Happy Thanksgiving P2Pool'ers!
I've been mining with P2Pool for about a year now, made it thru the 16.0 update, but would welcome your opinions on the upgrade to Segwit. Is the current github update compatible, or will Forrest post something official on his website?
Cheers 🍻
I've been mining with P2Pool for about a year now, made it thru the 16.0 update, but would welcome your opinions on the upgrade to Segwit. Is the current github update compatible, or will Forrest post something official on his website?
Cheers 🍻
November 23, 2016, 11:37:40 AM
I'm sorry but I discovered another little bug. Please update.
November 23, 2016, 10:59:31 AM
p2pool needs a high power PC. Running it on RPi would be real bad.
Concur. CPU performance aside, the RPi does not have the raw I/O performance necessary to cope with reading/writing both the blockchain and the sharechain. The getwork latency would be astronomical.4 cores in the pi 3, as long as your not stuffing phs down its throat it should be fine. The IO issue can be solved by booting off the sd card and then mounting a usb drive as the root filesystem post-boot (or using u-boot to boot the usb drive directly, and just have an sd card for the u-boot and firmware portions).
Out of the box with an sd card, there is no way the IO would ever be fast enough. If they ever finish the compute model for pi 3, that may be an option as I believe its emmc and much faster than regular sd card (or USB) IO.
The RAM is the next issue you would run into. p2pool itself on bitcoin chews about 700mb ram (on one of my systems). Pi 3 comes with 1GB ram. You could run p2pool on one pi 3, no wallets/daemons would work in the remaining amount of ram.
I love the idea of the peer pooling, would like to see it built into mining controllers, getting away from centralized pools all together
November 23, 2016, 10:56:28 AM
p2pool needs a high power PC. Running it on RPi would be real bad.
Concur. CPU performance aside, the RPi does not have the raw I/O performance necessary to cope with reading/writing both the blockchain and the sharechain. The getwork latency would be astronomical.4 cores in the pi 3, as long as your not stuffing phs down its throat it should be fine. The IO issue can be solved by booting off the sd card and then mounting a usb drive as the root filesystem post-boot (or using u-boot to boot the usb drive directly, and just have an sd card for the u-boot and firmware portions).
Out of the box with an sd card, there is no way the IO would ever be fast enough. If they ever finish the compute model for pi 3, that may be an option as I believe its emmc and much faster than regular sd card (or USB) IO.
The RAM is the next issue you would run into. p2pool itself on bitcoin chews about 700mb ram (on one of my systems). Pi 3 comes with 1GB ram. You could run p2pool on one pi 3, no wallets/daemons would work in the remaining amount of ram.
November 23, 2016, 10:54:59 AM
November 23, 2016, 10:54:40 AM
Has anyone set up a ready to run install for the RPi for this? Looks awesome. But I'd rather not tie a PC up, running a Pi with my miners seems to me like the best way to go?
I have, but just for fun, it would be pointless for mining....
The Intel NUC might be worth checking out: https://www-ssl.intel.com/content/www/us/en/nuc/overview.html
November 23, 2016, 10:51:47 AM
I fixed a few things in the segwit implementation. Please update if you are testing it.
November 22, 2016, 09:01:54 PM
Has anyone set up a ready to run install for the RPi for this? Looks awesome. But I'd rather not tie a PC up, running a Pi with my miners seems to me like the best way to go?
p2pool needs a high power PC. Running it on RPi would be real bad. November 22, 2016, 06:52:55 PM
Has anyone set up a ready to run install for the RPi for this? Looks awesome. But I'd rather not tie a PC up, running a Pi with my miners seems to me like the best way to go?
p2pool needs a high power PC. Running it on RPi would be real bad. November 22, 2016, 06:46:28 PM
Has anyone set up a ready to run install for the RPi for this? Looks awesome. But I'd rather not tie a PC up, running a Pi with my miners seems to me like the best way to go?
November 22, 2016, 03:26:26 PM
Can someone explain how can i update the twisted package that i must include in python27 folder (win platform) ?
EXE package is only provide before 15.5 ... and all newers packages (of twisted) use a command line .py ... and i don't see how use this.
Thanks.
EXE package is only provide before 15.5 ... and all newers packages (of twisted) use a command line .py ... and i don't see how use this.
Thanks.
November 22, 2016, 05:10:29 AM
Almost
Ok, ok, I glossed over a few things to make things simpler.
In an ideal world bitcoin mining would be truly random.
In reality there are many complicating details. In addition to things mentioned above there is also for example block withholding, which happened at BTCGuild and Eligius when a miner used buggy software they had made themselves. There is also the chance of vulnerabilities, like the one that was abused at GHash, when they used the proof-of-concept stratum server example code from github which had a nasty bug (you could get paid multiple times for the same work).
November 21, 2016, 03:05:47 PM
When a repeating event is truly random the outcome depends only on luck. That's exactly how it is when mining for bitcoin blocks. Luck cannot be manipulated. Luck is unpredictable for a small number of events (blocks) and predictable for a large number of events.
Short term: Gamber's fallacy tells us that yesterday's luck will not in any way help you predict your luck today.
Long term: The law of large numbers tells us that if you mine for 10 years you will have close to average luck overall.
Short term: Gamber's fallacy tells us that yesterday's luck will not in any way help you predict your luck today.
Long term: The law of large numbers tells us that if you mine for 10 years you will have close to average luck overall.
Good luck = found a block after a small amount of work.
Bad luck = found a block after a large amount of work.
Working faster does not affect luck. It only makes the rounds go by in less time.
Bad luck = found a block after a large amount of work.
Working faster does not affect luck. It only makes the rounds go by in less time.
Almost
There's 3 other factors.
1) In general, luck shown on all pools includes smaller controllable factors that are not shown separately.
This relates to orphans and stales.
2) Any pool that has payouts rarely per diff change, rewards are affected significantly by recent diff changes.
3) On p2pool, luck is also not correctly calculated.
Expected stale shares are 20 times vs on a normal pool since the shares become stale, on average every 30 seconds, not on average every 600 seconds.
This factors into including BTC blocks found by 95% of these stale shares.
November 21, 2016, 11:08:06 AM
As the good doctor pointed out, working faster does not mean increased luck. It just means you got more accomplished in the same time frame than you did previously.
You can look at a pool's history and determine how that pool has done compared to expectations, and thusly derive a luck value. Better than expectations is good luck, worse is bad.
However, you absolutely cannot predict future luck. You can use statistical models to provide expectations, but those are not indicators of luck. As I wrote in an earlier post, just because a pool has submitted 95% of expected shares this has no bearing whatsoever on whether or not that pool will block in the next 5%. You have no better chance of blocking at 96% than you did at 1%. The pool isn't suddenly more likely to find a block just because some percentage of expected work has been completed.
Both kano and I previously pointed out what DrHaribo just linked to (the law of large numbers). Mining follows a known pattern, and hence we can derive certain expectations from that pattern. However, those expectations do not provide for predictability of luck.
You can look at a pool's history and determine how that pool has done compared to expectations, and thusly derive a luck value. Better than expectations is good luck, worse is bad.
However, you absolutely cannot predict future luck. You can use statistical models to provide expectations, but those are not indicators of luck. As I wrote in an earlier post, just because a pool has submitted 95% of expected shares this has no bearing whatsoever on whether or not that pool will block in the next 5%. You have no better chance of blocking at 96% than you did at 1%. The pool isn't suddenly more likely to find a block just because some percentage of expected work has been completed.
Both kano and I previously pointed out what DrHaribo just linked to (the law of large numbers). Mining follows a known pattern, and hence we can derive certain expectations from that pattern. However, those expectations do not provide for predictability of luck.
November 21, 2016, 10:06:58 AM
Good luck = found a block after a small amount of work.
Bad luck = found a block after a large amount of work.
Working faster does not affect luck. It only makes the rounds go by in less time.
Bad luck = found a block after a large amount of work.
Working faster does not affect luck. It only makes the rounds go by in less time.
Jump to: