Hi @Thom I was wondering about that earlier also and found this about it:

url=http://docs.bitshares.org/bitshares/user/worker.html#burn-worker]refund400k is a "Pseudo worker": [/url]

Refund Worker
This worker is used to set an approval limit for worker proposals and their payment by simply refunding his payment/salary to the reserve pool. If its amount of daily pay is as large as the daily available funds, and the worker has highest approval among all worker proposals, all funds will be returned to the reserves and no one will be payed. If, however, an other worker proposal has more votes than the refund worker, the proposal gets paid its salary, and the rest is return.

I think in this case it is even a 'burn worker' where the salary gets burned, as I can conclude from this topic: https://bitsharestalk.org/index.php/topic,20710.msg267263.html#msg267263

The difficulty is in coming up with a reliable way to know for certain the node you want to take out of production will not be able to generate blocks after you switch production to another node. If the "aberrant" node has not crashed, is still running but cut off from the net (or the watchdog listener is cut off from that node) but the watchdog node falsely concludes it is dead,  it may broadcast a new signing key, causing a new node to take over, but then the network to the aberrant server is restored and resumes network communications still thinking it is the block producer and so generates a block along with the failover node.  As far as the aberrant node is concerned it never saw the new signing key, never thought it was offline and continues to generate a block whenever its time to do so comes around.

@Thom thanks for your feedback. I was under the impression that the way it works with signing keys is that if you have your witness producer name setup in config.ini but not supply the correct privkey corresponding to the current listed 'public signing key' that the witness node is not producing blocks?

A failsafe backup scenario (imho) would be: The main server runs under pubkey X with privkey XXX in the config.ini and should it fail the  independent monitoring server calls the 'update_witness' command to start siging with pubKey Y. The backup server runs as a hot witness with privkey YYY in the config.ini and will receive messages like: 'Not producing block 12394871234 because I don't have the private key for pubKey X', right?

Only thing is to setup an 'update_witness' with pybitshares @xeroc? Let's see if I can write it

Yes! I got voted in the active witness list! (here is my proposal) Thanks for your support!!! I immediately started my feed publishing more intense (twice per hour) and will continue to add more price feeds.

This morning I took the time to write a Witness Monitoring Script to monitor my witness main tasks on an independent server, powered by @xeroc 's Python Bitshares libraries (he just release 0.1.5!) for python3.

The script provides the monitoring of 3 core witness tasks and reports via a telegram bot API call the following:

1. Monitor missing blocks
Whenever a new block is missed you will get a notification. This part of the script can (and will) be extended towards automated switching to the backup witness signing key once a threshold is passed.

2. Monitor the availability of your public seednode
By utilising the telnet library the script tries to connect to the given seednode and will report on time-out or errors.

3. Monitor the publishing of a set of assets' pricefeed(s)
By requesting the asset's feeds and checking against your witness name (configurable) the script keeps monitoring how long since you posted the given asset's feed. Whenever the configurable threshold in hours has passed and you have not yet published a new feed for the asset, you will get a notification.

FYI:

• The script is written for & tested in python3 and to be run continuously in a 'screen'-session.
• It utilises Telegram for notifications. Create your Telegram bot at @BotFather (https://telegram.me/botfather), get your telegram id via @MyTelegramID_bot (https://telegram.me/mytelegramid_bot).
• Thanks to Python Bitshares you can run this script independent of your bitshares nodes and the script doesn't need cli_wallet or witness_node'd running.
• In the first lines of the script you will find all configurable parameters, with explaining comments

Check it out on Github!
Let me know your thoughts, remarks, or requests.

@Thom this is what I found about it:
http://docs.bitshares.eu/bitshares/dpos.html#how-many-witnesses-are-securing-the-network

HOW MANY WITNESSES ARE SECURING THE NETWORK
This is totally in the hands of the shareholders. If the majority votes for 50 witnesses, then 50 witnesses will be used. If the shareholders only vote for 20, so be it. The minimum possible witness count is 11.

I think here is the counter code: db_maint.cpp#L159

you don't even need a cli_wallet anymore

   

Bunkerchainlabs-com proxy is supporting this witness.

Thanks a great bunch!

@fav, i noticed that Blockfolio has the following pairs from Bitshares: BTS / BTC, BTS / CNY, PTS/BTC. You want them to have the Dex added as one of the exchanges to make them watch for?

@Pheonike would this be an app were you can glance your bitshares portfolio iaw your account_balances? Sounds like a fun app / site to make. I can see when I can put some time in this. It is totally possible with the cli_wallet / websocket.