Bitcoin Forum
December 09, 2016, 05:41:14 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 ... 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 [413] 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2033433 times)
h3m96
Member
**
Offline Offline

Activity: 60


View Profile
April 15, 2014, 03:43:04 AM
 #8241

Thanks!  How do I apply this kernel patch on your site, the linux 3.13?   I'm on Ubuntu 13 and I have this kernel:  3.2.0-59-generic-pae

Would that patch even work on my system?  Just curious, I just saw your site and thought I'd ask.   
1481305274
Hero Member
*
Offline Offline

Posts: 1481305274

View Profile Personal Message (Offline)

Ignore
1481305274
Reply with quote  #2

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

Activity: 56


View Profile
April 15, 2014, 04:11:15 AM
 #8242

So, I'm in the process of writing on Stratum client, and I'm getting some odd results from p2pool.

In the p2pool log, I'm seeing a ton of these:

Quote
2014-04-14 21:10:16.531268 Worker 12uCQa1rEBxQutWUkXE2AA6LnhfrAPJpgF submitted share with hash > target:
2014-04-14 21:10:16.531393     Hash:   93b4405c1ef4a1104a9a26bf30cbce5034847d7a6d5cb6babc8792326ef6b0ce
2014-04-14 21:10:16.531472     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

I've tried reading through p2pool's source, but Python isn't my thing and the code doesn't appear well structured IMHO. So, it was hard for me to tell if "target" referred to:

a) A Bitcoin block target - unlikely
b) A p2pool share - my first thought
or
c) A difficulty 1 (or x) share - my fear

My first guess was B, as my transactions with P2Pool have looked like this:

Quote
{"params":["12uCQa1rEBxQutWUkXE2AA6LnhfrAPJpgF","142929675283333299491430029355155482840","39000000","534c9506","d9d444d8"],"id":43,"method":"mining.submit"}

And P2Pool's response:

Quote
{"id":43,"error":null,"result":true}

So, it appears to be giving me a thumbs up, and my miner is happily mining away. Unfortunately if I visit http://localhost:9332 in my browser, it reports my local rate as 0. Thusly why I'm starting to fear C  Sad

Any thoughts? I hope I made sense of that all.

14Cow1HA12umeV3zdZXNmrE3TsnYaaf4Q5
h3m96
Member
**
Offline Offline

Activity: 60


View Profile
April 15, 2014, 04:22:51 AM
 #8243

When I look at my log, I don't see anything like that.  I have, however, seen that fffffffffffff thing, when my Win8 computer for some reason goes offline.  I was mining wireless on it the last 2 days with cgminer and I'm not sure if I had the right drivers installed via Zadig.    If you have 0 hashrate, maybe you're not connected? Just a thought
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
April 15, 2014, 04:56:38 AM
 #8244

...
I just want a steady income ($1736/mo) to live on!
...
Which requires ... every 2016 blocks ... to increase your hash rate by the % the difficulty goes up.

Which requires ... every 2016 blocks ... to increase your electricity usage ... and thus increase the $ amount to cover it.

Which requires ... every day you convert BTC to $ ... to increase or decrease your hash rate by the change in the BTC <-> $ exchange rate.

But in reality, the issue is that you seem to have stated, is that you are only mining BTC to cash it out.
You have no care or consideration for what BTC represents, how it can be used to the advantage of BTC and what it may be worth in the future.
So ... I don't really see the point of caring what pool you mine on ...

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
h3m96
Member
**
Offline Offline

Activity: 60


View Profile
April 15, 2014, 05:11:43 AM
 #8245

I have no care/consideration for what Bitcoin represents?  HUH?Huh?

You are a cgminer developer?   Please explain your ethical position to me.  I do not understand why you think I am abusing the Bitcoin network by simply mining on it.     
h3m96
Member
**
Offline Offline

Activity: 60


View Profile
April 15, 2014, 05:16:42 AM
 #8246

Kano:  if you know ckolivas and you developed cgminer together, I'm assuming I don't know, but why was he not saying those things to me? 

