Bitcoin Forum
March 19, 2024, 08:22:58 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 [292] 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 ... 814 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2591571 times)
GrapeApe
Sr. Member
****
Offline Offline

Activity: 476
Merit: 250



View Profile
June 23, 2013, 10:26:01 PM
Last edit: June 24, 2013, 12:26:26 AM by GrapeApe
 #5821

OK, so I've been looking at my orphans for the last 10 days or so.... about 33% of them occur after a block solve.

i guess i should also mention that 50% of them are orphaned by

1CTgYxMTY5j6SLytKeMsBWAXuUc6yNKcAe

and i know he isnt using an asic, so why so slow?

How do you know it was that address, and is it wrong to assume that you have his ip address? If so ban him don't send any more work his way. Not that it matters but that address has a huge balance by the way...

nah, he's a major contributor to p2pool.  i think he's been mining it for years.   i'm just whining and wish he had a faster setup.  =p

I can confirm that this address is mining since ages. The user behind may have changed his/her rigs since then but when the P2Pool mining started it was either GPU or FPGA based, seems the hashrate is fairly constant too: it always was around 50-60GH/s (computed from the payouts).

If he is reading this thread, he should definitely upgrade his setup: he's probably able to shave quite a few more bitcoins by lowering his bitcoind latency (which is probably the reason why his setup is orphaning zvs shares on occasion instead of building on top of them). This should help us too: he may have mined orphan blocks (not sure of the probabilities though).

I didn’t mean to sound so cold about it....

On another note I’m happy to hear that some are mining their jals on here.  I am waiting on mine and want to stay here. I read that someone has raised the difficulty to 6000 on it.  As salfter asked earlier won't this risk  throwing out good work or is the point to just get the efficiency up regardless of what it throws out. Which brings up another question if jals are throwing out easier work and the efficiency is acceptable, isn't that good for lower hash rate miners?
1710836578
Hero Member
*
Offline Offline

Posts: 1710836578

View Profile Personal Message (Offline)

Ignore
1710836578
Reply with quote  #2

1710836578
Report to moderator
1710836578
Hero Member
*
Offline Offline

Posts: 1710836578

View Profile Personal Message (Offline)

Ignore
1710836578
Reply with quote  #2

1710836578
Report to moderator
No Gods or Kings. Only Bitcoin
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710836578
Hero Member
*
Offline Offline

Posts: 1710836578

View Profile Personal Message (Offline)

Ignore
1710836578
Reply with quote  #2

1710836578
Report to moderator
forrestv (OP)
Hero Member
*****
Offline Offline

Activity: 516
Merit: 643


View Profile
June 24, 2013, 01:17:40 AM
 #5822

In the next couple days, I'm going to release a hard-forking change to P2Pool that will make the following changes:

Global changes
* Increase last transaction extranonce length from 4 bytes to 8 bytes, so full 4-byte Stratum workunits can be efficiently generated (which will prevent the need for the avalon branch)
* Delay payout calculation 1 share so that payouts can be calculated ahead of time, reducing latency between a new share being received and work being distributed to miners
* Option to set a "dust target," which increases your share difficulty so that you don't get payouts below that target

Bitcoin network
* Increase SHARE_PERIOD (average time between shares) from 10 seconds to 30 seconds, in order to make it more fair for high-latency miners (read: ASICs)

