[1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff]

[jake262144]

What's up, Doc? We're getting hit with some un-BitMinter-esque stale rates.
While 0.8% stales might blend into the crowd anywhere else, here it stands out like a nude in a convent.

[Turbor]

  veni vidi vici

[malavita]

veni vidi vici

+1

[ZodiacDragon84]

What's up, Doc? We're getting hit with some un-BitMinter-esque stale rates.
While 0.8% stales might blend into the crowd anywhere else, here it stands out like a nude in a convent.

Could it maybe be my use of GPUmax occasionally?

[DrHaribo]

Not sure what caused those stales. But yes, GPUmax can give high stales, both from buying shares and sometimes also from sending your own shares through GPUmax.

That said, I have higher stales than normal right now too (0.2%). But it's only 15 stales, so it may not be significant.

[jake262144]

Any progress pinpointing the source of those stales?
Mint is hitting 1% stale rate at 103 GHash/s - it doesn't look like GPUMAX is to blame...

EDIT:: I've been getting slow LPs lately - maybe that's some sort of a clue.

[DrHaribo]

Server lagging a bit. I think that's the reason for the stales - sometimes getting slow response. Looking into it.

[malavita]

Server lagging a bit. I think that's the reason for the stales - sometimes getting slow response. Looking into it.

Very low stales - great fix?

[DrHaribo]

Very low stales - great fix?

Not 100% sure what the problem was. I restarted the pool backend with different settings for the java virtual machine. May have to tweak that a bit further. Before restarting I saved a heap dump of the running backend - will analyze that today.

Anyway, it's running now with settings I have used before and it seems to be working very smoothly.

[jake262144]

Ummm... the pool has been down since 12:02 UTC.

[DrHaribo]

Sorry for the downtime. Looks like there is a problem with the pool backend. I'll start working on that in about 2 hours. Looks like it's the same issue that was causing slow reaction and high stales. I hope things will run ok with low stales until I get it fixed. At least the pool should not go down again.

Again, very sorry for these issues.

[DeathAndTaxes]

Long post Warning:
(hit the scroll wheel down if not interesting in my ramblings on Bitminter, p2pool and a stronger/decentralized network)

BitMinter has been a great place to mine. Dr. Haribo is an awesome pool op and one I have no problems trusting with large sums of coins.  I have however finished migrating my farm to p2pool.  I joined BitMinter (way back when we had 30GH/s and I was 10 of them ) because I was concerned about the risk large pools represented.  I decided to put my hashing power where my mouth was and it has been an interesting experience.

It wasn't an easy decision as I have grown attached to BitMinter but I have moved to p2pool because I feel it is the best "weapon" against an increasingly centralized Bitcoin.   Small pools find it difficult to grow due to variance which keeps them small and thus they have higher variance (and the cycle repeats).  Even if a pool does grow there is always the risk it displaces a fallen giant, becomes a giant itself and the risk remains.  Thus I now believe that "medium sized pools" are unstable.  They either decline or grow and while the top few pools may change mining will be dominated by a dynamic of a few super pools and lots of tiny ones.

That being said there are issues which make p2pool non optimal for small miners so pools (hopefully smaller pools) have a role to play.  We talked about it briefly weeks ago but i believe a hybrid pool which uses p2pool as a back end is the missing link.  It is a symbiotic relationship.  The hybrid pool and p2pool gains significantly reduced variance from increased hashing power.  Both are now more competitive at attracting their respective "core audience".  If BitMinter sent hashing power to p2pool then p2pool (and BitMinter) would have an average block generation time of <4 hours.

It is the integration of small & medium sized pools which will move p2pool to the next level.   I believe large farms, hybrid pools and "subp2pools" can form a decentralized backbone.   This is necessary for p2pool to grow beyond that TH/s level and maybe someday provide 51% of the hashing power.

It looks like this guy has taken that idea and run with it:
https://bitcointalk.org/index.php?topic=66202.0

Granted he only has 5GH/s (native) and a crude interface but I admire his spirit.  One thing i would point out is he enjoys about 70% less variance than BitMinter despite his tiny size.  Minters don't jump ship that wasn't the point.  I believe BitMinter could do it better using existing codebase and Dr. H experience as a solid pool ope.  I think BitMinter could grow to be one of the largest pools by offering a decentralized alternative for those who don't want to either use large centralized pools, get slammed by the variance of small pools or run their own p2pool instance.

