I clearly explained the situation to you, you asked me a question and I answered it. Please everyone, make sure to bookmark https://irdpool.tk and not http://irdpool.tk

This way everyone will have the HTTPS version bookmarked when the switch happens and it will be seamless. It is a valid HTTPS connection and a valid certificate, it currently redirects to HTTP to prevent the browser from producing a mixed content errors. Linking the HTTPS version does not hurt the user in any way, you're just annoyed because you seem to consider it false advertising or something. HTTPS was working until I had to rush to change the backend because every HF seems to break pool compatibility

Because the requirement to move from clintar-pool to fancoder-universal was a regression in the pool backend codebase and removed the SSL option from the node. To prevent the site from failing due to HTTPS-HTTP mixed content I setup the redirect. forknote-pool is also on this older version of the pool code and also does not support the more modern features of Monero mining pools.

To fix this I would need to setup nginx to encapsulate HTTPS connections and redirect them to HTTP locally within the server when connecting to the backend API. I have not set this up yet.

I've once again replaced the mining backend (clintar-pool -> fancoder-universal -> forknote-pool) on https://irdpool.tk/ sorry for the downtime.

https://irdpool.tk/ has been updated to the latest node version

https://irdpool.tk is back up, the node crashed and blew up the wallet. Recovered from backup.

It's fixed now, that change didn't make it over when I was vimdiffing the configs during testing.

Modifying the website would have done nothing, this is a pool configuration issue.

To make it clear exactly what I did, here are the following versions I tried.
clintar/cryptonote-xmr-pool
clintar/cryptonote-universal-pool
zone117x/node-cryptonote-pool <--used by others, broken by default
fancoder/cryptonote-universal-pool <--works

in combination with the following node-cryptonote-util
clintar/node-cryptonote-util
clintar/node-cryptonote-util#Nan-2.0
clintar/node-cryptonote-util#xdn-Nan-2.0
clintar/node-cryptonote-util#xmr-Nan-2.0
zone117x/node-cryptonote-util
Snipa22/node-cryptonote-util <--used by others, broken by default
fancoder/node-cryptonote-util <--works

I have dug into the fork history of all of this during my troubleshooting, read every issue involving messages, modified and recompiled node-cryptonote-util. Out of all available combinations and options, only one thing worked and that was fancoder's fork. It's working now and I'm not going to dig any deeper.

In my mind there may be one last difference. I compile my node, and last night there was a new commit, during my troubleshooting I did recompile the node. The possibility exists that the binary released days ago was compiled from code that was not available on the git at time of release. I don't believe this is the case, though.

I did use the exact pool software as used by others, it does not work. Not on any of the available branches either. I have no reason to believe stevebrush was not aware of these pool breaking changes, as per the previous issue, which he explicitly quoted the fix to me after I already fixed it.

I apologize for being aggressive, waking up at 3am to find a broken pool is not fun. Knowing that it could have been avoided with a basic level of communication, but didn't happen, as per stevebrush's PMs, because I don't donate.

I found the secret patch, and to quote the developer of the pool you feature in your signature: https://github.com/zone117x/node-cryptonote-pool/issues/14

The solution was to switch to a pool fork that explicitly supports Fantomcoin, by default the fork irdpool.fr and irdpool.eu run does not work with this HF and the developer has stated he will not support it. There is your secret patch.

Let it be no secret, Stevebush for whatever reason seems to hate me and seems to be actively attempting to fuck with irdpool.tk. It's getting the point where I feel I need to audit any code that gets pushed out.

Steve is not interested in approximately half the hashrate of the network? Sure that hashrate can go elsewhere. The idea that the developer doesn't seem to care about breaking major chunks of the ecosystem is concerning.

I've re-implemented the pool several times now, with several different forks (including the exact forks other running pools use), with several different forks of the back-end used by the pool forks.

All error messages, and research into them indicate a problem with a hardfork. I will continue my search for the secret fix the developer is withholding (probably located within node-cryptonote-util) for a bit more.

I can attempt to re-implement with entirely new pool software (not the same pool software all current IRD pools run) but this would involve migrating to a completely new DB schema.

I said earlier in this thread when mine77 was shutting down I would continue to run irdpool.tk on the condition it wasn't a major time sink. It now is. I have a actual development work I need to be doing, not reverse engineering someone else's patches.

I'm investigating the issue, something has changed. I'm assuming there's a secret fix the developer has decided not to inform me about again.

https://irdpool.tk now supports HTTPS, the mixin has been increased from 0 to 3 4 (0 was an original network requirement) and the fee has increased from 0.4% to 0.5%.

Asking for professionalism now? I get you're having fun playing developer by copy+pasting other people's code into a badly launched, out of date bytecoin fork but please understand some of us actually do have real development we're focused on and can't pay attention to every flailing attempt to push a HF within unrealistic time windows or botched version update (as has become the norm in the history of this coin).

I'm just here trying to maintain the oldest beacon on this network, back when there were barely any nodes and massively centralized hashrates. I'm not interested in indulging your fantasies or ego trips, simply to provide a stable service to people who have been mining with me since the very beginning of this coin. It would have been very helpful for you to mention ecosystem breaking bugs. Instead you've explained you intentionally withheld the information because you didn't like the way I said I was going to communicate with you by sending you logs of error messages, or because I don't donate (to you? hah).

I simply reiterate, you fundamentally changed the way the node handled blocks. Not only did you break every pool (or at least any pool that has been around for any real period of time) with your change, you apparently also broke the GUI wallets as well (as per Petiyashaket). You did not ever inform me of this until I sent you the relevant logs (which is precisely the point), at which point the answer was simple because you understood that you had broken anything that communicates with the node via RPC. Instead you decided to intentionally withhold the specific information from me.

While you're stumbling your way through a git pull of the upstream ByteCoin you might bother to note any ecosystem breaking changes next time.

How exactly are you going to handle this when an exchange is trying to communicate with the node software? Get angry at them, too? Clearly it's their fault that you changed the way everything has functioned since the beginning, I mean, it was a bug after all. It's concerns like this that made me want to keep this private.

By fixing the bug in the original code you broke the way every pool has functioned since the very beginning, a bit surprising you consider it outside of the scope of the blockchain development.

I'm referring to the original code the node was built from, and no, the node has not been updated since the last time it was necessary to do so.  http://irdpool.tk is the oldest pool on the network, I will not be subjecting it to every latest patch the moment it comes out before end-users have a chance to test it. This update was applied because it is required, and unlike last time you bothered to actually message me about it.

The way you are posting is embarrassing to this project and the network. Like you I do this for free, but I still have a modest amount of professionalism and I would have been happy to keep this exchange private. This could have been resolved simply by stating the minor change required that *every pool* must do, instead of passive-aggressive taunting.

http://irdpool.tk is upgraded (again) to the new HF node. I had to removed a very old workaround I did due to a bug in the original node. Sorry for the inconvenience.

I'm investigating, if I can't find a solution I may revert to the old version. Reverting now.


Update: node reverted, unlocking blocks again, sent developer relevant logs.

I'm compiling the latest node now and will begin upgrade work shortly on https://irdpool.tk/

PS. props to the twitter account, it's what tipped me off I should check the thread today

I don't think this should be hardcoded, if anything pool operators should opt into developer donations since all the cryptonote pool software supports this feature. It's how Monero handled it, along with a simple "donate" command built into the wallet.

Update: https://irdpool.tk/ is now on the new version, let me know if there's any issues.

irdpool .tk is back online, sorry for the downtime.