Litecoin network
* Decrease SPREAD (number of blocks a share's payout is spread over, on average) from 12 blocks to 3 blocks, significantly decreasing the dust payouts generated for miners who get a share less often than every 3 blocks the pool finds

Warnings will be spammed to miners (UPGRADE REQUIRED) once 50% of each P2Pool's mining power has upgraded and the changes will take effect 12 hours after 95% of the mining power has been upgraded, as usual.

If anyone has any recommendations for additional changes or comments on these, please respond.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
daemondazz
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250



View Profile
June 24, 2013, 01:42:29 AM
 #5823

Bitcoin network
* Increase SHARE_PERIOD (average time between shares) from 10 seconds to 30 seconds, in order to make it more fair for high-latency miners (read: ASICs)

Will this increase the sharechain from 1 day to 3 days?

Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
forrestv (OP)
Hero Member
*****
Offline Offline

Activity: 516
Merit: 643


View Profile
June 24, 2013, 01:53:27 AM
 #5824

Bitcoin network
* Increase SHARE_PERIOD (average time between shares) from 10 seconds to 30 seconds, in order to make it more fair for high-latency miners (read: ASICs)

Will this increase the sharechain from 1 day to 3 days?

I was planning on keeping it the same for now. The only disadvantage a long sharechain has is making P2Pool take a long time to start up and download shares, along with increased memory usage.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
Krellan
Member
**
Offline Offline

Activity: 106
Merit: 10


View Profile
June 24, 2013, 02:12:12 AM
 #5825

Bitcoin network
* Increase SHARE_PERIOD (average time between shares) from 10 seconds to 30 seconds, in order to make it more fair for high-latency miners (read: ASICs)

Will this increase the sharechain from 1 day to 3 days?

I was planning on keeping it the same for now. The only disadvantage a long sharechain has is making P2Pool take a long time to start up and download shares, along with increased memory usage.

I'm rather happy with all the changes, except this one.  Going from 10 seconds/share to 30 seconds/share, but without also increasing the sharechain length, means that there will be much fewer paid shares per found block.

24 hours at 10 seconds each = 8640 shares.  At 30 seconds each = only 2880 shares.

I have a rather slow node (only one Eurupter, it does 320 MH/s), so I have to be pretty lucky to squeeze in my shares during the 24 hour window of opportunity, otherwise they expire unpaid.  When the block was found recently, my node was pretty far down on the list.  Under these new rules, I might not be on the list at all.

That takes away one of the big reasons to do shared pool mining: consistent and steady payouts over time, instead of having to play the lottery for a rare big payout.

Please reconsider?

Is there a problem now with the payout being spread too thin?  I didn't think there was.  If that is a problem, then there would be reason to reduce the shares per block.  Otherwise, since you're already doing a hard fork, now would also be a great time to also stretch the sharechain to 3 days, instead of 1 day, which would keep the number of paid shares per block the same.

Josh

1JUZr4TZ5zuB4WdEv4mrhZMaM7yttpJvLG Smiley
forrestv (OP)
Hero Member
*****
Offline Offline

Activity: 516
Merit: 643


View Profile
June 24, 2013, 02:14:40 AM
 #5826

I'm rather happy with all the changes, except this one.  Going from 10 seconds/share to 30 seconds/share, but without also increasing the sharechain length, means that there will be much fewer paid shares per found block.

24 hours at 10 seconds each = 8640 shares.  At 30 seconds each = only 2880 shares.

I have a rather slow node (only one Eurupter, it does 320 MH/s), so I have to be pretty lucky to squeeze in my shares during the 24 hour window of opportunity, otherwise they expire unpaid.  When the block was found recently, my node was pretty far down on the list.  Under these new rules, I might not be on the list at all.

That takes away one of the big reasons to do shared pool mining: consistent and steady payouts over time, instead of having to play the lottery for a rare big payout.

Please reconsider?

Is there a problem now with the payout being spread too thin?  I didn't think there was.  If that is a problem, then there would be reason to reduce the shares per block.  Otherwise, since you're already doing a hard fork, now would also be a great time to also stretch the sharechain to 3 days, instead of 1 day, which would keep the number of paid shares per block the same.

Sorry about the confusion and your time spent writing a long post - the sharechain length is set in terms of number of shares, not time, and I meant that the number of shares (8640) will remain the same, so you have nothing to worry about! The new sharechain will indeed be 3 days long.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
notme
Legendary
*
Offline Offline

Activity: 1904
Merit: 1002


View Profile
June 24, 2013, 02:38:05 AM
 #5827

Bitcoin network
* Increase SHARE_PERIOD (average time between shares) from 10 seconds to 30 seconds, in order to make it more fair for high-latency miners (read: ASICs)

Will this increase the sharechain from 1 day to 3 days?

I was planning on keeping it the same for now. The only disadvantage a long sharechain has is making P2Pool take a long time to start up and download shares, along with increased memory usage.

I'm rather happy with all the changes, except this one.  Going from 10 seconds/share to 30 seconds/share, but without also increasing the sharechain length, means that there will be much fewer paid shares per found block.

24 hours at 10 seconds each = 8640 shares.  At 30 seconds each = only 2880 shares.

I have a rather slow node (only one Eurupter, it does 320 MH/s), so I have to be pretty lucky to squeeze in my shares during the 24 hour window of opportunity, otherwise they expire unpaid.  When the block was found recently, my node was pretty far down on the list.  Under these new rules, I might not be on the list at all.

That takes away one of the big reasons to do shared pool mining: consistent and steady payouts over time, instead of having to play the lottery for a rare big payout.

Please reconsider?

Is there a problem now with the payout being spread too thin?  I didn't think there was.  If that is a problem, then there would be reason to reduce the shares per block.  Otherwise, since you're already doing a hard fork, now would also be a great time to also stretch the sharechain to 3 days, instead of 1 day, which would keep the number of paid shares per block the same.

Josh


If you want to stay with p2pool, but desire lower variance perhaps you can consider one of the p2pool pooling options available in this thread: https://bitcointalk.org/index.php?topic=234841.0

The first option is a ruby based proxy which logs all pseudoshares and then redirects all shares to the same p2pool address.  As a miner all you have to do is change your pool address.  The other option is a python patch for p2pool that logs all pseudoshares.  You can then run the node with a 100% fee and split up the payments based on the logs.  Source code is available for both, but I'm not sure if there is a public pool for the patch option yet.  I run a server with the ruby proxy solution, but I welcome you to start your own pool with either codebase.

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
freshzive
Sr. Member
****
Offline Offline

Activity: 447
Merit: 250


View Profile
June 24, 2013, 03:19:56 AM
 #5828

What determines your # of incoming connections? Just uptime? It seems like the longer I leave my node up, the more I get?

bitpop
Legendary
*
Offline Offline

Activity: 2912
Merit: 1060



View Profile WWW
June 24, 2013, 03:22:43 AM
 #5829

Sweet can't wait to bring back my jalapeno!

daemondazz
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250



View Profile
June 24, 2013, 05:34:23 AM
 #5830

@forrestv - have you considered adding a string to the coinbase to identify p2pool?

Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
yxxyun
Member
**
Offline Offline

Activity: 99
Merit: 10



View Profile
June 24, 2013, 06:06:30 AM
 #5831

@forrestv - have you considered adding a string to the coinbase to identify p2pool?
+1
wtogami
Sr. Member
****
Offline Offline

Activity: 263
Merit: 250



View Profile
June 24, 2013, 07:35:14 AM
 #5832

@forrestv - have you considered adding a string to the coinbase to identify p2pool?

There is no need.  It can be identified automatically by forrestv's payout txo.

If you appreciate my work please consider making a small donation.
BTC:  1LkYiL3RaouKXTUhGcE84XLece31JjnLc3      LTC:  LYtrtYZsVSn5ymhPepcJMo4HnBeeXXVKW9
GPG: AEC1884398647C47413C1C3FB1179EB7347DC10D
wtogami
Sr. Member
****
Offline Offline

Activity: 263
Merit: 250



View Profile
June 24, 2013, 03:16:39 PM
Last edit: June 24, 2013, 03:58:53 PM by wtogami
 #5833

Litecoin-0.6.9.1 now recommended for all LTC p2pool nodes.
You MUST follow directions and connect to a supernode

Important bug fixes, August 15th hardfork deadline, plus reduced fee!

https://forum.litecoin.net/index.php/topic,4615.0.html

The release for the general public on Litecoin.org is coming real soon.  You can help smooth the transition of the network to the lower fee by upgrading the entire p2pool LTC network to be capable of relaying newfee transactions.  Follow the directions and add two or three supernodes to your litecoin.conf.

If you appreciate my work please consider making a small donation.
BTC:  1LkYiL3RaouKXTUhGcE84XLece31JjnLc3      LTC:  LYtrtYZsVSn5ymhPepcJMo4HnBeeXXVKW9
GPG: AEC1884398647C47413C1C3FB1179EB7347DC10D
salfter
Hero Member
*****
Offline Offline

Activity: 651
Merit: 501


My PGP Key: 92C7689C


View Profile WWW
June 24, 2013, 03:56:29 PM
 #5834

I'm seeing only 84% efficiency with mine. What settings are you using? My miner name has +256 appended to it. A poster in the BFL forums is using /6000 and is getting results more like yours than mine. Given that share difficulty is only 1080 as I write this, though, wouldn't setting difficulty too high risk throwing out valid shares?

What would be a good input to have to guess how good these ASICs are would be people comparing what their efficiency was with low-latency mining devices (GPUs/Icarus/Cairnsmore1/Ztex/...) and what is their efficiency with their BFL ASIC without any p2pool node reconfiguration.
If they have a mixed setup, knowing the total hashrate of the low-latency devices and the total hashrate of the BFL ASICs can do too.

Warning: don't use different payout addresses on your node: it currently adds latency in the P2Pool process and would lower efficiency.

Currently they don't seem horrible: 84% efficiency is the worst I'm aware of. It's bad but not far from what is good enough to make it almost as good as most pools (I consider the 90-95% range to be where P2Pool starts to be the best solution for mining).
Try to tune your setup according to my guide to see if you can reach a better efficiency (see my sig).

I've done that...average bitcoind latency seems to be hanging around 300 ms since the upgrade to 0.8.2.  With 0.8.1, I was seeing multiple-second latencies.  Over the weekend, efficiency went up slightly to around 86%.  I've switched from +256 to /6000 to see if that makes any difference; it's only been running a few minutes, but the 204 rejected shares to 642 accepted shares so far isn't much different than what I was already getting. I double-checked my router QoS settings; p2pool traffic is running at a high priority.

One thing: my P2Pool node is at home, but my Jalapeños are at work. Ping times tend to run 30-50 ms; both LANs are connected through Cox. Would even this little bit of added latency be enough to throw my efficiency into the basement?

By "don't use different payout addresses," are you suggesting that I should use an address from the bitcoind wallet, or only that I shouldn't use the "mine-to-the-address-in-the-username" feature (which I don't use)?

