Bitcoin Forum
December 06, 2016, 09:59:50 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 [195] 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2032070 times)
Aseras
Hero Member
*****
Offline Offline

Activity: 658


View Profile
November 16, 2012, 03:39:10 PM
 #3881

Yes, that's new. Preparation for ASICs! It tries to regulate the work's difficulty to keep it at one response per second.
Is there any way to configure the period server or client side?

Not currently, no. Do you have a need to?
Is this per miner or per node? Ie I have only 150MH, some 1GH miner is uisng my node. What will be share diff for me and for him? Same?
In this case each miner would receive work with the target adjusted such that on average each would report back once per second. The slower hasher would get a lower difficulty share (though solving a sharechain block would be just as hard for either one) and the faster hasher would get a higher target so they still report back once per second.

I was wondering if this could be changed by the server/node (to reduce how often they're contacted) or by the client/miner (so they didn't have to report back as often/more often). Less often leads to lower badwidth and less time used waiting for the server's response to the submitted work, lower times give a more accurate picture of miner performance at the cost of more overhead.

I don't have any particular need, I can make up use cases (miners over local network who don't care about server and network usage, wanting to reduce overhead, and wanting lower variability in stats) and I figured it would be similar to setting share difficulty manually at the miner using :diff syntax on the username. Wouldn't have known without asking basically. In truth I could see this being abused much more than it's worth by people trying to tweak their statistics and making overall performance worse.

It should work like this but it doesn't. It's handing 3+ diff shares to a miner of mine that is 2 150 mhash cards and every share is dead for >24 hours.

I've gone back to 8.2.

There need to be a way to toggle or control it, at least for now for the slower workers.
1481061590
Hero Member
*
Offline Offline

Posts: 1481061590

View Profile Personal Message (Offline)

Ignore
1481061590
Reply with quote  #2

1481061590
Report to moderator
1481061590
Hero Member
*
Offline Offline

Posts: 1481061590

View Profile Personal Message (Offline)

Ignore
1481061590
Reply with quote  #2

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

Posts: 1481061590

View Profile Personal Message (Offline)

Ignore
1481061590
Reply with quote  #2

1481061590
Report to moderator
1481061590
Hero Member
*
Offline Offline

Posts: 1481061590

View Profile Personal Message (Offline)

Ignore
1481061590
Reply with quote  #2

1481061590
Report to moderator
1481061590
Hero Member
*
Offline Offline

Posts: 1481061590

View Profile Personal Message (Offline)

Ignore
1481061590
Reply with quote  #2

1481061590
Report to moderator
rav3n_pl
Legendary
*
Offline Offline

Activity: 1320


