Bitcoin Forum
December 08, 2016, 12:17:46 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 [607] 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2032748 times)
PatMan
Hero Member
*****
Offline Offline

Activity: 924


Watch out for the "Neg-Rep-Dogie-Police".....


View Profile WWW
February 19, 2015, 08:40:41 AM
 #12121

So normal CGminer has submit stale on by default correct?
I know CK provided a fix for the S3, what do we do about the S5? (Assuming we need corrective action)
Is it safe to say that Spondoolies did this the correct way, that is submit stale is on by default?
S5 binary also available here (antminer's fork binaries still screw this up):
http://ck.kolivas.org/apps/cgminer/antminer/

Spondoolies do the right thing here.

@ck:  Am I right in saying that this has to be applied after every reboot - or is there a way to make it permanent:

Code:
cd /tmp
wget http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer
chmod +x cgminer
mv /usr/bin/cgminer /usr/bin/cgminer.bak
cp cgminer /usr/bin
/etc/init.d/cgminer.sh restart

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
1481199466
Hero Member
*
Offline Offline

Posts: 1481199466

View Profile Personal Message (Offline)

Ignore
1481199466
Reply with quote  #2

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

Activity: 182


View Profile
February 19, 2015, 10:13:30 AM
 #12122

So normal CGminer has submit stale on by default correct?
I know CK provided a fix for the S3, what do we do about the S5? (Assuming we need corrective action)
Is it safe to say that Spondoolies did this the correct way, that is submit stale is on by default?
S5 binary also available here (antminer's fork binaries still screw this up):
http://ck.kolivas.org/apps/cgminer/antminer/

Spondoolies do the right thing here.

@ck:  Am I right in saying that this has to be applied after every reboot - or is there a way to make it permanent:

Code:
cd /tmp
wget http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer
chmod +x cgminer
mv /usr/bin/cgminer /usr/bin/cgminer.bak
cp cgminer /usr/bin
/etc/init.d/cgminer.sh restart

Replacing cgminer binary is permanent, after firmware update one should do it again
PatMan
Hero Member
*****
Offline Offline

Activity: 924


Watch out for the "Neg-Rep-Dogie-Police".....


View Profile WWW
February 19, 2015, 10:48:07 AM
 #12123

Replacing cgminer binary is permanent, after firmware update one should do it again

I'm not so sure about that, according to ck:

Here's a quick binary for the S5 based on bitmain's existing code which will ignore any queue parameter, not discard stales, should be able to ramp up smoothly if you find yourself on a very low diff pool, and use a little less CPU:

http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer

Binaries will only be temporary so will not survive a machine reboot.

The following will change the cgminer binary for you (set the appropriate IP address), the default root password is "admin":

Code:
ssh 192.168.1.x -l root
cd /tmp
wget http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer
chmod +x cgminer
mv /usr/bin/cgminer /usr/bin/cgminer.bak
cp cgminer /usr/bin
/etc/init.d/cgminer.sh restart

There should be a more comprehensive merge in the future into mainline cgminer, hopefully by Kano. Bitmaintech has provided us both with S5s to support cgminer development.


As far as I know the merge didn't happen yet, cos if it had we wouldn't have to download this binary.

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
February 19, 2015, 10:58:29 AM
 #12124

If someone has added himself to p2pool 3 days before 344101 block was found he would get paid the same amount as if he added himself 4 or 5 days before it?

Theoretically speaking, yes.  It depends largely on your individual luck.

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.
aurel57
Legendary
*
Offline Offline

Activity: 1050



View Profile
February 19, 2015, 11:31:29 AM
 #12125

So normal CGminer has submit stale on by default correct?
I know CK provided a fix for the S3, what do we do about the S5? (Assuming we need corrective action)
Is it safe to say that Spondoolies did this the correct way, that is submit stale is on by default?
S5 binary also available here (antminer's fork binaries still screw this up):
http://ck.kolivas.org/apps/cgminer/antminer/

Spondoolies do the right thing here.

@ck:  Am I right in saying that this has to be applied after every reboot - or is there a way to make it permanent:

Code:
cd /tmp
wget http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer
chmod +x cgminer
mv /usr/bin/cgminer /usr/bin/cgminer.bak
cp cgminer /usr/bin
/etc/init.d/cgminer.sh restart

This seems like a problem if you rent hash?
jedimstr
Hero Member
*****
Offline Offline

Activity: 784



View Profile
February 19, 2015, 11:39:32 AM
 #12126

This seems like a problem if you rent hash?

Best bet for renting hash for use with p2pool is to stick to renters who advertise using Spondoolies boxes. You'll get less problems with the rental that way since they're great on p2pool.

jcumins
Full Member
***
Offline Offline

Activity: 192


View Profile
February 19, 2015, 02:19:26 PM
 #12127

CK  your last cgminer binary will not work with the Jan 2015 Bitmain S3 firmware.  the cgminer that is part of the Jan 2015 firmware is version 4.70  not 4.6.  Do you know if this has the fix in it.

 
Songminer
Member
**
Offline Offline

Activity: 67


View Profile
February 19, 2015, 03:14:12 PM
 #12128

I'm running an s5 with the January firmware.

Is there anything I should do to improve performance on the P2Pool?

PatMan
Hero Member
*****
Offline Offline

Activity: 924


Watch out for the "Neg-Rep-Dogie-Police".....


View Profile WWW
February 19, 2015, 04:18:36 PM
 #12129

I'm running an s5 with the January firmware.

Is there anything I should do to improve performance on the P2Pool?


Change the queue setting to 0 or 1 - whatever gives you the lowest DOA/reject rate  Wink

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
February 19, 2015, 09:18:06 PM
 #12130

CK  your last cgminer binary will not work with the Jan 2015 Bitmain S3 firmware.  the cgminer that is part of the Jan 2015 firmware is version 4.70  not 4.6.  Do you know if this has the fix in it.

 
No it doesn't.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
jcumins
Full Member
***
Offline Offline

Activity: 192


View Profile
February 20, 2015, 01:33:13 AM
 #12131

So what version of firmware will your cgminer work with I can always back rev and update the cgminer
jcumins
Full Member
***
Offline Offline

Activity: 192


View Profile
February 20, 2015, 01:48:58 AM
 #12132

I will update my s5 tomorrow with yck latest cgminer tomorrow when i install them in the data center
jtoomim
Hero Member
*****
Offline Offline

Activity: 555


View Profile WWW
February 20, 2015, 02:25:19 AM
 #12133

It looks like about 41% of all p2pool miners are now running on the Toomim Brothers datacenter's nodes, since most of the rest fled.

Node 1: 298 TH/s
Node 2: 60 TH/s
p2pool total: 864 TH/s

I'm amused, but also a bit disappointed. Can't you guys bring your hashrate back?

If you are running your own node and want to add us to your hardcoded IP list, please only add one of our nodes, since adding both would result in shares and transactions being sent twice over our internet connection instead of once over the 'net and then forwarded once over our LAN. Also, both of our nodes are a bit stressed in terms of CPU cycles (especially the big :9334 node), and each connection adds CPU load. Also keep in mind that those nodes are not currently on a static IP address, and their IP may change once every few months. (The IP has changed once so far since August.)

By the way, my guess is that the previous block took as long as it did in large part because a bunch of hashrate left p2pool several days ago, and the p2pool total hashrate estimates are slow to update. The estimates are based on the last 8640 shares submitted (right?). The default share difficulty is based on the estimated pool hashrate, so when the hashrate decreases rapidly, 8640 shares can encompass a time period significantly longer than 3 days, since those 8640 shares are at a higher (older) difficulty.

Hosting bitcoin miners for $75 to $90/kW/month on clean, cheap hydro power.
http://Toom.im
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
February 20, 2015, 02:41:22 AM
 #12134

It looks like about 41% of all p2pool miners are now running on the Toomim Brothers datacenter's nodes, since most of the rest fled.

Node 1: 298 TH/s
Node 2: 60 TH/s
p2pool total: 864 TH/s

I'm amused, but also a bit disappointed. Can't you guys bring your hashrate back?

If you are running your own node and want to add us to your hardcoded IP list, please only add one of our nodes, since adding both would result in shares and transactions being sent twice over our internet connection instead of once over the 'net and then forwarded once over our LAN. Also, both of our nodes are a bit stressed in terms of CPU cycles (especially the big :9334 node), and each connection adds CPU load. Also keep in mind that those nodes are not currently on a static IP address, and their IP may change once every few months. (The IP has changed once so far since August.)

By the way, my guess is that the previous block took as long as it did in large part because a bunch of hashrate left p2pool several days ago, and the p2pool total hashrate estimates are slow to update. The estimates are based on the last 8640 shares submitted (right?). The default share difficulty is based on the estimated pool hashrate, so when the hashrate decreases rapidly, 8640 shares can encompass a time period significantly longer than 3 days, since those 8640 shares are at a higher (older) difficulty.

I've seen the hashrate jump around a lot in a very short period of time.  I don't think it's based upon the last 8640 shares.  What it is based upon I don't know.  In order to keep the target at approx one share every 30 seconds, I'd think it'd have to recalculate pretty often and look at a pretty small window.  Otherwise someone could add 1 PH/s and the share difficulty would take quite some time to increase.

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

Activity: 555


View Profile WWW
February 20, 2015, 03:35:57 AM
 #12135

Cross-post from the Spondoolies thread, more relevant here:

centralization incoming Sad

If only everyone used p2pool....... Wink

If everyone did, the share difficulty would be through the roof.  2,222,770,798 if I understand it right..

p2pool is not the answer.

a rewrite perhaps.  but not in its current incarnation.

M

I was thinking about this the other day, actually, and I think I got a good solution to the problem.

p2pool uses a share chain much like the block chain for its reward allocation. This means that if you're mining on a share that isn't the most recent, your work is wasted. The blockchain was designed to solve the timestamping problem for creating a distributed ledger system for transactions, which is why the blockchain has to be serialized. With p2pool, there is no such requirement for timestamping and serializing the shares, so the shares do not necessarily need to be arranged in a chain. The fact that they are was probably mostly just a programming convenience in being able to reuse the bitcoin blockchain data structures. I think a better structure for p3pool shares would be a share tree, where each share references at least one parent share instead of exactly one parent share. That way, work done on shares that would end up marked as stale on the current p2pool (i.e. branching shares) could still be incorporated into the p3pool share tree. Add in a small reward to the miner who found the share for each parent share that's referenced for the first time, and everybody's shares should get incorporated as long as the share is based on the most recent block.

Since miners no longer would need to abandon work immediately when someone on p3pool finds a share, p3pool could target much higher share frequencies, such as 1 per second or faster. This would decrease share variance and allow for small miners to use p2pool effectively, and it would also allow p3pool to grow larger while keeping individual share targets reasonable.

Hosting bitcoin miners for $75 to $90/kW/month on clean, cheap hydro power.
http://Toom.im
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
February 20, 2015, 04:27:55 AM
 #12136

Cross-post from the Spondoolies thread, more relevant here:

centralization incoming Sad

If only everyone used p2pool....... Wink

If everyone did, the share difficulty would be through the roof.  2,222,770,798 if I understand it right..

p2pool is not the answer.

a rewrite perhaps.  but not in its current incarnation.

M

I was thinking about this the other day, actually, and I think I got a good solution to the problem.

p2pool uses a share chain much like the block chain for its reward allocation. This means that if you're mining on a share that isn't the most recent, your work is wasted. The blockchain was designed to solve the timestamping problem for creating a distributed ledger system for transactions, which is why the blockchain has to be serialized. With p2pool, there is no such requirement for timestamping and serializing the shares, so the shares do not necessarily need to be arranged in a chain. The fact that they are was probably mostly just a programming convenience in being able to reuse the bitcoin blockchain data structures. I think a better structure for p3pool shares would be a share tree, where each share references at least one parent share instead of exactly one parent share. That way, work done on shares that would end up marked as stale on the current p2pool (i.e. branching shares) could still be incorporated into the p3pool share tree. Add in a small reward to the miner who found the share for each parent share that's referenced for the first time, and everybody's shares should get incorporated as long as the share is based on the most recent block.

Since miners no longer would need to abandon work immediately when someone on p3pool finds a share, p3pool could target much higher share frequencies, such as 1 per second or faster. This would decrease share variance and allow for small miners to use p2pool effectively, and it would also allow p3pool to grow larger while keeping individual share targets reasonable.

That sounds like it would end up being a proportional reward method, yes?

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
jtoomim
Hero Member
*****
Offline Offline

Activity: 555


View Profile WWW
February 20, 2015, 04:52:31 AM
 #12137

That sounds like it would end up being a proportional reward method, yes?
I was thinking of it as being PPLNS like the current p2pool, but with the option for a larger number of shares in the LNS window than the 8640 of p2pool. However, the algorithm used to determine the rewards per miner or per share is partially independent of the share tree data structure, so it should be possible to make many different types of p2pool clones with different reward algorithms.

Hosting bitcoin miners for $75 to $90/kW/month on clean, cheap hydro power.
http://Toom.im
jtoomim
Hero Member
*****
Offline Offline

Activity: 555


View Profile WWW
February 20, 2015, 05:04:47 AM
 #12138

Fleshing it out a bit more, you could define the share height H as being the length of the shortest path from the root to a particular share. The PPLNS window could be sized to include all shares with a height greater than (H - X), where X is some arbitrary number roughly corresponding to the N in the LNS system. Shares would be allowed to name any valid share as a direct parent as long as that share was not already an ancestor through any of the other parents, possibly with some arbitrary maximum number of parents hardcoded to reduce the size of the p3pool share data that needs to be incorporated into the blockchain. Or something like that.

My brother passed me this paper as being relevant, but I haven't read it yet. https://eprint.iacr.org/2013/881.pdf

Hosting bitcoin miners for $75 to $90/kW/month on clean, cheap hydro power.
http://Toom.im
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
February 20, 2015, 10:28:51 AM
 #12139

Cross-post from the Spondoolies thread, more relevant here:

centralization incoming Sad

If only everyone used p2pool....... Wink

If everyone did, the share difficulty would be through the roof.  2,222,770,798 if I understand it right..

p2pool is not the answer.

a rewrite perhaps.  but not in its current incarnation.

M

I was thinking about this the other day, actually, and I think I got a good solution to the problem.

p2pool uses a share chain much like the block chain for its reward allocation. This means that if you're mining on a share that isn't the most recent, your work is wasted. The blockchain was designed to solve the timestamping problem for creating a distributed ledger system for transactions, which is why the blockchain has to be serialized. With p2pool, there is no such requirement for timestamping and serializing the shares, so the shares do not necessarily need to be arranged in a chain. The fact that they are was probably mostly just a programming convenience in being able to reuse the bitcoin blockchain data structures. I think a better structure for p3pool shares would be a share tree, where each share references at least one parent share instead of exactly one parent share. That way, work done on shares that would end up marked as stale on the current p2pool (i.e. branching shares) could still be incorporated into the p3pool share tree. Add in a small reward to the miner who found the share for each parent share that's referenced for the first time, and everybody's shares should get incorporated as long as the share is based on the most recent block.

Since miners no longer would need to abandon work immediately when someone on p3pool finds a share, p3pool could target much higher share frequencies, such as 1 per second or faster. This would decrease share variance and allow for small miners to use p2pool effectively, and it would also allow p3pool to grow larger while keeping individual share targets reasonable.
Everyone on p2pool has to have the same shares and agree the same shares are valid.
Thus the share chain exists and is based on the BTC block chain idea.

If you remove the share chain, you have to keep a pool database of shares (yeah something I know quite a bit about Tongue)
You suddenly need a full fledged database that's able to store all the shares required and also ... the biggest issue of all ... ensure that database is the same on EVERY p2pool node ... so how do you do that? Share chain ... Tongue

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

Activity: 1358


View Profile
February 20, 2015, 12:03:17 PM
 #12140

I was thinking about this the other day, actually, and I think I got a good solution to the problem.

p2pool uses a share chain much like the block chain for its reward allocation. This means that if you're mining on a share that isn't the most recent, your work is wasted. The blockchain was designed to solve the timestamping problem for creating a distributed ledger system for transactions, which is why the blockchain has to be serialized. With p2pool, there is no such requirement for timestamping and serializing the shares, so the shares do not necessarily need to be arranged in a chain. The fact that they are was probably mostly just a programming convenience in being able to reuse the bitcoin blockchain data structures. I think a better structure for p3pool shares would be a share tree, where each share references at least one parent share instead of exactly one parent share. That way, work done on shares that would end up marked as stale on the current p2pool (i.e. branching shares) could still be incorporated into the p3pool share tree. Add in a small reward to the miner who found the share for each parent share that's referenced for the first time, and everybody's shares should get incorporated as long as the share is based on the most recent block.

Since miners no longer would need to abandon work immediately when someone on p3pool finds a share, p3pool could target much higher share frequencies, such as 1 per second or faster. This would decrease share variance and allow for small miners to use p2pool effectively, and it would also allow p3pool to grow larger while keeping individual share targets reasonable.

That's similar to my idea, except mine was all current rounds of shares are based on a prior psuedo block, instead of the prior p2pool share.  One huge advantage of the current layout is each node verifies all the prior shares.  That's why each share has to contain the payout info for the p2pool miners, so when the "lucky one" that is a block is found, everyone is paid accordingly.

My idea would mean payouts are based on the last pseudo block, not last shares found.  The work submitted is based upon a "pseudo" block based upon all the shares submitted between the last two BTC blocks.  That "block" would be built in a defined order, ie:

root: last "true" BTC block
share #1: first share (based on timestamp) submitted
share #2: second share (based on timestamp) submitted

and so forth.  If a collision on timestamp is found, them some other logic has to be used to determine the tie breaker.

That way each node can still verify all the prior shares and work is still decentralized.

It also means work is only restarted when a BTC block is found, roughly every 10 mins, instead of every 30 seconds.

There may be a flaw in my theory.

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.
Pages: « 1 ... 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 [607] 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 ... 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!