Bitcoin Forum>Bitcoin>Mining>Pools
Pages:
Author

Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 520. (Read 2591928 times)

notme
legendary
Activity: 1904
Merit: 1002
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 28, 2013, 03:13:06 AM
#5893
Quote from: lenny_ on June 27, 2013, 07:08:38 PM
Block Erupter Blade support for p2pool - Bounty
Current bounty: 5 BTC

I would like to make ASIC Block Erupter Blades 13GH/s working with p2pool. ASICs support for p2pool is very important for p2pool survival.
I am giving 5 BTC bounty for developer who will make them working on p2pool. Bounty will be paid to developer or split between group of developers who will contribute to solving the problem.
If you guys have BE Blades too, please let me know. I can arrange escrow via John K. (or I can collect funds directly, I am trusted forum member, please check my OTC), once we gather more funds maybe one of our developers will be interested to look closer to this problem.
I myself can donate my Blade worktime for a developer to make debug and testing, please let me know.
PM me if you a developer and you would like to get access to my BE Blade and to my Linux server for debug purposes. Please help:)
PM me if you a BE Blade user and you d'love to see your blades hashing on p2pool to - let's gather more BTC for our honest developers.

Regards
Lenny


Have you tried it?  What kind of stats are you getting?

I'm running 10 AM USB sticks on p2pool and getting over 100% efficiency.
baloo_kiev
sr. member
Activity: 476
Merit: 250
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 28, 2013, 03:12:56 AM
#5892
Quote from: lenny_ on June 27, 2013, 07:08:38 PM
Block Erupter Blade support for p2pool - Bounty
Current bounty: 5 BTC

I would like to make ASIC Block Erupter Blades 13GH/s working with p2pool. ASICs support for p2pool is very important for p2pool survival.
I am giving 5 BTC bounty for developer who will make them working on p2pool. Bounty will be paid to developer or split between group of developers who will contribute to solving the problem.
If you guys have BE Blades too, please let me know. I can arrange escrow via John K. (or I can collect funds directly, I am trusted forum member, please check my OTC), once we gather more funds maybe one of our developers will be interested to look closer to this problem.
I myself can donate my Blade worktime for a developer to make debug and testing, please let me know.
PM me if you a developer and you would like to get access to my BE Blade and to my Linux server for debug purposes. Please help:)
PM me if you a BE Blade user and you d'love to see your blades hashing on p2pool to - let's gather more BTC for our honest developers.

Regards
Lenny


Could you please run it with direct getwork connection (without stratum proxy) for a couple of minutes and log tcp data. When mining run
Code:
sudo tcpdump -X -i any '(tcp port xxxx)' | tee tcpdump.log
where xxxx is your getwork port and post the log along with p2pool and miner log (if any). I'll take a look.

P.S. And essentially run p2pool with "--debug".
yxxyun
member
Activity: 99
Merit: 10
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 28, 2013, 01:19:08 AM
#5891
hope p2pool can support asic asap, p2pool need at least 1000Gh/s to mine a block in 1 day.
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 27, 2013, 08:45:21 PM
#5890
Quote from: lenny_ on June 27, 2013, 08:15:10 PM
Quote from: mdude77 on June 27, 2013, 07:21:28 PM
I'm a low end miner.  I'm also a windows developer ... linux makes me cringe.  

I wish I had the BTC to throw at getting a Blade.  But since I don't, I'll speculate.

I'm guessing the blade has its own built in miner, as opposed to using outside software?  I have a number of the erupter USB miners, and they all work great with cgminer in p2pool.  You say it needs a proxy, so that tells me it uses getwork instead of stratum?  Connecting straight to p2pool with getwork is a no go?

M

Yes. Connecting blade directly to p2pool results with thousands of warnings about wrong target:
Code:
Worker lenny_beblade submitted share with hash > target
Blade has it's own getwork unit. It can work on any central getwork pool and it's fine (apart from low efficiency). It can work with stratum mining proxy and it gets 99.5% efficiency (perfect combination) with central pool - on p2pool stratum proxy just won't work, with forrestv custom patch (a few pages earlier he published it) stratum proxy works fine (with cgminer or something), but still not with blade and p2pool on it.

Please guys also look at this errors about wrong merkle root:
Code:
2013-06-28 02:22:01.148992 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:01.149250     Hash:   665b7763d51f4f84b6d5a259b37acd744d6ec447bb329ee4fc97688aa9942a50
2013-06-28 02:22:01.149304     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:01.165738 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:01.165908     Hash:   e2c29d86997fa50648d2a2353ed96be17de9877abc206fc67baf7eca83bb06c8
2013-06-28 02:22:01.166017     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:01.196100 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:01.196313     Hash:   7bbccad7cd1068e8becb3db79e01d7d17f5b074aab175aacb56b4c1d9c8056c2
2013-06-28 02:22:01.196434     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:01.476883 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:01.477081     Hash:   b83f2e8d2cfa7319262c6aa2a8a9bc173b8e91de9513700286a2672a1c3a5575
2013-06-28 02:22:01.477236     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:01.493513 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:01.493689     Hash:   99fa634b06c7bb21eacec9e3ed10b5c312f4f385e3eed0869724091332d9644a
2013-06-28 02:22:01.493825     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:01.884136 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:01.884311     Hash:   c546a56767c24fe623ad2665c0d3bdb5a91f6d9b8977acaa588f569b0ecf1a38
2013-06-28 02:22:01.884400     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:02.343771 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
2013-06-28 02:22:02.527949 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:02.528119     Hash:   1a4576578c52767fe7130a35da71f05bf484d92b5c8f9b051ccd8c518d18083f
2013-06-28 02:22:02.528218     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:02.539340 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:02.539512     Hash:   adbcd9963a1e8b56a70795ece21eea08eb2fc2951c2f4f78e206dd67b82699cb
2013-06-28 02:22:02.539624     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:02.643953 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
2013-06-28 02:22:02.974312 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:02.974498     Hash:   ac848b7d8fa836b55d6e79d77bb4154c9c436d8b03f632d34f4b29c1acda5ff7
2013-06-28 02:22:02.974586     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:03.240763 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:03.240947     Hash:   cc5ee4e44b246b84a779a36fd7c5f0998ad450be220579ac655074e9a7e53c17
2013-06-28 02:22:03.241090     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:03.947524 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:03.947621     Hash:   86c5a5be9a25e7061d36f1d39d5e517cc507df6ece9eec87dedbfadca378e3b0
2013-06-28 02:22:03.947656     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:04.089961 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:04.090159     Hash:   53010ff6add781a34213abbf1ed3f262a7ac0199be5df16d03740f8ba2c0fa1a
2013-06-28 02:22:04.090281     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:04.101460 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:04.101637     Hash:   5252d5527e60c453533746f5d9cac8a02c5b1b8db36d147cb7553bbfb77a72da
2013-06-28 02:22:04.101742     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:04.487944 P2Pool: 17417 shares in chain (9364 verified/17421 total) Peers: 6 (0 incoming)
2013-06-28 02:22:04.488042  Local: 0H/s in last 10.0 minutes Local dead on arrival: ??? Expected time to share: ???
2013-06-28 02:22:04.488091  Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: 0.0000 BTC
Blade itself is mining happily, but p2pool won't recognize it's efforts:
Code:
Total MHS:	12581
Received:	0000000992
Accepted:	0000001045
Per Minute:	175.63
Efficiency:	105.34%
Up Time:	0d,00h,05m,57s

