Bitcoin Forum
December 10, 2016, 08:47:49 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2034851 times)
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
April 02, 2013, 05:21:33 PM
 #4781

We are concerning about that Avalons will sky high share diff to high. Share diff is raised, when shares are showing to fast in chain.
Maybe allow Avalon (or another high power devices) users to set share diff as high as they want?

There is an argument for multiple pools... an Avalon/ASIC pool, a GPU-and-smaller pool, etc.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
1481402869
Hero Member
*
Offline Offline

Posts: 1481402869

View Profile Personal Message (Offline)

Ignore
1481402869
Reply with quote  #2

1481402869
Report to moderator
1481402869
Hero Member
*
Offline Offline

Posts: 1481402869

View Profile Personal Message (Offline)

Ignore
1481402869
Reply with quote  #2

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

Posts: 1481402869

View Profile Personal Message (Offline)

Ignore
1481402869
Reply with quote  #2

1481402869
Report to moderator
1481402869
Hero Member
*
Offline Offline

Posts: 1481402869

View Profile Personal Message (Offline)

Ignore
1481402869
Reply with quote  #2

1481402869
Report to moderator
maqifrnswa
Sr. Member
****
Offline Offline

Activity: 454


View Profile
April 02, 2013, 05:52:30 PM
 #4782

This proposal will "only" need minor changes in code and we will not need separate share chain or hard fork.
OFC there should be "some" protection against changes in code, ie there should be at least 2 shares reported on same higher sd from same node/user/address.

I think there is another concern: avalons have high work-return latency. The hard fork would be caused if moving to a 30 second per share target to compensate for the latency issues. That alone would cause a 73% increase in variance across the board. Large miners (ASICS) might not care since their variance is low to begin with, but it might be too much to swallow for small miners who are already experiencing higher variance.

However, if the 3x increase in target time is combined with a 3x increase in the percentage of bitcoin hashing rate attributed to p2pool (thanks to ASICs now being able mine), then the small miners won't even notice the change in variance and there can be just one pool: the new 30 second one.

Or you can make a command line flag on p2pool and let the market choose/decide. Nothing would stop the smaller miners from choosing the 30 second pool if the variance is lower there.
Aseras
Hero Member
*****
Offline Offline

Activity: 658


View Profile
April 02, 2013, 06:27:16 PM
 #4783

I think I got p2pool working on avalon with stratum.. maybe.

its hashing at full speed last couple of minutes Cheesy

in main.py

Quote
serverfactory = switchprotocol.FirstByteSwitchFactory({'{': stratum.StratumServerFactory(wb)}, web_serverfactory)

same workaround as p2pool avalon branch, to disable work caching.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
April 02, 2013, 06:37:54 PM
 #4784

We are concerning about that Avalons will sky high share diff to high. Share diff is raised, when shares are showing to fast in chain.
Maybe allow Avalon (or another high power devices) users to set share diff as high as they want?

There is an argument for multiple pools... an Avalon/ASIC pool, a GPU-and-smaller pool, etc.

I'm not sure the argument is valid. The argument is based on the assumption that a GPU on an ASIC pool will get such a high variance that it will be a deterrent.

The problem with this line of thinking is that it doesn't scale: a GPU in a small ASIC pool is the same today as an ASIC in a big ASIC pool tomorrow. The problem is small relative hashrate, it will exist even with a balanced p2pool (with everybody in the same ballpark) when it grows.

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

Activity: 896



View Profile
April 02, 2013, 06:47:35 PM
 #4785

Another solution involving several pools:

The p2pool network could more or less automatically organize itself in subpools to avoid the problems of a too large pool. A node should target a pool where it gets a percentage of the hashrate in a range suited for low variance.

The problem I see is how a new subpool could be automatically created (it should be done cooperatively to avoid one single node on a subpool). A node could be connected to the old and new pools at the same time and balancing its hashrate among them progressively (monitoring other node hashrate rising) to make the transition less risky for its variance.

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

Activity: 924


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


View Profile WWW
April 02, 2013, 07:54:47 PM
 #4786

We are concerning about that Avalons will sky high share diff to high. Share diff is raised, when shares are showing to fast in chain.
Maybe allow Avalon (or another high power devices) users to set share diff as high as they want?

There is an argument for multiple pools... an Avalon/ASIC pool, a GPU-and-smaller pool, etc.



I not sure that this is a good option, it may cause more problems than it solves. Far better to have the one pool for everyone I think...keeps it simple also.

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

Activity: 2002


Ruu \o/


View Profile WWW
April 02, 2013, 09:05:52 PM
 #4787

It sounds like forrestv is instead in favor of alternate means to extend the effective work interval through merging of parallel chains.  Various theoretical designs were discussed.

We may end up making a fork or a frankenbuild of p2pool to fix things for testing. I don't see why in the end it would need to fork for everyone, but it would be a hard fork and everyone would need to upgrade to a version where everyone is on the same share chain.

It ultimately seems like 10 seconds is just too short, given Internet propagation, current Avalon hashrate, and the up to 1.5-second delay it can take for work to be returned from Avalons (high latency).  Thus, I argue for around 30 seconds, which would imply a hard fork at some point.

