Topic: Sidehack stick solo pool club - page 19. (Read 27301 times)

baktegon here again!

I've got them working! all 4 sticks should be pointed at the sidehack pool. I'm using regular cgminer-gekko on an ubuntu HP desktop from ages ago. All four sticks are showing hashrate in cgminer so this is good! I'm still waiting on my usb hub to run these on the raspberry pi but for the next couple of days I should be good to go.

It looks like my stats are showing up at http://solo.ckpool.org/workers/1JiWuyX94wrCr7JhkAn7x5qNMCEef1KhqX.baktegonUnit01


thanks for the help all!

That would be a simple solution too. It's easy to periodically query the JSON stats of the workers and save that in a file. In fact, that's what the notification script does, although currently it only "remembers" the last query without a historical record, so every 90 seconds it would be updated.

That probably doesn't matter since the script stores the JSON results in its entirety, including the daily average. Should be enough to figure out the hash rate contribution given that people will notice that the club found a block in way less than a day. A solved block would be noticed in seconds, I suspect

That said, if there was interest in keeping a limited historical record, that would be pretty easy to add. I designed the stats file format so that it would be easy to extend with new data structures.

Note that instead of using the script directly, anyone familiar with Python could take a look at it as an example. Most of the complexity of the script comes from command line option handling and support for authenticated emails. The actual code that loops through a list of workers querying the JSON stats URLs is just a few lines of code.

In the meantime if Phil wants to play with the script as-is, I've PM'd him with the info to get started, plus a discussion of other additions that could be made to to the script.

It would have to have been offline for a sufficient amount of time to also impact the 1d rolling average pretty badly.  But yeah, otherwise - since you're poking at linux anyway - look up cron jobs  Can just download each participants' stats to a daily stats file and tally up the numbers as appropriate if/when a block is found.

I don't see any real problems with it other then how to deal with stick down time.  For now I am going to err on the generous side if a stick crashes and is offline when we hit a block. As long as everyone is pretty much okay with it that way.

hash is up for today  Fixed order  #636639  0.011 btc 5th

If it helps, I could extend my notification script so that it reports the hash rates of the monitored addresses at the time a block is hit.
[...]
There's other algorithms that we could consider, but it probably makes sense to keep this simple. Also, someone else might have a better way to do this. It doesn't hurt my feelings if someone has a better alternative.

If it helps, I could extend my notification script so that it reports the hash rates of the monitored addresses at the time a block is hit. Basically you (or anyone) could run the script with the published list of club workers. If a block is hit, anyone who is running the script will receive an email with the list of workers and their hash rates at that moment.

I know that most forum members have the utmost respect for you Phil. We trust that you'd accurately carve out the winnings.

But the nice thing about this approach is that anyone who cares about the result of a found block by the club can subscribe to notifications for the same club list. So there could be corroboration of the numbers by any forum member who wants to receive the notifications. It's kind of fitting that there's the opportunity of distributed validation of each other's hash rates. It mirrors the distributed underpinnings of the coin itself.

The current script resolution is plus or minus 5 minutes of a block discovery event, but that's easy to tighten up if desired. That said, it might not matter if the agreement is that we use the 1 day hash rate average, or something like that, to determine the reward split.

There's other algorithms that we could consider, but it probably makes sense to keep this simple. Also, someone else might have a better way to do this. It doesn't hurt my feelings if someone has a better alternative.

Of course since the likelihood of cracking a block is low, we should probably temper our efforts for whatever works and not spend too much time on an ideal solution.