Current Server: 192.168.1.50:9332
Clock selected: High
Code:
Version: 11.4-14-g4d7a946

Pool rate: 554GH/s (17% DOA+orphan) Share difficulty: 1020

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

Local rate: 0.00H/s (NaN% DOA) Expected time to share: NaN hours

Shares: 0 total (0 orphaned, 0 dead) Efficiency: ???
I am using newshare branch.
Code:
Linux 3.2.0-4-amd64 x86_64 GNU/Linux
Description:	Debian GNU/Linux 7.1 (wheezy)
Python 2.7.3
Current p2pool version: 11.4-8-gec66318

I have a couple (or one, maybe, with diff addresses) of people with Avalons (I think, 60ghash or so) that have my pool as a secondary or tertiary....  and I see a lot of ^^ that in the log file... but about 50% of their stuff comes through fine.  You're getting 100% DOA?

ed: actually on second thought, it never says target: fffffffffffffffffffffffffffffffff   i don't believe.  so it's not even acquiring the work, or ?

yeah, it's never identifying your worker
lenny_
legendary
Activity: 1036
Merit: 1000
DARKNETMARKETS.COM
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 27, 2013, 08:15:10 PM
#5889
Quote from: mdude77 on June 27, 2013, 07:21:28 PM
I'm a low end miner.  I'm also a windows developer ... linux makes me cringe.  

I wish I had the BTC to throw at getting a Blade.  But since I don't, I'll speculate.

I'm guessing the blade has its own built in miner, as opposed to using outside software?  I have a number of the erupter USB miners, and they all work great with cgminer in p2pool.  You say it needs a proxy, so that tells me it uses getwork instead of stratum?  Connecting straight to p2pool with getwork is a no go?

M

Yes. Connecting blade directly to p2pool results with thousands of warnings about wrong target:
Code:
Worker lenny_beblade submitted share with hash > target
Blade has it's own getwork unit. It can work on any central getwork pool and it's fine (apart from low efficiency). It can work with stratum mining proxy and it gets 99.5% efficiency (perfect combination) with central pool - on p2pool stratum proxy just won't work, with forrestv custom patch (a few pages earlier he published it) stratum proxy works fine (with cgminer or something), but still not with blade and p2pool on it.

Please guys also look at this errors about wrong merkle root:
Code:
2013-06-28 02:22:01.148992 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:01.149250     Hash:   665b7763d51f4f84b6d5a259b37acd744d6ec447bb329ee4fc97688aa9942a50
2013-06-28 02:22:01.149304     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:01.165738 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:01.165908     Hash:   e2c29d86997fa50648d2a2353ed96be17de9877abc206fc67baf7eca83bb06c8
2013-06-28 02:22:01.166017     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:01.196100 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:01.196313     Hash:   7bbccad7cd1068e8becb3db79e01d7d17f5b074aab175aacb56b4c1d9c8056c2
2013-06-28 02:22:01.196434     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:01.476883 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:01.477081     Hash:   b83f2e8d2cfa7319262c6aa2a8a9bc173b8e91de9513700286a2672a1c3a5575
2013-06-28 02:22:01.477236     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:01.493513 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:01.493689     Hash:   99fa634b06c7bb21eacec9e3ed10b5c312f4f385e3eed0869724091332d9644a
2013-06-28 02:22:01.493825     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:01.884136 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:01.884311     Hash:   c546a56767c24fe623ad2665c0d3bdb5a91f6d9b8977acaa588f569b0ecf1a38
2013-06-28 02:22:01.884400     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:02.343771 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
2013-06-28 02:22:02.527949 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:02.528119     Hash:   1a4576578c52767fe7130a35da71f05bf484d92b5c8f9b051ccd8c518d18083f
2013-06-28 02:22:02.528218     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:02.539340 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:02.539512     Hash:   adbcd9963a1e8b56a70795ece21eea08eb2fc2951c2f4f78e206dd67b82699cb
2013-06-28 02:22:02.539624     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:02.643953 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
2013-06-28 02:22:02.974312 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:02.974498     Hash:   ac848b7d8fa836b55d6e79d77bb4154c9c436d8b03f632d34f4b29c1acda5ff7
2013-06-28 02:22:02.974586     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:03.240763 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:03.240947     Hash:   cc5ee4e44b246b84a779a36fd7c5f0998ad450be220579ac655074e9a7e53c17
2013-06-28 02:22:03.241090     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:03.947524 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:03.947621     Hash:   86c5a5be9a25e7061d36f1d39d5e517cc507df6ece9eec87dedbfadca378e3b0
2013-06-28 02:22:03.947656     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:04.089961 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:04.090159     Hash:   53010ff6add781a34213abbf1ed3f262a7ac0199be5df16d03740f8ba2c0fa1a
2013-06-28 02:22:04.090281     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:04.101460 Worker lenny_beblade submitted share with hash > target:
2013-06-28 02:22:04.101637     Hash:   5252d5527e60c453533746f5d9cac8a02c5b1b8db36d147cb7553bbfb77a72da
2013-06-28 02:22:04.101742     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 02:22:04.487944 P2Pool: 17417 shares in chain (9364 verified/17421 total) Peers: 6 (0 incoming)
2013-06-28 02:22:04.488042  Local: 0H/s in last 10.0 minutes Local dead on arrival: ??? Expected time to share: ???
2013-06-28 02:22:04.488091  Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: 0.0000 BTC
Blade itself is mining happily, but p2pool won't recognize it's efforts:
Code:
Total MHS:	12581
Received:	0000000992
Accepted:	0000001045
Per Minute:	175.63
Efficiency:	105.34%
Up Time:	0d,00h,05m,57s