No, taking this direction is a mistake. You are trying to redesign p2pool around the design of one device. There is nothing that says that all future ASICs will have this same hardware limitation. It is an intrinsic design flaw/limitation/shortcut taken in the first generation Avalons.

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

Activity: 658


View Profile
April 02, 2013, 09:17:42 PM
 #4788

It sounds like forrestv is instead in favor of alternate means to extend the effective work interval through merging of parallel chains.  Various theoretical designs were discussed.

We may end up making a fork or a frankenbuild of p2pool to fix things for testing. I don't see why in the end it would need to fork for everyone, but it would be a hard fork and everyone would need to upgrade to a version where everyone is on the same share chain.

It ultimately seems like 10 seconds is just too short, given Internet propagation, current Avalon hashrate, and the up to 1.5-second delay it can take for work to be returned from Avalons (high latency).  Thus, I argue for around 30 seconds, which would imply a hard fork at some point.

No, taking this direction is a mistake. You are trying to redesign p2pool around the design of one device. There is nothing that says that all future ASICs will have this same hardware limitation. It is an intrinsic design flaw/limitation/shortcut taken in the first generation Avalons.

it affects more devices, the bfl singles have the same issue. the minirigs have a work around, but sort of the same as well. I will bet money the bfl SC when/if they come out will as well. The way the current asics are designed is the issue, they are clusters of many small devices with overhead.

anyways, the issue is kinda moot right now since it appears that the avalons will work on p2pool once you disable work caching on stratum as well. No need to create a fork to test. But it would be nice to not loose 20-30% to DOA. But in the long run, once asic hit mainstream everyone else will have them too and it will even out.
rav3n_pl
Legendary
*
Offline Offline

Activity: 1320


Don`t panic! Organize!


View Profile
April 02, 2013, 09:35:40 PM
 #4789

Another way would be create 3 type of shares.
For current pool hash rate sd is about 700.
Make one share type that have diff 1/3 of standard share and one type that have 3x standard share diff. Each type have to be scored according to its diff.
Pool will take sd1+ shares form worker and calculate its hash rate. Then pool decide what type of share should be used for this worker.
We should also have ability to force standard or higher share diff using prefix or postfix in worker name (not allow to drop to type 1).
Lower share diff should be only enabled on pool side.
Also if node is making lots of low diff shares pool should punish those shares as invalid (in case that s1 mess in code).
This way we avoid too high share diff and allow smaller and bigger miners to mine in p2pool Smiley
This change require hard fork ofc.

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
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
April 02, 2013, 09:41:15 PM
 #4790

here is nothing that says that all future ASICs will have this same hardware limitation. It is an intrinsic design flaw/limitation/shortcut taken in the first generation Avalons.

it affects more devices, the bfl singles have the same issue. the minirigs have a work around, but sort of the same as well. I will bet money the bfl SC when/if they come out will as well. The way the current asics are designed is the issue, they are clusters of many small devices with overhead.
No, the BFL SC devices do not suffer this.

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

Activity: 896



View Profile
April 02, 2013, 10:04:57 PM
 #4791

Another way would be create 3 type of shares.
For current pool hash rate sd is about 700.
Make one share type that have diff 1/3 of standard share and one type that have 3x standard share diff. Each type have to be scored according to its diff.
Pool will take sd1+ shares form worker and calculate its hash rate. Then pool decide what type of share should be used for this worker.
We should also have ability to force standard or higher share diff using prefix or postfix in worker name (not allow to drop to type 1).
Lower share diff should be only enabled on pool side.
Also if node is making lots of low diff shares pool should punish those shares as invalid (in case that s1 mess in code).
This way we avoid too high share diff and allow smaller and bigger miners to mine in p2pool Smiley
This change require hard fork ofc.


There's an easier way: just make the code compute the difficulty needed to get a maximum of shares in the PPLNS window to limit its share usage while maintaining the variance to an acceptable level (200 shares should probably be enough: I get a little more than 100 and variance is OK).

But someone (I think it's gmaxwell on IRC) pointed to me that there's a flaw: even if the pool tries to enforce this rule, there's nothing preventing a user mining with several payout addresses to lower his variance even more, defeating the mechanism.

I think it would be a sane default for p2pool to behave that way though. The current PPLNS setup only allows for ~40 miners with low (at least low according to my own definition) variance (I'm not sure of the N in PPLNS as it involves both 24h and the estimated time to get a block but there's 8640 shares in one day).

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

Activity: 658


View Profile
April 03, 2013, 01:22:31 AM
 #4792

I still don't see why a slightly longer share chain long poll time would be bad. It would let the slower miners get a share in easier before being cut off and helps higher latency. It would benefit just about everyone. It's still PPLNS so the payouts would still be equal to the balance of shares.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
April 03, 2013, 02:10:06 AM
 #4793

I still don't see why a slightly longer share chain long poll time would be bad. It would let the slower miners get a share in easier before being cut off and helps higher latency. It would benefit just about everyone. It's still PPLNS so the payouts would still be equal to the balance of shares.
Longer LP means higher difficulty ...

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

Activity: 658


View Profile
April 03, 2013, 11:38:24 AM
 #4794

I still don't see why a slightly longer share chain long poll time would be bad. It would let the slower miners get a share in easier before being cut off and helps higher latency. It would benefit just about everyone. It's still PPLNS so the payouts would still be equal to the balance of shares.
Longer LP means higher difficulty ...

yes, but it will be a pittance compared to ASIC. I'm using +32 difficulty now. I would go even higher but p2pool has problems or the work DOA because of age.
PatMan
Hero Member
*****
Offline Offline

Activity: 924


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


View Profile WWW
April 03, 2013, 11:53:22 AM
 #4795

On a side note - what's the record for the longest period without finding a block? I have a feeling it's gonna be broken shortly...... Grin

(we usually find one when I mention something about it - let's hope it happens again.....soon Cheesy)

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

Activity: 1320


Don`t panic! Organize!


