[∞ YH] solo.ckpool.org 2% fee solo mining USA/DE 255 blocks solved!

[os2sam]

How would one go about viewing the data sent to a miner over stratum?

I would use Wireshark

[1714093400]

1714093400

[1714093400]

1714093400

[-ck]

In the first post you said "All you need to confirm you are mining to your own address is to examine the coinbase and template sent to you over stratum."

How would one go about viewing the data sent to a miner over stratum?

Start cgminer in debug mode and dump the output to a log. Adding the options: -D -P -T 2>log.txt
Cgminer gives a hex dump of all the stratum fields, you can examine the coinbase fields. The part of the coinbase that determines which wallet you are mining to doesn't change for the life of a stratum connection.

[-ck]

I see some people trying to authenticate on this pool with regular usernames. Please note you can ONLY mine on this pool with a valid bitcoin address as your username!

[WBF1]

question/scenario:

Lets say I have 8 equal devices.

If my goal is to use 1/8 of my work as a "lottery entry" in trying to find a block solo mining, is there a difference between the following 2 scenarios?

scenario 1) running 1 of these devices on solo pool full time and the other 7 on a regular pool full time

scenario 2) running all 8 of these devices for 1/8 time on solo pool and 7/8 time on a regular pool

or put another way, is there any difference between a low hashrate over a longer amount of time or a proportionally higher hashrate over a proportionally shorter amount of time when solo mining?

[-ck]

question/scenario:

Lets say I have 8 equal devices.

If my goal is to use 1/8 of my work as a "lottery entry" in trying to find a block solo mining, is there a difference between the following 2 scenarios?

scenario 1) running 1 of these devices on solo pool full time and the other 7 on a regular pool full time

scenario 2) running all 8 of these devices for 1/8 time on solo pool and 7/8 time on a regular pool

or put another way, is there any difference between a low hashrate over a longer amount of time or a proportionally higher hashrate over a proportionally shorter amount of time when solo mining?

It makes no difference overall. However there is benefit to one device running full time on solo pool as the mining works better when it's not flicking from one pool to another repeatedly.

[marto74]

I just find this tread.
Great project .
It is better than casino for a bit coiner with small hash rate;)
Congratz
I will take the gamble with 1+ TH
happy solo mining all

[WBF1]

I just find this tread.
Great project .
It is better than casino for a bit coiner with small hash rate;)
Congratz
I will take the gamble with 1+ TH
happy solo mining all

you must have cheap electricity my 1.6TH costs about $6 a day, but I can make .022 BTC/day elsewhere, consistently.

[WBF1]

question/scenario:

Lets say I have 8 equal devices.

If my goal is to use 1/8 of my work as a "lottery entry" in trying to find a block solo mining, is there a difference between the following 2 scenarios?

scenario 1) running 1 of these devices on solo pool full time and the other 7 on a regular pool full time

scenario 2) running all 8 of these devices for 1/8 time on solo pool and 7/8 time on a regular pool

or put another way, is there any difference between a low hashrate over a longer amount of time or a proportionally higher hashrate over a proportionally shorter amount of time when solo mining?

It makes no difference overall. However there is benefit to one device running full time on solo pool as the mining works better when it's not flicking from one pool to another repeatedly.

you mean in terms of a "ramp up" period so to speak?

[-ck]

It makes no difference overall. However there is benefit to one device running full time on solo pool as the mining works better when it's not flicking from one pool to another repeatedly.

you mean in terms of a "ramp up" period so to speak?

Mainly the issue is that pools have slightly different times they notify you of the block change and during that period you are working on data from the old and the new block. Then what happens is both pools tell you to restart your work and every time you do that you throw out work and have to wait for the device to start doing meaningful work again. Strictly speaking only the work from the new block really matters, but the main issue is that you are sending your devices multiple restart messages and they usually work best with as few restarts as possible. There are also some newer devices (like ava2/3) that actually can only work on one pool at a time due to their design.

[WBF1]

It makes no difference overall. However there is benefit to one device running full time on solo pool as the mining works better when it's not flicking from one pool to another repeatedly.

you mean in terms of a "ramp up" period so to speak?

Mainly the issue is that pools have slightly different times they notify you of the block change and during that period you are working on data from the old and the new block. Then what happens is both pools tell you to restart your work and every time you do that you throw out work and have to wait for the device to start doing meaningful work again. Strictly speaking only the work from the new block really matters, but the main issue is that you are sending your devices multiple restart messages and they usually work best with as few restarts as possible. There are also some newer devices (like ava2/3) that actually can only work on one pool at a time due to their design.

Interesting. Yeah the way I have it set currently is to switch pools every hour in a rotate fashion, with 19 identical pool entries and one pool entry for ckpool. That should devote 1/20 of my mining time (5%) to ckpool. My other pool is PPS, so i'm not concerned with that.

Are you basically saying that even though I'm not actively mining on a pool, it can send a restart work and cause a restart for the pool I actually am actively mining on?

[-ck]