In any case, it looks like I should see some benefit from the upcoming changes to P2Pool. I'd like to see the concept succeed, so I think I can stick with it at least a little while longer.

Tipjars: BTC 1TipsGocnz2N5qgAm9f7JLrsMqkb3oXe2 LTC LTipsVC7XaFy9M6Zaf1aGGe8w8xVUeWFvR | My Bitcoin Note Generator | Pool Auto-Switchers: zpool MiningPoolHub NiceHash
Bitgem Resources: Pool Explorer Paper Wallet
Krellan
Member
**
Offline Offline

Activity: 106
Merit: 10


View Profile
June 24, 2013, 04:06:01 PM
 #5835

Sorry about the confusion and your time spent writing a long post - the sharechain length is set in terms of number of shares, not time, and I meant that the number of shares (8640) will remain the same, so you have nothing to worry about! The new sharechain will indeed be 3 days long.

NICE!!

Thanks!!

Smiley  Grin

Josh

1JUZr4TZ5zuB4WdEv4mrhZMaM7yttpJvLG Smiley
gyverlb
Hero Member
*****
Offline Offline

Activity: 896
Merit: 1000



View Profile
June 24, 2013, 06:36:56 PM
 #5836

[...]
One thing: my P2Pool node is at home, but my Jalapeños are at work. Ping times tend to run 30-50 ms; both LANs are connected through Cox. Would even this little bit of added latency be enough to throw my efficiency into the basement?

