Bitcoin Forum
December 05, 2016, 12:48:40 AM *
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 ... 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 [498] 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2029671 times)
kgb2mining
Member
**
Offline Offline

Activity: 112


View Profile
August 08, 2014, 12:47:19 PM
 #9941

This is running 16 s-1's
Version: unknown 7032706f6f6c2d6e2d6d6173746572

Pool rate: 1.67PH/s (13% DOA+orphan) Share difficulty: 6520000

Node uptime: 2.8 days Peers: 6 out, 0 in

Local rate: 3.99TH/s (6.6% DOA) Expected time to share: 2.0 hours

Shares: 44 total (4 orphaned, 0 dead) Efficiency: 104.5%

Payout if a block were found NOW: 0.0698682 BTC to xxxxxxxxxxxxxxxxxxxxxxxxxxx. Expected after mining for 24 hours: 0.0691 BTC per block.

Current block value: 25.084773600000002 BTC Expected time to block: 14.1 hours
_______________________________________________________________________________ __________________________

Any opinions?Huh
I think I am finding a good amount of shares, its just that the blocks are not paying enough.
If we had a few more blocks it would be better?Huh?
But we really are not.

1 month ago my payouts were 0.14xxxxxxx
I'd say you're right on target, although your DOA rate seems a little high:

Version: 13.4-40-gce9e5a2
Pool rate: 1.67PH/s (13% DOA+orphan) Share difficulty: 6320000
Node uptime: 1.5 days Peers: 6 out, 0 in

Local rate: 8.65TH/s (2.7% DOA) Expected time to share: 52.3 minutes

Shares: 50 total (4 orphaned, 2 dead) Efficiency: 101.2%

Payout if a block were found NOW: 0 BTC to . Expected after mining for 24 hours: 0.130 BTC per block.

Current block value: 25.15205561 BTC Expected time to block: 14.1 hours

I'm a little over double your hashrate, and double your payout, it adds up.

And yes, a month ago my payout rate was higher (.18/day on BTCGuild), due to 2 things - first the pool rate was under 1PH/s with 100 less miners, and we've had at least 2 diff increases since then (last one happened overnight).  Unfortunately the pool rate has grown enough to down our earnings due to more total hashrate but we've been unlucky in not seeing enough of an increase in blocks yet to offset it.  However I believe the numbers are properly in-line for what has happened.

1480898920
Hero Member
*
Offline Offline

Posts: 1480898920

View Profile Personal Message (Offline)

Ignore
1480898920
Reply with quote  #2

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

Posts: 1480898920

View Profile Personal Message (Offline)

Ignore
1480898920
Reply with quote  #2

1480898920
Report to moderator
1480898920
Hero Member
*
Offline Offline

Posts: 1480898920

View Profile Personal Message (Offline)

Ignore
1480898920
Reply with quote  #2

1480898920
Report to moderator
1480898920
Hero Member
*
Offline Offline

Posts: 1480898920

View Profile Personal Message (Offline)

Ignore
1480898920
Reply with quote  #2

1480898920
Report to moderator
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 08, 2014, 12:47:38 PM
 #9942

also further to this current talk in here lol the /0 command sets to the bear min of the share diff on the miner as per the node diff so if the diff is 5mil for example it set the diff to 5mil   if it 7mil it sets to 7mil....      

But on saying this that /0 command can be used to set a diff higher than the min diff only for example if the diff was 5mil    you can set ya rig to a diff via the / number command to say 7.5 mil   eg /7500000   if this set under the current share diff on the nodes it defaults to the min diff on the node eg if you set it for 2.5 mil for example and the current diff was 5mil for a share it would default to the min diff of 5mil as that 2.5mil setting is below the current diff of 5mil
 
Show me the proof in the code that it does so.  I have linked multiple places in the code that completely contradict this statement.  All I've gotten back so far is, "based on my personal experience" and other anecdotal evidence.  As is the saying, "Show me the money!" Someone show me where setting the address to /0 sets share difficulty to p2pool minimum share difficulty by quoting the actual CODE from p2pool (and not some modified version of the code like the vardiff patch or some scrypt coin) from forrestv github.

As I wrote a number of times a few pages back, manually setting the share difficulty only makes sense if you're mining on a node where there is a very large discrepancy between your hash rate and the total hash rate of the node.  For example, if you were to bring a 180GH/s miner to a node with 10TH/s, set that S1s difficulty manually.  The same holds true going the other way.  If you're bringing 10TH/s to a node with 1TH/s, set your share difficulty HIGHER than the default p2pool share value.  I even provided a way for you to calculate what you should set it to to get an average of 1 share an hour.