A hybrid pool involves a few components
a) Running p2pool daemon (pool can provide it a static "vanity" address for payment)*
b) Issue getworks generated by p2pool to users
c) When miners returns shares:
   1) record diff 1 hashes (shares) for reward splits (same as now)
   2) forward share-chain diff hashes (currently ~600) to p2pool network
   3) broadcast full diff hashes (solved blocks) to Bitcoin network (same as now)

* p2pool may need to be either re-coded or integrated into existing pool backend to handle higher getwork volume.

When p2pool finds a block all miners payment addresses are already in the coinbase to payment is secure.  Bitminter would then take the sum it receives and split it among miners based on shares recorded in step b above.  This is very similar to how BitMinter pays out now.   Each day instead of having 1 or 2 blocks where it is the only payee in the coinbase it would have 6 to 12 blocks where it is one of many payees in the coinbase.

An example of the coinbase split can be seen here (this is the reward split in every hash worked by every miner):
http://p2pool.info/  (1p2pool is my vanity address, bitminter could advertise as say 1Minter )

I leave an open offer to assist with building/testing/experimenting with a BitMinterHybrid.  I also understand that it isn't something to be done lightly so a copy of the BitMinter code & database could be moved to a seperate "test instance" to test p2pool integration without interrupting the mainline pool.

I am willing to provide whatever is needed:
a) hashing power pointed at a server including remote access to the rig if needed.  No need for payment, no worries if it has 99% stales, instances crashes, etc.  All my rigs are 2GH/s (no you don't get the rack-mounted water cooled one ).  If we getting it working with one I am willing to donate all of them to provide further testing.
b) funding for servers, equipment, or anything else that is needed
c) coding work (while I can't take the lead I can provide assistance, bug checking, etc)
d) technical details on p2pool and optimizations (I have spent a large amount of time looking over the p2pool codebase)

If Dr. H doesn't want to be involved but would consider selling BitMinter code & database structure (not data) I would be willing to purchase it.  This would be an independent project, fully de-branded, not having any affiliation to BitMinter.  It would just provide a rapid template for building a 200GH/s capable hybrid pool.  I know he has worked extensively on the pool backend with little compensation this would be an opportunity to monetize it.   I will donate an extra 10% for Dr.H to offers as a block bonus to miners of BitMinter.

If Dr. H never wants to take me up on either offer no hard feeling.  If he gets the urge in a week, month, year the offer remains open.  I have enjoyed my time mining here.  I am sincere when I say BitMinter has the best pool op, a great layout, and an awesome community of miners.

Last Edit: 2/29/2012 09:54 - improved clarity of some parts, cut ramblings by 1.8%.

[malavita]

You will be missed, D&T - lot to learn from you

Best!

[DrHaribo]

D&T, I agree with what you are saying about variance. I have long been thinking about how this could best be done, pools cooperating in a "pool of pools". I believe that can even things out so that people join pools for their features, not for their size (which is a self-reinforcing thing, causing the biggest pool so stay biggest no matter what).

About 51% attacks on bitcoin and securing against this, I believe what Luke-jr. is doing with expanding on the "getmemorypool" json-rpc interface can be a solution. Also for making pooled mining totally transparent. We've been discussing that in another thread. It would make it impossible for the pool op to hide blocks from miners (stealing the 50 BTC), and could also prevent a pool op from using your hash power in a 51% attack, or using your hash power to pool hop other pools without your knowledge. I intend to implement getmemorypool as an alternative to getwork on BitMinter and build some features around that to make mining more transparent and give miners more control.

I think "getmemorypool" with the expanded functionality will fix a lot of problems with pools. So what remains is the backbone or "pool of pools" which could enable a small pool with better features to beat a bigger pool. It could make variance a non-issue and finally let miners and pool ops focus on everything else.

So what about p2pool? I think p2pool has a couple of problems due to its reward system being based on a chain of proofs of work. I see two problems which is a reason I don't think p2pool is good for end users: A small p2pool, if I understand it correctly, is vulnerable to 51% attack on the reward chain. Someone with 300 GH/s today (a hopper proxy or pool?) could hook up to p2pool and cash out every bitcoin that is created. Everyone else would be mining for free, giving away all their income to the attacker. And a big p2pool, well, the difficulty on the reward chain would approach the difficulty of bitcoin, and make p2pool useless.

What about p2pool as a "pool of pools" backend? The 51% attack could be scary. The difficulty issue makes it useless for the smallest pools. And 10 second long poll means the server is doing long polls all the time. Things like x-roll-ntime become useless. There's no way around it, the server spends all its time pumping out new work to every single miner. You need much faster servers and use a lot of resources simply because of the way p2pool is designed. If you can't do it quickly enough, your stale rate on the reward chain will sky rocket, payouts will drop and the pool dies.