Don`t panic! Organize!


View Profile
November 16, 2012, 03:51:43 PM
 #3882

In mean time V9 is passing 40% of pool.
Trouble is, that V5+V7 is about 10%, so if those ppl will not switch to v9 95% hardfork will not happen soon...

Upgrade mates! Upgrade!

v8 update rush has worked after some time, then no fork. ppl disappointed -> longer time to do it now.
v7 was fork update, v8 - anti-v7-fork ;]
Now finally v9 Cheesy
I just hope that tx sending will be rolling again.
Maybe do it in this way:
- preload: get all current txns form bitcoind
- found new txn in bitciond -> ask connected peers about that txn
- send full tx data to peer that want it
- got ask from peer -> check that you have it and ask for data if not
- all txns that are not in block need to be cashed to prevent asking/sending same txes over and over
- node forget txes that are put in block 2 blocks back - to prevent asking txes from nodes that are 1 block behind network when new block is propagated
- purge tx cache data from txes that are not in block every few blocks/refresh from bitcoind

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
My SatoshDice bot https://bitcointalk.org/index.php?topic=897685
Syke
Legendary
*
Offline Offline

Activity: 2086


View Profile
November 16, 2012, 06:44:23 PM
 #3883

OK, show me 5 or 6 blocks in a day when we are over 350 GH for the entire day and I will believe you. I know what variance is, but variance to the good when we are over 350 GH for 24 hours and I'm sold. It doesn't even need to be 5 or 6 blocks, just positive luck for that day.

The odds of having a 6-block day, when the hashrate is high, is quite low and simply due to variance. Not finding one isn't going to prove anything. Our 90-day moving average is over 110% of expected payout. That's impressive.

Buy & Hold
Clock Loop
Newbie
*
Offline Offline

Activity: 22


...2,951,413.141592...


View Profile
November 16, 2012, 07:24:12 PM
 #3884

BUGZZZZZ
I didn't do anything abnormal, using bcoin0.71
Started p2pool like I do normally,  but then I saw that an invalid hash message poped up, and then the bug showed up.
Code:
2012-11-16 13:14:56.292000 RECV forget_tx 019b904c00308d0f7d57af02ddfccc1559a8f16b9d6228a75f4bb147311b0fc152
2012-11-16 13:14:56.292000 > Error handling message: (see RECV line)
2012-11-16 13:14:56.292000 > Traceback (most recent call last):
2012-11-16 13:14:56.292000 >   File "twisted\internet\tcp.pyc", line 209, in _dataReceived
2012-11-16 13:14:56.292000 >    
2012-11-16 13:14:56.292000 >   File "p2pool\p2p.pyc", line 146, in new_dataReceived
2012-11-16 13:14:56.292000 >    
2012-11-16 13:14:56.292000 >   File "p2pool\util\p2protocol.pyc", line 39, in dataReceived
2012-11-16 13:14:56.292000 >    
2012-11-16 13:14:56.292000 >   File "p2pool\util\datachunker.pyc", line 40, in _DataChunker
2012-11-16 13:14:56.292000 >    
2012-11-16 13:14:56.292000 > --- <exception caught here> ---
2012-11-16 13:14:56.292000 >   File "p2pool\util\p2protocol.pyc", line 66, in dataReceiver
2012-11-16 13:14:56.292000 >    
2012-11-16 13:14:56.292000 >   File "p2pool\p2p.pyc", line 91, in packetReceived
2012-11-16 13:14:56.292000 >    
2012-11-16 13:14:56.292000 >   File "p2pool\util\p2protocol.pyc", line 79, in packetReceived
2012-11-16 13:14:56.292000 >    
2012-11-16 13:14:56.292000 >   File "p2pool\p2p.pyc", line 390, in handle_forget_tx
2012-11-16 13:14:56.292000 >    
2012-11-16 13:14:56.292000 > exceptions.KeyError: 37430759326633628792559864835538716825822374976072746282717190753054796583067L

I think this caused the bug:
2012-11-16 13:14:45.342000 invalid hash for 99.162.89.78 'remember_tx' 248345 04cac86c 86dc28a6********(rest of hash omitted because.....the text was too long for forum "The message exceeds the maximum allowed length (64000 characters). "

And this forum has no way to attach text files.

I am not sure if the invalid hash LENGTH is what cased the bug, because it was over 64,000 characters in length+
So perhaps this is just a bug that is caused by a hash that was too long, overloading a buffer or related.
This might just be a bug caused by getting hashes from peers that are wayyyy too long?   
(no idea how that would happen unless someone is malicious, or their pc flipped out/program crashed....)

Feel free to send me bitcoins. 1KSwVC3intr4KJK36bQ5NDMmyuxAcpzEY9
http://www.youtube.com/watch?v=fFYHWYaT_oo
Schleicher
Hero Member
*****
Offline Offline

Activity: 630



View Profile
November 16, 2012, 07:45:54 PM
 #3885

Started p2pool like I do normally,  but then I saw that an invalid hash message poped up, and then the bug showed up.
Same thing happened here some time ago:
https://bitcointalk.org/index.php?topic=18313.msg1328349#msg1328349

Bitcoin donations: 1H2BHSyuwLP9vqt2p3bK9G3mDJsAi7qChw
forrestv
Hero Member
*****
Offline Offline

Activity: 510


View Profile
November 16, 2012, 09:01:23 PM
 #3886

BUGZZZZZ
I didn't do anything abnormal, using bcoin0.71
Started p2pool like I do normally,  but then I saw that an invalid hash message poped up, and then the bug showed up.
Code:
...

I think this caused the bug:
2012-11-16 13:14:45.342000 invalid hash for 99.162.89.78 'remember_tx' 248345 04cac86c 86dc28a6********(rest of hash omitted because.....the text was too long for forum "The message exceeds the maximum allowed length (64000 characters). "

And this forum has no way to attach text files.

I am not sure if the invalid hash LENGTH is what cased the bug, because it was over 64,000 characters in length+
So perhaps this is just a bug that is caused by a hash that was too long, overloading a buffer or related.
This might just be a bug caused by getting hashes from peers that are wayyyy too long?   
(no idea how that would happen unless someone is malicious, or their pc flipped out/program crashed....)

I think it's due to a packet sent over the network getting corrupted somehow. Did P2Pool continue to work afterwards? It should have. If it didn't, this is a real bug ... but otherwise it's just a rare failure that was handled correctly.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
forrestv
Hero Member
*****
Offline Offline

Activity: 510


View Profile
November 16, 2012, 09:09:05 PM
 #3887

It should work like this but it doesn't. It's handing 3+ diff shares to a miner of mine that is 2 150 mhash cards and every share is dead for >24 hours.

I've gone back to 8.2.

There need to be a way to toggle or control it, at least for now for the slower workers.

A high difficulty shouldn't cause dead shares (it should only reduce how often pseudoshares are sent back to your P2Pool node), so this is either a bug in P2Pool or a bug in your miner. Can you tell me what mining software that miner was using? And send me p2pool's log file?

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
Aseras
Hero Member
*****
Offline Offline

Activity: 658


View Profile
November 16, 2012, 09:28:53 PM
 #3888



A high difficulty shouldn't cause dead shares (it should only reduce how often pseudoshares are sent back to your P2Pool node), so this is either a bug in P2Pool or a bug in your miner. Can you tell me what mining software that miner was using? And send me p2pool's log file?

Running cgminer newest version. Log file is >70mb. Let me zip it and see how much smaller it gets.
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
November 16, 2012, 10:05:02 PM
 #3889

...
And this forum has no way to attach text files.
...
If you need to post something big - you put it in pastebin (or similar) and include the link.

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

Activity: 383



View Profile
November 16, 2012, 11:03:40 PM
 #3890

OK, show me 5 or 6 blocks in a day when we are over 350 GH for the entire day and I will believe you. I know what variance is, but variance to the good when we are over 350 GH for 24 hours and I'm sold. It doesn't even need to be 5 or 6 blocks, just positive luck for that day.

The odds of having a 6-block day, when the hashrate is high, is quite low and simply due to variance. Not finding one isn't going to prove anything. Our 90-day moving average is over 110% of expected payout. That's impressive.

Yes our 90 day moving average is impressive and it is being used to sugar coat or slick over the issue we are trying to bring up. Just because our overall luck is good does not mean we don't have a scalability problem. When we get those bumps in hash speed, the person/s that jumped on board usually see that their payouts are low because of the bad luck during the period they hopped on and they leave. That drops us back down in hash rate back to where the supposed scalability issue is no longer in play.

So until we have a run of good luck in the 350+ GH range I and probably some others will still have doubts.

Donations welcome: 12KaKtrK52iQjPdtsJq7fJ7smC32tXWbWr
K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
November 16, 2012, 11:10:48 PM
 #3891

OK, show me 5 or 6 blocks in a day when we are over 350 GH for the entire day and I will believe you. I know what variance is, but variance to the good when we are over 350 GH for 24 hours and I'm sold. It doesn't even need to be 5 or 6 blocks, just positive luck for that day.

The odds of having a 6-block day, when the hashrate is high, is quite low and simply due to variance. Not finding one isn't going to prove anything. Our 90-day moving average is over 110% of expected payout. That's impressive.

Yes our 90 day moving average is impressive and it is being used to sugar coat or slick over the issue we are trying to bring up. Just because our overall luck is good does not mean we don't have a scalability problem. When we get those bumps in hash speed, the person/s that jumped on board usually see that their payouts are low because of the bad luck during the period they hopped on and they leave. That drops us back down in hash rate back to where the supposed scalability issue is no longer in play.

So until we have a run of good luck in the 350+ GH range I and probably some others will still have doubts.
i dont mind the variance, u still get more than all other pools, just not in a steady way Smiley

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
November 16, 2012, 11:32:36 PM
 #3892

...
i dont mind the variance, u still get more than all other pools, just not in a steady way Smiley
It does depend on how the pool hash rate is calculated ...

The pool hash rate is actually somewhere around 5% or greater above the share rate.

So if the share rate is used to determine the pool hash rate, then yes it is lower than the true hash rate by quite a bit and thus the blocks found would appear to be above the expected 100% ... when in reality the share rate doesn't include the VERY high stale rate ... whereas the block rate does since the blocks are not lost, just the shares.

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

Activity: 896



View Profile
November 17, 2012, 12:20:06 AM
 #3893

...
i dont mind the variance, u still get more than all other pools, just not in a steady way Smiley
It does depend on how the pool hash rate is calculated ...

The pool hash rate is actually somewhere around 5% or greater above the share rate.

So if the share rate is used to determine the pool hash rate
No. kano this is beginning to look like pure trolling: please install p2pool and use it or read the code instead of spreading FUD. I know using the forum to look for this kind of information is difficult, but it has actually already being discussed at lengths in this very thread.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
rav3n_pl
Legendary
*
Offline Offline

Activity: 1320


Don`t panic! Organize!