What would you do differently if you were me?  That'll help me understand better.

KyrosKrane
Sr. Member
****
Online Online

Activity: 292


View Profile WWW
April 15, 2014, 07:16:40 AM
 #8247

Then they do pseudo experiments ignoring all the things I said above and show a better payout at some random other pool for that day and they're lost for good.
While you're technically correct, I would contend that to the average user, his "pseudo experiment" is a pretty good indicator of his profitability, delta his very short term luck.  I understand the math behind this, and why this is wrong in the greater scheme of things. I know about variance, and about short term spikes (or dips!) in luck, and all the good stuff about p2pool and why it's better for a decentralized network than other alternatives.

But here's the thing - all of that is irrelevant to Joe Blow Miner. I have X GH/s of mining power.  If I point them at p2pool, or at GHash.io, or at Slush's, or at any other pool, I'm still "supporting the network", so long as I'm cautious about fraudulent pools or ones approaching 40% or more of the network.  The differentiating factors then become ease of use and profitability.

I'm pretty sure we can all agree that running your own p2pool node is a lot more complex than just typing in a URL into your miner. Using someone else's node is the same as any other pool.

So let's look at profitability. The common refrain when users complain about uneven payouts from p2pool is that it will all average out over the long term. This is not a useful answer to a user who's burning electricity for (what seems like) no gain. An answer of "wait a few months" is not going to sway the user. We need a better answer.

The thing is, while variance may average out over the long term, that only matters if difficulty remains the same.  If you think that I'm wrong, let me offer you a scenario. Hypothetically, let's say that based on current pool hashrate and network difficulty, we can expect one block per day. I'll offer you a choice. You can get three months of double the expected block success (two blocks per day initially), followed by three months of zero payouts. OR, you can get three months of zero payouts, followed by three months of double the expected success rate.  

The naive answer is that both will average out to the same thing - and that answer is correct so long as the pool maintains the same hashrate and block difficulty throughout the six months. In reality, even if we hold the pool hashrate constant over six months, your total payouts with the two options will be radically different due to the increasing difficulty rate. The double payouts followed by a dry spell will earn much more than a dry spell followed by double payouts, simply because you're getting paid when difficulty is lower - thus more blocks are found during a given time period.

And that doesn't even take into account the reduced pool hashrate that will result from a three-month dry spell.

So the short answer is the same it's always been: we need to find a way to make p2pool more attractive to users. That in turn will increase our chance of finding a block in a reasonable time, reduce the variance, and increase profitability for everyone. And yes, I realize the catch-22 inherent in what I just wrote.

Tips and donations: 1KyrosREGDkNLp1rMd9wfVwfkXYHTd6j5U  |  BTC P2Pool node: p2pool.kyros.info:9332
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
April 15, 2014, 07:34:44 AM
 #8248

The thing is, while variance may average out over the long term, that only matters if difficulty remains the same.  If you think that I'm wrong, let me offer you a scenario. Hypothetically, let's say that based on current pool hashrate and network difficulty, we can expect one block per day. I'll offer you a choice. You can get three months of double the expected block success (two blocks per day initially), followed by three months of zero payouts. OR, you can get three months of zero payouts, followed by three months of double the expected success rate.  

The naive answer is that both will average out to the same thing - and that answer is correct so long as the pool maintains the same hashrate and block difficulty throughout the six months. In reality, even if we hold the pool hashrate constant over six months, your total payouts with the two options will be radically different due to the increasing difficulty rate. The double payouts followed by a dry spell will earn much more than a dry spell followed by double payouts, simply because you're getting paid when difficulty is lower - thus more blocks are found during a given time period.

Sigh. I'm getting so tired of arguing with math fallacies. So I won't.
nreal
Full Member
***
Offline Offline

Activity: 182


View Profile
April 15, 2014, 08:25:41 AM
 #8249

Much more fun solomining Terracoin than Btc with p2pool - up to 5 blocks/day with 120GH  Shocked

Im in a hurry.

KyrosKrane
Sr. Member
****
Online Online

Activity: 292


