Bitcoin Forum
March 19, 2024, 05:58:36 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 [33] 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 ... 814 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2591571 times)
Rubberduckie
Legendary
*
Offline Offline

Activity: 1442
Merit: 1000



View Profile
February 12, 2012, 07:28:00 PM
 #641

(I'm getting 33% stales atm with -i8 -g1 and powertune @ 20)

1710827916
Hero Member
*
Offline Offline

Posts: 1710827916

View Profile Personal Message (Offline)

Ignore
1710827916
Reply with quote  #2

1710827916
Report to moderator
1710827916
Hero Member
*
Offline Offline

Posts: 1710827916

View Profile Personal Message (Offline)

Ignore
1710827916
Reply with quote  #2

1710827916
Report to moderator
1710827916
Hero Member
*
Offline Offline

Posts: 1710827916

View Profile Personal Message (Offline)

Ignore
1710827916
Reply with quote  #2

1710827916
Report to moderator
The trust scores you see are subjective; they will change depending on who you have in your trust list.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710827916
Hero Member
*
Offline Offline

Posts: 1710827916

View Profile Personal Message (Offline)

Ignore
1710827916
Reply with quote  #2

1710827916
Report to moderator
1710827916
Hero Member
*
Offline Offline

Posts: 1710827916

View Profile Personal Message (Offline)

Ignore
1710827916
Reply with quote  #2

1710827916
Report to moderator
ThiagoCMC
Legendary
*
Offline Offline

Activity: 1204
Merit: 1000

฿itcoin: Currency of Resistance!


View Profile
February 12, 2012, 08:23:27 PM
 #642

Hi!

 I just "git pull" p2pool and I'm seeing:

Code:
2012-02-12 17:15:34.299531 > Error while calling merged getauxblock:
2012-02-12 17:15:34.299732 > Traceback (most recent call last):
2012-02-12 17:15:34.299992 > Failure: twisted.internet.defer.TimeoutError: Getting http://127.0.0.1:7333/ took longer than 5 seconds.

But my namecoind is running normally...

Any thoughts?!

Never mind...
ThiagoCMC
Legendary
*
Offline Offline

Activity: 1204
Merit: 1000

฿itcoin: Currency of Resistance!


View Profile
February 12, 2012, 09:55:39 PM
 #643

My sencond block for P2Pool!!

Awesome! I find 2 blocks within one week!!! With only ~6GHash!

Code:
2012-02-12 05:34:41.298564 GOT BLOCK FROM MINER! Passing to bitcoind! bitcoin: 6ce97b20b9c71d2f686d2d5cf2e0b1d4e9ef9f2196c06cd0909
2012-02-12 05:34:41.305530 GOT BLOCK FROM PEER! Passing to bitcoind! a5065536 bitcoin: 6ce97b20b9c71d2f686d2d5cf2e0b1d4e9ef9f2196c06cd0909

hihihihi!!
LightRider
Legendary
*
Offline Offline

Activity: 1500
Merit: 1021


I advocate the Zeitgeist Movement & Venus Project.


View Profile WWW
February 13, 2012, 01:14:08 AM
Last edit: February 13, 2012, 02:23:24 AM by LightRider
 #644

Thinking about the growth problem, I was contemplating solutions that might be feasible. I began thinking about how we could evenly and fairly distribute hash power so that everyone is in a sub-p2pool that would benefit both them, and the bitcoin network at large. I imagine a system where the a miner's geolocation was determined, either using geoip services, or allowing the miner to specify their location, and then using that data to connect to others in the same graticule (1 degree x 1 degree area on the globe). If that graticule does not provide enough hashing power to produce blocks on a desired basis, then that subpool will connect with neighboring graticules. Each subpool is represented in the hash chain by a hash of all the graticules that the subpool serves. Subpools would have to determine if they should reconfigure themselves on a certain timescale to redistribute hashing power as needed. I know it sounds complicated, but I really think it would be an interesting solution to a unique problem.

Edit: Of course, one of the other issues that this would help with is latency, which I didn't mention originally, but is a big reason to base it off of geoip.

Bitcoin combines money, the wrongest thing in the world, with software, the easiest thing in the world to get wrong.
Visit www.thevenusproject.com and www.theZeitgeistMovement.com.
ThiagoCMC
Legendary
*
Offline Offline

Activity: 1204
Merit: 1000

฿itcoin: Currency of Resistance!


View Profile
February 13, 2012, 02:18:41 AM
 #645

I'm thinking in go to solo-mining!! LOL

Code:
2012-02-12 23:32:23.111945 GOT BLOCK FROM MINER! Passing to bitcoind! bitcoin: 6b0770b31d1ee4150d78cd738b028b3a904aa30ed992c2ea1a4
2012-02-12 23:32:23.144027 GOT BLOCK FROM PEER! Passing to bitcoind! 4ed95f7f bitcoin: 6b0770b31d1ee4150d78cd738b028b3a904aa30ed992c2ea1a4

I never find so many blocks within a so little time window... Tongue
ThiagoCMC
Legendary
*
Offline Offline

Activity: 1204
Merit: 1000

฿itcoin: Currency of Resistance!


View Profile
February 13, 2012, 02:23:54 AM
 #646

Thinking about the growth problem, I was contemplating solutions that might be feasible. I began thinking about how we could evenly and fairly distribute hash power so that everyone is in a sub-p2pool that would benefit both them, and the bitcoin network at large. I imagine a system where the a miner's geolocation was determined, either using geoip services, or allowing the miner to specify their location, and then using that data to connect to others in the same graticule (1 degree x 1 degree area on the globe). If that graticule does not provide enough hashing power to produce blocks on a desired basis, then that subpool will connect with neighboring graticules. Each subpool is represented in the hash chain by a hash of all the graticules that the subpool serves. Subpools would have to determine if they should reconfigure themselves on a certain timescale to redistribute hashing power as needed. I know it sounds complicated, but I really think it would be an interesting solution to a unique problem.

I have two questions for you:

1- WHEN the P2Pool difficulty will be bad for small miners? When we reaches 1THash, 2THash, 4THash?!

2- This reallocation to sob-pools can be done automatically, right?

Cheers,
Thiago
twmz
Hero Member
*****
Offline Offline

Activity: 737
Merit: 500



View Profile
February 13, 2012, 04:49:22 AM
 #647

1- WHEN the P2Pool difficulty will be bad for small miners? When we reaches 1THash, 2THash, 4THash?!

Much sooner than that.  Some might say it is already bad for small miners.  But I suppose it depends on what you consider "bad for small miners"?  If it takes a typical miner several hours to find a share, that is going to lead to painful variance.

I made a chart to illustrate what happens as the pool gets larger.  The chart is based on an overall bitcoin difficulty of 1.4 million (approx what we are now and will be for the next round).

Here is what the chart shows:

  • The solid red line is the average time for the pool to find a block as the pool's hashrate grows.
  • The dotted lines are the average time for miners of various sizes to find a SHARE as the pool's size increases and the share difficulty increases with it.
  • The point where a dotted line crosses the solid red line is the point at which the average time for a miner to find a share becomes larger than the time for the pool to find a block.



Here is a large version: https://i.imgur.com/77zM9.png


Was I helpful?  1TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs
WoT, GPG

Bitrated user: ewal.
kano
Legendary
*
Offline Offline

Activity: 4438
Merit: 1794


Linux since 1997 RedHat 4


View Profile
February 13, 2012, 04:55:20 AM
 #648

Thinking about the growth problem, I was contemplating solutions that might be feasible. I began thinking about how we could evenly and fairly distribute hash power so that everyone is in a sub-p2pool that would benefit both them, and the bitcoin network at large. I imagine a system where the a miner's geolocation was determined, either using geoip services, or allowing the miner to specify their location, and then using that data to connect to others in the same graticule (1 degree x 1 degree area on the globe). If that graticule does not provide enough hashing power to produce blocks on a desired basis, then that subpool will connect with neighboring graticules. Each subpool is represented in the hash chain by a hash of all the graticules that the subpool serves. Subpools would have to determine if they should reconfigure themselves on a certain timescale to redistribute hashing power as needed. I know it sounds complicated, but I really think it would be an interesting solution to a unique problem.

I have two questions for you:

1- WHEN the P2Pool difficulty will be bad for small miners? When we reaches 1THash, 2THash, 4THash?!

2- This reallocation to sob-pools can be done automatically, right?

Cheers,
Thiago
Interesting, the reduction in variance caused by pools is in fact a problem for P2Pool due to the amount of network data to deal with a pseudo-chain ...
P2Pools solution is already to increase the variance (block difficulty much > 1)
But suggesting to reduce the size of the actual pools themselves makes P2Pool sound like it's going to end up only being good for big hash rate miners.
Having to increase the variance (both ways) to solve the problem sounds bad IMO ...

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
twmz
Hero Member
*****
Offline Offline

Activity: 737
Merit: 500



View Profile
February 13, 2012, 05:07:10 AM
 #649

1- WHEN the P2Pool difficulty will be bad for small miners? When we reaches 1THash, 2THash, 4THash?!

I made a chart to illustrate what happens as the pool gets larger.  The chart is based on an overall bitcoin difficulty of 1.4 million (approx what we are now and will be for the next round).

Here is what the chart shows:

  • The solid red line is the average time for the pool to find a block as the pool's hashrate grows.
  • The dotted lines are the average time for miners of various sizes to find a SHARE as the pool's size increases and the share difficulty increases with it.
  • The point where a dotted line crosses the solid red line is the point at which the average time for a miner to find a share becomes larger than the time for the pool to find a block.

On the other hand, the higher the pool hash rate, the sooner your found-share turns into a payment.  Currently, if you are a 200 MH/s miner and find a share (about once every 3-4 hours on average), you may have to wait 8-10 hours for the pool to find a block and turn that share into BTC.  If the pool hashrate gets up to 1TH/s, you may only find a share every 13-14 hours, but the pool will likely find a block within an hour or two and turn that share into a payment.

Variance math hurts my head and I can't wrap my brain around how to quantify how the two competing variances (pool variance interacting with miner variance) contribute to a miner's overall payment variance.  Need someone like Meni to enlighten me, I guess.

Was I helpful?  1TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs
WoT, GPG

Bitrated user: ewal.
ThiagoCMC
Legendary
*
Offline Offline

Activity: 1204
Merit: 1000

฿itcoin: Currency of Resistance!


View Profile
February 13, 2012, 05:24:13 AM
 #650

So, in the end of the day, what is the best approach for miners?!

Can something like P2Pool be built without this pseudo-chain?! Something complete new... Between actual pools and P2Pool... I guess...  O_o
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 3920
Merit: 2347


Eadem mutata resurgo


View Profile
February 13, 2012, 06:34:56 AM
 #651

So, in the end of the day, what is the best approach for miners?!

Can something like P2Pool be built without this pseudo-chain?! Something complete new... Between actual pools and P2Pool... I guess...  O_o

Based on that nice plot above of "twmc" it seems that the 'optimal' solution will be p2pools will split up according to size of the miners.

I.e. bigger miners will go in one p2pool that has time-of-share and time-of-block nearly the same, medium sized miners will go in separate pool with similar set-up and smaller miners will go in another pool with similar time-of-share to time-of-block ratio.

Maybe throw in some variation due to location of miners and network latency to skew it a little.

So anyone want to start another p2pool for "less than big" miners?

chunglam
Donator
Full Member
*
Offline Offline

Activity: 229
Merit: 106



View Profile
February 13, 2012, 06:36:06 AM
 #652

1- WHEN the P2Pool difficulty will be bad for small miners? When we reaches 1THash, 2THash, 4THash?!

I made a chart to illustrate what happens as the pool gets larger.  The chart is based on an overall bitcoin difficulty of 1.4 million (approx what we are now and will be for the next round).

Here is what the chart shows:

  • The solid red line is the average time for the pool to find a block as the pool's hashrate grows.
  • The dotted lines are the average time for miners of various sizes to find a SHARE as the pool's size increases and the share difficulty increases with it.
  • The point where a dotted line crosses the solid red line is the point at which the average time for a miner to find a share becomes larger than the time for the pool to find a block.

On the other hand, the higher the pool hash rate, the sooner your found-share turns into a payment.  Currently, if you are a 200 MH/s miner and find a share (about once every 3-4 hours on average), you may have to wait 8-10 hours for the pool to find a block and turn that share into BTC.  If the pool hashrate gets up to 1TH/s, you may only find a share every 13-14 hours, but the pool will likely find a block within an hour or two and turn that share into a payment.

Variance math hurts my head and I can't wrap my brain around how to quantify how the two competing variances (pool variance interacting with miner variance) contribute to a miner's overall payment variance.  Need someone like Meni to enlighten me, I guess.

According to P2Pool Wiki
Quote
Each share contains a generation transaction that pays to the previous n shares, where n is the number of shares whose total work is equal to 3 times the average work required to solve a block, or 8640, whichever is smaller.
So you still got payout as long as your shares are still in sharechain of last n shares(3 times the average work required to solve a block, or 8640, whichever is smaller).
kano
Legendary
*
Offline Offline

Activity: 4438
Merit: 1794


Linux since 1997 RedHat 4


View Profile
February 13, 2012, 07:22:14 AM
 #653

...
According to P2Pool Wiki
Quote
Each share contains a generation transaction that pays to the previous n shares, where n is the number of shares whose total work is equal to 3 times the average work required to solve a block, or 8640, whichever is smaller.
So you still got payout as long as your shares are still in sharechain of last n shares(3 times the average work required to solve a block, or 8640, whichever is smaller).
Actually that's a rather interesting definition (yes I've seen it before) but realised something else about it:
Since ... the average work required to solve a block is adjusted based on the number of miners (bigger difficulty means less shares per block) and the average work/shares per block drops as more people mine and thus it should pretty much always be 8640 once it gets there.
So you'll need at least one in the last 8640 shares to get paid anything ...
Hmm ... actually it's already almost down to 8640 now isn't it? (by calculation)

