PeerMining.us - Mining Pool - Instant Payouts - Proportional Payouts 0% FEES!

[BTCMiners.net]

PeerMining.us - Mining Pool - Instant Payouts - Proportional - 0% Fees.

- Proportional Payouts 0% fees.
- USA Based
- Long Polling Enabled
- Instant Payout
- API
- Detailed Statistics
- Planned - Pay-per-share (PPS)
- We will add more features at miners request.

Thank you !

www.PeerMining.us

Sign up your account, create a worker and point your miner here:

Hostname: mine.PeerMining.us
Port: 8332
Username: Username.[worker]
Password: [insert password here]

[1714161293]

1714161293

[1714161293]

1714161293

[1714161293]

1714161293

[BTCMiners.net]

Forums coming back soon by the way.

==UPDATED FEES TO 0.5%==

[akahs]

It looks like you're running under 80 MH/s. With proportional payouts isn't it
going to be a long time between payouts?

What makes your pool worth mining at when there's so many others and Pay-Per-Share offers
a much faster return on mining?

Also, the USD/BTC chart is broken. Trade Hill shut down a long time ago.

[BTCMiners.net]

It looks like you're running under 80 MH/s. With proportional payouts isn't it
going to be a long time between payouts?

What makes your pool worth mining at when there's so many others and Pay-Per-Share offers
a much faster return on mining?

Also, the USD/BTC chart is broken. Trade Hill shut down a long time ago.

Yes, at 80 MH/s it would be quite a while before one individual gets a block.  That's why we're accepting miners, so that the increase in hashing will help bring those numbers up.

What makes our pool worth mining at?  It's a straight 0.5% fee, most places make you pay a "donation" or PPS is sometimes 3-17%, so if enough people mine, the odds are higher you're going to get what you mine for, making it more fair.

The more shares you have per round on finding a block, the higher the payout is for you.

In regards to the graph being broken, we're aware of that.  Some things we are keeping as is, as we're working with the original developer of it on upgrading it.  We're aware Trade Hill is gone, along with the graph not working.

There will be some website updates coming soon, along with that, we'll be bringing our Xenforo forums back for everyone.

[BTCMiners.net]

Accepting new and Experienced Miners!

If you'd like to see something changed in our pool, please let us know too!

[BTCMiners.net]

Recent update, our pool is now at 0% fees and will remain 0% fee based to gain popularity.  Donations are gladly accepted, as of this time no fees will be taken.

[firefop]

~3500mh/s online for the next 14 days. This puts average time to find a block at ~40 days.

If we could get another 6.5 gh/s  --- we could bring our average time to find a block down to 14 days. C'mon folks, lets get it done.

Noticed a 2.5gh/s discrepency between the pool owners hashing numbers and reported statistics. I'm out.

This has been resolved to my satisfaction, turns out some software needs updating, and I wasn't reading as carefully as I thought.

[BTCMiners.net]

~3500mh/s online for the next 14 days. This puts average time to find a block at ~40 days.

If we could get another 6.5 gh/s  --- we could bring our average time to find a block down to 14 days. C'mon folks, lets get it done.

We're now at ~8.5GH/s total right now, keep 'em coming!

[BTCMiners.net]

~3500mh/s online for the next 14 days. This puts average time to find a block at ~40 days.

If we could get another 6.5 gh/s  --- we could bring our average time to find a block down to 14 days. C'mon folks, lets get it done.

Noticed a 2.5gh/s discrepency between the pool owners hashing numbers and reported statistics. I'm out.

The shares are logged, the front end is ~1 year old, which Xenland (the original developer) and I worked together on patching back together for it to work, so there could be some bugs in it.  I'm not sure how you calculated a 2.5 GH/s discrepancy; but I'd really like to figure out your math.

[Shadow383]

~3500mh/s online for the next 14 days. This puts average time to find a block at ~40 days.

If we could get another 6.5 gh/s  --- we could bring our average time to find a block down to 14 days. C'mon folks, lets get it done.

Noticed a 2.5gh/s discrepency between the pool owners hashing numbers and reported statistics. I'm out.

The hashrate number on there isn't very good, but the share totals on the stats page seem to be right 

[BTCMiners.net]

~3500mh/s online for the next 14 days. This puts average time to find a block at ~40 days.

If we could get another 6.5 gh/s  --- we could bring our average time to find a block down to 14 days. C'mon folks, lets get it done.

Noticed a 2.5gh/s discrepency between the pool owners hashing numbers and reported statistics. I'm out.

The hashrate number on there isn't very good, but the share totals on the stats page seem to be right  

Yes, the graphs and the hash rates aren't extremely accurate but the shares are 100% accurate as that number is directly pulled from MySQL.  The graphs are simple Java scripts that calculate your hash rate based on the time stamp and how often you send shares, so it's not actually reading your hash rate in real time, thus making it inaccurate from what I understand.  I'll see what I can do on fixing this, however, for now it won't be something that is immediately resolved since I believe an update of the entire website will be coming soon enough.