View Profile WWW
April 15, 2014, 12:59:39 PM
 #8250

The thing is, while variance may average out over the long term, that only matters if difficulty remains the same.  If you think that I'm wrong, let me offer you a scenario. Hypothetically, let's say that based on current pool hashrate and network difficulty, we can expect one block per day. I'll offer you a choice. You can get three months of double the expected block success (two blocks per day initially), followed by three months of zero payouts. OR, you can get three months of zero payouts, followed by three months of double the expected success rate.  

The naive answer is that both will average out to the same thing - and that answer is correct so long as the pool maintains the same hashrate and block difficulty throughout the six months. In reality, even if we hold the pool hashrate constant over six months, your total payouts with the two options will be radically different due to the increasing difficulty rate. The double payouts followed by a dry spell will earn much more than a dry spell followed by double payouts, simply because you're getting paid when difficulty is lower - thus more blocks are found during a given time period.

Sigh. I'm getting so tired of arguing with math fallacies. So I won't.

My statement is that while things may average out over the long term, I don't live or mine in the long term - only in the short term. If in the short term I get better results on another pool then I'm more inclined to stay with the other pool.  It's exactly the same logic as saying that if I go to Las Vegas casino A and lose, then go to casino B, play the same games, and win, I'm more inclined to play at casino B the next day. Long term, on average, most players will lose at both casinos, which is why the casino business can be so profitable - but individuals can and do win big in the short term. It's pure gambler's fallacy, but it's the way many people think - both in terms of casinos and in terms of pools.

Here's the math basis I used to come to this conclusion I stated in the quote above. For simplicity, I made the following assumptions:

  • Difficulty adjusts every 10 days exactly, and each increase is exactly 5%.
  • All months have 30 days.
  • A starting difficulty of six billion (expressed in millions below, so 6000 = 6000MM).
  • Both overall pool hash rate and your share of that hash rate remain constant (which means your p2pool shares per period of time is also assumed to be constant).
  • The pool always find blocks at the expected rate.

Here's the part I'm not 100% on. I'm assuming that if the difficulty exactly doubles, then your chance of finding a block is exactly halved.  I suspect this isn't correct, but regardless, it's certain that as difficulty increases, the chance of finding a block decreases. So while the block probability numbers below may be slightly off, the overall trend would be the same.

Here's what the block-finding probabilities would look like (note that the table lists number of blocks found per 10-day period, not amount of BTC earned).

Period #Starting monthStarting dayStarting difficultyChance of block/dayBlocks found
1116,0001.00010.000
21116,3000.9529.524
31216,6150.9079.070
4216,9460.8648.638
52117,2930.8238.227
62217,6580.7847.835
7318,0410.7467.462
83118,4430.7117.107
93218,8650.6776.768
10419,3080.6456.446
114119,7730.6146.139
1242110,2620.5855.847
135110,7750.5575.568
1451111,3140.5305.303
1552111,8800.5055.051
166112,4740.4814.810
1761113,0970.4584.581
1862113,7520.4364.363

So, how does that look like in terms of blocks?

Option 1: double blocks for first three months, zero for next three months. Total blocks found: about 150 (with rounding).
Option 2: zero blocks for first three months, double for next three months. Total blocks found: about 96 (with rounding).

Option 0: no scenario, just straight mining for six months: Total blocks found: about 123.

Which would you pick? Given that your BTC payout per block is constant (as per our assumptions), I'd much rather have the first option.  If I buy mining gear with a useful lifespan of a few months to a year, it very much matters to me which option I pick.

Tips and donations: 1KyrosREGDkNLp1rMd9wfVwfkXYHTd6j5U  |  BTC P2Pool node: p2pool.kyros.info:9332
roy7
Sr. Member
****
Offline Offline

Activity: 434


View Profile
April 15, 2014, 01:58:14 PM
 #8251

Which would you pick?

The point you are seemingly missing or ignoring is that the odds of either great luck or terrible luck happening are the same, and you don't know which will happen ahead of time. You don't get to pick.

Yes, larger pools provide smaller variance. Everyone knows that.