Regarding your comments on the minimum requirements to join p2pool, you've hit it pretty much dead on accurate.  If you want to ensure you've got a good chance of having a share on the chain for every block found, that means you're going to need enough hardware to find a share every 12 hours or so.  Currently the share difficulty is 6.5M.  So, to find 2 shares a day, you'd need just about 650GH/s.

Your statement about the hardware to bring to the party is incorrect, though.  It's not like a dragon or an S2 is somehow better at finding shares than an S1 is.  Hash rate is hash rate, no matter how you get there.


Dude that easy to see 1st hand lol that /0 is a manual diff setting override try this and watch what happens on ya miner diff....   1st set to 7500000 watch ya miner diff rise above the node diff and set at 7.5mil....     Then set any number under the current node diff eg 4mil it will default to the min node diff as it will NOT allow you to set a diff under the current min diff of the node share rate so basically a 0 setting or a 4mil or 5 mil setting is going to gave a min diff or the node at 6.5 .....
kgb2mining
Member
**
Offline Offline

Activity: 112


View Profile
August 08, 2014, 12:54:57 PM
 #9943

Unless you are running 1th rigs forgot p2pool as you will earn no where the amount you would on a normal pool...
I don't necessarily agree with this statement, although I don't have empirical data to back it up.  Hashrate is hashrate, it should even out in the end.  Even if you don't get a share today in this block, your share will count for the next block and you would get a payout then.
Quote
not 4-5 s1 ants or 2-3 s3's to get that 1th figure
This is patently false.  I have 3 groups of 12 S1's running "together", meaning they are all using the same miner address, for a total of roughly 2.4TH/s per group.  Each group of S1's is completely out-performing the group of 2 Terraminers I have with a slightly higher hashrate.  I can show the graphs to prove it.
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 08, 2014, 12:58:31 PM
 #9944

Unless you are running 1th rigs forgot p2pool as you will earn no where the amount you would on a normal pool...
I don't necessarily agree with this statement, although I don't have empirical data to back it up.  Hashrate is hashrate, it should even out in the end.  Even if you don't get a share today in this block, your share will count for the next block and you would get a payout then.
Quote
not 4-5 s1 ants or 2-3 s3's to get that 1th figure
This is patently false.  I have 3 groups of 12 S1's running "together", meaning they are all using the same miner address, for a total of roughly 2.4TH/s per group.  Each group of S1's is completely out-performing the group of 2 Terraminers I have with a slightly higher hashrate.  I can show the graphs to prove it.

hash rate they may be out doing the 2 terra's but earning wise what happening may pay to look at how many shares they are putting in ......   in theory on a s1 you should hit around 16mil diff 1 shares every 2 days on normal mining pools    that is 2-3 shares p2 wise they are luck to hit 1 so off your example above 3 by 12 ants = 36 ant miners in total you should be seeing around 90 odd share every 2 days between them or there abouts to be on par with their diff 1 share rate and that the issue they are hitting no where near their diff 1 share rates......


mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
August 08, 2014, 01:06:36 PM
 #9945

Unless you are running 1th rigs forgot p2pool as you will earn no where the amount you would on a normal pool...
I don't necessarily agree with this statement, although I don't have empirical data to back it up.  Hashrate is hashrate, it should even out in the end.  Even if you don't get a share today in this block, your share will count for the next block and you would get a payout then.

This is regularly stated here, however it only holds true *if* bitcoin difficulty remains the same.  Which it doesn't, so therefore it's false.

If your luck averages out over the difficulty period, then yes, it will.  However, the lower your hashrate, the less likely it is to average out over a fixed period of time (a given difficulty period).  The higher the difficulty, the worse it gets.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
kgb2mining
Member
**
Offline Offline

Activity: 112


View Profile
August 08, 2014, 01:46:02 PM
 #9946

hash rate they may be out doing the 2 terra's but earning wise what happening may pay to look at how many shares they are putting in ......   in theory on a s1 you should hit around 16mil diff 1 shares every 2 days on normal mining pools    that is 2-3 shares p2 wise they are luck to hit 1 so off your example above 3 by 12 ants = 36 ant miners in total you should be seeing around 90 odd share every 2 days between them or there abouts to be on par with their diff 1 share rate and that the issue they are hitting no where near their diff 1 share rates......

The last 27 shares found on my node (out of 52 total for 1.5 day uptime):

8 shares - S1 group 1
5 shares - S1 group 2
5 shares - S1 group 3
9 shares - Terraminer group

Very appropriately proportional.  Roughly 7TH/s for the S1's, roughly 3TH/s for the Terraminers.  2:1 hash ratio, 2:1 share ratio.



KyrosKrane
Sr. Member
****
Offline Offline

Activity: 292


View Profile WWW
August 08, 2014, 01:47:59 PM
 #9947

Updated list to include FSC (fusioncoin):

To help other p2pool ops that may be interested in sharing their merged mining income, I have dedicated addresses you can send to that I'll then convert to BTC and feed back into the pool:

DVC: 1f56VqR9ajX3K42qSaDezvKXFmruSDg1B
IXC: xaNQ54gxowcwHyxqGtFM4vwCfS84V6fmKF
NMC: N1XhWNmvGhFL145zmQGQv7Vug6mThNh1iQ
I0C: jMDtRnMAk2WxaoAw8HUceMaxPPqAuZ8AEN
FSC: Fjhv8Sk8iC7AF76CTJbKo1zkHLUbTTTBs2

(I haven't given up on this yet... despite the fact that it doesn't seem be going anywhere.)

M


Are these still current and correct?

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

Activity: 98


View Profile
August 08, 2014, 01:52:12 PM
 #9948

hash rate they may be out doing the 2 terra's but earning wise what happening may pay to look at how many shares they are putting in ......   in theory on a s1 you should hit around 16mil diff 1 shares every 2 days on normal mining pools    that is 2-3 shares p2 wise they are luck to hit 1 so off your example above 3 by 12 ants = 36 ant miners in total you should be seeing around 90 odd share every 2 days between them or there abouts to be on par with their diff 1 share rate and that the issue they are hitting no where near their diff 1 share rates......

The last 27 shares found on my node (out of 52 total for 1.5 day uptime):

8 shares - S1 group 1
5 shares - S1 group 2
5 shares - S1 group 3
9 shares - Terraminer group

Very appropriately proportional.  Roughly 7.2TH/s for the S1's, roughly 3TH/s for the Terraminers.  2:1 hash ratio, 2:1 share ratio.





dude look at them number close they are no where near what they should be for an s1 diff 1 share rate.......      the 1st group has hit at less than a share each in 1.5 days    and it get worst from there I rest my case    


8 * 6.5 mil =   5200000 diff 1 share    for that 1st group of 12 miners they should be around 32000000 diff 1 share at the end of day 2 they are about 26 mil shares down atm vs ya mining a normal pool...... diff 1 share wise  so there a huge loss there atm vs mining at a normal pool

mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
August 08, 2014, 02:10:36 PM
 #9949

Updated list to include FSC (fusioncoin):

To help other p2pool ops that may be interested in sharing their merged mining income, I have dedicated addresses you can send to that I'll then convert to BTC and feed back into the pool:

DVC: 1f56VqR9ajX3K42qSaDezvKXFmruSDg1B
IXC: xaNQ54gxowcwHyxqGtFM4vwCfS84V6fmKF
NMC: N1XhWNmvGhFL145zmQGQv7Vug6mThNh1iQ
I0C: jMDtRnMAk2WxaoAw8HUceMaxPPqAuZ8AEN
FSC: Fjhv8Sk8iC7AF76CTJbKo1zkHLUbTTTBs2

(I haven't given up on this yet... despite the fact that it doesn't seem be going anywhere.)

M


Are these still current and correct?

Yes.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
kgb2mining
Member
**
Offline Offline

Activity: 112


View Profile
August 08, 2014, 02:10:53 PM
 #9950

dude look at them number close they are no where near what they should be for an s1 diff 1 share rate.......      the 1st group has hit at less than a share each in 1.5 days    and it get worst from there I rest my case    


8 * 6.5 mil =   5200000 diff 1 share    for that 1st group of 12 miners they should be around 32000000 diff 1 share at the end of day 2 they are about 26 mil shares down atm vs ya mining a normal pool...... diff 1 share wise  so there a huge loss there atm vs mining at a normal pool
I don't understand your math.

Current diff as reported by p2pool is 5.9mil, not 6.5mil, meaning 47 instead of 52.  
Yesterday the diff was lower, it increased overnight with the block adjustment.
I don't understand where you're coming up with the 32mil after day 2.
This sample size is 1.5 days total, not 2.  I only counted the last 27 shares in my last post, not the full 54 over the past 1.5 days, but I'm going to assume it's equally proportional.
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
August 08, 2014, 02:12:39 PM
 #9951

hash rate they may be out doing the 2 terra's but earning wise what happening may pay to look at how many shares they are putting in ......   in theory on a s1 you should hit around 16mil diff 1 shares every 2 days on normal mining pools    that is 2-3 shares p2 wise they are luck to hit 1 so off your example above 3 by 12 ants = 36 ant miners in total you should be seeing around 90 odd share every 2 days between them or there abouts to be on par with their diff 1 share rate and that the issue they are hitting no where near their diff 1 share rates......

The last 27 shares found on my node (out of 52 total for 1.5 day uptime):

8 shares - S1 group 1
5 shares - S1 group 2
5 shares - S1 group 3
9 shares - Terraminer group

Very appropriately proportional.  Roughly 7.2TH/s for the S1's, roughly 3TH/s for the Terraminers.  2:1 hash ratio, 2:1 share ratio.