[BTCMiners.net]

Need a new pool?  Join Peer Mining!

www.PeerMining.us

[firefop]

Yes, the graphs and the hash rates aren't extremely accurate but the shares are 100% accurate as that number is directly pulled from MySQL.  The graphs are simple Java scripts that calculate your hash rate based on the time stamp and how often you send shares, so it's not actually reading your hash rate in real time, thus making it inaccurate from what I understand.  I'll see what I can do on fixing this, however, for now it won't be something that is immediately resolved since I believe an update of the entire website will be coming soon enough.

Oh crud - total shares - My mistake. I'll be editing my posts to reflect it.

As for the hash - I went ahead and sold my free hashes to someone so I won't be able to mine on your pool for the next 13 days... unless more hardware arrives --- if ASICs don't start shipping in october, I may just hit you up to 90% of pool capacity then. Is that number accurate... if not how much getwork could you actually handle?

[BTCMiners.net]

Yes, the graphs and the hash rates aren't extremely accurate but the shares are 100% accurate as that number is directly pulled from MySQL.  The graphs are simple Java scripts that calculate your hash rate based on the time stamp and how often you send shares, so it's not actually reading your hash rate in real time, thus making it inaccurate from what I understand.  I'll see what I can do on fixing this, however, for now it won't be something that is immediately resolved since I believe an update of the entire website will be coming soon enough.

Oh crud - total shares - My mistake. I'll be editing my posts to reflect it.

As for the hash - I went ahead and sold my free hashes to someone so I won't be able to mine on your pool for the next 13 days... unless more hardware arrives --- if ASICs don't start shipping in october, I may just hit you up to 90% of pool capacity then. Is that number accurate... if not how much getwork could you actually handle?

Currently we are working to be able to support both Getwork and Getblocktemplate.  Once we have Getblocktemplate, we'll be able to support a lot more.

[BTCMiners.net]

More miners are welcome!

[EngMan]

How many GH/s can you handle at the moment? What is your current approx hash rate? Hopping proof?

[BTCMiners.net]

How many GH/s can you handle at the moment? What is your current approx hash rate? Hopping proof?

Well based on the current maximum getwork rate it's 4GH/s with "rollntime" extension, we have a very very low stale rate less than 0.1% and even lower on rejected.

"The original getwork protocol only provides a single block header, which is sufficient for a total of about 4 GH of mining. With the "rollntime" extension, this can be extended to 4 GH *per second*, but even that is far from sufficient for the next generation of mining equipment (ASICs) which are capable of 1000 GH/s on the high end.
By moving block creation to the miners, they are enabled to create as much work as they need locally, thus overcoming this limitation."

Which is why we will be support both getwork and getblocktemplate in there very near future.

[Shadow383]

How many GH/s can you handle at the moment? What is your current approx hash rate? Hopping proof?

Well based on the current maximum getwork rate it's 4GH/s with "rollntime" extension, we have a very very low stale rate less than 0.1% and even lower on rejected.

"The original getwork protocol only provides a single block header, which is sufficient for a total of about 4 GH of mining. With the "rollntime" extension, this can be extended to 4 GH *per second*, but even that is far from sufficient for the next generation of mining equipment (ASICs) which are capable of 1000 GH/s on the high end.
By moving block creation to the miners, they are enabled to create as much work as they need locally, thus overcoming this limitation."

Which is why we will be support both getwork and getblocktemplate in there very near future.

Your pool can handle more than 4Gh/s - I tried pointing 19Gh/s your way for a few minutes and it held up 

[BTCMiners.net]

How many GH/s can you handle at the moment? What is your current approx hash rate? Hopping proof?

Well based on the current maximum getwork rate it's 4GH/s with "rollntime" extension, we have a very very low stale rate less than 0.1% and even lower on rejected.

"The original getwork protocol only provides a single block header, which is sufficient for a total of about 4 GH of mining. With the "rollntime" extension, this can be extended to 4 GH *per second*, but even that is far from sufficient for the next generation of mining equipment (ASICs) which are capable of 1000 GH/s on the high end.
By moving block creation to the miners, they are enabled to create as much work as they need locally, thus overcoming this limitation."

Which is why we will be support both getwork and getblocktemplate in there very near future.

Your pool can handle more than 4Gh/s - I tried pointing 19Gh/s your way for a few minutes and it held up 

Well that is from the Bitcoin wiki.  It does say 4GH *per second*, so I'm sure it can handle more, I'm just not exactly sure where the -actual- amount of total GH/s it can handle would be.  From my understanding its a limitation on the JSON being the 4 GH *per second*.

[chewie]

When do you plan on rolling out PPS for your pool, and what will the fees be?