Prohashing Mining Pool Forums

One of the largest costs we face now is losses due to being unaware of software updates. When we don't know about exchange API changes, or coin daemon updates, money is wasted. For example, Peercoin forked recently and about $1,631.60 was lost on the old fork. Apparently, the upgrade was announced several months ago, but there was no way to know that we should have searched for the announcement. Likewise, in December we lost Coinbase support for a few days because they deprecated their v1 API. The announcement was made 3 months before that, but it had worked for five years, and how were we supposed to know to search for Coinbase's announcement? All of these organizations assume that their service is the most important to all of their customers, when people like us are using thousands of different services at once.

Some updates, like operating system updates, are managed through package managers and therefore it is easy to keep security vulnerabilities at bay by running aptitude update.

Is anyone aware of a similar service for cryptocurrency updates? If not, is there someone willing to start a business that offers one? We would still save money at $2000/yr for this service, and all it has to do is to provide a JSON feed with three fields - coin/exchange name, new version, and deadline (or null if not mandatory.) A reliable feed, updated, daily, for all coins and exchanges would be extremely valuable.

I hope you find such a service.

It is unreasonable to expect you to monitor 1000's of feeds for upcoming changes.

An alternative is to enlist your users - who do watch the ones they care about - and ask us to provide you a service ticket to let you know. I have done so, and will continue to for things I care about. (Frankly, it is in my best interest to do so, as I benefit by your continued support.) You could even provide a "bounty" for first to notify you. (I would donate mine to your team). A bounty would still be better than the lost money as described above. Just thinking of a crowd sourced version of that service.

ajs wrote:I hope you find such a service.

It is unreasonable to expect you to monitor 1000's of feeds for upcoming changes.

An alternative is to enlist your users - who do watch the ones they care about - and ask us to provide you a service ticket to let you know. I have done so, and will continue to for things I care about. (Frankly, it is in my best interest to do so, as I benefit by your continued support.) You could even provide a "bounty" for first to notify you. (I would donate mine to your team). A bounty would still be better than the lost money as described above. Just thinking of a crowd sourced version of that service.

I like this idea. We could add a form to have us notified on the "Settings" page. Let's see how it works with no reward first. If we add a reward, then I think we're going to end up with five submissions for each fork, and the people who are not first will think we're cheating them.

This doesn't just apply to coins, though. We also need to get updates from exchanges. Maybe there needs to be a page that lists the name of each dependency we use and the version we are using, and people can enter new versions on the form.

for wallets/daemons couldn't you have a script check each one with "getpeerinfo" and if it notices any peers with version numbers larger than the one you are running to bring to your attention?

That's a great idea. But doesn't it provide those as a string, and since every daemon has a different string, there's no way to easily compare them?

Steve Sokolowski wrote:That's a great idea. But doesn't it provide those as a string, and since every daemon has a different string, there's no way to easily compare them?

Simply not equal might be sufficient. If it is not the same as when run yesterday, someone should look. The false alarm rate should be low. The problem is still that this will notify you AFTER then change has occurred. You are still playing defense to recover. Warning is what you really want. Notification a week (or two) before the change happens.

Probably doing both makes sense.

Steve Sokolowski wrote:That's a great idea. But doesn't it provide those as a string, and since every daemon has a different string, there's no way to easily compare them?

well, yes, there can be quite a bit of variation on how different coin clients identify themselves, but for the most part
just extracting and looking at the numeric part of that string seems sufficient.
you also have to be sure you are looking at the same 'family' of clients. the big BTC variants have more than one client program
available with wildly different version numbers showing up in the getpeerinfo list. a method in the script needs to be available
to exclude clients not in your ' core family' for those few coins with this issue. really odd to see how even btc-ABC clients were connected to my btc-SV wallet.

i decided to spend the last day doing a proof-of-concept of this for my own site, and was startled to find out a full half
of my 20 daemons are out of date. i had the delusion i was doing a pretty good job at keeping up.

i cant speak to java based wallets, but for normal C++ clients they all, regardless of generation, seem pretty consistent
in what they report for 'getpeerinfo'.

the tricky bit is automatically determining ones own local version. newer wallets that support "getnetworkinfo" are good and reliable for this. older wallets are wildly inconsistent on how they enocde version info into the output of 'getinfo'
so for some older coins you'll end up hand-maintaining a list of version numbers.
++[edit: turns out manual maintenance is minimal, for about 40 different coins i've only encountered one that needed a manual entry]

the script i wrote can be demonstrated by visiting my web page http://dognose.net/coins/verscheck.cgi

you'd have to rewrite it into your language of choice, i'm sure how it flows is not so important as how it can show
that the information is there and can be extracted in an automated fashion.

i can send you the script if you wish.
but i now have a new tool for my server

ajs wrote: The problem is still that this will notify you AFTER then change has occurred. You are still playing defense to recover. Warning is what you really want. Notification a week (or two) before the change happens.

Probably doing both makes sense.

before a major fork, new clients tend to appear on the network before hand.
during development the developers tend to pop up on the production network with their new versions too.

if only one or two connections are new versions, its probably developers. if a good portion of your connections
are a new version, it's probably an omen that something is coming down the pipe at you.

so, a heads-up on a new client version running around could be useful if checked on a weekly basis i think.