GUI tool for running Masternode with Trezor

[FTL_Ian]

Hello again Bertrand256, as always thanks for the great product and support. I've run into a snag restarting masternode after updating. Updated dash on the server to 0.12.3.2. Updated DMT to 0.9.20. Plugged in trezor, tested connection, got status on node, hit "Start Masternode using hardware wallet". Clicked the confirm button on Trezor and DMT pops up "Trezor address signature mismatch."

Any ideas?

 

[Bertrand256]

Hello again Bertrand256, as always thanks for the great product and support. I've run into a snag restarting masternode after updating. Updated dash on the server to 0.12.3.2. Updated DMT to 0.9.20. Plugged in trezor, tested connection, got status on node, hit "Start Masternode using hardware wallet". Clicked the confirm button on Trezor and DMT pops up "Trezor address signature mismatch."

Any ideas?

First of all, check if you have no spaces or other illegal characters in the collateral address. Second thing: make sure you do not have the Trezor online wallet running when signing the start message - it happens often, that another app connected to the same device distorts the data exchanged between DMT and the hardware wallet.

If it does not help, let me know via DM.

 

[Bertrand256]

As tomorrow the declared 3-month period of implementation of my proposal related to the development of the DMT application will end, I wanted to reassure everyone that the work is under way. However, the number of changes that I started turned out to be too large to be closed by the end of August, which is why the proposal will be implemented until they are all finished, i.e. probably by the end of September.

The changes being implemented concern the areas most expected by users, reported to me by various channels:
- improvements and fixes related to the payment/proposal windows
- transaction history focusing on tax purposes
- support for a new signature format (SPORK 6)
- support for new functionalities provided by the Trezor One firmware version 1.6.2
- masternode list in the main window

 

[jeffh]

Keep up the good work @Bertrand256!!

Looking forward to the upcoming features. I pinged you on Discord as well to offer some help implementing the tx history for tax purposes as well, I have some code that already does this which I'm happy to share.

 

[qwizzie]

@Bertrand256

Do you have any information regarding support for Ledger Blue ? Is it in the pipeline ?

 

[Bertrand256]

Do you have any information regarding support for Ledger Blue ? Is it in the pipeline ?

I'm sorry, unfortunately not. Access to a physical device of this type would be needed to add the support for it, but unfortunately I do not have one.

The good news is that after migrating Dash to v0.13, using DMT will no longer be needed to start MN if collateral is controlled by the hardware wallet: https://github.com/dashpay/dips/pull/28.

 

[Bertrand256]

After a few months of work, I can finally share the first official test version of DMT supporting deterministic masternodes.
Binaries: https://github.com/Bertrand256/dash-masternode-tool/releases/tag/v0.9.21-beta4

This version allows you to:

• perform masternode tests on testnet if the masternode collateral is controlled by Trezor. We can thus check various scenarios which we can not perform with the production masternode without risking a loss of position in the payment queue. Fortunately, in the meantime, the Trezor firmware supporting Dash testnet has been published, so these tests are now possible without having to bother with custom firmwares.
• test migration from a non-deterministic masternode to a deterministic or start a new deterministic masternode

Below are the steps that should be done to run a testnet masternode with Trezor:

1. Connect your Trezor and run the wallet window in DMT by clicking the tool button with a brown wallet icon on it.

2. On the left side of the wallet window, a list of BIP44 accounts is displayed, similarly to the Trezor online wallet. If you have not used the Trezor device on testnet before, you should only see one item, labelled as "Account # 1". Click the expand button on the left side of the label to show the first fresh tDash address (it will be displayed in green).

3. Double-click the address and copy it.

4. Send 1000 tDash to the address - it will be your tMN collateral. If you have a problem with getting this amount, PM me - I have some spare and can share it.

5. When entering the masternode configuration in DMT, click the "Locate collateral" button to let the application find and automatically fill in the collateral address, path, TX hash and index fields.

All other actions to be carried out are essentially identical to those for a normal masternode.

After installing and configuring the Dash daemon on your VPS server, you must notifye the Dash network about the new masternode:
a) If spork 15 is active (as is currently on testnet), click the <Send ProRegTx> button at the bottom of the main DMT window to start the "ProRegTx" wizard.
b) If spork 15 is not active, first broadcast the masternode start message by clicking the <Start Masternode using hardware wallet> button, and after eraching the status "ENABLED", do step a)

The sending of ProRegTx transactions using DMT has been described by strophy in his great document: https://docs.dash.org/en/latest/masternodes/dip3-upgrade.html#masternode-registration-from-dmt
The documentation is based on the previous beta version of DMT, so it differs by a few details from the current version, but they are not significant.

The presented scenarios should be treated as my proposal and I am open to any suggestions how to improve the process.
As I am currently working on other aspects, there will certailny be many changes in other parts of the application before I release a stable version.

 