dude look at them number close they are no where near what they should be for an s1 diff 1 share rate.......      the 1st group has hit at less than a share each in 1.5 days    and it get worst from there I rest my case    


8 * 6.5 mil =   5200000 diff 1 share    for that 1st group of 12 miners they should be around 32000000 diff 1 share at the end of day 2 they are about 26 mil shares down atm vs ya mining a normal pool...... diff 1 share wise  so there a huge loss there atm vs mining at a normal pool

You're comparing apples and oranges.  A share in the p2pool alt chain is worth a *lot* more than a normal diff 1 share on a normal pool.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
jonnybravo0311
Hero Member
*****
Offline Offline

Activity: 994


Mine at Jonny's Pool


View Profile WWW
August 08, 2014, 03:30:46 PM
 #9952

also further to this current talk in here lol the /0 command sets to the bear min of the share diff on the miner as per the node diff so if the diff is 5mil for example it set the diff to 5mil   if it 7mil it sets to 7mil....      

But on saying this that /0 command can be used to set a diff higher than the min diff only for example if the diff was 5mil    you can set ya rig to a diff via the / number command to say 7.5 mil   eg /7500000   if this set under the current share diff on the nodes it defaults to the min diff on the node eg if you set it for 2.5 mil for example and the current diff was 5mil for a share it would default to the min diff of 5mil as that 2.5mil setting is below the current diff of 5mil
 
Show me the proof in the code that it does so.  I have linked multiple places in the code that completely contradict this statement.  All I've gotten back so far is, "based on my personal experience" and other anecdotal evidence.  As is the saying, "Show me the money!" Someone show me where setting the address to /0 sets share difficulty to p2pool minimum share difficulty by quoting the actual CODE from p2pool (and not some modified version of the code like the vardiff patch or some scrypt coin) from forrestv github.

As I wrote a number of times a few pages back, manually setting the share difficulty only makes sense if you're mining on a node where there is a very large discrepancy between your hash rate and the total hash rate of the node.  For example, if you were to bring a 180GH/s miner to a node with 10TH/s, set that S1s difficulty manually.  The same holds true going the other way.  If you're bringing 10TH/s to a node with 1TH/s, set your share difficulty HIGHER than the default p2pool share value.  I even provided a way for you to calculate what you should set it to to get an average of 1 share an hour.

Regarding your comments on the minimum requirements to join p2pool, you've hit it pretty much dead on accurate.  If you want to ensure you've got a good chance of having a share on the chain for every block found, that means you're going to need enough hardware to find a share every 12 hours or so.  Currently the share difficulty is 6.5M.  So, to find 2 shares a day, you'd need just about 650GH/s.

Your statement about the hardware to bring to the party is incorrect, though.  It's not like a dragon or an S2 is somehow better at finding shares than an S1 is.  Hash rate is hash rate, no matter how you get there.


Dude that easy to see 1st hand lol that /0 is a manual diff setting override try this and watch what happens on ya miner diff....   1st set to 7500000 watch ya miner diff rise above the node diff and set at 7.5mil....     Then set any number under the current node diff eg 4mil it will default to the min node diff as it will NOT allow you to set a diff under the current min diff of the node share rate so basically a 0 setting or a 4mil or 5 mil setting is going to gave a min diff or the node at 6.5 .....

Show me the code.  Don't tell me, "dude that easy to see 1st hand lol...".  Here's my proof.  First, the reading of manually set difficulty:
Code:
desired_pseudoshare_target = None
        desired_share_target = None
        for symbol, parameter in zip(contents2[::2], contents2[1::2]):
            if symbol == '+':
                try:
                    desired_pseudoshare_target = bitcoin_data.difficulty_to_target(float(parameter))
                except:
                    if p2pool.DEBUG:
                        log.err()
            elif symbol == '/':
                try:
                    desired_share_target = bitcoin_data.difficulty_to_target(float(parameter))
                except:
                    if p2pool.DEBUG:
                        log.err()

        if random.uniform(0, 100) < self.worker_fee:
            pubkey_hash = self.my_pubkey_hash
        else:
            try:
                pubkey_hash = bitcoin_data.address_to_pubkey_hash(user, self.node.net.PARENT)
            except: # XXX blah
                pubkey_hash = self.my_pubkey_hash

        return user, pubkey_hash, desired_share_target, desired_pseudoshare_target
Now, here's the difficulty_to_target definition:
Code:
def difficulty_to_target(difficulty):
    assert difficulty >= 0
    if difficulty == 0: return 2**256-1
    return min(int((0xffff0000 * 2**(256-64) + 1)/difficulty - 1 + 0.5), 2**256-1)
