"Masternode broadcast signature verification failed" about dash-masternode-tool

[Bertrand256]

The problem is not related to sending "start masternode" messages multiple times - this message can be sent as many times as you want, but after each try you need to wait several minutes until the information propagates through the network.

The "Masternode broadcast signature verification failed" error is returned by the Dash RPC node, to which the message has been sent, not the DMT app itself. In most cases it means that from the node's point of view, the start message has been signed with incorrect private key (different than the pk related to the masternode collateral address).

First of, make sure that during all these operations, you have closed other apps, that could utilize your Trezor, such as Trezor web wallet in Chrome or Firefox. Unfortunately, leaving those apps connected to Trezor while signing messages from DMT, can interfere the process, which could result in errors as yours. It's not possible though to detect whether another app is connected to the device at the same time, so I can't display appropriate warning when it happens.

Second, verify if the BIP32 path and collateral address in your configuration are consistent and reflect the reality. For this, enable editing and click the left arrow button on the left side of the 'BIP32 path' edit box and check whether the collateral address that's displayed in the 'Collateral' edit box matches the actual collateral address of your masternode.

[SmartLayer]

That's a very detailed and user-friendly explanation!

I don't think the Trezor was opened by other apps at the time and I was sure that the address, BIP32 path and transaction ID remained the same between two attempts to start the master node. In order to be sure, I attempted a 3rd time, making sure absolutely no application is using Trezor by rebooting first. I still got the same error.

I did this: "click the left arrow button on the left side of the 'BIP32 path' edit box and check..." The click event changed nothing on the UI. I then emptied the Collateral key, clicked the button you suggested, and the key came back, showing that it was correct. And, of course, I checked that 1000 Dash is on that address. So what would be the cause? And is there a way for me to see the message (except on Trezor) and signature so I can verify it myself, given that I am rather familiar with verifying signatures?

[SmartLayer]

Can you advise if you think the masternode is correctly running? In my case, I have 'STATUS: ENABLED' and a diminishing Queue count.

[SmartLayer]

I guess that you have considered validating the signature against the user-configured collateral address before forwarding the message to the node through RPC call for the purpose of improving user experience? It may also help isolating the problem.

[Bertrand256]

Having the 'Enbled' status, your masternode is running ok, so it seems that the first start message you've sent did the work.

During the process, the app verifies if the address used by the hardware wallet to perform the signing operation is the same as the masternode's collateral - if they differ, the appropriate message is displayed. If you haven't seen any warnings along the way, we are dealing with some rare problem, which I haven't met before.

To deducate why the start message you're sending now is rejected, you actually need to analyze this signed message, in particular if there are signed with the proper private key.

For this:

1. Enable the "debug" log level in the configuration dialog
2. Try sending the start masternode message
3. In the app's log file find the line starting with "Start MN message signature: ", after which you will get the signed message encoded with hex.

Raw message structure is as follows:

• masternode ip followed by the ':' character
• masternode tcp port
• current time (in the format of unix epoch time)
• hash ripmed160 of the collateral public key
• hash ripmed160 of the public key related to the masternode private key
• protocol version (currently 70208)

Here is the source code of this part of the process:

dash-masternode-tool/src/main_dlg.py

Lines 1284 to 1290 in f1eae7b

	serialize_for_sig = self.curMasternode.ip + ':' + self.curMasternode.port + str(int(sig_time)) + \
	binascii.unhexlify(bitcoin.hash160(collateral_pubkey))[::-1].hex() + \
	binascii.unhexlify(bitcoin.hash160(bytes.fromhex(mn_pubkey)))[::-1].hex() + \
	str(protocol_version)
	sig = hw_intf.sign_message(self, self.curMasternode.collateralBip32Path, serialize_for_sig)

To verify the signed message you will also need the value of the signature time, being part of the message. This value is also written to the log file, just after the signature itself (the line starts with: "Start MN message sig_time").

[SmartLayer]

As I learned how to find the problem, the problem is gone. I repeated the process with debug level of log, again making sure Trezor is not running in the browser and this time and no signature verification error was produced. The master node went to PRE_ENABLED status from ENABLED.

[SmartLayer]

The problem is not related to sending "start masternode" messages multiple times - this message can be sent as many times as you want

With no consequences? I realised that I am at the bottom of the queue after I rebroadcasted the message, and that is a loss of a few hundred dollars!

Well, I have no problem sacrificing a few hundred dollars for science but I could have planned the test after I got the master node reward if I knew that gonna happen!

[Bertrand256]

With no consequences? I realised that I am at the bottom of the queue
after I rebroadcasted the message, and that is a loss of a few hundred
dollars!

My statement about the possibility of sending the start message multiple times was written in the context of your suspicion that re-sending could be the cause of the error. Regarding the consequences of re-sending, I simply assumed that you have read the doc chapter related to the issue (https://github.com/Bertrand256/dash-masternode-tool/blob/master/README.md#sequence-of-actions):

3. Verification that the masternode status is not already ENABLED or PRE_ENABLED. If it is, the following warning appears: ...

   If your masternode is running and you decide to send a start masternode message anyway, your masternode's payment queue position will be reset.

I thought you decided to pin down the cause while the topic is fresh for you and thus free yourself of a potential problem in the future. I'm sorry about that assumptions.

Anyway, if you still want to track down the cause, I will soon publish a release that will work with the TESTNET, so you will be able to "play" in starting masternodes without financial consequences.

[SmartLayer]

I guess this issue at this stage can either be closed for not reproducible or be amended to a quality insurance issue: having DMT checking the signature first before sending it to the server, so that we can either eliminate this issue or, when it happens, we can be sure from which side is the issue.

[Bertrand256]

Ok, thanks for the comment. I'm closing the issue, if it reappears it will be reopened. Additionally, I will add a signature verification code before the mesage broadcast call.

[AdvancedStyle]

I'm getting this error; have checked everything (IP, address, txid, tx index, bip32 path...)

How do I debug this message?

[SmartLayer]

Read your link today:

My statement about the possibility of sending the start message multiple times was written in the context of your suspicion that re-sending could be the cause of the error. Regarding the consequences of re-sending, I simply assumed that you have read the doc chapter related to the issue (https://github.com/Bertrand256/dash-masternode-tool/blob/master/README.md#sequence-of-actions):

With respect, here is why, as someone who came along with the rise of Linux and being scolded with RTFM and scolded others to RTFM, I did not read it. 1) It wasn't an implied requirement in GUI. GUI was kind of expected to tell users of the meaning of their action through visual cue (good) or words (normal). 2) The guide directly link to the binary download page:

https://dashpay.atlassian.net/wiki/spaces/DOC/pages/116031498/Send+the+collateral