Given that your BTC payout per block is constant (as per our assumptions), I'd much rather have the first option.

What the heck, I'll play along. How do I choose the pool which is about to have 3 months of finding blocks at twice the normal rate? Yes I'll choose that option too. Will you share which pool it is going to be?

RoyalMiningCo: Pools retired. Was fun!
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1008


Mine at Jonny's Pool


View Profile WWW
April 15, 2014, 02:20:31 PM
 #8252

Quick question.  What happens when the expected time to block exceeds the rolling window of shares counted for payout?

Yes, I understand that you *might* have a string of luck where you find more blocks than expected, and you also *might* have a string of luck where you might find fewer blocks than expected.  However, we are dealing with an expected time to block, because that's what the "average" should work out to be given enough time.

Currently, it's a 3 day window of shares counted for payout, correct?  If that's the case, then our average time to block (given the latest stats I'm looking at in my local p2pool node and those on p2pool.info) with ~130TH/s is ~2.3 days.  So, with that average, we're good because time to block falls within the payout window.

If the hash rate is such, or the difficulty is such, or whatever, where the expected time to block becomes 4 days, 5 days, longer... doesn't that equate to "wasted" work mining because there are days gone by without being counted?

Please educate me oh Gurus of Mining Knowledge! Smiley

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1008


Mine at Jonny's Pool


View Profile WWW
April 15, 2014, 03:47:58 PM
 #8253

On a different topic, but still very much related to educating me...

What is the recommended setup when you've got multiple miners pointing to a local p2pool node?

Let's first describe the hardware:

Box running local p2pool node and Bitcoin-Qt.  P2Pool pays out to wallet address other than the one running locally.  Since it's a local node, there are no fees (seems a bit silly to charge myself)
2 Antminer S1
1 Raspberry Pi controlling 5 Antminer U2 USB sticks

Options:

1) Have all miners payout to a single address by starting each with -u MYPAYOUTADDRESS, where MYPAYOUTADDRESS is the same as the address the p2pool node pays.
2) Have all miners payout to a single address as in option 1; however, that address is not the same as the p2poool node payout address
3) Have each miner payout to a different address, independent of the node's payout address.
4) Something I haven't thought of?

If my understanding is correct, the only time the p2pool node would payout to it's default address is if I'm collecting fees.  If I want to see payouts on the "Payout if a block were found now", I would have to set my miners to pay to the node's payout address as well.

If I go with option 3, does the p2pool node software dole out appropriate difficulty to each miner?  Here, the 2 S1s at 200GH/s each should get higher difficulty than the 5 U2 sticks with a total of 8GH/s, right?  I realize that it really doesn't make much difference in the long run since the difficulty is purely for "lying" to the miner and getting better approximations of hash rate by allowing the miner to solve less difficult shares, right?

Again, thanks for the inputs!

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
KyrosKrane
Sr. Member
****
Online Online

Activity: 292


View Profile WWW
April 15, 2014, 04:22:27 PM
 #8254

Which would you pick?

The point you are seemingly missing or ignoring is that the odds of either great luck or terrible luck happening are the same, and you don't know which will happen ahead of time. You don't get to pick.

Yes, larger pools provide smaller variance. Everyone knows that.

Given that your BTC payout per block is constant (as per our assumptions), I'd much rather have the first option.

What the heck, I'll play along. How do I choose the pool which is about to have 3 months of finding blocks at twice the normal rate? Yes I'll choose that option too. Will you share which pool it is going to be?
I'm not missing it at all; in fact, that's the point I was trying to make. I even highlighted it with my example of the gambler's fallacy! What I was saying is that while you can't predict when a good streak will come, you have to judge for yourself whether you can ride out the cold streaks. For a machine with a useful life of months, an extended cold streak like what we're seeing now means a significant loss. Many users will decide they'd rather have smaller but more consistent payouts from a traditional pool, rather than larger but inconsistent payouts from p2pool. If we want p2pool to thrive, we have to find a way to counter that.

