• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Dash Core v0.13 on Mainnet

Attention Dash Masternode Owners: Please register with the Deterministic Masternode List now

https://www.dash.org/forum/threads/...-the-deterministic-masternode-list-now.43668/

NpdYMuz.jpg
 
So i have upgraded my masternode to a deterministic masternode and its showing up as one in the Masternodes DIP3 tab.
I created a new address that functions both as owner address and as voting address (same address).

How does the voting actually takes place now ? Because thats just an address i created...
Is my old masternode voting priv key still in play ? How exactly do i vote or what changes with voting when spork 15 activates ?
 
Last edited:
Does dashqt needs to be upgraded as well? I am stuck at 1028180 block. Several blockexplorer as well. I can not find any node that has more blocks as well.
 
Sadly I got no answer on my burning registration question over on bitcointalk. So hopefully more luck here,

Could use some help understanding that.

So from that masternode registration description page:

Quote
-------------------------
collateralHash: The txid of the 1000 Dash collateral funding transaction
collateralIndex: The output index of the 1000 Dash funding transaction
ipAndPort: Masternode IP address and port, in the format x.x.x.x:yyyy
ownerKeyAddr: The new Dash address generated above for the owner/voting address
operatorPubKey: The BLS public key generated above (or provided by your hosting service)
votingKeyAddr: The new Dash address generated above, or the address of a delegate, used for proposal voting
operatorReward: The percentage of the block reward allocated to the operator as payment
payoutAddress: A new or existing Dash address to receive the owner’s masternode rewards
feeSourceAddress: An (optional) address used to fund ProTx fee. payoutAddress will be used if not specified.
------------
(reference let out .. no links allowed as new user)


Using a Masternode Host service I understand that I have to wait first for the BLS operatorPubKey send from the hoster bevor I can start with that registration.
Let's say I have it.

Then there are 3 Wallets in play
Wallet (A) Masternode Host on the Host Service
Wallet (B) The 1000DASH Collateral Wallet
Wallet (C) My General Operation Wallet I want to use for everything (getting the fees, voteing etc)

Best case I will never ever have to open Wallet B after. So for this case I asume I have to do this:


* ownerKeyAddr I create on B
Question 1) could I create one on C instead?

* votingKeyAddr I create on C

* payoutAddress I create on C

* feeSourceAddress an Address with DASH on it from where I send the transaction..so if I do it from B one from B if I do it from C one from C

Question 2) Can I prepare and send the transaction entierly from wallet C or is it recommended to do it from B?

Question 3) After all this can I restart the masternode if required in the future from my C Wallet? I guess not or is this depending on the ownerKeyAddr if this one is form C or B?

Edit: Question 4) instead waiting on the host service for sending the BLS pup key..can I generate the BLS key pair on my C Wallet and give that info to the host service? So I could start without haveing to wait first.

Thanks for the help

The masternode service provided the BLS keys now so question 4 is obsolete. But would be interesting to know.

My most burning question is of course question 1 in connection with if this will allow me to restart a masternode from my C wallet and never have to touch the 1000DASH collateral wallet again. That would be very neat!
 
Decided to create all the addresses on Wallet C.

protx register_prepare seems to do fine.

When I try to submit the on my collateral wallet sign message with protx register_submit it tells me:

bad-protx-key-not-same (code 16) (code -1)

What does this mean? The tx is a copy past and the signed message should be correct too as far as I can tell.


Edit: Ah found the answer somewhere in the forum. votingKeyAddr has to be identical to ownerKeyAddr.

Thanks to Figlmueller.

Well I read the doc before but it says:
generate an address..."It must also be used as the voting address if Spork 15 is not yet active".

So I thought as long as spork15 is not active it will use the one address and later automatical the other that you provided. Seems no. You have to provide the same address. :/
 
Last edited:
And the next wired thing:

When I try to reuse the feeSourceAddress for a second MN it says Missing inputs despite seeing still enough DASH on that address.
(the protx registration transfer seems to have placed the rest back to that adress)
Moved it to another address and a part of it back -> still doesnt work.
Used the other address -> works
Does each need an own SourceAddress? Wired thought thats a one time trash address just to pay the one time fee.
 