Current Server: 192.168.1.50:9332
Clock selected: High
Code:
Version: 11.4-14-g4d7a946

Pool rate: 554GH/s (17% DOA+orphan) Share difficulty: 1020

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

Local rate: 0.00H/s (NaN% DOA) Expected time to share: NaN hours

Shares: 0 total (0 orphaned, 0 dead) Efficiency: ???
I am using newshare branch.
Code:
Linux 3.2.0-4-amd64 x86_64 GNU/Linux
Description:	Debian GNU/Linux 7.1 (wheezy)
Python 2.7.3
Current p2pool version: 11.4-8-gec66318
GrapeApe
sr. member
Activity: 476
Merit: 250
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 27, 2013, 07:54:12 PM
#5888
Quote from: zvs on June 27, 2013, 06:32:08 PM
Quote from: baloo_kiev on June 27, 2013, 06:19:46 PM
It would be nice if forrestv commented on this!

This is what I see after looking into the code. If a share C is based on a stale block (usually shortly after a block was found), it gets "punished" and nodes start working on top of its parent share P, so C is forced to orphan. However, if a node does not follow this rule (may be a result of code modification or high bitcoind latency), it works on top of C (while others are working on P!) and may eventually find a share, "save" C from orphanage and (easily since it is 1 share ahead by total work!) orphan all P's children found before it. Looks like a bug to me.

Yeah, that is exactly what I think is happening.  I think it's the result of latency (internet) + bitcoind getblocktemplate latency.  It doesn't help that some of the highest hash power miners on p2pool seem to be behind firewalls & are on slow connections/machines.  Miner X finds a share, say, 1-3 seconds after a new block, Miner X's client thinks it is a legit share and passes it around, some of the other p2pool nodes relay it as legit....  another share is then built off of that one, and then that's it for anyone that (ed: has found a share off of) the parent of the 'punished' share...  the two shares > one share, so everyone switches over.

I didn't keep my old logs, but I've had a few times where I've found a share, gotten a new work (not just from the sleep time deferral, +1 to verified shares, etc), then the next work, it'll become an orphan... so then that means that some other nodes had some 3 share chain vs the 2 share chain.  The 3rd share on that chain might not even necessarily be from a slow node..

This is exactly what we were talking about a few days a go. Someone suggested that your bitcoin was behind your p2pool, but that wouldn’t explain why 50% of your orphans are attributed to the same address. It seems to me that some p2pool nodes (large ones) are far behind bitcoin and those of us that are not are punished when the above scenario happens.

edit: It would be nice to here from forrestv about this. There is a new p2pool branch in his github called new share I wonder if it has a fix for this. https://github.com/forrestv/p2pool/tree/newshare
mdude77
legendary
Activity: 1540
Merit: 1001
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 27, 2013, 07:21:28 PM
#5887
Quote from: lenny_ on June 27, 2013, 07:08:38 PM
Block Erupter Blade support for p2pool - Bounty
Current bounty: 5 BTC

I would like to make ASIC Block Erupter Blades 13GH/s working with p2pool. ASICs support for p2pool is very important for p2pool survival.
I am giving 5 BTC bounty for developer who will make them working on p2pool. Bounty will be paid to developer or split between group of developers who will contribute to solving the problem.
If you guys have BE Blades too, please let me know. I can arrange escrow via John K. (or I can collect funds directly, I am trusted forum member, please check my OTC), once we gather more funds maybe one of our developers will be interested to look closer to this problem.
I myself can donate my Blade worktime for a developer to make debug and testing, please let me know.
PM me if you a developer and you would like to get access to my BE Blade and to my Linux server for debug purposes. Please help:)
PM me if you a BE Blade user and you d'love to see your blades hashing on p2pool to - let's gather more BTC for our honest developers.

Regards
Lenny

I'm a low end miner.  I'm also a windows developer ... linux makes me cringe. 

I wish I had the BTC to throw at getting a Blade.  But since I don't, I'll speculate.

I'm guessing the blade has its own built in miner, as opposed to using outside software?  I have a number of the erupter USB miners, and they all work great with cgminer in p2pool.  You say it needs a proxy, so that tells me it uses getwork instead of stratum?  Connecting straight to p2pool with getwork is a no go?

M
lenny_
legendary
Activity: 1036
Merit: 1000
DARKNETMARKETS.COM
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 27, 2013, 07:08:38 PM
#5886
Block Erupter Blade support for p2pool - Bounty
Current bounty: 5 BTC

I would like to make ASIC Block Erupter Blades 13GH/s working with p2pool. ASICs support for p2pool is very important for p2pool survival.
I am giving 5 BTC bounty for developer who will make them working on p2pool. Bounty will be paid to developer or split between group of developers who will contribute to solving the problem.
If you guys have BE Blades too, please let me know. I can arrange escrow via John K. (or I can collect funds directly, I am trusted forum member, please check my OTC), once we gather more funds maybe one of our developers will be interested to look closer to this problem.
I myself can donate my Blade worktime for a developer to make debug and testing, please let me know.
PM me if you a developer and you would like to get access to my BE Blade and to my Linux server for debug purposes. Please help:)
PM me if you a BE Blade user and you d'love to see your blades hashing on p2pool to - let's gather more BTC for our honest developers.