According to zvs results in a similar setup, no: he achieved high efficiency with much higher ping times (and one other user reported high efficiency at around 30ms too).
Can you find out if your network connection has some headroom left? The most reliable way would be to monitor your P2Pool host public network interface with a low monitor interval to detect spikes under the 10s interval, then check what your network usage is by graphing the data: spikes up to your downlink or uplink max capacity should be the exception.

By "don't use different payout addresses," are you suggesting that I should use an address from the bitcoind wallet, or only that I shouldn't use the "mine-to-the-address-in-the-username" feature (which I don't use)?

If you have only one miner you are using a single payout address whichever way you configured it. If you have several miners, either use names to connect to the P2Pool node to use its configured (or automatically generated, but not advisable) payout address (my preferred configuration which makes nice graphs for each miner) or use the same address for all miners (if you don't want multiple graphs).

In any case, it looks like I should see some benefit from the upcoming changes to P2Pool. I'd like to see the concept succeed, so I think I can stick with it at least a little while longer.

These are world changing indeed. I've always felt that 10s interval was a bit low (and argued about it with forrestv on IRC in the early days of P2Pool IIRC) but this was a compromise (new miners will have to wait a bit longer to get their full payouts with the new 30s interval). The dust removing and payout computation delay are very nice too.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
gyverlb
Hero Member
*****
Offline Offline

Activity: 896
Merit: 1000



View Profile
June 24, 2013, 06:42:18 PM
 #5837

These are world changing indeed. I've always felt that 10s interval was a bit low (and argued about it with forrestv on IRC in the early days of P2Pool IIRC) but this was a compromise (new miners will have to wait a bit longer to get their full payouts with the new 30s interval). The dust removing and payout computation delay are very nice too.

In fact I believe that most node efficiencies will converge to 100% with these changes which is really good (although it will probably reduce my income as I'm in the 110-115% range most of the time...).

As tuning P2Pool/bitcoind won't bring much benefit this will help with people still insisting on running nodes generating low block sizes and make our income even slightly higher. This could even deprecate much of what I spent quite some time writing in my guide :-(

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
Subo1977
Sr. Member
****
Offline Offline

Activity: 344
Merit: 250


Flixxo - Watch, Share, Earn!


View Profile
June 24, 2013, 08:52:31 PM
 #5838

Hi has anyone Problems with Bitcoind connectet to other Bitcoind nodes over Tor and connectet to local p2pool?

X       ▄▄█████████▄▄
    ▄██▀▀         ▀▀██▄
  ▄██▀              ▀██▄
 ▄██     ██▄▄          ██▄
▄██      █████▄▄        ██▄
██       ████████▄▄      ██
██       ███████████▄    ██
██       ██████████▀     ██
▀██      ███████▀       ██▀
 ▀██     ████▀         ██▀
  ▀██▄   █▀          ▄██▀
    ▀██▄▄         ▄▄██▀
       ▀▀█████████▀▀
.flixxo    X▄████████████████████▄
██████████████████████
██████████████████████
████████████▀▀███████
█████▀████░░░░░░▄████
█████░░░░░░░░░░▄█████
█████▄░░░░░░░░░░██████
██████░░░░░░░░░███████
███████░░░░░░▄████████
████▄▄░░░░▄▄██████████
██████████████████████
██████████████████████
▀████████████████████▀
▄████████████████████▄
██████████████████████
█████████▀█▀██████████
██████▀▀▀▀▀████████
██████▄▄░░▄▄▄░░███████
████████░░███░░███████
████████░░░░░░▀███████
████████░░███▄░░██████
██████▀▀░░▀▀▀░░░██████
██████▄▄▄▄▄▄███████
█████████▄█▄██████████
██████████████████████
▀████████████████████▀
X[[]]X
salfter
Hero Member
*****
Offline Offline

Activity: 651
Merit: 501


My PGP Key: 92C7689C


View Profile WWW
June 24, 2013, 09:21:58 PM
 #5839

[...]
One thing: my P2Pool node is at home, but my Jalapeños are at work. Ping times tend to run 30-50 ms; both LANs are connected through Cox. Would even this little bit of added latency be enough to throw my efficiency into the basement?

According to zvs results in a similar setup, no: he achieved high efficiency with much higher ping times (and one other user reported high efficiency at around 30ms too).
Can you find out if your network connection has some headroom left? The most reliable way would be to monitor your P2Pool host public network interface with a low monitor interval to detect spikes under the 10s interval, then check what your network usage is by graphing the data: spikes up to your downlink or uplink max capacity should be the exception.

nload says my P2Pool node (running just bitcoind, P2Pool, and cgminer & CryptoSwitcher (the latter two for GPU-mining altcoins)) is averaging 1.04 Mbps upstream, which is about two-thirds of what's available to me IIRC.  This is with P2Pool reporting 7 outbound peers and 12 inbound peers.  Should it be using this much bandwidth?

Tipjars: BTC 1TipsGocnz2N5qgAm9f7JLrsMqkb3oXe2 LTC LTipsVC7XaFy9M6Zaf1aGGe8w8xVUeWFvR | My Bitcoin Note Generator | Pool Auto-Switchers: zpool MiningPoolHub NiceHash
Bitgem Resources: Pool Explorer Paper Wallet
freshzive
Sr. Member
****
Offline Offline

Activity: 447
Merit: 250


View Profile
June 24, 2013, 09:42:16 PM
 #5840

[...]
One thing: my P2Pool node is at home, but my Jalapeños are at work. Ping times tend to run 30-50 ms; both LANs are connected through Cox. Would even this little bit of added latency be enough to throw my efficiency into the basement?

According to zvs results in a similar setup, no: he achieved high efficiency with much higher ping times (and one other user reported high efficiency at around 30ms too).
Can you find out if your network connection has some headroom left? The most reliable way would be to monitor your P2Pool host public network interface with a low monitor interval to detect spikes under the 10s interval, then check what your network usage is by graphing the data: spikes up to your downlink or uplink max capacity should be the exception.

nload says my P2Pool node (running just bitcoind, P2Pool, and cgminer & CryptoSwitcher (the latter two for GPU-mining altcoins)) is averaging 1.04 Mbps upstream, which is about two-thirds of what's available to me IIRC.  This is with P2Pool reporting 7 outbound peers and 12 inbound peers.  Should it be using this much bandwidth?

It is most likely Bitcoind not p2pool. My bitcoind was using nearly all of my 2mbit upstream, so I lowered the maxconnections variable from 125 (default) to 20 and it dropped that down to around 200kbps. I haven't noticed any increase in orphans (or bitcoind latency) with the change.

Pages: « 1 ... 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 [292] 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 ... 814 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!