This CLEARLY sets the difficulty to 2**256-1 if you set /0.  Using python and printing what 2**256-1 resolves to:
Code:
Python 2.7.8 (default, Jul  3 2014, 06:13:58)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x=2**256-1
>>> print x
115792089237316195423570985008687907853269984665640564039457584007913129639935
>>> exit()
Now, here's where the comparison between YOUR set value and the value p2pool determines happens:
Code:
if desired_share_target is None:
            desired_share_target = 2**256-1
            local_hash_rate = self._estimate_local_hash_rate()
            if local_hash_rate is not None:
                desired_share_target = min(desired_share_target,
                    bitcoin_data.average_attempts_to_target(local_hash_rate * self.node.net.SHARE_PERIOD / 0.0167)) # limit to 1.67% of pool shares by modulating share difficulty

            local_addr_rates = self.get_local_addr_rates()
            lookbehind = 3600//self.node.net.SHARE_PERIOD
            block_subsidy = self.node.bitcoind_work.value['subsidy']
            if previous_share is not None and self.node.tracker.get_height(previous_share.hash) > lookbehind:
                expected_payout_per_block = local_addr_rates.get(pubkey_hash, 0)/p2pool_data.get_pool_attempts_per_second(self.node.tracker, self.node.best_share_var.value, lookbehind) \
                    * block_subsidy*(1-self.donation_percentage/100) # XXX doesn't use global stale rate to compute pool hash
                if expected_payout_per_block < self.node.net.PARENT.DUST_THRESHOLD:
                    desired_share_target = min(desired_share_target,
                        bitcoin_data.average_attempts_to_target((bitcoin_data.target_to_average_attempts(self.node.bitcoind_work.value['bits'].target)*self.node.net.SPREAD)*self.node.net.PARENT.DUST_THRESHOLD/block_subsidy)
                    )
This block is NEVER reached.  Why?  Because the value of "desired_share_target" at this point is not None.  It is 2**256-1.  Therefore, your desired target difficulty remains at 2**256-1 when you set it to "0" manually by using /0.

Now that I've shown my proof why you're wrong, show me why you're right.

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

Activity: 994


Mine at Jonny's Pool


View Profile WWW
August 08, 2014, 03:43:14 PM
 #9953

Unless you are running 1th rigs forgot p2pool as you will earn no where the amount you would on a normal pool...
I don't necessarily agree with this statement, although I don't have empirical data to back it up.  Hashrate is hashrate, it should even out in the end.  Even if you don't get a share today in this block, your share will count for the next block and you would get a payout then.

This is regularly stated here, however it only holds true *if* bitcoin difficulty remains the same.  Which it doesn't, so therefore it's false.

If your luck averages out over the difficulty period, then yes, it will.  However, the lower your hashrate, the less likely it is to average out over a fixed period of time (a given difficulty period).  The higher the difficulty, the worse it gets.

M
While your statement about rising difficulty is true, the application of it here is not addressing the statement made by fire000.  His statement implied a difference between using a dragon miner at 1TH/s vs using a combination of other miners to also achieve that 1TH/s.  In this sense, hash rate is hash rate.  If you have 500 Antminer U2s all hashing at 2GH/s each, or 5 over clocked S1s hashing at 200GH/s each, or 1 dragon hashing at 1TH/s, you still have 1TH/s mining.

Your statement is entirely accurate about it not evening out in the end, precisely because of increased difficulty.

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

Activity: 994


Mine at Jonny's Pool


View Profile WWW
August 08, 2014, 04:31:40 PM
 #9954

Lmao how hard is it to understand that /0 is a manual override code for diff....     It can only be set above the current diff to have any effect eg if the current diff is say 6 mil a share it need to be set above this to see any effect on diff.....     If it is set under this value of 6 mil it defaults to the current share diff ........    Weather you set it at 5 mil 4 mil 3.5 mil or 0 as the value is less than the min current diff in this case of 6 mil  it not rocket science and the proof is ya only got to test it and take note of the diff your miner is set at to see it in effect 1st hand DO I HAVE TO SCREEN SHOT IT to highlight it too you that the / number if less than the current share diff it will default to the current min share diff of the node as ya do not know where to find the diff reading on ya miner Huh??

Ps does not need to look at code etc to know you can not set a diff under the current share diff if you do it will default to current share diff hence the comment above

You have yet to provide proof of your statements.  I have shown you where the code explicitly sets the difficulty to 2**256-1 if you set the difficulty to /0.  Show me where it doesn't.

I understand quite well that /0 or /100 or /10000000 is a manual override for share difficulty.  What I want YOU to show to me is proof of your statement
Quote
If it is set under this value of 6 mil it defaults to the current share diff.
Show me that.  Not by screenshots.  By the CODE.