Regards
Lenny
lenny_
legendary
Activity: 1036
Merit: 1000
DARKNETMARKETS.COM
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 27, 2013, 06:55:01 PM
#5885
Problem 1.
branch newshare is not accepting username with "+" or "/", I tried "lenny+10" for example
Error caught here:
Code:
2013-06-28 00:46:15.688125 > Unhandled Error
2013-06-28 00:46:15.688275 > Traceback (most recent call last):
2013-06-28 00:46:15.688350 >   File "run_p2pool.py", line 5, in 
2013-06-28 00:46:15.688463 >     main.run()
2013-06-28 00:46:15.688543 >   File "/home/pioruns/p2pool-newshare/p2pool/p2pool/main.py", line 576, in run
2013-06-28 00:46:15.688620 >     reactor.run()
2013-06-28 00:46:15.688691 >   File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/base.py", line 1192, in run
2013-06-28 00:46:15.688765 >     self.mainLoop()
2013-06-28 00:46:15.688839 >   File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/base.py", line 1201, in mainLoop
2013-06-28 00:46:15.688928 >     self.runUntilCurrent()
2013-06-28 00:46:15.689000 > ---  ---
2013-06-28 00:46:15.689081 >   File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/base.py", line 824, in runUntilCurrent
2013-06-28 00:46:15.689184 >     call.func(*call.args, **call.kw)
2013-06-28 00:46:15.689260 >   File "/home/pioruns/p2pool-newshare/p2pool/p2pool/bitcoin/stratum.py", line 35, in _send_work
2013-06-28 00:46:15.689334 >     x, got_response = self.wb.get_work(*self.wb.preprocess_request('' if self.username is None else self.username))
2013-06-28 00:46:15.689406 >   File "/home/pioruns/p2pool-newshare/p2pool/p2pool/work.py", line 169, in preprocess_request
2013-06-28 00:46:15.689477 >     user, pubkey_hash, desired_share_target, desired_pseudoshare_target = self.get_user_details(user)
2013-06-28 00:46:15.689552 >   File "/home/pioruns/p2pool-newshare/p2pool/p2pool/work.py", line 140, in get_user_details
2013-06-28 00:46:15.689624 >     assert len(contents) % 2 == 1
2013-06-28 00:46:15.689698 > exceptions.AssertionError: 
2013-06-28 00:46:15.690074 > Unhandled Error
2013-06-28 00:46:15.690167 > Traceback (most recent call last):
2013-06-28 00:46:15.690242 >   File "run_p2pool.py", line 5, in 
2013-06-28 00:46:15.690314 >     main.run()
2013-06-28 00:46:15.690384 >   File "/home/pioruns/p2pool-newshare/p2pool/p2pool/main.py", line 576, in run
2013-06-28 00:46:15.690456 >     reactor.run()
2013-06-28 00:46:15.690529 >   File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/base.py", line 1192, in run
2013-06-28 00:46:15.690605 >     self.mainLoop()
2013-06-28 00:46:15.690677 >   File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/base.py", line 1201, in mainLoop
2013-06-28 00:46:15.690771 >     self.runUntilCurrent()
2013-06-28 00:46:15.690839 > ---  ---
2013-06-28 00:46:15.690910 >   File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/base.py", line 824, in runUntilCurrent
2013-06-28 00:46:15.690986 >     call.func(*call.args, **call.kw)
2013-06-28 00:46:15.691058 >   File "/home/pioruns/p2pool-newshare/p2pool/p2pool/bitcoin/stratum.py", line 35, in _send_work
2013-06-28 00:46:15.691129 >     x, got_response = self.wb.get_work(*self.wb.preprocess_request('' if self.username is None else self.username))
2013-06-28 00:46:15.691204 >   File "/home/pioruns/p2pool-newshare/p2pool/p2pool/work.py", line 169, in preprocess_request
2013-06-28 00:46:15.691279 >     user, pubkey_hash, desired_share_target, desired_pseudoshare_target = self.get_user_details(user)
2013-06-28 00:46:15.691350 >   File "/home/pioruns/p2pool-newshare/p2pool/p2pool/work.py", line 140, in get_user_details
2013-06-28 00:46:15.691421 >     assert len(contents) % 2 == 1
2013-06-28 00:46:15.691495 > exceptions.AssertionError:
Same on standard, default branch of p2pool BTC:
Code:
2013-06-28 02:35:28.349535 > Squelched JSON error:
2013-06-28 02:35:28.349708 > Traceback (most recent call last):
2013-06-28 02:35:28.349816 >   File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1070, in _inlineCallbacks
2013-06-28 02:35:28.349905 >     result = g.send(result)
2013-06-28 02:35:28.349995 >   File "/home/pioruns/p2pool/p2pool/util/jsonrpc.py", line 85, in _handle
2013-06-28 02:35:28.350106 >     result = yield method_meth(*list(preargs) + list(params))
2013-06-28 02:35:28.350217 >   File "/home/pioruns/p2pool/p2pool/bitcoin/worker_interface.py", line 20, in rpc_getwork
2013-06-28 02:35:28.350342 >     return self.parent._getwork(request, data, long_poll=self.long_poll)
2013-06-28 02:35:28.350444 >   File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1213, in unwindGenerator
2013-06-28 02:35:28.350541 >     return _inlineCallbacks(None, gen, Deferred())
2013-06-28 02:35:28.350636 > ---  ---
2013-06-28 02:35:28.350734 >   File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1070, in _inlineCallbacks
2013-06-28 02:35:28.350830 >     result = g.send(result)
2013-06-28 02:35:28.350933 >   File "/home/pioruns/p2pool/p2pool/bitcoin/worker_interface.py", line 84, in _getwork
2013-06-28 02:35:28.351031 >     x, handler = self.worker_bridge.get_work(*self.worker_bridge.preprocess_request(request.getUser() if request.getUser() is not None else ''))
2013-06-28 02:35:28.351127 >   File "/home/pioruns/p2pool/p2pool/work.py", line 169, in preprocess_request
2013-06-28 02:35:28.351224 >     user, pubkey_hash, desired_share_target, desired_pseudoshare_target = self.get_user_details(user)
2013-06-28 02:35:28.351316 >   File "/home/pioruns/p2pool/p2pool/work.py", line 140, in get_user_details
2013-06-28 02:35:28.351411 >     assert len(contents) % 2 == 1
2013-06-28 02:35:28.351504 > exceptions.AssertionError: 
2013-06-28 02:35:28.403725 > Squelched JSON error:
2013-06-28 02:35:28.403910 > Traceback (most recent call last):
2013-06-28 02:35:28.404019 >   File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1070, in _inlineCallbacks
2013-06-28 02:35:28.404120 >     result = g.send(result)
2013-06-28 02:35:28.404216 >   File "/home/pioruns/p2pool/p2pool/util/jsonrpc.py", line 85, in _handle
2013-06-28 02:35:28.404331 >     result = yield method_meth(*list(preargs) + list(params))
2013-06-28 02:35:28.404438 >   File "/home/pioruns/p2pool/p2pool/bitcoin/worker_interface.py", line 20, in rpc_getwork
2013-06-28 02:35:28.404540 >     return self.parent._getwork(request, data, long_poll=self.long_poll)
2013-06-28 02:35:28.404637 >   File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1213, in unwindGenerator
2013-06-28 02:35:28.404735 >     return _inlineCallbacks(None, gen, Deferred())
2013-06-28 02:35:28.404846 > ---  ---
2013-06-28 02:35:28.404945 >   File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1070, in _inlineCallbacks
2013-06-28 02:35:28.405045 >     result = g.send(result)
2013-06-28 02:35:28.405144 >   File "/home/pioruns/p2pool/p2pool/bitcoin/worker_interface.py", line 84, in _getwork
2013-06-28 02:35:28.405263 >     x, handler = self.worker_bridge.get_work(*self.worker_bridge.preprocess_request(request.getUser() if request.getUser() is not None else ''))
2013-06-28 02:35:28.405359 >   File "/home/pioruns/p2pool/p2pool/work.py", line 169, in preprocess_request
2013-06-28 02:35:28.405453 >     user, pubkey_hash, desired_share_target, desired_pseudoshare_target = self.get_user_details(user)
2013-06-28 02:35:28.405547 >   File "/home/pioruns/p2pool/p2pool/work.py", line 140, in get_user_details
2013-06-28 02:35:28.405640 >     assert len(contents) % 2 == 1
2013-06-28 02:35:28.405787 > exceptions.AssertionError: 
2013-06-28 02:35:28.467292 > Squelched JSON error:
2013-06-28 02:35:28.467489 > Traceback (most recent call last):
2013-06-28 02:35:28.467746 >   File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1070, in _inlineCallbacks
2013-06-28 02:35:28.467859 >     result = g.send(result)
2013-06-28 02:35:28.467954 >   File "/home/pioruns/p2pool/p2pool/util/jsonrpc.py", line 85, in _handle
2013-06-28 02:35:28.468223 >     result = yield method_meth(*list(preargs) + list(params))
2013-06-28 02:35:28.468415 >   File "/home/pioruns/p2pool/p2pool/bitcoin/worker_interface.py", line 20, in rpc_getwork
2013-06-28 02:35:28.468540 >     return self.parent._getwork(request, data, long_poll=self.long_poll)
2013-06-28 02:35:28.468716 >   File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1213, in unwindGenerator
2013-06-28 02:35:28.468894 >     return _inlineCallbacks(None, gen, Deferred())
2013-06-28 02:35:28.469067 > ---  ---
2013-06-28 02:35:28.469322 >   File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1070, in _inlineCallbacks
2013-06-28 02:35:28.469450 >     result = g.send(result)
2013-06-28 02:35:28.469694 >   File "/home/pioruns/p2pool/p2pool/bitcoin/worker_interface.py", line 84, in _getwork
2013-06-28 02:35:28.469810 >     x, handler = self.worker_bridge.get_work(*self.worker_bridge.preprocess_request(request.getUser() if request.getUser() is not None else ''))
2013-06-28 02:35:28.469917 >   File "/home/pioruns/p2pool/p2pool/work.py", line 169, in preprocess_request
2013-06-28 02:35:28.470017 >     user, pubkey_hash, desired_share_target, desired_pseudoshare_target = self.get_user_details(user)
2013-06-28 02:35:28.470117 >   File "/home/pioruns/p2pool/p2pool/work.py", line 140, in get_user_details
2013-06-28 02:35:28.470211 >     assert len(contents) % 2 == 1
2013-06-28 02:35:28.470307 > exceptions.AssertionError: 
2013-06-28 02:35:29.620175 Processing 497 shares from 91.121.170.215:9333...