I have some ideas how stales on the reward chain could be reduced. But I see no way to prevent 51% attacks or p2pool creating very high server loads when used by a pool. Otherwise I would have switched already. I would love a tool to make variance less significant.

The only way I see how to fix this is by making a pool backbone that doesn't use a reward chain, but works a little differently. I have a lot of ideas for this. But I'm not sure how much point there is to working on that. I'm not sure if any pools would join a backbone. There isn't much interest for "getmemorypool" either.

[DeathAndTaxes]

 I understand p2pool is different and has unique issues.  It will require more getworks per effective GH/s.  Also the hardest load on a server is at the LP (where every client needs to be updated) and it with short LP interval the server will be pretty continually loaded.  So if it is something you feel is uneconomical I understand.  You know better than me the load requirement a large pool can produce.   If you wish to sell the code I am still interested.  I believe it can be overcome (maybe naively) and if more powerful servers are necessary it may just require higher fees.  If not then either someone else will do it or I will need to start from scratch.

So what about p2pool? I think p2pool has a couple of problems due to its reward system being based on a chain of proofs of work. I see two problems which is a reason I don't think p2pool is good for end users: A small p2pool, if I understand it correctly, is vulnerable to 51% attack on the reward chain. Someone with 300 GH/s today (a hopper proxy or pool?) could hook up to p2pool and cash out every bitcoin that is created. Everyone else would be mining for free, giving away all their income to the attacker. And a big p2pool, well, the difficulty on the reward chain would approach the difficulty of bitcoin, and make p2pool useless.

I don't believe this is true.   The reward split is based on the share chain.   The coinbase of every hash contains the split of the share-chain.  This is why an LP occurs ~ every 10 seconds.   When a block is found by any miner it has the reward "hardcoded". 

Simplified (assume node has prior x shares)
a) node detects new share, LP issued.
b) node drops oldest share, adds newest share and tallies by address.
c) coinbase is constructed so that % of 50BTC = % of shares in tally
d) work (which has hash of merkle tree and coinbase locking in reward split) sent to miner
e1) when miner finds a hash < target for share chain it is submitted to network (goto a) updating reward split.
e2) when miner finds a hash < target for bitcoin the blocks reward split is already hardcoded into coinbase.

For example (current reward tab) shows what is put into the coinbase of every hash (until the next share is found and it is updated):
http://p2pool.info/  (current reward).

It is possible to fork p2pool (and sometimes that happens accidentally) but if you do so then any blocks found by the rest of p2pool network won't have any shares you find in their chain and thus any work you complete won't be accounted in the coinbase split.  An attacker which "51%" (which I believe is incorrect term) the share-chain can't alter the record of the prior shares.  They can cause a fork but the rest of the network will function as is.  Essentially they are solo mining.

And 10 second long poll means the server is doing long polls all the time.

There are potential solutions to increase the LP window and other issues (how to handle 1TH/s+, how balance share variance vs block variance, etc).  To avoid derailing the thread further I will save them for another discussion.

[DrHaribo]

I don't want to sell the BitMinter source code. It should be possible to hook up pushpool or poolserverj or something else to p2pool though. And there is already a pool running on top of p2pool.

When there is a split in the share chain, I would assume p2pool nodes will see multiple chains and go with the longest one, just like bitcoin does?

Imagine if I am an evil pool with 310 GH/s and you are the honest p2pool miners with 280 GH/s. I hop over to p2pool with my pool and start mining on top of your shares, entering the share chain. You then try to build shares on top of mine, but every time you do I create a fork. I only build shares on top of my own shares. My forks are always longer than yours, so you never get paid. I am now using 310 GH/s and getting paid for 590 GH/s. You get nothing.

How does p2pool prevent this? If it doesn't go with the fastest-growing fork or something similar, but just stays on the local fork whenever a fork occurs, then it would have forked into a whole bunch of solo miners a long time ago.

Also, I don't see a way to control the difficulty - it's based on the share chain.

Bitcoin block chain technology gives you a single advantage: decentralization (hard for bad guys to shut down). You have to pay for it with 51% attacks, high difficulty locking out small players, and in general very inefficient processing, especially with 10 second block intervals. In this instance I'm not sure if this is a good way forward.

If I'm wrong about 51% attacks, and the 10 second block intervals could be turned into 10 minutes, I'd jump on the bandwagon right now. (The remaining problem, difficulty/variance, is what pools are there to fix)

[rjk]