[Bertrand256]

I have published next DMT beta version with some small fixes: https://github.com/Bertrand256/dash-masternode-tool/releases/tag/v0.9.21-beta5

In addition, I've also prepared a compiled binary of Trezor T emulator, which can be useful for people who only have Keepkey or Ledger Nano S devices, which do not support Dash testnet. Thanks to the emulator, you can prepare for the production migration in advance, which will work in the same way for all types of hw devices.

The emulator works identically to the physical device, so after its first start it will ask for initialization.

This can be done using the official Trezor online wallet, but it would require reconfiguration of your Trezor Bridge to enable communication with emulator, so it will probably be easier to use the initialization/recovery feature built into DMT, which uses Trezor API and basically do the same.
To do this launch the menu item: "Tools->Hardware Wallet Initialization/Recovery", then choose the hw type (Trezor) and the recovery or initialization option.

The rest of the steps do not require explanation - in general, everything is the same as with the physical device.

Emulator is available on Mac and Linux - Windows is not supported yet.
Binaries: https://github.com/Bertrand256/trezor-core/releases/tag/v2.0.10-trezor-emulator

Probably I do not need to remind you about it, but I will do it anyway: when performing the seed recovery do not use the seed which controls funds other than tDash. The memory of the emulated device is stored in your computer's file system (~/.dmt/trezor-core-emu/trezor.flash), so it is vulnerable to being copied by people/programs having access to it. If you remember this, the emulator can be a great help in carrying out various tests that you can not afford with a physical device.

 

[Bertrand256]

DMT v0.9.21 has been published.
Binaries: https://github.com/Bertrand256/dash-masternode-tool/releases/tag/v0.9.21

The most important change is the support for deterministic masternodes (Dash v0.13).

Notes on starting masternodes.
In the period of coexistence of v0.12 and v0.13 nodes, starting a masternode should be carried out with some attention

A. Before Spork 15 is active on mainnet:

• When starting v0.12.x masternode, send the "start" message in a traditional way, that is by pressing the <Start Masternode using hardware wallet> button. In your masternode configuration, enter this protocol version: 70210.

• When starting v0.13 masternode, first send the "start" message by pressing the <Start Masternode using hardware wallet> button, using this protocol version in your mn configuration: 70213. After the masternode is enabled, register deterministic mn from a wizard started by pressing the <Send ProRegTx> button.

B. After Spork 15 activation (it will be announced):

• only register deterministic mn from a wizard started by pressing the <Send ProRegTx> button

***EDIT: Look at @UdjinM6's post below, specifying the scenario in the context of DIP-3 activation.

Documentation of the deterministic mn registration process: https://docs.dash.org/en/latest/masternodes/dip3-upgrade.html#masternode-registration-from-dmt

Deterministic mn registration with DMT can be carried out in one of the two scenarios:
a) automatic, in which the public RPC nodes maintained by me, send ProRegTx transactions on behalf of the user (I pay tx fees),
b) manual, using your own RPC node.

Method a) is convenient, but on the other hand, it requires sending some sensitive information to the node. For security reasons, this information is not logged anywhere within the node. Similarly, when it comes to privacy-related data such as the client IP address - they are not stored. However, if you have the option to use your own Dash node, it will be the best solution.

Other notes
In this version, the wallet dialog was significantly rebuilt. It does not yet have all the planned features, but it has everything what the previous versions had plus a little more. In the near future, the rest of the planned changes will be made. Hint: if you want to show only addresses of your masternodes' collaterals, select the "View As: Mastenode Address" option in the upper left part of the window. You can also select multiple masternode addresses to display their utxos/transactions in one view.

 

[UdjinM6]

Great job!

Small correction:
"A" has actually 2 phases for 0.13 masternodes:
A1. Before DIP3 activation: Start MN as usual via "start". You won't be able to send ProRegTx yet.
A2. After DIP3 activation: Start MN as usual via "start" if you haven't already, if it's already started, skip to sending ProRegTx. Send ProRegTx to register as a deterministic masternode (this protx and its data won't be used until spork15 activation but you MUST register as a deterministic masternode before it activates to stay in queue once it does).

Also, I found a small issue: IPs like 555.555.555.555 won't fit into corresponding field, the widest IPs that fit are like 555.555.55.55 or 555.555.555.5

 

[Bertrand256]

Small correction:....

@UdjinM6 thanks for the the comment!

 

[camosoul]

@Bertrand256

Send ProRegTX button often displays error:

Could not generate BLS private key

Keep clicking, eventually it works.

Could not? No mention of why? So diagnostic...

Same error message occurs, seemingly at random, whenever the "Generate New" button for Operator Key is clicked. Click again, it might work, click again, it might throw the very same error.

I occasionally encounter when clicking "Continue":

Invalid operator private key: Key data too large, must be smaller than group order

At least it's diagnostic to someone who knows what the fugg that means...

This occurs much less frequently, but still appears to be completely random. If new Owner and Operator Keys are successfully generated (without creating any of the previous errors, which happen a lot), trying again is often successful.

Seems to be something wrong with the generation process. The validation mechanism seems to be catching invalid data that should never have been generated? Or the validation mechanism is finding false positives and disliking valid data? I suggest the former due to the can't create it in the first place error wording occurring far more frequently... The second error suggests invalid data is slipping through the validation mechanism, and causes an error in the next step when it does... So, maybe the generation and sanity checking both need a look? False positives? Is it still using testnet methodologies?

Have not encountered these errors by other means, or any other errors, so far...

Concern that sanity checking and keygeneration may not be working fully/properly, and may pass derp to network broadcast... Also makes me question OpSec data leakage.

 

[camosoul]

Not sure if or how DMT is involved with this, but thought it might be relevant...

New DMT version notified me that Trezor T Firmware was out of date and tasks could not be performed.

Updated.

New Trezor T Firmware has problems...

When using HD paths of this form:

m/44'/5'/[random9digit]'/0/[random9digit]

Trezor T displays error of:

Path m/44'/5'/[random9digit]'/0/[random9digit] is unknown

with Red X and Green Checkmark
Tapping Green Checkmark results in it proceeding, aparently, properly and as normal.
No explanation. No confirmation that it's working properly or not.
My guess is that some new form of caching/chasing mechanism has been introduced and it's validation process is a bit retarded.

 

[camosoul]

Before DIP3 activation
After DIP3 activation

How does one determine if DIP003 is in effect?

spork15 activation

Are sporks still handled by the centralized arbiter model?

 

[Bertrand256]

Send ProRegTX button often displays error:

Regardless of this error, sending ProRegTx will fail because DIP3 has not yet been activated.

I occasionally encounter when clicking "Continue":

Invalid operator private key: Key data too large, must be smaller than group order

At least it's diagnostic to someone who knows what the fugg that means...

Please DM me with the log file contents and the information about what OS you are using.

Trezor T displays error of:

Path m/44'/5'/[random9digit]'/0/[random9digit] is unknown

with Red X and Green Checkmark

Trezor uses this mechanism as a protection against accidental providing the wrong path, i.e. the one which the user later may not remember. The conditions of this validation depend on the functionality used, for example when signing a message, this warning appears if you use an account with a number greater than 20: https://github.com/trezor/trezor-co...580/src/apps/wallet/sign_tx/addresses.py#L219

 

[UdjinM6]

How does one determine if DIP003 is in effect?
...

You can use "getblockchaininfo" which should produce output like

...
    "dip0003": {
      "status": "started",
      "bit": 3,
      "period": 4032,
      "threshold": 3226,
      "windowStart": 1003968,
      "windowBlocks": 0,
      "windowProgress": 0,
      "startTime": 1546300800,
      "timeout": 1577836800,
      "since": 999936
    },
...

When activation is done "status" should say "active". Also, there will be some graphs later, same as we had for bip147 last time I believe.

...
Are sporks still handled by the centralized arbiter model?

Yep, sporks are still centralized.

 

[GrandMasterDash]

I've also randomly seen those two errors, "Could not generate BLS private key" and "Invalid operator private key: Key data too large, must be smaller than group order"

 

[Bertrand256]

I've also randomly seen those two errors, "Could not generate BLS private key" and "Invalid operator private key: Key data too large, must be smaller than group order"

You are using linux, right?
Can you send me a log file?

 

[camosoul]

You are using linux, right?

Yup.

I've got some other issues for which I managed to get screenshots, but I'm pretty sure it's related...

Removing the checkbox from "Hide collateral utxos" shows no collateral.

...but this tab clearly shows all of the TXes, including the collateral...

...and this one goes back to making me panic and freak out; where the hell did all my DASH go?!?!?

Everything works fine in 0.9.2

think this might be related to using paths resembling:

m/44'/5'/123456789'/0/123456789

Or perhaps my head is up my ass.

Having an active connection to the Trezor has no effect.

25th word is enabled, though I doubt that's got anything to do with it...

I don't think it's playing nice with the goofy new firmware...

 

[Bertrand256]

think this might be related to using paths resembling:

m/44'/5'/123456789'/0/123456789

I confirm that there is some problem with reading/processing transactions data in the "Masternode Addresses" view mode.

As a workaround, follow these steps:
1. select the "View as: Wallet Account" item in the upper left part of the dialog
2. wait until the fetching transaction data is finished (the "Fetching transactions" label disappears)
3. switch back to the "View as: Masternode Addresses" mode

Now, the UTXOs for the selected masternode address should be visible.