Bitcoin Forum
March 19, 2024, 09:12:50 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 [615] 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 ... 814 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2591571 times)
windpath
Legendary
*
Offline Offline

Activity: 1258
Merit: 1027


View Profile WWW
March 10, 2015, 01:29:08 PM
 #12281

Just translating p2pool as it exists into C, C++, C#, Objective C, Swift, Java, Perl, Lisp, whatever, is not going to suddenly bring the mining masses here.  I know a number of us have listed out the problems previously, and a number of us have had discussions on potential solutions to those problems; however, nobody has been able to successfully crack the nut.  Maybe the problem is that we're all trying to solve p2pool's problems while keeping ourselves in the context of the existing structure.  Let's try another approach.  Forget p2pool even exists.

We as a community want a new pool to be created.  Here is a list of high-level bullet points we would want to have in our new pool:

  • Decentralized
  • Easy to use
  • Performant
  • Scalable
  • Inclusive

Please feel free to add to these points and/or provide more details/solutions.

This is exactly what I'm suggesting JB - a complete re-write. But in order to achieve this I think we should do the donation bounty option from within the current p2pool structure, as it's (I think) an excellent way of raising awareness in the community as well as raising funds, while the amount of work involved in making the changes are minimal & simple.

Nothing happening with this then I presume?  Sad

Stagnation is a killer.

I've been continuing to noodle on it.

Was at the MIT BTC expo this past weekend and was able to bring up the issues with some pretty smart folks.

The consensus seemed to lean toward addressing the payment threshold and scheme as the key issue, the rest can be addressed by a rewrite in a language like C++.

The challenge is to come up with a method to accumulate payouts for smaller miners within the pool, in a decentralized and trust-less way, so that they can be paid out at some threshold above what is considered dust.

The often proposed solution was to centralize the dust payments and payout from a trusted party. This is essentially what Nasty Pool has done, and its a great service for smaller miners, however the fact that it requires trust would take away a lot of what P2Pool has to offer, and I don't consider it a long term solution.

I'm in touch with a couple of the folks I met, including a dev who has the chops to pull it off (with an attractive bounty), however he is just as stuck as we are until we can come up with a solution for accumulating smaller payouts in a trust-less way...



Every time a block is mined, a certain amount of BTC (called the subsidy) is created out of thin air and given to the miner. The subsidy halves every four years and will reach 0 in about 130 years.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1344
Merit: 1023


Mine at Jonny's Pool


View Profile WWW
March 10, 2015, 01:58:02 PM
 #12282

I don't know that concentrating on how to accumulate and distribute the smaller "dust" payouts is the most critical item to address.  I agree it's an issue that would arise; however, it's only going to rear it's head once the variance problem is solved.

Right now, the minimum share value in p2pool is higher than the dust threshold.  There's even code in p2pool as it is currently written to ensure you get more than a dust payout:

Code:
if expected_payout_per_block < self.node.net.PARENT.DUST_THRESHOLD:
    desired_share_target = min(desired_share_target,
        bitcoin_data.average_attempts_to_target((bitcoin_data.target_to_average_attempts(self.node.bitcoind_work.value['bits'].target)*self.node.net.SPREAD)*self.node.net.PARENT.DUST_THRESHOLD/block_subsidy)
                    )

It's certainly an interesting paradox.  Effectively we are saying the share difficulty must be lowered so that smaller miners do not feel the effects of p2pool's inherent variance.  However, the code also has to say that if you're going to receive a dust payout, increase your share difficulty so you don't - which means you're right back at the high share difficulty causing the variance for the small miners.

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
windpath
Legendary
*
Offline Offline

Activity: 1258
Merit: 1027


View Profile WWW
March 10, 2015, 02:01:37 PM
 #12283

I don't know that concentrating on how to accumulate and distribute the smaller "dust" payouts is the most critical item to address.  I agree it's an issue that would arise; however, it's only going to rear it's head once the variance problem is solved.

Right now, the minimum share value in p2pool is higher than the dust threshold.  There's even code in p2pool as it is currently written to ensure you get more than a dust payout:

Code:
if expected_payout_per_block < self.node.net.PARENT.DUST_THRESHOLD:
    desired_share_target = min(desired_share_target,
        bitcoin_data.average_attempts_to_target((bitcoin_data.target_to_average_attempts(self.node.bitcoind_work.value['bits'].target)*self.node.net.SPREAD)*self.node.net.PARENT.DUST_THRESHOLD/block_subsidy)
                    )

It's certainly an interesting paradox.  Effectively we are saying the share difficulty must be lowered so that smaller miners do not feel the effects of p2pool's inherent variance.  However, the code also has to say that if you're going to receive a dust payout, increase your share difficulty so you don't - which means you're right back at the high share difficulty causing the variance for the small miners.

Agreed, but say in a re-write you could increase efficiency 10x, and 10x the # of shares in the chain (that may be optimistic), now you have a chain that can support many more smaller miners, but need a method to address the dust payouts...

Edit: The only way I know to fix the variance issue is to grow global p2pool hashrate.
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1344
Merit: 1023


Mine at Jonny's Pool


View Profile WWW
March 10, 2015, 02:29:29 PM
 #12284

I don't know that concentrating on how to accumulate and distribute the smaller "dust" payouts is the most critical item to address.  I agree it's an issue that would arise; however, it's only going to rear it's head once the variance problem is solved.

Right now, the minimum share value in p2pool is higher than the dust threshold.  There's even code in p2pool as it is currently written to ensure you get more than a dust payout:

Code:
if expected_payout_per_block < self.node.net.PARENT.DUST_THRESHOLD:
    desired_share_target = min(desired_share_target,
        bitcoin_data.average_attempts_to_target((bitcoin_data.target_to_average_attempts(self.node.bitcoind_work.value['bits'].target)*self.node.net.SPREAD)*self.node.net.PARENT.DUST_THRESHOLD/block_subsidy)
                    )

It's certainly an interesting paradox.  Effectively we are saying the share difficulty must be lowered so that smaller miners do not feel the effects of p2pool's inherent variance.  However, the code also has to say that if you're going to receive a dust payout, increase your share difficulty so you don't - which means you're right back at the high share difficulty causing the variance for the small miners.

Agreed, but say in a re-write you could increase efficiency 10x, and 10x the # of shares in the chain (that may be optimistic), now you have a chain that can support many more smaller miners, but need a method to address the dust payouts...

Edit: The only way I know to fix the variance issue is to grow global p2pool hashrate.
Increasing global pool hash rate serves to help mitigate variance at a pool level, not a miner level.  Yes, we'd expect the pool to find blocks more frequently, but now we're faced with the higher and higher share difficulty because the hash rate has increased.  As you stated, even if we could become 10x more efficient - which would basically mean going from 30 second share time to 3 second share time - this is only a bandaid.  And, at 3 seconds a share, you're going to start running into a ton of orphans and rejects as latency between miners/nodes/network plays a more significant role.

Let's say we abandon the idea of a share chain altogether.  How can we decentralize and make trust-less the work a miner has done and the payments the miner is owed upon block find for that work?

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
windpath
Legendary
*
Offline Offline

Activity: 1258
Merit: 1027


View Profile WWW
March 10, 2015, 02:36:47 PM
 #12285

Let's say we abandon the idea of a share chain altogether.  How can we decentralize and make trust-less the work a miner has done and the payments the miner is owed upon block find for that work?

Interesting thought, were you thinking something like a weighted share pool where shares are accepted by the pool by consensus and then expire based on weight?

How could you trust that each node accepts shares it should without a chain?
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1344
Merit: 1023


Mine at Jonny's Pool


View Profile WWW
March 10, 2015, 03:00:54 PM
 #12286

Let's say we abandon the idea of a share chain altogether.  How can we decentralize and make trust-less the work a miner has done and the payments the miner is owed upon block find for that work?

Interesting thought, were you thinking something like a weighted share pool where shares are accepted by the pool by consensus and then expire based on weight?