Edit: Yeah once share difficulty reaches 470
Edit2: It's 468 at the moment?

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
Ente
Legendary
*
Offline Offline

Activity: 2126
Merit: 1001



View Profile
February 13, 2012, 07:26:35 AM
 #654

Based on that nice plot above of "twmc" it seems that the 'optimal' solution will be p2pools will split up according to size of the miners.

That is my first thought too.
A big pool, with high share-difficulty and with the bigger miners.
A sub-pool, with its own sharechain, where small miners work. The sub-pool would request work from the big pool, just as the sub-pool would be one of the bigger miners.

That way all miners would have payouts in short timeframes, and the small miners would have fine-grained enough proof-of-their-work too.

The small miners would have one (or double) the hops, with higher latency accordingly.
There might be more centralization with this setup too.

Ente
1Pakis
Full Member
***
Offline Offline

Activity: 227
Merit: 100



View Profile
February 13, 2012, 07:45:42 AM
 #655


Is that normal for ~370Mhs?

Tips are welcome at this address 18DVZkpSwmejPjekX3QMKvRRtR8Bfx65LN.
Regex
Newbie
*
Offline Offline

Activity: 23
Merit: 0



View Profile
February 13, 2012, 08:19:29 AM
Last edit: February 13, 2012, 08:39:44 AM by Regex
 #656

