Dev fund proposal: fixed 20%, opt in/out measure, minimal disrupt



Thats the way it works :slight_smile:

This is a solo mining pool so that single share IS the block solution, check the destination address to see if coins are turning up - they go out in the coinbase transaction so you should have ‘immature’ coins.

When you find a solution the pool starts on the next block, which for you is always going be an ‘odd’ one so the pool kicks your miner off… thats why it times out.

Edit: testnet is up to 141 sols now

1 Like

Changed the retry delay parameter to 0 seconds so it’s still timing out but immediately reconnecting, it appears to be working just as well
I’m fairly sure this is a claymore specific issue

Yeah, I see that, lol.

Your miner is desperetly trying to reconnect but its gotta wait for my puny little 1060 to find an ‘odd’ block before it will let you in to work on an ‘even’ one.

320 sols isn’t much & the difficulty is catching up… not long now until 150 second blocks.

Try reconnecting with the password set to ‘both’, it should run full speed then & no timeouts as the pool will allow it to work on every block.

There appears to be a parameter to change the timeout delay for ethereum Mining and Sia Decred dual mining but not for Zcash

@ChileBob Ok there should be a mini now
Similiar disconnect issues
Ill keep trying

yup - I see it trying to connect but its not happy, something weird with the pool that it doesn’t like - everything it sends is tagged as ‘invalid-solution’ & its the same problem I saw with garetht. Might as well turn that off for now.

At some point I’ll write a proxy so I can capture traffic & see whats going on - prob next week as I still owe sonya a user guide for zatsuma.

I switched my miner to ‘both’ so its doing all blocks now.

Try running your miner with the password set to ‘both’, betting the timeouts you see disappear

1 Like

The kernel log says this alot during the wait

But appears to have corrected itself after receiving new work

I’m going to monitor it and let it go see what happens
It still hasn’t reported any accepted shares however

Also Claymore just kind of decides on its own that the address is no longer valid after a while so…yeah!
I added a worker named to it, maybe that’ll help

The mini seems to handle waiting for the work, it just ramps up the fan speed for that amount of time and then once it starts solving again slows it back down, still no accepted shares from 320 discarded, 106 rejected, 27 stale

I went ahead and disconnected the mini, it’s a separate issue
the invalid address error on the gpu rig is because of the dev fee portion going on right now which is why it is an invalid address
Silly! :stuck_out_tongue_closed_eyes:
It doesn’t seem to be able to recover from it, I’ll try the no-fee flag as well as “both”

all good fun - I figured out why Claymore was timing out & that should be fixed now, I’d removed a few too many essential bits from the Ycash pool when I built this one. Ooops.

Almost silly-o-clock here so I’ll leave you to it, will leave the pool running & my miner on ‘both’

1 Like

The no fee flag appears to work, the Miner is still running which makes me wonder if it could be just that simple and that all of the coding is already done pretty much (currently the miner incurs a performance penalty for this flag, should the proposal go forward the miner should not be penalized or this)
It’s still times out but there are a lot of posts online about people complaining about Claymore doing this so I don’t know if you can do anything about it particularly, this is an old version 12.6 so ya know!

Try it with EWBF (0.3.3b), its not that fast & kinda old but works reliably for me.

Unfortunately it does not work on my machine, if you recall a certain Ycash Windows 10 debacle in which only LOL Miner would work!
I really think it could work in the Linux subsystem but I’m going to have to read more into about properly marrying the hardware

1 Like

The pool survivied the night, not bad for a quick & ugly hack :slight_smile:

I have to point my GPU at a different project today so the testnet hash will have to come from elsewhere - only one spare left now. I’ll leave the pool running so you can experiment.

1 Like

I disconnected last night before I went to bed, ran smooth
Ill reconnect when I get home later this afternoon

This Thread is obviously still open to any questions comments concerns pertaining to the proposal, don’t mind the mining up there!

Are you guys still using this test pool? I’ll need to turn it off at some point, let me know.

1 Like

No I haven’t connected since the last time, seems like it worked how we would want it with the miner being diverted to an alternate port for that period of time
(Like I mentioned above I think the big change is that the “default” should just be the opposite)

1 Like

OK. I’ll shut it down & keep the code handy in case you want to experiment some more.


2nd edit, apparently system didn’t like me quoting your whole post. kinda needs the end bit or it looks like im thanking you for shutting it down, heh.

Thanks, I haven’t had time to do anything but I would really like to test a couple of things on it, specifically rolling burn. where the burn goes to an address that can be spent.

I don’t have time at the moment. but would really appreciate it if you could help me in a few days. I am in UTC+1 timezone, so I don’t know how that fits with you. Will probably continue this over PM when I get the time, if that is okay.


Sure, just let me know what you need.

Its UTC-4 here, will be mixing concrete next week somewhere with dodgy internet but available in the evenings.