How could you trust that each node accepts shares it should without a chain?
Exactly my line of thinking, and you've raised exactly the question that has stumped me... how to ensure that each/every node knows of the work of miners on other nodes.  Using PoW blockchain technology like the share chain is the obvious answer, and it's what forrestv did in his work.  Unfortunately, the solution just isn't scalable using standard PoW blockchain tech.  Maybe some other kind of proof?  For example, PoS coins certainly don't rely upon massive hash rates to support them or their blockchains.  I'm not sure a PoS approach would work, it was just an example... but could we devise some kind of proofing algorithm that would allow work to be broadcast and shared across nodes?

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
squidicuz
Newbie
*
Offline Offline

Activity: 58
Merit: 0


View Profile
March 10, 2015, 04:05:20 PM
 #12287

Just translating p2pool as it exists into C, C++, C#, Objective C, Swift, Java, Perl, Lisp, whatever, is not going to suddenly bring the mining masses here.  I know a number of us have listed out the problems previously, and a number of us have had discussions on potential solutions to those problems; however, nobody has been able to successfully crack the nut.  Maybe the problem is that we're all trying to solve p2pool's problems while keeping ourselves in the context of the existing structure.  Let's try another approach.  Forget p2pool even exists.

We as a community want a new pool to be created.  Here is a list of high-level bullet points we would want to have in our new pool:

  • Decentralized
  • Easy to use
  • Performant
  • Scalable
  • Inclusive

Please feel free to add to these points and/or provide more details/solutions.

This is exactly what I'm suggesting JB - a complete re-write. But in order to achieve this I think we should do the donation bounty option from within the current p2pool structure, as it's (I think) an excellent way of raising awareness in the community as well as raising funds, while the amount of work involved in making the changes are minimal & simple.

Nothing happening with this then I presume?  Sad

Stagnation is a killer.

I've been continuing to noodle on it.

Was at the MIT BTC expo this past weekend and was able to bring up the issues with some pretty smart folks.

The consensus seemed to lean toward addressing the payment threshold and scheme as the key issue, the rest can be addressed by a rewrite in a language like C++.

The challenge is to come up with a method to accumulate payouts for smaller miners within the pool, in a decentralized and trust-less way, so that they can be paid out at some threshold above what is considered dust.

The often proposed solution was to centralize the dust payments and payout from a trusted party. This is essentially what Nasty Pool has done, and its a great service for smaller miners, however the fact that it requires trust would take away a lot of what P2Pool has to offer, and I don't consider it a long term solution.

I'm in touch with a couple of the folks I met, including a dev who has the chops to pull it off (with an attractive bounty), however he is just as stuck as we are until we can come up with a solution for accumulating smaller payouts in a trust-less way...


Damn! I wanted to go to that conference and completely forgot when the day came.  Was hoping to meet some like minds and discuss p2pool... Shame I missed out.

Anyway, I have some programming experience and would be interested in assisting with development and fixes where I can.  Though I am just as stuck with actually coming up with a solution to these issues.  Here are some crazy idea...

What if the share-chain played less of an important role in deciding proof of work?  Currently something like 10% of the shares are discarded anyway, and sometimes those discarded shares are even valid bitcoin blocks!  While we would need the sharechain to keep track of the historical proof of work for the miners on the pool, we should find a way to have the pools sidechain play less of a critical role in the race to decide valid work.  Right now it functions as a microcosm of the greater bitcoin mining space, the share chain is like the main chain just valid work to the sharechain mostly counts to only the sharechain.  That should change.  The sharechain should be something on the side and not the main focus. It should be just for maintaining consensus, not deciding miners work.

Instead of what we do now, what if there was a window where valid work/shares could be accepted? This could allow for more than one tip of the chain to exist at a time, but as long as the gap between heights of the multiple chains isn't too large, we can keep consensus. There can be a rule so if the desync between the chains is too large, then less valid shares will reject until total consensus is restored.  I am not sure how to actually implement that, and will have to look into the practicality of it...  This could help with a higher hashrate miner saturating the share finding rate and wasting their work on just the sidechain.

This will make the issue of cognitive distortion potentially worse (or better), but reduce the amount of dead work from race conditions. There would have to be a system in place where instead of the tip of the chain being the confirmed head, the actual tip would be unknown and the actual head would be several shares behind the tip(s). So after (i.e.) 3 shares the head would be decided, but with multiple potential tips... The tips would exist concurrently, the head would lag beyond and assure total consensus.  So you would submit a share, and it wouldn't be considered completely valid until several following [miner] shares confirm it. The work you submitted would be counted from the tips found and then validated at the head.