View Profile
April 03, 2013, 12:04:43 PM
 #4796

On a side note - what's the record for the longest period without finding a block? I have a feeling it's gonna be broken shortly...... Grin

(we usually find one when I mention something about it - let's hope it happens again.....soon Cheesy)
Over 4 days.... looks like we will have lots of short blocks soon ;]

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

Activity: 924


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


View Profile WWW
April 03, 2013, 12:19:35 PM
 #4797

On a side note - what's the record for the longest period without finding a block? I have a feeling it's gonna be broken shortly...... Grin

(we usually find one when I mention something about it - let's hope it happens again.....soon Cheesy)
Over 4 days.... looks like we will have lots of short blocks soon ;]

What - twice in three months? I wouldn't bet on it......

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

Activity: 783



View Profile
April 03, 2013, 12:45:19 PM
 #4798

I've been mining LTC on p2pool for almost a week now.  The pool seems to solve over 20 blocks per day.

You are in a maze of twisty little passages, all alike.
maqifrnswa
Sr. Member
****
Offline Offline

Activity: 454


View Profile
April 03, 2013, 03:45:15 PM
 #4799

I still don't see why a slightly longer share chain long poll time would be bad. It would let the slower miners get a share in easier before being cut off and helps higher latency. It would benefit just about everyone. It's still PPLNS so the payouts would still be equal to the balance of shares.
Longer LP means higher difficulty ...

yes, but it will be a pittance compared to ASIC. I'm using +32 difficulty now. I would go even higher but p2pool has problems or the work DOA because of age.

The real problem is the DOA because of latency, and whether we should change p2pool just for Avalons. BFL single FPGAs don't work on p2pool for the exact same reason (latency), and BFL has claimed (for what it's worth) that they designed the SCs so that they will work with p2pool. I don't have much of an opinion either way yet, but I wanted to show the numbers so people know what they are getting in to.

It may seem like a pittance for you now, but when everyone has ASICs it will be noticeable and currently the smaller GPU miners may feel it. And in the future, smaller miners may mean jalapenos, not GPU.

There are currently 241 users on p2pool right now (unique address, at least)
The current variance in pseduoshares is:
86400 seconds/day
10 seconds/pseudoshare
8640 pseudoshares/day
~36 pseudoshares per user per day
Variance = sqrt(36) = 6 shares (or ~17%)


Under the proposed 30 second block time target:
86400 seconds/day
30 seconds/pseudoshare
2880 pseudoshares/day
~12 pseudoshares per user per day
Variance = sqrt(12) = 3.5 shares (or ~29%)


So the average user (which in the future will be an ASIC user) will see  their variance increase from 17% per day to 29% per day. Again, I'm not trying to express an opinion - just show what the numbers are so others can form opinions.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
April 03, 2013, 10:32:08 PM
 #4800

I still don't see why a slightly longer share chain long poll time would be bad. It would let the slower miners get a share in easier before being cut off and helps higher latency. It would benefit just about everyone. It's still PPLNS so the payouts would still be equal to the balance of shares.
Longer LP means higher difficulty ...

yes, but it will be a pittance compared to ASIC. I'm using +32 difficulty now. I would go even higher but p2pool has problems or the work DOA because of age.

The real problem is the DOA because of latency, and whether we should change p2pool just for Avalons. BFL single FPGAs don't work on p2pool for the exact same reason (latency), and BFL has claimed (for what it's worth) that they designed the SCs so that they will work with p2pool. I don't have much of an opinion either way yet, but I wanted to show the numbers so people know what they are getting in to.
...
The reason BFL FPGA's suck on p2pool is that it takes ~5s to complete any work and it doesn't respond before the 5s is finished.
Since LP is 10s that means a LARGE % of time wasted/stale/DOA

If it is 60GH/s, a BFL SC Single would take ~72ms to complete any work ... so yeah it's rather obvious it will work fine on p2pool.
It's simply the faster nonce time vs 10s that makes the difference, there is no real difference in the WAY it processes that fixes the problem.

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
Pages: « 1 ... 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 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 ... 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!