I'm not objecting but is it better if we have an hashpower criteria, e.g. if the pool hash reach 20g, then it's ok for the 24 shares bounty. So not every pool who has deploy the same code can apply this bounty.
The reason for the bounty is to see if Sidhujag's Daemon makes devcoin blocks that the old clients accept. We just need a single block for that. If it does, then we can make Sidhujag's the official client and archive the old one.
Ok, it make sense.
I thought it's for the mining business bounty... so it's basically a wallet testing bounty
The problem is with the devcoind daemon, or at least between the daemon and the server. I'm not sure if I've somehow inadvertently blocked access to the network for the devcoin daemon or what, but the other daemons don't seem to be having any issues so I've done something specifically to this.
The P2Pool is running fine with the other merged mine coins (at least they seem to be, but we haven't found any blocks yet).
..
I suggest a 24 share bounty to the pool which mines the first devcoin block with Sidhujag's daemon. Any objections?
I'm not objecting but is it better if we have an hashpower criteria, e.g. if the pool hash reach 20g, then it's ok for the 24 shares bounty. So not every pool who has deploy the same code can apply this bounty.
I'm also not objecting what you're saying, but isn't it quite hard to get a devcoin block now anyway? Its difficulty is up there with bitcoin, so even the pool I set up is going to take a while to get an actual block I believe.
Speaking of which...wtb moar hashpower! Server's looking stable and sexy. The good thing about p2pool is even if mine goes down, you can automatically connect to a backup p2pool node in your conf files and keep going with the shares and everything you left off with.
Ok, I've not considering the pool as p2pool when I post the last reply. Yes, it's enough when we mined one first block out.