Then on top of that, (if the POW difficulty is still way too high)... Instead of each payout being decided at time of a block found and accurred valid shares, for smaller miners, would it be possible to store what would be considered dust within the pool itself? If we set it up so each node keeps track of the smaller payouts in a multi sig wallet that is handled by the pool and acts as an escrow, this could allow for a smaller miner to submit work that would be normally be too minimal, and have it incur to a payout that would be more than a dust transaction.
In addition to storing just the dust payouts, since a payout isn't totally decided at the time of last share, the main payouts could be stored within this multi-node/sig wallet in case there isn't clear consensus [within the pool] following the solving of a bitcoin block.

I don't even know if this is all possible, just some thoughts... please pull them apart.
topminingcontracts
Hero Member
*****
Offline Offline

Activity: 532
Merit: 500


TaaS is a closed-end fund designated to blockchain


View Profile WWW
March 11, 2015, 01:40:33 PM
 #12288

Just my mind dump:

In my mind, p2pool needs to see a block every two - three days to stay alive...  Beyond three days work is completely discarded.

I'm a noob, but correct me if I'm wrong.   There's a finite number of blocks discovered, and if P2Pool doesn't have the hash they will be solved by other pools... so "luck" is disproportionately lost as the hash goes down. 

Slush is running at 10-11PH, and yesterday with over 200% luck it found 8 blocks.  100% means 4 blocks a day at 10 PH/s.

so if we're running at 2.5PH/s at 100% luck.. 1 per day might be expected by may not be realistic as larger pools could steal them away before they are solved, no?

Watching rented hash or home grown hash fall off the share list after 3 days is a deal killer.   P2Pool will not continue to retain hash if multiple 4 & 5 day intervals occur on a regular basis.

Seems like P2Pool needs 2-3PH/s minimum  to be viable with the current software state and difficulty.

When I log in and see 1-1.5PH/s I think the 7 day delays are going to continue popping up.

Can someone tell me if my thinking is screwed up?

Well ANY pool needs to have at least 1% of total hashrate to be considered as a solution for the luck factor, today is 3.2 PH.

Having said that P2pool has the potential to become a quite big mining pool.

Require some more active development probably.

Regards


 
 
           ▄████▄
         ▄████████▄
       ▄████████████▄
     ▄████████████████▄
    ████████████████████      ▄█▄                 ▄███▄                 ▄███▄                 ▄████████████████▀   ▄██████████

  ▄▄▄▀█████▀▄▄▄▄▀█████▀▄▄▄     ▀██▄             ▄██▀ ▀██▄             ▄██▀ ▀██▄             ▄██▀                   ██
▄█████▄▀▀▀▄██████▄▀▀▀▄█████▄     ▀██▄         ▄██▀     ▀██▄         ▄██▀     ▀██▄         ▄██▀        ▄█▄          ▀██████████████▄
████████████████████████████       ▀██▄     ▄██▀         ▀██▄     ▄██▀         ▀██▄     ▄██▀          ▀█▀                        ██
 ▀████████████████████████▀          ▀██▄ ▄██▀             ▀██▄ ▄██▀     ▄█▄     ▀██▄ ▄██▀                                       ██
   ▀████████████████████▀              ▀███▀                 ▀███▀       ▀█▀       ▀███▀      ▄███████████████████████████████████▀
     ▀████████████████▀
       ▀████████████▀
         ▀████████▀
           ▀████▀
║║


║║
.
.

║║
██
║║
.
.

║║
██
║║
.
║║


║║
Meuh6879
Legendary
*
Offline Offline

Activity: 1512
Merit: 1011



View Profile
March 11, 2015, 06:20:36 PM
 #12289

Luck is very high this week ...  Cheesy
http://minefast.coincadence.com/p2pool-stats.php
windpath
Legendary
*
Offline Offline

Activity: 1258
Merit: 1027


View Profile WWW
March 11, 2015, 06:30:47 PM
 #12290

Luck is very high this week ...  Cheesy
http://minefast.coincadence.com/p2pool-stats.php