Problem 2.
branch newshare is still not working with Block Erupter Blade:
Code:
2013-06-28 00:46:26.706712 Worker lenny_beblade submitted share with hash > target:
2013-06-28 00:46:26.706890     Hash:   6be20e139936e6e901f194db962496e4075f981f60d26e47cf4ee43c58e86893
2013-06-28 00:46:26.707016     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 00:46:27.021801 Worker lenny_beblade submitted share with hash > target:
2013-06-28 00:46:27.021974     Hash:   dd9c23faf88f6a4b40e201997b36465d69a7c6fc128646300dca596006dbbb50
2013-06-28 00:46:27.022060     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 00:46:27.458897 Worker lenny_beblade submitted share with hash > target:
2013-06-28 00:46:27.459062     Hash:   69c027d971b35b026de60daeffb903decc5fc4b84a885ed1529f6ce5eb55d91c
2013-06-28 00:46:27.459150     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 00:46:27.753403 Worker lenny_beblade submitted share with hash > target:
2013-06-28 00:46:27.753576     Hash:   41de4103704b308e0068f13478383fd8b66ee0385f76b4610b46b81945362ebb
2013-06-28 00:46:27.753664     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 00:46:27.765767 Worker lenny_beblade submitted share with hash > target:
2013-06-28 00:46:27.765933     Hash:   33e92727e16d7eb7690b9c4a130a1bd4551632967a480883490d5bd5a4f2530c
2013-06-28 00:46:27.766020     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 00:46:28.070039 Worker lenny_beblade submitted share with hash > target:
2013-06-28 00:46:28.070234     Hash:   903f685e2618ae492a08b022c47ac87da27eb5a0358466e84ba806eeea1e1139
2013-06-28 00:46:28.070365     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 00:46:28.085547 Worker lenny_beblade submitted share with hash > target:
2013-06-28 00:46:28.085719     Hash:   c7de8758d56be5859a29fbe0343ab8f6647151c0e6eb38fc54f06ff8e62f316e
2013-06-28 00:46:28.085805     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 00:46:28.112343 Worker lenny_beblade submitted share with hash > target:
2013-06-28 00:46:28.112517     Hash:   5add6207c14c5c7bb50b2d0791b9fecf19a682670f565ae0071e75e39ebfb8a6
2013-06-28 00:46:28.112605     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 00:46:28.124978 Worker lenny_beblade submitted share with hash > target:
2013-06-28 00:46:28.125141     Hash:   187e3af9a0b31605316ab352539033bc42ea4d762128da5d83714f4249dbe0bb
2013-06-28 00:46:28.125284     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 00:46:28.436658 Worker lenny_beblade submitted share with hash > target:
2013-06-28 00:46:28.436833     Hash:   ec47157fde3bfbdb1f526d2539b82babaee1f3a178908e49cf54071f814e4a0
2013-06-28 00:46:28.436921     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 00:46:28.844327 Worker lenny_beblade submitted share with hash > target:
2013-06-28 00:46:28.844527     Hash:   496217830522b0719a7a6a5b9377129b2a0fae3d3022c25c954ba67f354c37a4
2013-06-28 00:46:28.844654     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 00:46:28.855535 Worker lenny_beblade submitted share with hash > target:
2013-06-28 00:46:28.855709     Hash:   d28f1d81aa2bb106086128389b47520e652d3c56d37bace6d6e2f14a58555bb0
2013-06-28 00:46:28.855796     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 00:46:28.880225 Worker lenny_beblade submitted share with hash > target:
2013-06-28 00:46:28.880398     Hash:   bd872f119ca55e75d217c41c7a6849bbdd3a534f330cedafa471d686c2ac099f
2013-06-28 00:46:28.880485     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2013-06-28 00:46:28.953461 P2Pool: 17457 shares in chain (8812 verified/17461 total) Peers: 6 (0 incoming)
2013-06-28 00:46:28.953551  Local: 95380kH/s in last 2.3 minutes Local dead on arrival: ~33.3% (6-80%) Expected time to share: 15.4 hours
2013-06-28 00:46:28.953599  Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: 0.0000 BTC
2013-06-28 00:46:28.953646  Pool: 620GH/s Stale rate: 15.3% Expected time to block: 1.5 days

