Please update the Masternode setup documentation

M

masternube

Member
I'm not sure if this is the right forum to contact the maintainers of this documentation. Please direct me to the right location.

I was trying to follow the masternode setup documentation, but it has some problems.
I have my collateral already in a Ledger Nano S so I skipped the section "Option 2: Sending from Dash Core wallet". But that is the only section that mentions creating a masternodeprivatekey which is needed in dash.conf when running dashd with dashman. Since I didn't create the masternodeprivatekey, I thought I had to put my legacy voting key in dash.conf, which didn't work.

Second, when starting dashd with dashman, you already need the BLS key in dash.conf. But the documentation only mentions the BLS key in a later secion.
 
Hi @masternube I am responsible for that documentation. Please use the stable documentation for the current version of Dash Core - latest should be considered beta and a work in progress. They will be synchronised and a version added to a branch each time Dash Core is released to keep an archive of old documentation and processes for previous versions of Dash.

For your specific problem, you are correct! There was a check added in Dash 0.13.2 to ensure the BLS key is present. dashman unfortunately doesn't do this, so the process fails with newer versions of Dash. It looks like I have specified to generate a legacy masternode privkey (which is currently also still required) but I will need to move the BLS sections up..
0IomamQ.png


I'll try and figure out a reasonable point to do this, but I agree the current guide is horribly complicated because of the amount of options it supports, and the need to include legacy and BLS keys at an early point in the process. This should all be a lot simpler in 0.14...

Were you able to get it working in the end?
 
@strophy
Thanks for pointing out step 2 in the Send collateral section.
I didn't look closely at that part because I already have my collateral.
(I'm actually just trying to move a masternode from a hosted masternode to one that I manage myself.)
But generating the masternode private key, I believe has nothing to do with collateral, does it?
I ended up generating a masternode private key in a Dash Core wallet that doesn't hold my collateral and it seems to work.

I did manage to get dashd running, but I don't know yet if it will work as a masternode because I'm waiting for my payment before migrating, in case it will cause me to drop out of the queue. Do you think it will not work because of the way I generated the masternode private key?
 
Also, I don't remember how I got on that "latest" page but I think it was through a Google search. If that page is not ready for consumption, maybe it shouldn't be on the website?
 
The "latest" page is intended for consumption by users of testnet. I'm working with the hosting platform to prioritize "stable" over "latest", the reason "latest" pops up in Google is something that happened accidentally when they implemented XML sitemaps without thinking through actual use cases. Hopefully it will revert back to "stable" soon. Although I'm starting to think this versioning is more trouble than it's worth, maybe just "latest" and snapshots of older version numbers is more logical...

If you are moving to a masternode you manage yourself, you should generate at least a new operator key, don't reuse the key from your old operator. This will require a ProUpServTx, but you probably need that since you will be changing IP as well and will probably get PoSe-Banned. As long as you are still using Dash 0.13.3+, you will need both the legacy masternodeprivkey and the new masternodeblsprivkey or dashd will not start in masternode mode. You can generate the legacy key using "masternode genkey" or under "Masternode private key" in DMT. The requirement for the legacy key is removed in Dash 0.14, only masternodeblsprivkey is required there.

I'll update the docs now to reflect all of this. Thanks for the thoughtful comments on the process!
 
Thanks @strophy.
I generated a masternodeprivkey in Dash Core (not holding the collateral) and a masternodeblsprivkey in DMT. I'll change it so both are from DMT, but I still suspect it doesn't matter.
My plan is to first use protx update_registrar to change the operator key and then use protx update_service to change the IP.
Why do you think the MN will be banned?
If things go wrong, I do a new ProRegTx from DMT.
I'm assuming that should work but will definitely kick me out of the queue.
 
I thought you might get banned because of the downtime while switching the node, but if you just change the IP and operator privkey, you might be ok actually. Either way, you have the right approach now, let me know how it goes!
 
@strophy
Once I got my payment I sent the protx update_registrar command. This seemed to work.
Then I tried the protx update_service command but I got "the operator key does not belong to the registered public key"
So I waited for my update_registrar tx to confirm and tried again. This time it seemed to work, but in hindsight it seems that at that point my node was already POSE_BANNED, or at least before that second transaction confirmed.
So then I started over with a new ProRegTx and that seems to have worked. In total it cost me 12 spots in the payment queue.

But based on this experience it seems like updating the operator key with protx update_registrar is not possible without getting banned. This seems wrong.
 
You must log in or register to reply here.
Back
Top