It is, finding a block 1.5 hours after the previous when expected time was over a day is a nice boost Smiley

2015-03-10 09:11:03    346974 2,930.23%   
2015-03-10 07:40:31    346962 179.39%   
lightfoot
Legendary
*
Offline Offline

Activity: 3080
Merit: 2222


I fix broken miners. And make holes in teeth :-)


View Profile
March 11, 2015, 08:40:17 PM
 #12291

Luck is very high this week ...  Cheesy
http://minefast.coincadence.com/p2pool-stats.php

It is, finding a block 1.5 hours after the previous when expected time was over a day is a nice boost Smiley

2015-03-10 09:11:03    346974 2,930.23%   
2015-03-10 07:40:31    346962 179.39%   
Yup. Normal variance. Luck is luck.

But it is nice. :-) Edit: We found another one? Oh yeah, this is good times. Remember it when we go a few days with no blocks, the manna will return.
yslyung
Legendary
*
Offline Offline

Activity: 1500
Merit: 1002


Mine Mine Mine


View Profile
March 12, 2015, 12:56:41 AM
 #12292

pour more hash in & be luckier.
IYFTech
Hero Member
*****
Offline Offline

Activity: 686
Merit: 500


WANTED: Active dev to fix & re-write p2pool in C


View Profile
March 12, 2015, 01:30:44 AM
 #12293

pour more hash in & be luckier.

No it won't, It'll make it worse cos of the scalability problem. More hash power makes the problem worse, not better  Sad

No bounty = no development = no fix.

I actually pointed a few S3's at my node because the rise in BTC made it worth a gamble, but if the hash rate gets too high I'll pull them off again - it's a crazy situation  Tongue

-- Smiley  Thank you for smoking  Smiley --  If you paid VAT to dogie for items you should read this thread:  https://bitcointalk.org/index.php?topic=1018906.0
yslyung
Legendary
*
Offline Offline

Activity: 1500
Merit: 1002


Mine Mine Mine


View Profile
March 12, 2015, 01:48:50 AM
 #12294

pour more hash in & be luckier.

No it won't, It'll make it worse cos of the scalability problem. More hash power makes the problem worse, not better  Sad

No bounty = no development = no fix.

I actually pointed a few S3's at my node because the rise in BTC made it worth a gamble, but if the hash rate gets too high I'll pull them off again - it's a crazy situation  Tongue

true but atm 6m is not high for p2p imo, still bearable for now. i do point mine from time to time to keep the shares especially when diff is low.
Chupacabras
Member
**
Offline Offline

Activity: 166
Merit: 10


View Profile
March 13, 2015, 11:33:56 AM
 #12295

Bitcoin Wallet

Have you guys had transactions that have not gone thru? or Unconfirmed?

If so, how do you fix it?

I did a google search and it says to close the wallet and reopen, but i have done that a few time already.


Thanks.
IYFTech
Hero Member
*****
Offline Offline

Activity: 686
Merit: 500


WANTED: Active dev to fix & re-write p2pool in C


View Profile
March 13, 2015, 11:45:21 AM
 #12296

Bitcoin Wallet

Have you guys had transactions that have not gone thru? or Unconfirmed?
 

From p2pool? Never.

Sounds like a wallet problem - you should ask in the appropriate support thread  Wink

-- Smiley  Thank you for smoking  Smiley --  If you paid VAT to dogie for items you should read this thread:  https://bitcointalk.org/index.php?topic=1018906.0
topminingcontracts
Hero Member
*****
Offline Offline

Activity: 532
Merit: 500


TaaS is a closed-end fund designated to blockchain


View Profile WWW
March 13, 2015, 02:44:10 PM
 #12297

Bitcoin Wallet

Have you guys had transactions that have not gone thru? or Unconfirmed?

If so, how do you fix it?

I did a google search and it says to close the wallet and reopen, but i have done that a few time already.


Thanks.

Yes twice.

Never when I include a pool fee.

J


 
 
           ▄████▄
         ▄████████▄
       ▄████████████▄
     ▄████████████████▄
    ████████████████████      ▄█▄                 ▄███▄                 ▄███▄                 ▄████████████████▀   ▄██████████

  ▄▄▄▀█████▀▄▄▄▄▀█████▀▄▄▄     ▀██▄             ▄██▀ ▀██▄             ▄██▀ ▀██▄             ▄██▀                   ██
▄█████▄▀▀▀▄██████▄▀▀▀▄█████▄     ▀██▄         ▄██▀     ▀██▄         ▄██▀     ▀██▄         ▄██▀        ▄█▄          ▀██████████████▄
████████████████████████████       ▀██▄     ▄██▀         ▀██▄     ▄██▀         ▀██▄     ▄██▀          ▀█▀                        ██
 ▀████████████████████████▀          ▀██▄ ▄██▀             ▀██▄ ▄██▀     ▄█▄     ▀██▄ ▄██▀                                       ██
   ▀████████████████████▀              ▀███▀                 ▀███▀       ▀█▀       ▀███▀      ▄███████████████████████████████████▀
     ▀████████████████▀
       ▀████████████▀
         ▀████████▀
           ▀████▀
║║


║║
.
.

║║
██
║║
.
.

║║
██
║║
.
║║


║║
Meuh6879
Legendary
*
Offline Offline

Activity: 1512
Merit: 1011



View Profile
March 13, 2015, 10:04:42 PM
 #12298

Never.

be carefull to not associate finding a block (by the p2pool) and the ability of "win" job reward by shares.

shares indicate the amount of bitcoins ... and finding a block ... do the transaction.
if p2pool find a block ... and you don't have emit share (because of your power hash), it's normal.

with my 32GH/s = 1 pay reward per month only.
zvs
Legendary
*
Offline Offline

Activity: 1680
Merit: 1000


https://web.archive.org/web/*/nogleg.com


View Profile WWW
March 14, 2015, 05:37:38 AM
 #12299

Just my mind dump:

In my mind, p2pool needs to see a block every two - three days to stay alive...  Beyond three days work is completely discarded.

I'm a noob, but correct me if I'm wrong.   There's a finite number of blocks discovered, and if P2Pool doesn't have the hash they will be solved by other pools... so "luck" is disproportionately lost as the hash goes down. 

Slush is running at 10-11PH, and yesterday with over 200% luck it found 8 blocks.  100% means 4 blocks a day at 10 PH/s.

so if we're running at 2.5PH/s at 100% luck.. 1 per day might be expected by may not be realistic as larger pools could steal them away before they are solved, no?

Watching rented hash or home grown hash fall off the share list after 3 days is a deal killer.   P2Pool will not continue to retain hash if multiple 4 & 5 day intervals occur on a regular basis.

Seems like P2Pool needs 2-3PH/s minimum  to be viable with the current software state and difficulty.

When I log in and see 1-1.5PH/s I think the 7 day delays are going to continue popping up.

Can someone tell me if my thinking is screwed up?

Well ANY pool needs to have at least 1% of total hashrate to be considered as a solution for the luck factor, today is 3.2 PH.

Having said that P2pool has the potential to become a quite big mining pool.

Require some more active development probably.

Regards

Probably more a case of all the ASIC companies keeping their ASICs and using their own pools. 

they don't seem to keen on giving up future profits for having a little extra $ on hand immediately.  so they then price these ASICs at some absurd price, so only some mining hobbiest will buy them,  so  p2pool grows much slower than these ASIC companies chinese pools
IYFTech
Hero Member
*****
Offline Offline

Activity: 686
Merit: 500


WANTED: Active dev to fix & re-write p2pool in C


View Profile
March 14, 2015, 11:12:09 AM
 #12300

...so p2pool grows much slower than these ASIC companies......

Grows? Where is the "growth"? Look at the last 6 months:



The reason p2pool doesn't grow is because it can't handle the scalability. Every other pool manages to grow. Blaming p2pools problems on asics manufacturers is just plain wrong I'm afraid. It's a p2pool problem & nobody else's, & always has been.

-- Smiley  Thank you for smoking  Smiley --  If you paid VAT to dogie for items you should read this thread:  https://bitcointalk.org/index.php?topic=1018906.0
Pages: « 1 ... 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 [615] 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 ... 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!