Bitcoin Forum
December 09, 2016, 11:43:21 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 343 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2034039 times)
Krellan
Member
**
Offline Offline

Activity: 105


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

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
1481327001
Hero Member
*
Offline Offline

Posts: 1481327001

View Profile Personal Message (Offline)

Ignore
1481327001
Reply with quote  #2

1481327001
Report to moderator
1481327001
Hero Member
*
Offline Offline

Posts: 1481327001

View Profile Personal Message (Offline)

Ignore
1481327001
Reply with quote  #2

1481327001
Report to moderator
1481327001
Hero Member
*
Offline Offline

Posts: 1481327001

View Profile Personal Message (Offline)

Ignore
1481327001
Reply with quote  #2

1481327001
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481327001
Hero Member
*
Offline Offline

Posts: 1481327001

View Profile Personal Message (Offline)

Ignore
1481327001
Reply with quote  #2

1481327001
Report to moderator
forrestv
Hero Member
*****
Offline Offline

Activity: 510


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

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: 1526


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

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.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
freshzive
Sr. Member
****
Offline Offline

Activity: 447


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

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: 1932


https://keybase.io/bitpop


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

Sweet can't wait to bring back my jalapeno!

Reputation  |  PGP  |  DigitalOcean  |  OpenVPN 2GB Free  |  TorGuard  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
Bitmessage: BM-2cXN9j8NFT2n1FxDVQ6HQq4D4MZuuaBFyb
daemondazz
Sr. Member
****
Offline Offline

Activity: 294



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

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

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

Activity: 100



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

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

1Yxx3GinTkNHtodDpSKioBBsTYdW9zZAK
wtogami
Sr. Member
****
Offline Offline

Activity: 263



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

@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



View Profile
June 24, 2013, 03:16:39 PM
 #5849

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: 550


My PGP Key: 92C7689C


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

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.

My Bitgem Pool - PPLNS, Stratum | Gridseed Miners - $25 off your first order | BTG Explorer
Tipjars: BTC 1TipsGocnz2N5qgAm9f7JLrsMqkb3oXe2 LTC LTipsVC7XaFy9M6Zaf1aGGe8w8xVUeWFvR BTG gTipsVB9qmyYHuqMMKTuCYMHpfkUFBXKrZ | My Bitcoin Note Generator | Pyramining: 1 2 3 4 5
Krellan
Member
**
Offline Offline

Activity: 105


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

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



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

[...]
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



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

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: 345


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

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

I provide a 1000Mbit+ Torrent-Seedbox in FR and a 500Mbit Box in NL for orginal Blockchain Bootstrap.dat download. and also for Armoryclient Torrent

Tips are welcome:  15MuGdPSXU62fEFE9XbBZN3UvJMHBDVBoy
salfter
Hero Member
*****
Offline Offline

Activity: 550


My PGP Key: 92C7689C


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

[...]
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?

My Bitgem Pool - PPLNS, Stratum | Gridseed Miners - $25 off your first order | BTG Explorer
Tipjars: BTC 1TipsGocnz2N5qgAm9f7JLrsMqkb3oXe2 LTC LTipsVC7XaFy9M6Zaf1aGGe8w8xVUeWFvR BTG gTipsVB9qmyYHuqMMKTuCYMHpfkUFBXKrZ | My Bitcoin Note Generator | Pyramining: 1 2 3 4 5
freshzive
Sr. Member
****
Offline Offline

Activity: 447


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

[...]
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.

gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
June 24, 2013, 10:13:59 PM
 #5857

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.

That's exactly what I recommend in the guide. Lowering the max number of P2Pool connections to 12 (4 outgoing, 8 incoming, which I'm currently testing with no measurable change in efficiency) would be safer too with salfter limited bandwidth.

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
westkybitcoins
Legendary
*
Offline Offline

Activity: 980

Firstbits: Compromised. Thanks, Android!


View Profile
June 24, 2013, 10:38:48 PM
 #5858

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.

YES!

Guess I'll be able to throw a few Gh of reduced variability your way after all!

Bitcoin is the ultimate freedom test. It tells you who is giving lip service and who genuinely believes in it.
...
...
In the future, books that summarize the history of money will have a line that says, “and then came bitcoin.” It is the economic singularity. And we are living in it now. - Ryan Dickherber
...
...
ATTENTION BFL MINING NEWBS: Just got your Jalapenos in? Wondering how to get the most value for the least hassle? Give BitMinter a try! It's a smaller pool with a fair & low-fee payment method, lots of statistical feedback, and it's easier than EasyMiner! (Yes, we want your hashing power, but seriously, it IS the easiest pool to use! Sign up in seconds to try it!)
...
...
The idea that deflation causes hoarding (to any problematic degree) is a lie used to justify theft of value from your savings.
zvs
Legendary
*
Offline Offline

Activity: 1386



View Profile WWW
June 25, 2013, 01:20:11 AM
 #5859

When I was running my local node, my bitcoind had 1 maxconnection, listen=0, and connected to my germany server.  p2pool had 6 outgoing and default incoming.  i don't think i ever ended up with more than 10 incoming though.  i shut it down after a day since I was still getting around 1-2% DOA, but also about 10-15% orphans...  which was more than the typical 5% DOA and 3% orphans or so I got mining to my remote server.

I think if I tried it again it would be with the 1 bitcoind connection and 3 p2pool connections, one to my server in germany, one to my server in jacksonville, and one to my friend's server in quebec.  i suspect this would cut the # of orphans, maybe down to 10% or so...    this assumption for when my link is performing fine 24/7 instead of when bandwidth is oversold like it is now

I restarted server roughly 3 1/2 hrs ago, at 4:40PM local time,

here is what my link has been like since then (I started the ping about 30 minutes before restarting the server):



it is scaled to 400ms and 10% packetloss.  the top bar is jitter (scaled to 50ms, goes off the chart a lot).  note that this is a ping to my first hop, so to get the ping times to my server, add 150ms to that

in this time the server has gotten 29 shares, 0 orphans, 4 DOA.  17 of those are mine, and 2 of the DOA are mine.  12 are others, and 2 of the DOA are them (1G8D has gotten incredibly unlucky with 2 DOA out of 8 shares, even though it looks like his DOA rate is only about 3% to server)

anyway, even my 11.5% DOA or so would have an efficiency of well over 100%,  with that ^^ crap link shown above

Dacentec, best deals for US dedicated servers. They regularly restock $20-$25 Opterons with 8-16GB RAM & 2x1-2TB HDD's (ofc, usually lots of other good stuff to choose from).  I did a Serverbear benchmark of one of my $20/mo Opteron (June last year), it's here.  Have had about a half dozen different servers with Dacentec, & none have failed to sustain at least 40MB/s (burst higher). My favorite is a 12-month rent-to-own ZT Systems 2XL5520 16GB 2x2TB SATA for $40/month (got lucky with the 'off-brand', haven't seen a RTO 2xL5520 for under $50/mo since -- at least for monthly contracts).  wholesaleinternet.com has some ancient 2-core intel CPUs @ $10/mo sometimes (I got an Intel Core 2 6300 @ 1.86GHz, with a 250GB HDD with 46000 hours on it, LOL. $20 @ Dacentec is much better, if you can grab one). joesdatacenter.com (same location as Wholesale Internet) also occasionally has specials (or if you don't want to wait, it has an AMD Opteron 170 @ $16/mo).
yxxyun
Member
**
Offline Offline

Activity: 100



View Profile
June 25, 2013, 07:52:29 AM
 #5860

p2pool / Commits
Jun 24, 2013

fixed "invalid fee" message in test case
f78a4e86eb Browse code
forrestv authored 17 hours ago

reinstated share voting logic
7c28b06588 Browse code
forrestv authored 17 hours ago

the update start?

1Yxx3GinTkNHtodDpSKioBBsTYdW9zZAK
Pages: « 1 ... 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 343 ... 744 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!