Problem 3.
Stratum mining proxy is still not working with Block Erupter Blade, blade just shows 0 Accepted, 0 Received, 0 MH/s, and proxy remain silent while blade is trying to connect to proxy. Same device, same machine but proxy pointed to central pool - works 100% fine.
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 27, 2013, 06:32:08 PM
#5884
Quote from: baloo_kiev on June 27, 2013, 06:19:46 PM
It would be nice if forrestv commented on this!

This is what I see after looking into the code. If a share C is based on a stale block (usually shortly after a block was found), it gets "punished" and nodes start working on top of its parent share P, so C is forced to orphan. However, if a node does not follow this rule (may be a result of code modification or high bitcoind latency), it works on top of C (while others are working on P!) and may eventually find a share, "save" C from orphanage and (easily since it is 1 share ahead by total work!) orphan all P's children found before it. Looks like a bug to me.

Yeah, that is exactly what I think is happening.  I think it's the result of latency (internet) + bitcoind getblocktemplate latency.  It doesn't help that some of the highest hash power miners on p2pool seem to be behind firewalls & are on slow connections/machines.  Miner X finds a share, say, 1-3 seconds after a new block, Miner X's client thinks it is a legit share and passes it around, some of the other p2pool nodes relay it as legit....  another share is then built off of that one, and then that's it for anyone that (ed: has found a share off of) the parent of the 'punished' share...  the two shares > one share, so everyone switches over.

I didn't keep my old logs, but I've had a few times where I've found a share, gotten a new work (not just from the sleep time deferral, +1 to verified shares, etc), then the next work, it'll become an orphan... so then that means that some other nodes had some 3 share chain vs the 2 share chain.  The 3rd share on that chain might not even necessarily be from a slow node..
baloo_kiev
sr. member
Activity: 476
Merit: 250
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 27, 2013, 06:19:46 PM
#5883
It would be nice if forrestv commented on this!

This is what I see after looking into the code. If a share C is based on a stale block (usually shortly after a block was found), it gets "punished" and nodes start working on top of its parent share P, so C is forced to orphan. However, if a node does not follow this rule (may be a result of code modification or high bitcoind latency), it works on top of C (while others are working on P!) and may eventually find a share, "save" C from orphanage and (easily since it is 1 share ahead by total work!) orphan all P's children found before it. Looks like a bug to me.
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 27, 2013, 05:41:44 PM
#5882
Quote from: GrapeApe on June 27, 2013, 05:15:17 PM
Quote from: zvs on June 27, 2013, 03:08:51 PM
p2pool falsely claiming share is "dead on arrival" after block solved, orphaning valid shares over invalid shares, claiming "Dead on arrival" shares that become undead

first time, it became undead, and valid

second time, it remained dead

2013-06-27 14:59:35.699635  Shares: 58 (2 orphan, 3 dead) Stale rate: ~8.6% (3-19%) Efficiency: ~114.5% (101-121%) Current payout: 0.2480 BTC
2013-06-27 14:59:36.885926 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!
2013-06-27 14:59:36.888536 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!
2013-06-27 14:59:37.338727 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!
2013-06-27 14:59:40.485636 New work for worker! Difficulty: 5.000000 Share difficulty: 1115.669886 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:40.701845  Shares: 58 (2 orphan, 3 dead) Stale rate: ~8.6% (3-19%) Efficiency: ~114.2% (101-121%) Current payout: 0.2480 BTC
2013-06-27 14:59:41.640140 GOT SHARE! Tempbastard 115dabec prev 82d3447f age 17.21s DEAD ON ARRIVAL
2013-06-27 14:59:45.449055 New work for worker! Difficulty: 5.000000 Share difficulty: 1107.910003 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:45.704697  Shares: 59 (2 orphan, 4 dead) Stale rate: ~10.2% (4-21%) Efficiency: ~112.3% (99-120%) Current payout: 0.2480 BTC