Your next statement:
Quote
Weather you set it at 5 mil 4 mil 3.5 mil or 0 as the value is less than the min current diff in this case of 6 mil  it not rocket science and the proof is ya only got to test it and take note of the diff your miner is set at to see it in effect 1st hand DO I HAVE TO SCREEN SHOT IT to highlight it too you that the / number if less than the current share diff it will default to the current min share diff of the node as ya do not know where to find the diff reading on ya miner Huh??
That's just outright incorrect.  Your miner does NOT show the value you set in /0 or /100 or /100000.  Your miner shows the PSEUDO share value you defined using +0 or +100 or +1000.  Your miner has absolutely no concept of anything set with using /#.

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.
contactlight
Full Member
***
Offline Offline

Activity: 168


View Profile
August 08, 2014, 04:32:32 PM
 #9955

For some reason this new difficulty increase has been great for my luck. I have been finding blocks left and right.
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 08, 2014, 04:45:46 PM
 #9956

Lmao how hard is it to understand that /0 is a manual override code for diff....     It can only be set above the current diff to have any effect eg if the current diff is say 6 mil a share it need to be set above this to see any effect on diff.....     If it is set under this value of 6 mil it defaults to the current share diff ........    Weather you set it at 5 mil 4 mil 3.5 mil or 0 as the value is less than the min current diff in this case of 6 mil  it not rocket science and the proof is ya only got to test it and take note of the diff your miner is set at to see it in effect 1st hand DO I HAVE TO SCREEN SHOT IT to highlight it too you that the / number if less than the current share diff it will default to the current min share diff of the node as ya do not know where to find the diff reading on ya miner Huh??

Ps does not need to look at code etc to know you can not set a diff under the current share diff if you do it will default to current share diff hence the comment above

You have yet to provide proof of your statements.  I have shown you where the code explicitly sets the difficulty to 2**256-1 if you set the difficulty to /0.  Show me where it doesn't.

I understand quite well that /0 or /100 or /10000000 is a manual override for share difficulty.  What I want YOU to show to me is proof of your statement
Quote
If it is set under this value of 6 mil it defaults to the current share diff.
Show me that.  Not by screenshots.  By the CODE.

Your next statement:
Quote
Weather you set it at 5 mil 4 mil 3.5 mil or 0 as the value is less than the min current diff in this case of 6 mil  it not rocket science and the proof is ya only got to test it and take note of the diff your miner is set at to see it in effect 1st hand DO I HAVE TO SCREEN SHOT IT to highlight it too you that the / number if less than the current share diff it will default to the current min share diff of the node as ya do not know where to find the diff reading on ya miner Huh??
That's just outright incorrect.  Your miner does NOT show the value you set in /0 or /100 or /100000.  Your miner shows the PSEUDO share value you defined using +0 or +100 or +1000.  Your miner has absolutely no concept of anything set with using /#.

I am not going to go digging through code when it common knowelge you can not put a share in that not above the share value and be credited for it as a paying share......   hence that statement above if your share is not over that current share diff you not going to be credited with it as a paying share are ya HuhHuh??       So it defaults to the current share diff value not rocket science  Ps next time ya quote something quote the full statement not part of it
Quote
It can only be set above the current diff to have any effect eg if the current diff is say 6 mil a share it need to be set above this to see any effect on diff... If it is set under this value of 6 mil it defaults to the current share diff

jonnybravo0311
Hero Member
*****
Offline Offline

Activity: 994


Mine at Jonny's Pool


View Profile WWW
August 08, 2014, 05:14:54 PM
 #9957

Lmao how hard is it to understand that /0 is a manual override code for diff....     It can only be set above the current diff to have any effect eg if the current diff is say 6 mil a share it need to be set above this to see any effect on diff.....     If it is set under this value of 6 mil it defaults to the current share diff ........    Weather you set it at 5 mil 4 mil 3.5 mil or 0 as the value is less than the min current diff in this case of 6 mil  it not rocket science and the proof is ya only got to test it and take note of the diff your miner is set at to see it in effect 1st hand DO I HAVE TO SCREEN SHOT IT to highlight it too you that the / number if less than the current share diff it will default to the current min share diff of the node as ya do not know where to find the diff reading on ya miner Huh??

Ps does not need to look at code etc to know you can not set a diff under the current share diff if you do it will default to current share diff hence the comment above

You have yet to provide proof of your statements.  I have shown you where the code explicitly sets the difficulty to 2**256-1 if you set the difficulty to /0.  Show me where it doesn't.

I understand quite well that /0 or /100 or /10000000 is a manual override for share difficulty.  What I want YOU to show to me is proof of your statement
Quote
If it is set under this value of 6 mil it defaults to the current share diff.
Show me that.  Not by screenshots.  By the CODE.