Interesting. Yeah the way I have it set currently is to switch pools every hour in a rotate fashion, with 19 identical pool entries and one pool entry for ckpool. That should devote 1/20 of my mining time (5%) to ckpool. My other pool is PPS, so i'm not concerned with that.

Are you basically saying that even though I'm not actively mining on a pool, it can send a restart work and cause a restart for the pool I actually am actively mining on?

Rotate is different again. Each failover mechanism has its positives and negatives. In rotate mode you'll lose a small amount of work every time you switch which is different to the problem in load-balance mode where you are connected to multiple pools at the same time - that's what I'm describing above.

[WBF1]

Interesting. Yeah the way I have it set currently is to switch pools every hour in a rotate fashion, with 19 identical pool entries and one pool entry for ckpool. That should devote 1/20 of my mining time (5%) to ckpool. My other pool is PPS, so i'm not concerned with that.

Are you basically saying that even though I'm not actively mining on a pool, it can send a restart work and cause a restart for the pool I actually am actively mining on?

Rotate is different again. Each failover mechanism has its positives and negatives. In rotate mode you'll lose a small amount of work every time you switch which is different to the problem in load-balance mode where you are connected to multiple pools at the same time - that's what I'm describing above.

Gotcha. Yeah load-balance is a no-go with a proxy device (running 2 AM tubes through BFGMiner as a proxy so I can have failover and stats I can easily digest).

So when I rotate I lose a little bit of work. Is it dependant on various factors or a set number of shares/percentage, so to speak? I haven't seen rejects or stales when switching thus far.

EDIT: also hashrate doesn't seem to dip when switching, though worker difficulty goes down then back up.

[-ck]

So when I rotate I lose a little bit of work. Is it dependant on various factors or a set number of shares/percentage, so to speak? I haven't seen rejects or stales when switching thus far.

EDIT: also hashrate doesn't seem to dip when switching, though worker difficulty goes down then back up.

It's only a very small amount lost (I wrote the failover strategies to be as seamless as possible), and happens with every switch. If you're not switching frequently like every minute you almost certainly won't notice a thing so it is the best option.

[WBF1]

So when I rotate I lose a little bit of work. Is it dependant on various factors or a set number of shares/percentage, so to speak? I haven't seen rejects or stales when switching thus far.

EDIT: also hashrate doesn't seem to dip when switching, though worker difficulty goes down then back up.

It's only a very small amount lost (I wrote the failover strategies to be as seamless as possible), and happens with every switch. If you're not switching frequently like every minute you almost certainly won't notice a thing so it is the best option.

Alright that makes sense. I'll be rolling the dice then for 1 hour out of every 20

[Krak]

Statistics:
To access this, enter your BTC address at the end of: http://solo.ckpool.org/users/

I entered my wallet address at the end of this URL and all I get is:
{"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "0", "hashrate1d": "0", "hashrate7d": "0", "workers": 1}

Do I need to be hashing for a certain length of time before the hashrate data values get filled in?

EDIT:
hashrate data values are filling in but don't make a lot of sense
{"hashrate1m": "389", "hashrate5m": "389", "hashrate1hr": "389", "hashrate1d": "684", "hashrate7d": "1.3K", "workers": 1}

{"hashrate1m": "194", "hashrate5m": "194", "hashrate1hr": "194", "hashrate1d": "453", "hashrate7d": "1.18K", "workers": 1}

{"hashrate1m": "97", "hashrate5m": "97", "hashrate1hr": "97", "hashrate1d": "300", "hashrate7d": "1.08K", "workers": 1}

I'm running a 7GH BFL Jalapeno - everything looks fine when I run it from a command line..

Have you gotten past the initial 1024 difficulty and all of the subsequent drops? It might take a bit for the stats to stabilize.

[-ck]

To the person trying to mine with an asicminer tube on this pool, the tubes have a broken stratum implementation and will not work on the regular pool, but there is a special instance for these devices alone on solo.ckpool.org:3334

[CrazyGuy]

Lightweight C based pool software, and open source! I'm really excited about this project and interested to see where it's going. Great work!

[-ck]

Lightweight C based pool software, and open source! I'm really excited about this project and interested to see where it's going. Great work!

Thanks. While I've made the link to the source publicly available from this thread, I have not yet made a public announcement or a "release" version for the software, but that will be coming soon, now that the first of the comprehensive mining pool options with ckpool at their core are starting to come online.

[-ck]

Do you support testnet?

No I don't but I could easily set one up on a separate VPS. However these servers do have running costs and there's not much in the way of incentive with running a testnet pool is there?

No:) Just asking.

Since you asked...

http://testnet.ckpool.org

Now offering testnet mining on its own node for people wishing to test their configuration only or for hardware development testing!

Note that you must be using a testnet bitcoin address to be able to mine on this edition.

If you find this additional service useful, please consider a donation to the author since there are no fees to be gained from running this pool.

[-ck]

Full announcement of the first public release of the ckpool code: https://bitcointalk.org/index.php?topic=790323.0