this is the case of the DOA share remaining DOA, despite:

the parent share:

Share 82d3447f
Time first seen: Thu Jun 27 2013 14:59:17 GMT-0500 (Central Daylight Time) (1372363157.042115)
Payout address: 1GL7mM8ZA69WXQcSLu69WYTHGXgXajjSPT

the "non-DOA" child share:

Share b684ab9e (<--- as you can see, my log repeatedly "punished" this share, for being "block-stale")
Time first seen: Thu Jun 27 2013 14:59:24 GMT-0500 (Central Daylight Time) (1372363164.357247)
Payout address: 185Kip6odGYs4eSHD6DYsWVDJBg2DNLfiV




While trying to wrap my head around this I was going through your log and found this.....

2013-06-27 14:59:22.200435 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from 82d3447f to f619b3c1!
2013-06-27 14:59:22.243440 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.246420 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.249283 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.252093 New work for worker! Difficulty: 5.000000 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.255850 New work for worker! Difficulty: 5.000000 Share difficulty: 5000.002049 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.327728 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.330796 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.333631 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.522117 New work for worker! Difficulty: 5.000000 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.705084 New work for worker! Difficulty: 5.000000 Share difficulty: 5000.002049 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:24.375464 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!

I don't understand how  82d3447f can be the parent share if we jumped from 82d3447f to f619b3c1. How do we jump  back to  82d3447f what happened to f619b3c1??? I am confused by this....


Yeah, there are all sorts of weird anomalies like that.  I think that was the case for my DOA that became undead, wasn't it?   I remember we both mentioned something about having no clue wtf happened to xxxxxxx share that it said it was jumping to, haha.

re: debug mode, I have no more mhash on the pool and it may not happen again with ~1500-2000mhash or so that's on it now.  I wish I had saved all my old logs, tho
baloo_kiev
sr. member
Activity: 476
Merit: 250
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 27, 2013, 05:24:09 PM
#5881
Quote from: zvs on June 27, 2013, 03:08:51 PM
p2pool falsely claiming share is "dead on arrival" after block solved, orphaning valid shares over invalid shares, claiming "Dead on arrival" shares that become undead

...

also, I'm going to be shutting down my p2pool sometime in the next 12-24 hrs, giving the ppl mining there some fair warning if you dont have a backup set

Please run with -debug command line option for verbose logging. Thanks.
GrapeApe
sr. member
Activity: 476
Merit: 250
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 27, 2013, 05:15:17 PM
#5880
Quote from: zvs on June 27, 2013, 03:08:51 PM
p2pool falsely claiming share is "dead on arrival" after block solved, orphaning valid shares over invalid shares, claiming "Dead on arrival" shares that become undead

first time, it became undead, and valid

second time, it remained dead

2013-06-27 14:59:35.699635  Shares: 58 (2 orphan, 3 dead) Stale rate: ~8.6% (3-19%) Efficiency: ~114.5% (101-121%) Current payout: 0.2480 BTC
2013-06-27 14:59:36.885926 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!
2013-06-27 14:59:36.888536 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!
2013-06-27 14:59:37.338727 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!
2013-06-27 14:59:40.485636 New work for worker! Difficulty: 5.000000 Share difficulty: 1115.669886 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:40.701845  Shares: 58 (2 orphan, 3 dead) Stale rate: ~8.6% (3-19%) Efficiency: ~114.2% (101-121%) Current payout: 0.2480 BTC
2013-06-27 14:59:41.640140 GOT SHARE! Tempbastard 115dabec prev 82d3447f age 17.21s DEAD ON ARRIVAL
2013-06-27 14:59:45.449055 New work for worker! Difficulty: 5.000000 Share difficulty: 1107.910003 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:45.704697  Shares: 59 (2 orphan, 4 dead) Stale rate: ~10.2% (4-21%) Efficiency: ~112.3% (99-120%) Current payout: 0.2480 BTC

this is the case of the DOA share remaining DOA, despite:

the parent share:

Share 82d3447f
Time first seen: Thu Jun 27 2013 14:59:17 GMT-0500 (Central Daylight Time) (1372363157.042115)
Payout address: 1GL7mM8ZA69WXQcSLu69WYTHGXgXajjSPT

the "non-DOA" child share:

Share b684ab9e (<--- as you can see, my log repeatedly "punished" this share, for being "block-stale")
Time first seen: Thu Jun 27 2013 14:59:24 GMT-0500 (Central Daylight Time) (1372363164.357247)
Payout address: 185Kip6odGYs4eSHD6DYsWVDJBg2DNLfiV




While trying to wrap my head around this I was going through your log and found this.....

2013-06-27 14:59:22.200435 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from 82d3447f to f619b3c1!
2013-06-27 14:59:22.243440 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.246420 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.249283 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.252093 New work for worker! Difficulty: 5.000000 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.255850 New work for worker! Difficulty: 5.000000 Share difficulty: 5000.002049 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.327728 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.330796 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.333631 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.522117 New work for worker! Difficulty: 5.000000 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:22.705084 New work for worker! Difficulty: 5.000000 Share difficulty: 5000.002049 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:24.375464 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!

I don't understand how  82d3447f can be the parent share if we jumped from 82d3447f to f619b3c1. How do we jump  back to  82d3447f what happened to f619b3c1??? I am confused by this....
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 27, 2013, 03:08:51 PM
#5879
p2pool falsely claiming share is "dead on arrival" after block solved, orphaning valid shares over invalid shares, claiming "Dead on arrival" shares that become undead

first time, it became undead, and valid

second time, it remained dead