Your next statement:
Quote
Weather you set it at 5 mil 4 mil 3.5 mil or 0 as the value is less than the min current diff in this case of 6 mil  it not rocket science and the proof is ya only got to test it and take note of the diff your miner is set at to see it in effect 1st hand DO I HAVE TO SCREEN SHOT IT to highlight it too you that the / number if less than the current share diff it will default to the current min share diff of the node as ya do not know where to find the diff reading on ya miner Huh??
That's just outright incorrect.  Your miner does NOT show the value you set in /0 or /100 or /100000.  Your miner shows the PSEUDO share value you defined using +0 or +100 or +1000.  Your miner has absolutely no concept of anything set with using /#.

I am not going to go digging through code when it common knowelge you can not put a share in that not above the share value and be credited for it as a paying share......   hence that statement above if your share is not over that current share diff you not going to be credited with it as a paying share are ya HuhHuh??       So it defaults to the current share diff value not rocket science  Ps next time ya quote something quote the full statement not part of it
Quote
It can only be set above the current diff to have any effect eg if the current diff is say 6 mil a share it need to be set above this to see any effect on diff... If it is set under this value of 6 mil it defaults to the current share diff


You are obviously failing to understand.  Your miner has no knowledge whatsoever of you setting a share difficulty of /0 or /256 or /245982345.  None.  Whatsoever.  Your miner shows you the PSUEDO share value you have set using +0 or +256 or +1000.

What I am stating is the following:

If you set your share difficulty to /0, that then gets translated by the p2pool code to set your desired share target to be 2**256-1.  If you set your share difficulty to ANY other value, p2pool will evaluate that value and attempt to add it to the share chain.  It will not be added if your desired share target is LESS than the required difficulty to actually get on the chain in the first place.  If you set your share difficulty to something LARGER than the p2pool minimum, when you find a share at least your target difficulty it WILL be added to the share chain (assuming it's not orphaned or DOA), and its payout value WILL be weighted appropriately.  This is also proven in the code.

I want you, or anybody, to prove to me that setting /0 somehow gets translated into p2pool minimum difficulty.  That's what I'm looking for.  Proof.  The ACTUAL CODE that does this.  I have shown the ACTUAL CODE that supports my theory.  You have given nothing but incoherent blathering about how you're right and everybody knows it.

Let me put it another way.  I WANT to be proven wrong.  I WANT to be shown where I'm incorrect.  Do that.  Prove me wrong.

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.
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 08, 2014, 05:23:59 PM
 #9958

Lmao how hard is it to understand that /0 is a manual override code for diff....     It can only be set above the current diff to have any effect eg if the current diff is say 6 mil a share it need to be set above this to see any effect on diff.....     If it is set under this value of 6 mil it defaults to the current share diff ........    Weather you set it at 5 mil 4 mil 3.5 mil or 0 as the value is less than the min current diff in this case of 6 mil  it not rocket science and the proof is ya only got to test it and take note of the diff your miner is set at to see it in effect 1st hand DO I HAVE TO SCREEN SHOT IT to highlight it too you that the / number if less than the current share diff it will default to the current min share diff of the node as ya do not know where to find the diff reading on ya miner Huh??

Ps does not need to look at code etc to know you can not set a diff under the current share diff if you do it will default to current share diff hence the comment above

You have yet to provide proof of your statements.  I have shown you where the code explicitly sets the difficulty to 2**256-1 if you set the difficulty to /0.  Show me where it doesn't.

I understand quite well that /0 or /100 or /10000000 is a manual override for share difficulty.  What I want YOU to show to me is proof of your statement
Quote
If it is set under this value of 6 mil it defaults to the current share diff.
Show me that.  Not by screenshots.  By the CODE.

Your next statement:
Quote
Weather you set it at 5 mil 4 mil 3.5 mil or 0 as the value is less than the min current diff in this case of 6 mil  it not rocket science and the proof is ya only got to test it and take note of the diff your miner is set at to see it in effect 1st hand DO I HAVE TO SCREEN SHOT IT to highlight it too you that the / number if less than the current share diff it will default to the current min share diff of the node as ya do not know where to find the diff reading on ya miner Huh??
That's just outright incorrect.  Your miner does NOT show the value you set in /0 or /100 or /100000.  Your miner shows the PSEUDO share value you defined using +0 or +100 or +1000.  Your miner has absolutely no concept of anything set with using /#.

I am not going to go digging through code when it common knowelge you can not put a share in that not above the share value and be credited for it as a paying share......   hence that statement above if your share is not over that current share diff you not going to be credited with it as a paying share are ya HuhHuh??       So it defaults to the current share diff value not rocket science  Ps next time ya quote something quote the full statement not part of it
Quote
It can only be set above the current diff to have any effect eg if the current diff is say 6 mil a share it need to be set above this to see any effect on diff... If it is set under this value of 6 mil it defaults to the current share diff


You are obviously failing to understand.  Your miner has no knowledge whatsoever of you setting a share difficulty of /0 or /256 or /245982345.  None.  Whatsoever.  Your miner shows you the PSUEDO share value you have set using +0 or +256 or +1000.

What I am stating is the following:

If you set your share difficulty to /0, that then gets translated by the p2pool code to set your desired share target to be 2**256-1.  If you set your share difficulty to ANY other value, p2pool will evaluate that value and attempt to add it to the share chain.  It will not be added if your desired share target is LESS than the required difficulty to actually get on the chain in the first place.  If you set your share difficulty to something LARGER than the p2pool minimum, when you find a share at least your target difficulty it WILL be added to the share chain (assuming it's not orphaned or DOA), and its payout value WILL be weighted appropriately.  This is also proven in the code.

I want you, or anybody, to prove to me that setting /0 somehow gets translated into p2pool minimum difficulty.  That's what I'm looking for.  Proof.  The ACTUAL CODE that does this.  I have shown the ACTUAL CODE that supports my theory.  You have given nothing but incoherent blathering about how you're right and everybody knows it.

Let me put it another way.  I WANT to be proven wrong.  I WANT to be shown where I'm incorrect.  Do that.  Prove me wrong.

What part are you NOT UNDERSTANDING and you have said it your self above IF that diff is set lower that the share diff to get to the chain it does what Huh?   It defaults to the min share value to get to the chain to stop people from putting in under target shares you have said this yourself.....    So again /0 or /100 or /1000 any number under the current share value will see it set to the min value to put a share into the chain to stop undervalue shares getting to the chain which = what oh that would be min diff Smiley
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 08, 2014, 05:37:00 PM
 #9959

so basically as said miles back in this whole topic lol

Quote
also further to this current talk in here lol the /0 command sets to the bear min of the share diff on the miner as per the node diff so if the diff is 5mil for example it set the diff to 5mil   if it 7mil it sets to 7mil....     

But on saying this that /0 command can be used to set a diff higher than the min diff only for example if the diff was 5mil    you can set ya rig to a diff via the / number command to say 7.5 mil   eg /7500000   if this set under the current share diff on the nodes it defaults to the min diff on the node eg if you set it for 2.5 mil for example and the current diff was 5mil for a share it would default to the min diff of 5mil as that 2.5mil setting is below the current diff of 5mil


jonnybravo0311
Hero Member
*****
Offline Offline

Activity: 994


Mine at Jonny's Pool


View Profile WWW
August 08, 2014, 05:57:26 PM
 #9960

so basically as said miles back in this whole topic lol

Quote
also further to this current talk in here lol the /0 command sets to the bear min of the share diff on the miner as per the node diff so if the diff is 5mil for example it set the diff to 5mil   if it 7mil it sets to 7mil....     

But on saying this that /0 command can be used to set a diff higher than the min diff only for example if the diff was 5mil    you can set ya rig to a diff via the / number command to say 7.5 mil   eg /7500000   if this set under the current share diff on the nodes it defaults to the min diff on the node eg if you set it for 2.5 mil for example and the current diff was 5mil for a share it would default to the min diff of 5mil as that 2.5mil setting is below the current diff of 5mil



/0 behaves differently than /1.  That's what the code says, and what I'm stating.  By setting it to /0, the CODE translates that to 2**256-1.  If you set it to /1, the code sets the difficulty to min(int((0xffff0000 * 2**(256-64) + 1)/difficulty - 1 + 0.5), 2**256-1).  See the difference?  0 means 2**256-1.  1 means evaluate the minimum of int((0xffff0000 * 2**(256-64) + 1)/difficulty - 1 + 0.5) and 2**256-1.  Look at both statements if you just isolate this part of the code and execute it.  Let me explain it line by line:
Code:
def difficulty_to_target(difficulty):
    assert difficulty >= 0
    if difficulty == 0: return 2**256-1
    return min(int((0xffff0000 * 2**(256-64) + 1)/difficulty - 1 + 0.5), 2**256-1)
Line 1 - defines the difficulty_to_target function.  It takes a single parameter - the difficulty
Line 2 - makes sure the difficulty passed is 0 or larger
Line 3 - if the difficulty equals 0, return a value of 2**256-1
Line 4 - if the difficulty equals ANY OTHER NUMBER, return the value that is the minimum of the two numbers.

Pay very close attention to the bolded part.  Therefore, if you set your miner like this:

ADDRESS/0

When that function is called, difficulty equals 0.  Therefore, it returns 2**256-1.

If you set your miner like this:

ADDRESS/1

When that function is called, difficulty equals 1.  Therefore, it returns the minimum of int((0xffff0000 * 2**(256-64) + 1)/difficulty - 1 + 0.5) and 2**256-1.

Do you understand this?

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.
Pages: « 1 ... 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 [498] 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 ... 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!