https://i.imgur.com/6MJLY.png
Is that normal for ~370Mhs?


yes.


Btw: 3 blocks in 1 hour, wth  Shocked
Ed
Member
**
Offline Offline

Activity: 69
Merit: 10


View Profile
February 13, 2012, 09:07:40 AM
 #657

my logfile is fast growing  Shocked
how I can cut it?

where I can see full run_p2pool.exe options list?
1Pakis
Full Member
***
Offline Offline

Activity: 227
Merit: 100



View Profile
February 13, 2012, 09:54:41 AM
 #658


Is that normal for ~370Mhs?


yes.


Btw: 3 blocks in 1 hour, wth  Shocked
It 's actually 3 shares in 11 min 8 sec
But over a period of ~28 hour only 12 shares.
According to reported time per share from p2pool I should get about 12 to 18 shares per 24 hours.

Tips are welcome at this address 18DVZkpSwmejPjekX3QMKvRRtR8Bfx65LN.
chunglam
Donator
Full Member
*
Offline Offline

Activity: 229
Merit: 106



View Profile
February 13, 2012, 10:26:00 AM
 #659

10 blocks in last 24 hours Grin
Regex
Newbie
*
Offline Offline

Activity: 23
Merit: 0



View Profile
February 13, 2012, 10:36:25 AM
 #660

https://i.imgur.com/6MJLY.png
Is that normal for ~370Mhs?


yes.


Btw: 3 blocks in 1 hour, wth  Shocked
It 's actually 3 shares in 11 min 8 sec
But over a period of ~28 hour only 12 shares.
According to reported time per share from p2pool I should get about 12 to 18 shares per 24 hours.

Are you aware of the term "variance" ?
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 [33] 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 ... 814 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!