Given that delegate pay rate cannot be increased, does this mean that delegates that want to have more than 3% pay rate after Nov 5th will have to create new delegates (with new names)?

 

I'm not too sure how to incentivize people to vote, but at least for those who wish to do so, we need to make it easy to get information about who the delegates are, what they propose, and show this in an easy and attractive format to read.

no offense taken, I agree with you, in this new crypto world, "better safe than sorry" seem like wise words 
If people want to do code reviews, then I'd be more than happy.

Although it is possible to monitor remote node, the setup is still a bit complicated (and you need ssh access to the machine where the delegate is running). I intended the monitor to be run on the same host as the delegate, and using the remote to monitor a delegate which is taken down while recompiling to upgrade to a new version.

Note that the tools do not unlock wallets, you still need to do this manually. The passwords in the config file are only the rpc passwords, you should never put your wallet password near the tools.

Another use case is to monitor seed nodes, which allows to get a central view of multiple seed nodes on different hosts easily.

I just released the 0.1 version of the tools, this is the first public release and is available on pypi. That means it is now much easier to install.

Notably, I also fixed quite a number of bugs, the tools can now:
 - monitor seed nodes and delegate nodes
 - monitor one or more of them, either on the same machine or on a remote one
 - build DNS nodes, although that's probably gonna be the shortest-lived feature ever    At least, the infrastructure is in place to support more DACs in the future
 - iOS notifications are now sent to the Boxcar app, much easier to configure than the previous hand-crafted solution

You can either pip install bitshares_delegate_tools or get the source code from github: https://github.com/wackou/bitshares_delegate_tools

And if you use those tools/like them, don't forget to vote for my delegate for funding further development: http://digitalgaia.io/wackou.html

Cheers!

Thanks! I already have an active delegate (wackou-delegate) but it's my old one which I'd like to phase out in favor of wackou.digitalgaia, I imagine BM hasn't switched his votes yet (or hasn't seen this post yet)

yes, I also do believe that missed blocks are not such a big deal. If you miss one, then the delegate after you will pick up the transactions you couldn't sign and pocket the transactions fees for itself. So instead of being validated in avg 5 seconds, a block might take 10s. Still leagues ahead of the competition! Obviously, it shouldn't become systematic for a delegate to miss block (or for 50 delegates to start missing blocks at the same time, ie: during an upgrade), but one missed block from time to time should go completely unnoticed by the users of the network.

So my next plans for the bitshares_delegate_tools is not to focus on this automatic backup agent, but rather on:
 - enhance the way I publish feeds, or use your script or xeroc's version
 - adapt the tools to also be able to build the DNS client (and setup one for me!)
 - I'd like to focus a bit also on collaborating with people like you and setting up the backbone, as I believe it is a low-hanging fruit that can reap big rewards for the whole network

@emski, @xeroc: about the backbone delegates, I think that ideally they should not all be managed by a single entity (me, or whoever else) for obvious decentralization reasons, similarly to why they shouldn't be run on the same VPS or in the same geographical locations. The more diverse, the better. (@emski: I did see your post yesterday, but considering the time I invested in making the webpage--not my biggest skill--I decided to keep it anyway )

However, it is a good idea to have a public place to list all of those seed nodes/backbone nodes, so that they can either be included by default in the client, or that people can easily add them manually. I can offer to host such a list on my server, or maybe we could code it and then have svk host it on bitsharesblocks (excellent job on that btw, svk, bitsharesblocks seriously rocks!). The list would be updated in realtime and show the status (online/offline) of each node.
In the concept of backbone nodes they also need to be connected in a fully-connected graph, so having a central place listing those nodes helps the backbone nodes to know who their peer nodes are and maintain live connections to most of them.

or maybe you just connect your 'hiding' nodes to each other and your delegate only interacts with hiding nodes YOU control

I thought about this, but it somehow feels fragile to me, as if your relay nodes are down for whatever reasons then your delegate becomes isolated. Unless you have a lot of them for a single delegate, in which case it seems a bit wasteful. I believe that it should be possible to create a network which has a topology that allows both efficiency and security for the delegates, in a public way. My backbone node is a proposal towards that goal, but we can probably do better.
@emski: I remember your post about ddos prevention, I had a similar wish to hide the delegates at the time and it inspired me to keep thinking in that direction, as I see this as something that should be (relatively) easily achievable, and would provide perfect protection.