[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[mdude77]

Well i allways loved cgminer but i switched simply because the other just runs without doing any zadig crap.
It probably depends also on which version of windows your running in my case windows 8 pro x64.

You say : install zadig once and all work....... The hell it does not

It will not install on all usb devices.
You have to freaking add all by hand every freaking device

It simply not install any other then that one device you did, in my case each and every block erupter YES all 12

True after that .. it works flawless with this zadig, unless you want to use a different hardware with it ... like bfl jalapeno

Because indeed i could not get the freaking jala to work with or without zadig at all, cgminer simply refused to find that thing.
Even though it was clearly visible as a FTDI device in windows

And last but not least to get the zadig crap out your kinda busy as well, the only simple solution is delete each and every usb driver which was used with zadig and keep deleting them till the libusb driver is back instead of winusb.
It really turned out to be nastier then i expected, even now some ports still got the winusb installed after several attempts to get rid of them. I have not found one simple solution to remove that winusb driver yet.
The libusb which the zadig tool puts in IS not the one which works flawless with bfgminer

I didn't have such difficulty.  I installed zadig once for one, rebooted, and it's worked great ever since.  When I get a new USB erupter, I plug it in, modify my command line to launch cgminer, and it just works (tm). 

Quite different from my experiences with linux.  I can spend a day trying to get linux to work and fail, or an hour to get windows and succeed.  Easy choice for me.

M

[kano]

lol
I admit tux has some advantages but also has many disadvantages
If i would not have to cope with 5 ladies using winblows software like *cough* ms office *cough* and if games really would run smooth and instant on tux, like they do on winblows i would instant switch over.
This far non of the game industry is willing and able to port their games over to linux.
So i guess thats not gonna happen anytime soon, and i expect that not to happen for at least 10 decades.

Well, I guess if mining reliability and uptime takes a 2nd importance to playing games ... well yeah ... who cares

Get an RPi ~$50+ and it will run linux and mine on all those devices ... and never shutdown at 3am doing windows updates (that you'll have to know how to deal with) ... and not detect cgminer as a virus (that you'll have to know how to deal with) ... and not need buying the OS and updating the hardware (or wiping and reinstalling windows that you'll need to know how to deal with) every couple of years due to windows slowing down to a crawl ...

In my case I simply have all the consoles (for my kids )
Cheaper and more reliable than playing games on windows
(I got sick of having to spend up to $1k every couple of years updating the windows computer ... with a new cheap GPU etc)

I support 6 small companies (I'm their full IT department) and I sure don't run windows on my desktop ... even though every desktop they have I setup as Windows coz that's what they want.
I have a windows VM coz ... some people want to run cgminer on windows ... so I have to be able to test it

[HellDiverUK]

Get an RPi ~$50+ and it will run linux and mine on all those devices ... and never shutdown at 3am doing windows updates (that you'll have to know how to deal with) ... and not detect cgminer as a virus (that you'll have to know how to deal with) ... and not need buying the OS and updating the hardware (or wiping and reinstalling windows that you'll need to know how to deal with) every couple of years due to windows slowing down to a crawl ...

If any of this happens to you, you should definitely stick to Linux, because you suck at running Windows.   

[-ck]

I've completed the rework of the stratum work generation code which was where most of the high CPU usage on p2pool was, and uploaded new firmware with the newly released version 3.3.3 of cgminer:

Updated link, with slightly newer firmware addressing slower speeds on auto:
http://ck.kolivas.org/apps/cgminer/avalon/20130813-1/

[kano]

Get an RPi ~$50+ and it will run linux and mine on all those devices ... and never shutdown at 3am doing windows updates (that you'll have to know how to deal with) ... and not detect cgminer as a virus (that you'll have to know how to deal with) ... and not need buying the OS and updating the hardware (or wiping and reinstalling windows that you'll need to know how to deal with) every couple of years due to windows slowing down to a crawl ...

If any of this happens to you, you should definitely stick to Linux, because you suck at running Windows.   

It will definitely happen to anyone who thinks Zadig is too complex to follow the simple instructions I wrote in the cgminer READMEs

[HellDiverUK]

If you need to read a readme to get it working, it's too complex by default. 

[zvs]

log:2013-08-13 08:54:28.443218  Shares: 1 (0 orphan, 0 dead) Stale rate: ~0.0% (0-80%) Efficiency: ~119.2% (24-120%) Current payout: 0.0156 BTC
log:2013-08-13 08:54:43.445825  Shares: 2 (0 orphan, 1 dead) Stale rate: ~50.0% (9-91%) Efficiency: ~59.6% (11-108%) Current payout: 0.0156 BTC
log:2013-08-13 08:56:13.468986  Shares: 2 (0 orphan, 1 dead) Stale rate: ~50.0% (9-91%) Efficiency: ~59.6% (11-108%) Current payout: 0.0156 BTC
log:2013-08-13 08:56:28.472261  Shares: 2 (0 orphan, 2 dead) Stale rate: ~100.0% (34-100%) Efficiency: ~0.0% (0-78%) Current payout: 0.0156 BTC

......

I'm curious as to how something like that happens?  Essentially some share from 2 minutes earlier was moved from OK to DOA?  It initially reported it as DOA, too.  (i'll refrain from posting more, the log is at www.nogleg.com/log)

Also, is there some setting I have messed up where it doesn't work properly with ASICs, or?  (re 3 out of 4 DOA)

(ed: I guess from looking at the graph it could have just been bad luck, looks like about 13% DOA)

oh, I'm also testing something at nogleg.net:9332 that may be faster (the blocksize is just at 1000 temporarily)

[centove]

While chasing some other unrelated issue I found the following nodes haven't bothered upgrading yet:

Code:

107.23.239.94
108.23.226.104
118.208.155.250
118.208.3.142
128.250.61.122
128.84.98.23
132.187.207.113
178.208.137.77
178.219.102.86
184.185.89.116
195.162.48.78
198.144.178.100
198.211.112.91
199.21.86.50
202.60.68.242
213.112.114.73
218.104.84.203
222.83.251.105
46.170.233.26
46.23.72.52
47.67.129.61
58.210.65.114
59.167.237.19
63.246.129.56
69.47.57.170
76.117.124.58
79.140.64.11
86.50.113.159
87.244.203.17
88.190.229.196
88.190.60.96
91.127.111.209

Magical incantation to produce said list:

Code:

data/bitcoin$ grep peer log | grep "p2pool version: 1100"  | awk '{print $7}' | cut -d ':' -f1 | sort | uniq

[Krak]

If you need to read a readme to get it working, it's too complex by default.  

According to that logic, p2pool and pretty much every other piece of mining software (except maybe BitMinter) are too complex. Cgminer is extremely easy to figure out even with the readmes.

[TierNolan]

Is there any documentation explaining exactly how the system works?

How is initial chain syncing accomplished?

Only 1 day is kept, so how does a new peer distinguish which is the correct sharechain, since it can't trace back to genesis?

Mining a sharechain that dies means that you share any winnings, but then there are no later winners to share back with you.

Is there persistence for the sharechain?

Does restart the p2pool daemon mean it has to re-acquire the sharechain from scratch?

What are "heads" and "tails" (and what are "verified heads" and "verified tails")?

Why is the difficulty of the sharechain not linked directly to the main chain's difficulty?

Related to that is why not just keep 24 hours worth of main chain blocks?

[Krak]

Is there any documentation explaining exactly how the system works?

How is initial chain syncing accomplished?

Only 1 day is kept, so how does a new peer distinguish which is the correct sharechain, since it can't trace back to genesis?

Mining a sharechain that dies means that you share any winnings, but then there are no later winners to share back with you.

Is there persistence for the sharechain?

Does restart the p2pool daemon mean it has to re-acquire the sharechain from scratch?

What are "heads" and "tails" (and what are "verified heads" and "verified tails")?

Why is the difficulty of the sharechain not linked directly to the main chain's difficulty?

Related to that is why not just keep 24 hours worth of main chain blocks?

This link should answer most of your questions. There's an error on the wiki though; the share chain difficulty is adjusted so that a share is found every 30 seconds now, not 10 seconds (for ASIC compatibility).

[TierNolan]

This link should answer most of your questions. There's an error on the wiki though; the share chain difficulty is adjusted so that a share is found every 30 seconds now, not 10 seconds (for ASIC compatibility).

I was looking for a little more info than that, but thanks for the link.

How is initial chain syncing accomplished?

I think this has to do with the verification system.  Shares are compared to main chain blocks somehow?

What happens during the period until initial verification?

From what I can see, the node effectively solo mines, until it is sure that the sharechain is valid.

I think explaining "verified" heads and tails (what are heads and tails?) would give the info.

[forrestv]

How is initial chain syncing accomplished?

Nodes download the most recent portion of the sharechain from their peers.

Only 1 day is kept, so how does a new peer distinguish which is the correct sharechain, since it can't trace back to genesis?

From the wiki:

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 shares (the last day's worth). In order to prevent an attacker from working on a chain in secret and then releasing it, overriding the existing chain, chains are judged by how much work they have since a point in the past. To ascertain that the work has been done since that point, nodes look at the Bitcoin blocks that the shares reference, establishing a provable timestamp. (If a share points to a block, it was definitely made after that block was made.)

Mining a sharechain that dies means that you share any winnings, but then there are no later winners to share back with you.

Is there persistence for the sharechain?

Does restart the p2pool daemon mean it has to re-acquire the sharechain from scratch?

Yes, you're mining on the assumption that the pool is not going to disappear while your shares are valid. I'm not sure exactly what you mean with the second question, but the sharechain is persisted to disk, so when you restart your node, it only has to download shares since it was stopped.

What are "heads" and "tails" (and what are "verified heads" and "verified tails")?

Why is the difficulty of the sharechain not linked directly to the main chain's difficulty?

Related to that is why not just keep 24 hours worth of main chain blocks?

"Heads" are shares without child shares (leaves of a tree structure). "Tails" are shares without their parent present (roots of a tree structure). The difficulty of the sharechain is unlinked so it can go as fast as possible, which we've empirically determined to be something like 20 to 30 seconds. Keeping 24 hours worth of main chain blocks would require storing an unbounded number of shares in memory, which is a bad idea.

[Mobius]

Trying p2pool , running for 1 hour . I will add more devices if I can successfully configure my desktop to do so.

* Windows 7 Ultimate
* 8 Gigs of RAM
* Quadcore CPU
* What is wrong here ?
* What do I add to bitcoin conf file ?
* No incoming connections ?
* Only 6 peers ?

May I please request some feedback from forum members to help me.

Code:

 cgminer version 2.11.0 - Started: [2013-08-14 11:26:24]
--------------------------------------------------------------------------------
 (5s):2.410G (avg):2.289Gh/s | Q:159  A:14  R:0  HW:15  E:9%  U:0.3/m
 ST: 2  SS: 0  DW: 298  NB: 47  LW: 3778  GF: 4  RF: 0  WU: 33.9
 Connected to 127.0.0.1 diff 96 with stratum as user Polyatomic/+96
 Block: 0014d6fba674e7c9...  Diff:50.8M  Started: [12:03:17]  Best share: 1.88K
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 364.2M/351.5Mh/s | A:2 R:0 HW:6 U:0.04/m
 ICA 1:                | 358.9M/346.4Mh/s | A:2 R:0 HW:0 U:0.04/m
 ICA 2:                | 419.1M/403.4Mh/s | A:0 R:0 HW:2 U:0.00/m
 ICA 3:                | 420.1M/403.6Mh/s | A:4 R:0 HW:1 U:0.08/m
 ICA 4:                | 402.6M/394.2Mh/s | A:3 R:0 HW:2 U:0.06/m
 ICA 5:                | 401.6M/390.4Mh/s | A:3 R:0 HW:4 U:0.06/m
--------------------------------------------------------------------------------

 [2013-08-14 12:11:08] Stratum from pool 0 requested work restart
 [2013-08-14 12:11:34] Stratum from pool 0 requested work restart
 [2013-08-14 12:11:45] Stratum from pool 0 requested work restart
 [2013-08-14 12:12:07] Stratum from pool 0 requested work restart
 [2013-08-14 12:12:53] Accepted 01444329 Diff 202/96 ICA 3
 [2013-08-14 12:12:56] Stratum from pool 0 requested work restart
 [2013-08-14 12:13:28] Stratum from pool 0 requested work restart
 [2013-08-14 12:13:54] Stratum from pool 0 requested work restart
 [2013-08-14 12:14:21] Stratum from pool 0 requested work restart
 [2013-08-14 12:14:45] Stratum from pool 0 requested work restart
 [2013-08-14 12:15:04] Stratum from pool 0 requested work restart
 [2013-08-14 12:15:40] Icarus 3 Re-estimate: Hs=2.371480e-009 W=8.729913e-003 re
ad_count=100 fullnonce=10.194s
 [2013-08-14 12:15:43] Stratum from pool 0 requested work restart
 [2013-08-14 12:15:49] Stratum from pool 0 requested work restart
 [2013-08-14 12:16:07] Stratum from pool 0 requested work restart
 [2013-08-14 12:16:46] Accepted 017e145f Diff 171/96 ICA 0
 [2013-08-14 12:16:59] Stratum from pool 0 requested work restart
 [2013-08-14 12:17:13] Stratum from pool 0 requested work restart
 [2013-08-14 12:17:17] Stratum from pool 0 requested work restart
 [2013-08-14 12:17:21] Stratum from pool 0 requested work restart

Try taking the /+96 off your miner's name

[yxxyun]

Trying p2pool , running for 1 hour . I will add more devices if I can successfully configure my desktop to do so.

* Windows 7 Ultimate
* 8 Gigs of RAM
* Quadcore CPU
* What is wrong here ?
* What do I add to bitcoin conf file ?
* No incoming connections ?
* Only 6 peers ?

May I please request some feedback from forum members to help me.

Code:

 cgminer version 2.11.0 - Started: [2013-08-14 11:26:24]
--------------------------------------------------------------------------------
 (5s):2.410G (avg):2.289Gh/s | Q:159  A:14  R:0  HW:15  E:9%  U:0.3/m
 ST: 2  SS: 0  DW: 298  NB: 47  LW: 3778  GF: 4  RF: 0  WU: 33.9
 Connected to 127.0.0.1 diff 96 with stratum as user Polyatomic/+96
 Block: 0014d6fba674e7c9...  Diff:50.8M  Started: [12:03:17]  Best share: 1.88K
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 364.2M/351.5Mh/s | A:2 R:0 HW:6 U:0.04/m
 ICA 1:                | 358.9M/346.4Mh/s | A:2 R:0 HW:0 U:0.04/m
 ICA 2:                | 419.1M/403.4Mh/s | A:0 R:0 HW:2 U:0.00/m
 ICA 3:                | 420.1M/403.6Mh/s | A:4 R:0 HW:1 U:0.08/m
 ICA 4:                | 402.6M/394.2Mh/s | A:3 R:0 HW:2 U:0.06/m
 ICA 5:                | 401.6M/390.4Mh/s | A:3 R:0 HW:4 U:0.06/m
--------------------------------------------------------------------------------

 [2013-08-14 12:11:08] Stratum from pool 0 requested work restart
 [2013-08-14 12:11:34] Stratum from pool 0 requested work restart
 [2013-08-14 12:11:45] Stratum from pool 0 requested work restart
 [2013-08-14 12:12:07] Stratum from pool 0 requested work restart
 [2013-08-14 12:12:53] Accepted 01444329 Diff 202/96 ICA 3
 [2013-08-14 12:12:56] Stratum from pool 0 requested work restart
 [2013-08-14 12:13:28] Stratum from pool 0 requested work restart
 [2013-08-14 12:13:54] Stratum from pool 0 requested work restart
 [2013-08-14 12:14:21] Stratum from pool 0 requested work restart
 [2013-08-14 12:14:45] Stratum from pool 0 requested work restart
 [2013-08-14 12:15:04] Stratum from pool 0 requested work restart
 [2013-08-14 12:15:40] Icarus 3 Re-estimate: Hs=2.371480e-009 W=8.729913e-003 re
ad_count=100 fullnonce=10.194s
 [2013-08-14 12:15:43] Stratum from pool 0 requested work restart
 [2013-08-14 12:15:49] Stratum from pool 0 requested work restart
 [2013-08-14 12:16:07] Stratum from pool 0 requested work restart
 [2013-08-14 12:16:46] Accepted 017e145f Diff 171/96 ICA 0
 [2013-08-14 12:16:59] Stratum from pool 0 requested work restart
 [2013-08-14 12:17:13] Stratum from pool 0 requested work restart
 [2013-08-14 12:17:17] Stratum from pool 0 requested work restart
 [2013-08-14 12:17:21] Stratum from pool 0 requested work restart

Try taking the /+96 off your miner's name

change the 96 to 4

[kano]

Except, +96 wont make any difference to the shares found - just the fake shares found that don't count for anything.
(and +96 vs +4 will reduce the network usage by not bothering to send 24 times as many useless shares )
So that change will be just window dressing

[HellDiverUK]

I keep getting this spamming my p2pool node's terminal window.  Happens every 3-5 seconds:

Code:

2013-08-14 08:55:53.386000 >   File "p2pool\util\deferred_resource.pyc", line 24
, in render
2013-08-14 08:55:53.387000 >
2013-08-14 08:55:53.388000 >   File "twisted\internet\defer.pyc", line 134, in m
aybeDeferred
2013-08-14 08:55:53.389000 >
2013-08-14 08:55:53.390000 >   File "twisted\web\resource.pyc", line 216, in ren
der
2013-08-14 08:55:53.391000 >
2013-08-14 08:55:53.392000 >   File "twisted\internet\defer.pyc", line 1187, in
unwindGenerator
2013-08-14 08:55:53.393000 >
2013-08-14 08:55:53.393000 > --- <exception caught here> ---
2013-08-14 08:55:53.393000 >   File "twisted\internet\defer.pyc", line 1045, in
_inlineCallbacks
2013-08-14 08:55:53.394000 >
2013-08-14 08:55:53.395000 >   File "p2pool\web.pyc", line 186, in render_GET
2013-08-14 08:55:53.395000 >
2013-08-14 08:55:53.395000 >   File "p2pool\web.pyc", line 446, in <lambda>
2013-08-14 08:55:53.396000 >
2013-08-14 08:55:53.396000 > exceptions.KeyError: 'last_'

Everything seems to work OK, but I don't know what this error means.  Only started yesterday.

[kano]

Try a version of cgminer from this decade, too. 

He can't, he has Cairnsmore1's and I've not got one to make a proper USB driver for them ... though he probably could update to 3.1.1

I wrote the necessary Cairnsmore1 code for the Icarus driver before, that he is using (for no real reason actually and Yohan never gave a damn about that either) but to do it in USB will require the hardware.
They've used an 8 endpoint chip (unlike any other device has used) so I'd need the hardware to get the code right and do a new type of driver for that.

Also, supporting it is a right PITA when I don't have the hardware myself coz I can't ever see if I've managed to screw it up every time I make a related change elsewhere.

At the moment, ckolivas has an Avalon, and I have a BitBurner, so that means we have to get the other to test related changes each time.
Not a big deal, but at least we have incentive (having each our selves) and it's easy to get the other to test changes that we do for our own hardware.

... and I'm not really all that interested in spending all the time necessary to do that with no reason at all for me to do it either.

We've had this problem twice already with the ztex, nelisky dropped doing support and it fell by the wayside, then dennisx took it over.
However he's not been around at all recently when people have asked about possible problems, enhancements or help with it.

[HellDiverUK]

Got to love the bleeding edge that is bitcoin mining.   

[TierNolan]

From the wiki:

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 shares (the last day's worth). In order to prevent an attacker from working on a chain in secret and then releasing it, overriding the existing chain, chains are judged by how much work they have since a point in the past. To ascertain that the work has been done since that point, nodes look at the Bitcoin blocks that the shares reference, establishing a provable timestamp. (If a share points to a block, it was definitely made after that block was made.)

What is the "point in the past"?

When the pool finds a block, it adds a marker into the bitcoin chain?

Yes, you're mining on the assumption that the pool is not going to disappear while your shares are valid. I'm not sure exactly what you mean with the second question, but the sharechain is persisted to disk, so when you restart your node, it only has to download shares since it was stopped.

I was thinking about what would happen if you mined on the wrong chain.  

Does the pool immediately mine on the sharechain or wait until a few bitcoin blocks have passed?

In fact, what makes a head/tail "verified"?