Tips and donations: 1KyrosREGDkNLp1rMd9wfVwfkXYHTd6j5U  |  BTC P2Pool node: p2pool.kyros.info:9332
KyrosKrane
Sr. Member
****
Online Online

Activity: 292


View Profile WWW
April 15, 2014, 04:57:51 PM
 #8255

1) Have all miners payout to a single address by starting each with -u MYPAYOUTADDRESS, where MYPAYOUTADDRESS is the same as the address the p2pool node pays.
2) Have all miners payout to a single address as in option 1; however, that address is not the same as the p2poool node payout address
3) Have each miner payout to a different address, independent of the node's payout address.
4) Something I haven't thought of?

If my understanding is correct, the only time the p2pool node would payout to it's default address is if I'm collecting fees.  If I want to see payouts on the "Payout if a block were found now", I would have to set my miners to pay to the node's payout address as well.
I actually had to make a very similar decision recently. What I learned is that if you don't set an address (and instead use a generic label like "Antminer") for each miner, then all the shares earned will default to the payout address you've set for your pool.  That way, you can track each device individually in your local p2pool node's stats, but still get the benefit of a combined payout.  If you use the -a option on the command line, you can specify any payout address, even one that isn't part of the local bitcoin node's wallet.

If you prefer, you can set a specific payout address for each device, and track the earnings that way, but with your RPi, you won't get shares very often.  That will lead to long stretches of no shares.  Also your payouts will be more fragmented, which means when it comes time to spend them, you'll have to pay slightly higher transaction fees.

As to your options, you could do #1, but I personally went with the "labels" option I mentioned. #2 is more or less identical to #1; it's just up to you where you define the address (on each miner, or on p2pool's command line). #3 is also permissible, but has the downsides I mentioned.

Tips and donations: 1KyrosREGDkNLp1rMd9wfVwfkXYHTd6j5U  |  BTC P2Pool node: p2pool.kyros.info:9332
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1008


Mine at Jonny's Pool


View Profile WWW
April 15, 2014, 05:20:39 PM
 #8256

1) Have all miners payout to a single address by starting each with -u MYPAYOUTADDRESS, where MYPAYOUTADDRESS is the same as the address the p2pool node pays.
2) Have all miners payout to a single address as in option 1; however, that address is not the same as the p2poool node payout address
3) Have each miner payout to a different address, independent of the node's payout address.
4) Something I haven't thought of?

If my understanding is correct, the only time the p2pool node would payout to it's default address is if I'm collecting fees.  If I want to see payouts on the "Payout if a block were found now", I would have to set my miners to pay to the node's payout address as well.
I actually had to make a very similar decision recently. What I learned is that if you don't set an address (and instead use a generic label like "Antminer") for each miner, then all the shares earned will default to the payout address you've set for your pool.  That way, you can track each device individually in your local p2pool node's stats, but still get the benefit of a combined payout.  If you use the -a option on the command line, you can specify any payout address, even one that isn't part of the local bitcoin node's wallet.

If you prefer, you can set a specific payout address for each device, and track the earnings that way, but with your RPi, you won't get shares very often.  That will lead to long stretches of no shares.  Also your payouts will be more fragmented, which means when it comes time to spend them, you'll have to pay slightly higher transaction fees.

As to your options, you could do #1, but I personally went with the "labels" option I mentioned. #2 is more or less identical to #1; it's just up to you where you define the address (on each miner, or on p2pool's command line). #3 is also permissible, but has the downsides I mentioned.

Great point.  That would be option 4 - one I didn't think of Wink  Just start the miners up with usernames like "S1_1", "S1_2", "rPi" and they will default payout to the node's wallet.  I'll restart them that way so I can track each miner's performance, but get the benefits of combined payouts (and like you stated, smaller fees because the payouts would be larger).

Thanks for the tip!

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
roy7
Sr. Member
****
Offline Offline

Activity: 434


View Profile
April 15, 2014, 05:56:48 PM
 #8257

If my understanding is correct, the only time the p2pool node would payout to it's default address is if I'm collecting fees.  If I want to see payouts on the "Payout if a block were found now", I would have to set my miners to pay to the node's payout address as well.