View Profile
November 17, 2012, 12:43:25 AM
 #3894

Stale/doa shares depends on miner config and p2pool server load.
Orphan shares are just luck.
Shares are ONLY to calculate payout.
All shares are tested for possible block found.
Share diff is scaled to pool ratio/share about every 10s.
So stale and orphan ratio are NOT responsible for pool luck/block finding ratio.

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
My SatoshDice bot https://bitcointalk.org/index.php?topic=897685
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
November 17, 2012, 01:03:54 AM
 #3895

...
i dont mind the variance, u still get more than all other pools, just not in a steady way Smiley
It does depend on how the pool hash rate is calculated ...

The pool hash rate is actually somewhere around 5% or greater above the share rate.

So if the share rate is used to determine the pool hash rate
No. kano this is beginning to look like pure trolling: please install p2pool and use it or read the code instead of spreading FUD. I know using the forum to look for this kind of information is difficult, but it has actually already being discussed at lengths in this very thread.
So - how is the pool hash rate calculated?

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

Activity: 896



View Profile
November 17, 2012, 01:49:31 AM
 #3896

So - how is the pool hash rate calculated?
It includes orphans and dead on arrival shares as they are seen by every node.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
forrestv
Hero Member
*****
Offline Offline

Activity: 510


View Profile
November 17, 2012, 01:56:58 AM
 #3897