2013-06-27 14:59:35.699635  Shares: 58 (2 orphan, 3 dead) Stale rate: ~8.6% (3-19%) Efficiency: ~114.5% (101-121%) Current payout: 0.2480 BTC
2013-06-27 14:59:36.885926 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!
2013-06-27 14:59:36.888536 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!
2013-06-27 14:59:37.338727 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!
2013-06-27 14:59:40.485636 New work for worker! Difficulty: 5.000000 Share difficulty: 1115.669886 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:40.701845  Shares: 58 (2 orphan, 3 dead) Stale rate: ~8.6% (3-19%) Efficiency: ~114.2% (101-121%) Current payout: 0.2480 BTC
2013-06-27 14:59:41.640140 GOT SHARE! Tempbastard 115dabec prev 82d3447f age 17.21s DEAD ON ARRIVAL
2013-06-27 14:59:45.449055 New work for worker! Difficulty: 5.000000 Share difficulty: 1107.910003 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:45.704697  Shares: 59 (2 orphan, 4 dead) Stale rate: ~10.2% (4-21%) Efficiency: ~112.3% (99-120%) Current payout: 0.2480 BTC

this is the case of the DOA share remaining DOA, despite:

the parent share:

Share 82d3447f
Time first seen: Thu Jun 27 2013 14:59:17 GMT-0500 (Central Daylight Time) (1372363157.042115)
Payout address: 1GL7mM8ZA69WXQcSLu69WYTHGXgXajjSPT

the "non-DOA" child share:

Share b684ab9e (<--- as you can see, my log repeatedly "punished" this share, for being "block-stale")
Time first seen: Thu Jun 27 2013 14:59:24 GMT-0500 (Central Daylight Time) (1372363164.357247)
Payout address: 185Kip6odGYs4eSHD6DYsWVDJBg2DNLfiV


please fix this crap.  thanks



ed: oh, oops, here's the earlier part:

2013-06-27 14:59:24.375464 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!
2013-06-27 14:59:24.425505 New work for worker! Difficulty: 5.000000 Share difficulty: 1110.049880 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:25.689527  Shares: 58 (2 orphan, 3 dead) Stale rate: ~8.6% (3-19%) Efficiency: ~114.5% (101-121%) Current payout: 0.2480 BTC
2013-06-27 14:59:26.885891 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!
2013-06-27 14:59:26.888480 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!

log is always linked at www.nogleg.com/log

added www.nogleg.com/log.2

which shows

2013-06-27 11:37:27.023558 GOT SHARE! Tempbastard 18fae184 prev 1a0e47a0 age 4.15s

a share being orphaned right before a block, presumably because of the same slow nodes that cause ^^^

the cause of about 1/2 of my orphans and maybe 1/5th of the DOAs

ed: next begins here

2013-06-27 16:05:17.479788 GOT SHARE! Crazed Hookers 9436d28f prev ce2367af age 0.48s
2013-06-27 16:05:22.517996 Skipping from block a4bd5a28f726c27f813cd0657b354f81f79855d4752de4ba56 to block bb36b7e2cba69a75d33f4f16c564690540869c98abcebd3a7a!

******************************

also, I'm going to be shutting down my p2pool sometime in the next 12-24 hrs, giving the ppl mining there some fair warning if you dont have a backup set
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 27, 2013, 01:32:16 PM
#5878
Quote from: bitpop on June 27, 2013, 12:20:51 PM
I don't think latency in those terms is the problem
Well, you didn't make it clear who you were replying to

but, yeah, getblocktemplate latency has nothing to do with having more or less peers, it has to do with your local machine

(ed: well, i suppose if you had a max of 1 connection in bitcoind, then that one connection didn't relay any transactions, you'd have a really low getblocktemplate time)
bitpop
legendary
Activity: 2912
Merit: 1060
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 27, 2013, 12:20:51 PM
#5877
I don't think latency in those terms is the problem
chanson
member
Activity: 84
Merit: 10
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 27, 2013, 12:16:37 PM
#5876
Isn't this JSON-RPC thing for getblocktemplate completely stupid? Why aren't we using a shared memory segment with bitcoind?
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 27, 2013, 11:11:33 AM
#5875
it's really simple to set up p2pool to have a low getblocktemplate latency

in bitcoin.conf,

blockprioritysize=0
blockmaxsize=3000
minrelaytxfee=100000  (or maybe 0.001)

i'm not sure which one of those is the proper way to put it in conf, my guess is the 1st

that's all you need to do



    // Fee-per-kilobyte amount considered the same as "free"
    // If you are mining, be careful setting this:
    // if you set it to zero then
    // a transaction spammer can cheaply fill blocks using
    // 1-satoshi-fee transactions. It should be set above the real
    // cost to you of processing a transaction.

oh, the getblocktemplate latency doesnt have a huge effect, really

just when blocks are solved.  so then some ppl are penalized that have faster bitcoind, if some ppl with slow getblocktemplate latencies get off a couple shares in a row
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
June 27, 2013, 10:58:24 AM
#5874
Quote from: chanson on June 27, 2013, 09:44:48 AM
Thank you for the pointers!

I actually had read those guides, but I think I feel victim to pre-mature optimization and applying without testing. Particularly in light of gyverlb's advice linked by GrapeApe which describes actually methodically testing and measuring the results of tuning to see what's working (sacrilege!). So... I disabled all the tweaks for now in bitcoin.conf and restarted bitcoind... But it turns out there was also a second "mistake" I made.

After restarting bitcoind without tweaks, getblocktemplate latency started out low but then would gradually and steadily build up to ~2sec(!) over the course of 30 minutes! So I decided to open 8333 for bitcoind to maybe get more connections. That didn't do much, either... That's when I noticed that I had been too clever and set "ufw limit" on the bitcoind and p2pool ports (linux kernel firewall rate limiting). When I deleted those rules and replaced them with the corresponding "ufw allow" unlimited rules my rate dropped considerably and seems to have stayed low over night (0.1-0.3s for the last six hours). So, I'll now work on tweaking more methodically.

Thanks for getting me pointed in the right direction!
that shouldn't have had any impact, the getblocktemplate latency will increase mainly because 1) you build up a lot of transactions in storage, that'll show up on bitcoind getmininginfo, 2) your system is overloaded

more connections would probably make the second case more likely

no blocks within the last 30 minutes or so makes #1 a problem, for some people

rate limiting, connections, all this is totally different area
Pages:
Bitcoin Forum>Bitcoin>Mining>Pools
Jump to: