Bitcoin Forum
December 03, 2016, 11:47:25 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 666 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2028944 times)
jonnybravo0311
Hero Member
*****
Offline Offline

Activity: 994


Mine at Jonny's Pool


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

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

Posts: 1480765645

View Profile Personal Message (Offline)

Ignore
1480765645
Reply with quote  #2

1480765645
Report to moderator
1480765645
Hero Member
*
Offline Offline

Posts: 1480765645

View Profile Personal Message (Offline)

Ignore
1480765645
Reply with quote  #2

1480765645
Report to moderator
1480765645
Hero Member
*
Offline Offline

Posts: 1480765645

View Profile Personal Message (Offline)

Ignore
1480765645
Reply with quote  #2

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

Posts: 1480765645

View Profile Personal Message (Offline)

Ignore
1480765645
Reply with quote  #2

1480765645
Report to moderator
1480765645
Hero Member
*
Offline Offline

Posts: 1480765645

View Profile Personal Message (Offline)

Ignore
1480765645
Reply with quote  #2

1480765645
Report to moderator
1480765645
Hero Member
*
Offline Offline

Posts: 1480765645

View Profile Personal Message (Offline)

Ignore
1480765645
Reply with quote  #2

1480765645
Report to moderator
windpath
Legendary
*
Offline Offline

Activity: 938


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

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

Activity: 994


Mine at Jonny's Pool


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

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

Activity: 50


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

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

Activity: 462



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

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: 1078



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

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

French ... but not so much   ---===---   P2P ... it's people at the end   ---===---   P2Pool (10,9 GH/s).
Comment miner des bitcoins ? Un tutoriel est là : https://bitcointalk.org/index.php?topic=1114415.0
Bitcoin change everything ... an explain of this fact : https://www.youtube.com/watch?v=joITmEr4SjY
windpath
Legendary
*
Offline Offline

Activity: 938


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

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: 980

Hacking KNC stuff because it goes FOOM well.


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

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: 1050


Mine Mine Mine


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

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

Activity: 686


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


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

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: 1050


Mine Mine Mine


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

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: 108


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

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.

LXC: DFfLxDJfbqXyVNsTeWuARGPfQ2YKRE6y1a
BTC: 1N3misAgyCTW7b5BQojoLx7p9ok39e52UV
Life is like a box of chocolate. Famous Runner Forrest Gump
IYFTech
Hero Member
*****
Offline Offline

Activity: 686


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


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

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

Activity: 462



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

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: 1078



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

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.

French ... but not so much   ---===---   P2P ... it's people at the end   ---===---   P2Pool (10,9 GH/s).
Comment miner des bitcoins ? Un tutoriel est là : https://bitcointalk.org/index.php?topic=1114415.0
Bitcoin change everything ... an explain of this fact : https://www.youtube.com/watch?v=joITmEr4SjY
zvs
Legendary
*
Offline Offline

Activity: 1386



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

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

Dacentec, best deals for US dedicated servers. They regularly restock $20-$25 Opterons with 8-16GB RAM & 2x1-2TB HDD's (ofc, usually lots of other good stuff to choose from).  I did a Serverbear benchmark of one of my $20/mo Opteron (June last year), it's here.  Have had about a half dozen different servers with Dacentec, & none have failed to sustain at least 40MB/s (burst higher). My favorite is a 12-month rent-to-own ZT Systems 2XL5520 16GB 2x2TB SATA for $40/month (got lucky with the 'off-brand', haven't seen a RTO 2xL5520 for under $50/mo since -- at least for monthly contracts).  wholesaleinternet.com has some ancient 2-core intel CPUs @ $10/mo sometimes (I got an Intel Core 2 6300 @ 1.86GHz, with a 250GB HDD with 46000 hours on it, LOL. $20 @ Dacentec is much better, if you can grab one). joesdatacenter.com (same location as Wholesale Internet) also occasionally has specials (or if you don't want to wait, it has an AMD Opteron 170 @ $16/mo).
IYFTech
Hero Member
*****
Offline Offline

Activity: 686


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


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

...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
aurel57
Legendary
*
Offline Offline

Activity: 1050



View Profile
March 14, 2015, 11:35:27 AM
 #12318

Threw some rental hash back at p2pool last night about 1 hour before that block was found.... wish I had done it earlier but can hope the pool finds another fast couple.
minerpool-de
Hero Member
*****
Offline Offline

Activity: 686


View Profile
March 14, 2015, 12:12:33 PM
 #12319

i take my Node offline. There are no p2pool Miner. 2 Months Uptime, 0% Fee and no p2pool Miner.  Huh

aurel57
Legendary
*
Offline Offline

Activity: 1050



View Profile
March 14, 2015, 05:12:43 PM
 #12320

Just received a small donation from someone on p2pool that was a suprise
Pages: « 1 ... 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 666 ... 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!