I updated the client to 0.6.2 and now I am on a minority fork:

same here, can't manage to get on the main chain... I added the problematic block to my checkpoints.json file:
[[
    1,
    "8523e28fde6eed4eb749a84e28c9c7b56870c9cc"
  ],[
    172718,
    "e452dd44902bc86110923285da03ac12e8cfbe6f"
  ],[
    173585,
    "1d1695bc8ebd3ebae0168007afb2912269adbef1"
  ],[
    179000,
    "ba3d03f5bf65d8cc051417b673206e6b0472bcae"
  ],[
    189181,
    "9c4c7f9bab5bea6a64fb1986f8ae131d9d9e2083"
  ]
]

and restarted with --resync-blockchain, but to no avail... Any suggestion as to how to do this properly? Thanks

Quote from: xeroc on January 26, 2015, 09:10:58 pm

Gonna put you on my slate when back at the computer

Quote from: wackou on January 26, 2015, 09:54:34 pm

Added you to my slate

Won't adding this delegate to other trusted delegates' slate compromise its entire purpose?

Don't we want stakeholders to explicitly vote for this delegate if they believe its approval rating is lower than what they think the vote-of-no-confidence threshold should be and to take away some or all of their vote if they think the approval rating is higher than what they think the threshold should be? If this is added to the slate of well established delegates, then I don't think we can really infer much from the approval rating of the "paid-delegate-cutoff.misc.nikolai" delegate, which defeats its entire purpose.

Well, I believe this delegate and voting for another delegate's slate are 2 orthogonal concepts, I don't see a problem there. If I vote for another delegate's slate, I see it as a way for me to "delegate" my vote to someone else, and if that someone else thinks the cutoff delegate should be voted in, then that's fair game. This does make more sense indeed if the slate is the slate of all delegates you vote, instead of just a few more delegates that you want to add to your already partially complete list of delegates, so putting the cutoff delegate on a slate of 5 delegates makes less sense than putting it on a slate of 80 delegates (unless you think there should only be 5 paid delegate, of course).

The other point is: this delegate is just an indicator anyway, it doesn't hold any "juridical" value, and it is a 0% delegate anyway, which might be seen as a good thing to some (although the diff between a 3% and a 0% one is not so big seeing the number of 100% delegates currently voted in)

Released 0.1.6, which contains (amongst other fixes):

- full support for DevShares
- fixed issue with new naming of tags (bts/X.X.X and dvs/X.X.X)
- include slate for btstools.digitalgaia as an example slate
- send notifications grouped by clients (for multiple delegates in same wallet)
- fixed tools for new API in 0.6.0 (blockchain_get_delegate_slot_records)

This version should support both 0.5.3 and 0.6.0, but there might be minor quirks, please let me know if this is the case.

The other main task that I have been working on lately is to write documentation and a tutorial for setting up a delegate. This is still work in progress, but is already in a state which I consider useful. The annoucement for the tutorial is here:

https://bitsharestalk.org/index.php?topic=13627

In the coming weeks, I plan to work mostly on expanding the documentation a lot, and obviously fix the bugs in the tools that are going to pop up.

i'll include this tut into delegate page of ravamped .org site - if i'll get your GO - and link to your delegate proposal here!

Sure, go ahead, I'd love it! I see that the countdown is extended and is now a week, that'll give me a bit more time to fine tune it.

Thanks guys for the kind words!

If you could expand the moniting app tutorials a bit that would be great!

will do, that's definitely the part that I think is useful so I will try to make it clearer

How to install it?

you get all in the same package, so

pip install bts_tools

is all you ever have to do. It is really recommended to take 5 mins to understand and use virtualenvs, though, it will save you a lot of headaches in the future. See http://bts-tools.readthedocs.org/en/latest/howto_install.html

What is a WSGI server?

the monitoring tools are run by default as a python script, and serving the http requests is done by an embedded http server written in python. This is nice for development, but is usually not recommended for production.

In production, the usual way of doing this is to have a "real" webserver, such as Apache or nginx do the http part, and ask the python code to give it just the contents of the page, but not serve it. This has many advantages, such as a better security model, more features (eg: SSL if supported by your webserver, etc.)

WSGI is the standard allowing a webserver to execute directly python code (think: mod_php, but for python)

Can I use it with a remote server using ssh key?

if you mean having the client run on a machine, and the monitoring tools run on a different one but monitoring the client through ssh, then yes, it is possible. I would have to review this part, though, as I did it with convenience in mind first, without taking into account the security too much. There is nothing in the doc yet, will get on it too.

well, that's because I have "nico" registered on the blockchain

"wallet_list_my_accounts" shows your account in your wallet, and "wallet_get_account" shows the one from the blockchain (which is mine) (the function name is a bit of a misnomer, there's also "blockchain_get_account" which is about the same, but seems to return the data in a different format)

This is strange as it should not have let you create the account with the name "nico" in your wallet knowing that there was already such an account on the blockchain (it's not a problem with the blockchain, but it can sometimes lead to confusion, as what just happened to you).

  voted and adding you to my slate, too!

  your blog posts are great, but writing code is where you excel at. Definitely looking forward to a great 1.0 release, with nice (full and light) wallets, cold-storage and multisig. Then, world domination can only be a couple of steps away