When there is a split in the share chain, I would assume p2pool nodes will see multiple chains and go with the longest one, just like bitcoin does?

My understanding is that miners can continue to mine on a split chain, and still be able to get valid blocks and payouts. They just have greater variance due to lower hash rate because of the split.

EDIT: I am however, not sure of the actual mechanics of a split - what causes them, and how they can be rectified if it were unwanted behavior. The splits I have heard of in the past I assumed were due to incompatible client versions and things like that.

[DrHaribo]

Quick backend restart. Fixed a memory leak and a couple other issues. The memory leak is what was causing the downtime today and the slow response which gave high stales earlier. Should be back to low stales, quick response and stable server. (knock on wood)

My understanding is that miners can continue to mine on a split chain, and still be able to get valid blocks and payouts. They just have greater variance due to lower hash rate because of the split.

Sure, it becomes like 2 separate p2pools. But I imagine all nodes end on the same fork after a while, to prevent degenerating into everyone solo mining by themselves.

Btw, awesome miner project you have.

[DeathAndTaxes]

Imagine if I am an evil pool with 310 GH/s and you are the honest p2pool miners with 280 GH/s. I hop over to p2pool with my pool and start mining on top of your shares, entering the share chain. You then try to build shares on top of mine, but every time you do I create a fork. I only build shares on top of my own shares. My forks are always longer than yours, so you never get paid. I am now using 310 GH/s and getting paid for 590 GH/s. You get nothing.

How would the good miners get nothing?

It does look like an exploit is possible but the exploit is non-economic or minimally economic.  51% attacks in Bitcoin are powerful because you can reverse prior transactions.  That isn't possible in p2pool.  Attacker could reject all other shares and only build on his chain but that only affects future shares.

There are a couple things that make that of limited value:
a) It will take 24 hours (at 51%) to get full value.  Attacker can't build the chain any faster and it will take 8640 shares to remove all prior "good" shares from the chain by attrition.  If attacker had been mining "good" (to avoid a noticeable instant doubling of hash power) then the effective hashpower of the attack chain would be half and it would take 48 hours to achieve full effect.  p2pool could keep a longer history to extend the full value time.

b) It is immediately obvious. all good nodes would see 100% reject rate.  The node currently doesn't have a "failsafe" but imlementing a max global orphaned in last x minutes check could make automated detection.  If global orphan rate spikes node stops issuing work and miners drop back to backup pools.  In the case of a hybrid pool it would drop to "conventional mode" (albeit with increased variance).

c) Attack has limited economic value as to achieve full value (200% pps) attacker would need to sustain the attack for 24/48 hours without any good miners dropping out.

d) Attacker can't work in secret.  In Bitcoin 51% attack since the goal is reversing a prior transaction an attacker can work days or even weeks in secret building an attack chain.  That doesn't work here because the value of any shares is "cashed out" when a block is found.  Every second attacker doesn't publish the attack chain is a second p2pool could find a block and make all the attack work worthless.

Still I am glad you brought it up.  A failsafe based on global orphan rate is a good feature to add to the node. 

Also, I don't see a way to control the difficulty - it's based on the share chain.
...
the 10 second block intervals could be turned into 10 minutes,

Difficulty can be controlled but it is linked to the LP interval.

Difficulty = (LP interval) * (p2pool network hashing power) / (2^32)

Right now p2pool uses a target LP interval of 10 seconds and has ~300 GH/s that gives it a share difficulty of ~690.

As a side note this is no different than Bitcoin.  Bitcoin targets a 10 minute block interval and has roughly 9.5 TH of hashing power (at the last adjustment) so it has a difficulty of ~1.3 million.

So (by consensus of hashing power) one could choose another interval and to support sub pools someday p2pool will likely need to have a longer interval.  10 minutes is far too long though as difficulty for a share would be a fraction of Bitcoin = p2pool hashing power.   Reverse way to look at it is p2pool lowers share difficulty by a) having less hashing power than bitcoind network and b) having a shorter interval.

A LP interval of 60 sec would require 6x the difficulty relative today for the same hashing power.   At say 1.5 TH/s that would mean a difficulty of ~21,000.  Very high but a tiny fraction of the block difficulty that pools currently shoot for (and the variance that comes with it).

[DrHaribo]

Yes, switching to solo mining if p2pool is 51% attacked is a good solution. You can detect it before losing much income, so it should be adequate.

Also, I'm starting to think maybe p2pool's problems with frequent block changes and high difficulty stem from copying bitcoin's block chain technique directly. P2pool has different needs. Maybe this can be fixed by doing things a little differently. Have to think about that.