So - how is the pool hash rate calculated?
It includes orphans and dead on arrival shares as they are seen by every node.
Gyver, not quite. Share have a flag that indicates whether the node that generated it got a stale share in the past, and from those, nodes can compute the stale share percentage and then the total hash rate with an expression like: unstale_hash_rate / (1 - pool_stale_proportion)

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
Syke
Legendary
*
Offline Offline

Activity: 2086


View Profile
November 17, 2012, 03:41:33 AM
 #3898

Yes our 90 day moving average is impressive and it is being used to sugar coat or slick over the issue we are trying to bring up. Just because our overall luck is good does not mean we don't have a scalability problem. When we get those bumps in hash speed, the person/s that jumped on board usually see that their payouts are low because of the bad luck during the period they hopped on and they leave. That drops us back down in hash rate back to where the supposed scalability issue is no longer in play.

So until we have a run of good luck in the 350+ GH range I and probably some others will still have doubts.

That's just ridiculous. Take a look at the last week. Hashrate has been climing to over 400 GH/s, and the 7-day average is still over 115%.

Buy & Hold
sharky112065
Sr. Member
****
Offline Offline

Activity: 383



View Profile
November 17, 2012, 04:31:11 AM
 #3899

Yes our 90 day moving average is impressive and it is being used to sugar coat or slick over the issue we are trying to bring up. Just because our overall luck is good does not mean we don't have a scalability problem. When we get those bumps in hash speed, the person/s that jumped on board usually see that their payouts are low because of the bad luck during the period they hopped on and they leave. That drops us back down in hash rate back to where the supposed scalability issue is no longer in play.

So until we have a run of good luck in the 350+ GH range I and probably some others will still have doubts.

That's just ridiculous. Take a look at the last week. Hashrate has been climing to over 400 GH/s, and the 7-day average is still over 115%.

As you said... "has been climbing" So for part of the week we were below 350 GH. and 7 day average is now down to 110%

I'm done (as in, not gonna argue with you anymore), no one will take a serious look into the issue as long as people are sugar coating it with ... see look our overall luck is good. What I and others are saying is we are noticing that blocks are being solved by the pool less frequently when we are over a certain hash rate.

Donations welcome: 12KaKtrK52iQjPdtsJq7fJ7smC32tXWbWr
Syke
Legendary
*
Offline Offline

Activity: 2086


View Profile
November 17, 2012, 05:11:07 AM
 #3900

As you said... "has been climbing" So for part of the week we were below 350 GH. and 7 day average is now down to 110%

So what you're saying is, when you flip a coin less than 350 times a day you get 50/50, but when you flip it more than 350 times in a day you get 60/40? Claim it all you want, it makes no sense.

Let's look at this week day by day (which is a bad idea as there's too much variation). 2 blocks or less is below expected, 3 blocks or more is above average.

1-day ago. 2 - Below
2-days ago. 3 - Above
3-days ago. 4 - Above
4-days ago. 4 - Above
5-days ago. 4 - Above
6-days ago. 1 - Below
7-days ago. 0 - Below

4 days above average, 3 days below average. Where's the problem???

I'm done (as in, not gonna argue with you anymore), no one will take a serious look into the issue as long as people are sugar coating it with

Go for it. Take a serious look.

https://github.com/forrestv/p2pool

And when ASICs hit you'll see that you're imagining patterns where there are none.

Buy & Hold
Pages: « 1 ... 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 [195] 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 ... 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!