And the next wired thing:

When I try to reuse the feeSourceAddress for a second MN it says Missing inputs despite seeing still enough DASH on that address.
(the protx registration transfer seems to have placed the rest back to that adress)
Moved it to another address and a part of it back -> still doesnt work.
Used the other address -> works
Does each need an own SourceAddress? Wired thought thats a one time trash address just to pay the one time fee.


I recommend joining one of the discord’s (invite links at the bottom of the new homepage).

You will likely get help more quickly there.
 
I recommend joining one of the discord’s (invite links at the bottom of the new homepage).

You will likely get help more quickly there.

Yes thanks. I have my troubles with discord. Tried it in the past. It looks like a messi chatt room to me with no structure. Don't understand how someone can find relevant information there and why it is so wide spread this days. But yes if bitcointalk is dead and dash.org is dead and discord is the place to go for help then guess I will have to bite in that sure apple in the future.

I got my MN registered now. Strange that of this 1000 of MNs owners hardly anyone seems to have questions about that registration process.
It doesn't looks to me that everyone understand the new addresses and what is possible to do and what not.
 
Yes thanks. I have my troubles with discord. Tried it in the past. It looks like a messi chatt room to me with no structure. Don't understand how someone can find relevant information there and why it is so wide spread this days. But yes if bitcointalk is dead and dash.org is dead and discord is the place to go for help then guess I will have to bite in that sure apple in the future.

I got my MN registered now. Strange that of this 1000 of MNs owners hardly anyone seems to have questions about that registration process.
It doesn't looks to me that everyone understand the new addresses and what is possible to do and what not.

We got tons of questions on Discord which is why I suggested you head over there. Messy yes, but many find it easier to get (and give) help in real time, per say. Different stokes for different folks though so don’t feel like I am pressuring you or anything.

And I am glad you got your node registered.
 
And the next wired thing:

When I try to reuse the feeSourceAddress for a second MN it says Missing inputs despite seeing still enough DASH on that address.
(the protx registration transfer seems to have placed the rest back to that adress)
Moved it to another address and a part of it back -> still doesnt work.
Used the other address -> works
Does each need an own SourceAddress? Wired thought thats a one time trash address just to pay the one time fee.
Maybe the fee source input is required to have a certain amount of confirmations? Just guessing.
 
Hi @gadado

I suspect you prepared multiple transactions using the same feeSourceAddress, then tried to sign and broadcast them sequentially. Because the tx field output from register_prepare is the actual transaction exactly as it is broadcast on the network, it will spend a specific UTXO on that address as an input. Since you (probably) prepared all the registration transactions at the same time, they are trying to double spend the same UTXO for the transaction fee, which is not permitted by the network. Only the first transaction will succeed. You will need to run register_prepare again to use a different UTXO on the same address for your subsequent registration transactions.

Hope this makes sense, good luck!
 
Hi @gadado

I suspect you prepared multiple transactions using the same feeSourceAddress, then tried to sign and broadcast them sequentially. Because the tx field output from register_prepare is the actual transaction exactly as it is broadcast on the network, it will spend a specific UTXO on that address as an input. Since you (probably) prepared all the registration transactions at the same time, they are trying to double spend the same UTXO for the transaction fee, which is not permitted by the network. Only the first transaction will succeed. You will need to run register_prepare again to use a different UTXO on the same address for your subsequent registration transactions.

Hope this makes sense, good luck!

You are correct. Exactly what I did or tried to do. Yes makes sense. So I could have finished the first registration in complete and only after that start preparing the next with the same feeSourceAddress.

I solved it by creating multiple feeSourceAddresses. For each one.

Because of that for me strange behaviour I was a bit worried after that the feeSourceAddress might be something bound to the registration you have to keep but I see that is not the case. That's good.

Thanks for your answer.
 
Byway I really like the solution with a Wallet C (created all new addresses on C).

With all the relevant addresses on Wallet C, C is a Command Wallet seeing and controlling all the Masternodes and the Masternodes Collaterals itself can stay in cold storage. That's what I call a neat progress! :)
 
Back
Top