Yes the pool's address (you can specify it with -a) is only for fees or if a miner connects with an invalid payment address.

I wouldn't worry about the "payout if a block were found now" overly much and instead recommend you install the p2pool-node-status interface, or one of the other ones that are nice. Smiley

If I go with option 3, does the p2pool node software dole out appropriate difficulty to each miner?  Here, the 2 S1s at 200GH/s each should get higher difficulty than the 5 U2 sticks with a total of 8GH/s, right?  I realize that it really doesn't make much difference in the long run since the difficulty is purely for "lying" to the miner and getting better approximations of hash rate by allowing the miner to solve less difficult shares, right?

By default the vardiff for share difficulty and pseudoshare difficulty per miner will be set based on the total local node speed. If you want to be sure you get plenty of pseudo shares from each of your devices with varying speeds for graphing purposes, you probably need to add the auto-worker-diff patch so you can have the vardiff provide pseudo share difficulties by miner connection or by payment address. There's also a patch I made called vardiffbyaddress which sets actual share difficulty targets per payment address, but that's only useful to a public node with numerous people mining. For your own node, the auto-worker-diff is all you'd need to better control the pseudo share targets to each of your devices.

If all you cared about was total pool hash rate graphs, by default the node will aim for about 1 pseudo share per second. But your S1s will do so many that your USB miners get pushed down to doing far less than that, making their graphs very spotty (if you are graphing each miner separately).

RoyalMiningCo: Pools retired. Was fun!
roy7
Sr. Member
****
Offline Offline

Activity: 434


View Profile
April 15, 2014, 06:01:01 PM
 #8258

Great point.  That would be option 4 - one I didn't think of Wink  Just start the miners up with usernames like "S1_1", "S1_2", "rPi" and they will default payout to the node's wallet.  I'll restart them that way so I can track each miner's performance, but get the benefits of combined payouts (and like you stated, smaller fees because the payouts would be larger).

Thanks for the tip!

Yeah that's probably the best way to go. This way all pay is on same address (less dust issues) but you can still graph your miners separately. However you do have the issue that the miners will have a single pseudo share target of 1/sec. You can upgrade the vardiff algorithm with the auto-worker-diff patch, or set the pseudo target you want each miner to have manually using +DIFF after their name.

RoyalMiningCo: Pools retired. Was fun!
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
April 15, 2014, 06:34:19 PM
 #8259

If the hash rate is such, or the difficulty is such, or whatever, where the expected time to block becomes 4 days, 5 days, longer... doesn't that equate to "wasted" work mining because there are days gone by without being counted?

No. Think of mining like flipping 40 coins and trying to get all heads. Getting a share when the pool doesn't get a block is like flipping 40 coins and getting say 38 or 39 heads. Close but no cigar. This is not wasted work, just a near miss. It feels like it because your brain plays tricks on you and you feel that because you almost accomplished the required task, you "should" be rewarded. But no, it doesn't work that way.

irrational
Jr. Member
*
Offline Offline

Activity: 56


View Profile
April 16, 2014, 01:14:19 AM
 #8260

In the p2pool log, I'm seeing a ton of these:

Quote
2014-04-14 21:10:16.531268 Worker 12uCQa1rEBxQutWUkXE2AA6LnhfrAPJpgF submitted share with hash > target:
2014-04-14 21:10:16.531393     Hash:   93b4405c1ef4a1104a9a26bf30cbce5034847d7a6d5cb6babc8792326ef6b0ce
2014-04-14 21:10:16.531472     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

I've tried reading through p2pool's source, but Python isn't my thing and the code doesn't appear well structured IMHO. So, it was hard for me to tell if "target" referred to:

a) A Bitcoin block target - unlikely
b) A p2pool share - my first thought
or
c) A difficulty 1 (or x) share - my fear

Surely somebody knows which it's referring to?

14Cow1HA12umeV3zdZXNmrE3TsnYaaf4Q5
Pages: « 1 ... 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 [413] 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 ... 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!