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.

 

[camosoul]

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.

Unfortunately, this does not work around the problem.

All it does is pull TXes from account #1. MN collaterals are on random 0 - 999999999 accounts at random 0 - 999999999 address. Trying to seek data and check for address use would take forever in that format... Where is it getting this info from? It's not going clearnet to a block explorer, is it? Seems to go too fast for that...

I don't think that viewing "as account" is going to work with the way I store collateral.

It's as if it's ignoring the HD path provided...

I'm able to use the old 0.12.x.x start broadcast when upgrading nodes to 0.13.0.0 while DIP3 is still not in effect. So, it seeks out the HD path properly there, and on the TRANSACTIONS tab. It's just not doing it in the SEND and DETAILS tabs... ?? Result being unable to extract payments...

0.9.2 worked flawlessly... Something didn't translate...

 

[camosoul]

Also, I sent logs to your protonmail a few days ago. bertrand256 username was reported as disabled by protonmail when I tried to send... I used b256 and it worked... Release appeared to be signed by that one alone.

 

[Bertrand256]

I don't think that viewing "as account" is going to work with the way I store collateral.

From what I guess the paths you are using are, let's say non-standard - part of the path specifying the account number does not start from 0 ' in simplified notation or 2147483648 in full notation. I'd like to create the conditions similar to yours, so can you confirm if the account number is lower or greater that 2147483648 (you can do it via DM)?

What I can say now, is that DMT currently does not handle cases where accounts are used in a different way than described in this document BIP44: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#account-discovery, i.e. if create gaps between account 0' and the ones you are using.
Despite this, I think I can handle it somehow.

Until then, you can use version 0.9.20 in parallel, because the wallet implemented in it is not based on BIP44 and there is absolute freedom in choosing the BIP32 path.

Also, I sent logs to your protonmail a few days ago. bertrand256 username was reported as disabled by protonmail when I tried to send... I used b256 and it worked... Release appeared to be signed by that one alone.

Ah, it was you, I just did not know who to associate with. I confirm that the logos have arrived. Thanks.

 

[camosoul]

...freedom in choosing the BIP32 path.

The troubles of too little freedom are always worse than the troubles of too much... Due to this dynamic, there is no such thing as too much freedom...

Apparently, that applies here as it applies to everything else.

It seems that was the very intent of the Masternode Address View...

Fixing that seems better than a band-aid on top of a work-around.

Wallet Account View seems to be working exactly as you intend it to; following the standard. Don't break it when the whole point of the Masternode Address View is to do this task...

Ah, it was you, I just did not know who to associate with. I confirm that the logos have arrived. Thanks.

I posted a message to this thread with a similar subject line included so you'd know... Maybe you're not a Ren and Stimpy fan... ;-)

 

[camosoul]

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

It seems you created both modes for a reason.

Fixing this problem directly makes more sense than trying to band-aid a work-around intended to use a specific standard.

Why not simply use what appears on the Transactions tab to select on the Send tab?

It almost seems like a problem of too much segregation of the user interface. Why do these two things need separate tabs when they work better together on the same pane, like 0.9.2 does it?

It seems to be mostly working, just not all in the same spot... And having different tabs where they don't need to be separated is an organizational annoyance itself...

 

[Bertrand256]

Important information about starting v0.13 masternodes with DMT.

A lot of people are confused about how to currently start v0.13 masternodes, which is mainly due my unfortunate wording in the "Start masternode" button label, but also the nuances about DIP3 and Spork 15 activation.

So, I'd like to summarize the information provided earlier: starting v0.13 masternode should be done in a traditional way, ie by pressing the <Start masternode with hardware wallet> button. Please note that the name of the button is misleading: "<= 0.12" should not be there. The feature associated with the button also applies to v0.13 masternodes and now it is the only thing you should do in DMT to start a masternode. As for the <Send ProRegTx> button: it will not work until DIP3 activation. If you try to use it, you will see the error "bad-tx-type (code 16)".

After the DIP3 activation (it may take a few weeks), you can start registering DIP3 masternodes by clicking the "Send ProRegTx" button. You should do this before Spork 15 is activated to stay in payment queue, but there will be enough time for this if you do not unnecessarily delay it after the payment cycle ends.

 

[Bertrand256]

Fixing that seems better than a band-aid on top of a work-around.
Wallet Account View seems to be working exactly as you intend it to; following the standard. Don't break it when the whole point of the Masternode Address View is to do this task...

Without going into details, let me just say that the reason is some unhandled scenario deep inside the code that I intend to handle as soon as I finish more urgent stuff.

When implementing this, I do not need/plan to remove any existing features, because everything has its purpose, i.e. there are people who need a given function.

 

[camosoul]

Without going into details, let me just say that the reason is some unhandled scenario deep inside the code that I intend to handle as soon as I finish more urgent stuff.

When implementing this, I do not need/plan to remove any existing features, because everything has its purpose, i.e. there are people who need a given function.

Since the ability to launch the old way will only cause confusion in the future, I'll assume the fix will be out when DIP3 goes active, and be combined with the elimination if the old braodcast methods.

...which beggs the question... Does it look like miners are going to go 80% anytime soon? Or is this upgrade never going to happen because miners can control it by simply refusing to upgrade?

Much like sporks still being manual... DASH needs a conscious distributed consensus mechanism for triggering this. DASH can't continue to cede this power and authority to people who merely plug in a box for profit and don't know or care how this negatively impacts the project/network. They don't even know an upgrade is happening...

Miners are distributed, but unconscious.
Sporks are conscious, but centralized.

MNs need a way to say "alright, fuckers, it's been long enough [flip switch, punt the bad actors]" to miners and other MNs... This upgrade will still be pending when 0.14.0.0-rcNN is ready...

Let's not forget, the budget can't fund DASH anymore... Time wasted is more precious than ever.

 

[Bertrand256]

DMT v0.9.22 beta1 has been published.

Binaries: https://github.com/Bertrand256/dash-masternode-tool/releases/tag/v0.9.22-beta1

Note, that this is a beta version that I hope a few people will test to help me spot any problems before publishing the "stable" version at the end of the week. Despite this, the version should work correctly with mainnet in most cases.

The most important change concerns MNOs whose masternode is managed by a separate entity - the operator. In most such cases, it is probably the operator who is responsible for the operator private key generation. The public key associated with it is then handed over to the owner, who uses it in the DIP3 masternode registration process (publishing ProRegTx transaction). In this version, DMT supports such a scenario: after launching the ProRegTx wizard, you need to change the operator key type to "public" by clicking on the "use pubkey" link as in the screenshot below:

Other improvements
The "Start Masternode using hardware wallet" (A) and "Send ProRegTx" (B) buttons are now shown/hidden depending on the status of the DIP3 and Spork 15 network parameters:

1. Both, DIP3 and Spork15 are inactive (currently on mainnet): only the button A is visible. Masternodes are started in a "traditional" way.
2. DIP3 is active, Spork 15 is inactive (on mainnet in a few days): both buttons are visible. Starting masternode (eg after protocol upgrade or after a long mn inactivity) is done first by clicking A and after a while by clicking B.
3. Both, DIP3 and Spork 15 are active: only the B button is visible. Starting masternode is done in a new way: by sending ProRegTx transaction.

This version also includes several other fixes, e.g. regarding the wallet feature. @camosoul, I appreciate if you verify whether the version fixes problems you had with the wallet feature.

 

[camosoul]

This version also includes several other fixes, e.g. regarding the wallet feature. @camosoul, I appreciate if you verify whether the version fixes problems you had with the wallet feature.

Previously reported issue remains unchanged. Same symptoms/problem persist. Not clear on how to help you with it...

EDIT: no, something has changed. MOST of the same problems persist. However, unchecking the "hide collateral" button on the "send" tab does show the collateral now, which it previously failed to do. But, none of the payments show. There's nothing for me to select. Yes, a payment is sitting there, shown properly in status and "transactions" tab.

Issues relating to the "details" tab remain unchanged (the state of the "hide collateral" button has no impact, expected). It says balance and received are zero. Other data accurate.

The "transactions" tab still seems to be functioning properly, and it shows the entire history accurately.

EDIT AGAIN: Not sure what happened, but it now shows accurate data in "details" tab and "send" tab. Maybe it was just a REALLY long delay for some reason? I'm not sure. but it wasn't working initially, about 10 minutes on it's working. Program was not exited and reloaded. It just spontaneously displayed accurately. Seems to be working appropriately so far...

MOAR EDIT: Error after extracting/sending a payment. Payment does get sent, but this weird error pops up. Basically, hit send, it shows green success, and this error pops up at the exact same moment. Click OK and life appears to go on normally...

DIP3 button not active now, so can't test the other weird stuff that was happening. It's 4am. Sleepie time