Bertrand256
Well-known member
What is the version number of your Trezor's firmware?
GUI tool for running Masternode with Trezor
- Thread starter Bertrand256
- Start date
It was on the previous version before the latest release (cant remember version sorry) it was showing the error then. So I then updated to the latest 1.6.0 firmware thinking that may help, but still the same error showed
Bertrand256
Well-known member
I have a few other questions/suggestions:
- what is your destintation address type, multisig (P2SH) or normal (P2PKH) Dash address? If you don't know this, give me the first character of your destination address.
- if open, please close your web browsers that you use as an interface to wallet.trezor.io (eg. Chrome or Firefox) and retry signing a transaction
- what is your OS type and version?
If the issue persists, please send me a DMT's log file (Tools->Open log file) via DM.
Greetings
I'm trying to get into the cool club here and want to use the DMT. My system is Ubuntu 16.04 and I have python 3.5.2 installed.
After starting the program with "python3 DashMasternodeTool" I get the following error:
SyntaxError: Non-UTF-8 code starting with '\xe8' in file DashMasternodeTool on line 2, but no encoding declared;
Anyone know what might be missing?
I'm trying to get into the cool club here and want to use the DMT. My system is Ubuntu 16.04 and I have python 3.5.2 installed.
After starting the program with "python3 DashMasternodeTool" I get the following error:
SyntaxError: Non-UTF-8 code starting with '\xe8' in file DashMasternodeTool on line 2, but no encoding declared;
Anyone know what might be missing?
Bertrand256
Well-known member
DashMasternodeTool file is a compiled executable with python sources and interpreter inside it - you just need to execute it like a normal linux program.
Oh that's too easy. Ok, I made an alias so that the default python is now a 3.5.2 instead of 2 and pray to Linus that nothing breaks. After some new errors about the directory I moved it to my dashcore/bin folder and then it worked! Thank you...
Bertrand256
Well-known member
New version of DashMasternodeTool (v0.9.16) has been released.
Changelist:
https://github.com/Bertrand256/dash-masternode-tool/blob/master/changelog.md#0915---2018-01-18
https://github.com/Bertrand256/dash-masternode-tool/blob/master/changelog.md#0916---2018-01-23
The most important changes:
* Hardware wallet initialization & recovery for online/offline usage (see: https://github.com/Bertrand256/dash-masternode-tool/blob/master/doc/hw-initialization-recovery.md)
* Filtering proposals by name/title/owner.
* A scroll area inside the Vote tab in the Proposals window to improve the visibility of proposls for users with several masternodes in the configuration and low screen resolution.
Changes in the backend.
I'm in the midst of migrating the "public" RPC nodes behind CloudFlare to mitigate DDoS-kind traffic. From the user's point of view this involves changing the domain name and the TCP port number of those nodes in the DMT configuration. These changes should be made by the application itself during the first execution of version 0.9.16, but you should review them and do the changes manually if needed.
Name/port mapping:
alice.dash-dmt.eu:8080 -> alice.dash-masternode-tool.org:443
luna.dash-dmt.eu:8080 -> luna.dash-masternode-tool.org:443
new connection: suzy.dash-masternode-tool.org:443
Since version 0.9.15 I have introduced the procedure of signing of binary files, so you can now easily verify that the files have not been corrupted while downloading or forged (see: https://github.com/Bertrand256/dash-masternode-tool#verification-of-the-binary-files).
I clearly do not stick to my original schedule which I published along with my proposal, but for me the quicker reaction to the current needs of the community is more important than strict adherence to this schedule. In the meantime, there have been some unplanned challenges, not all of which are reflected in the DMT code, but what I promised as part of my proposal seems to be still needed, so I am determined to continue.
To make this possible I intend to prolong my exclusive involvement in the project by two months, of course within the funds granted beforehand. Therefore, I will cooperate with you in this mode at least till the end of March 2018.
Changelist:
https://github.com/Bertrand256/dash-masternode-tool/blob/master/changelog.md#0915---2018-01-18
https://github.com/Bertrand256/dash-masternode-tool/blob/master/changelog.md#0916---2018-01-23
The most important changes:
* Hardware wallet initialization & recovery for online/offline usage (see: https://github.com/Bertrand256/dash-masternode-tool/blob/master/doc/hw-initialization-recovery.md)
* Filtering proposals by name/title/owner.
* A scroll area inside the Vote tab in the Proposals window to improve the visibility of proposls for users with several masternodes in the configuration and low screen resolution.
Changes in the backend.
I'm in the midst of migrating the "public" RPC nodes behind CloudFlare to mitigate DDoS-kind traffic. From the user's point of view this involves changing the domain name and the TCP port number of those nodes in the DMT configuration. These changes should be made by the application itself during the first execution of version 0.9.16, but you should review them and do the changes manually if needed.
Name/port mapping:
alice.dash-dmt.eu:8080 -> alice.dash-masternode-tool.org:443
luna.dash-dmt.eu:8080 -> luna.dash-masternode-tool.org:443
new connection: suzy.dash-masternode-tool.org:443
Since version 0.9.15 I have introduced the procedure of signing of binary files, so you can now easily verify that the files have not been corrupted while downloading or forged (see: https://github.com/Bertrand256/dash-masternode-tool#verification-of-the-binary-files).
I clearly do not stick to my original schedule which I published along with my proposal, but for me the quicker reaction to the current needs of the community is more important than strict adherence to this schedule. In the meantime, there have been some unplanned challenges, not all of which are reflected in the DMT code, but what I promised as part of my proposal seems to be still needed, so I am determined to continue.
To make this possible I intend to prolong my exclusive involvement in the project by two months, of course within the funds granted beforehand. Therefore, I will cooperate with you in this mode at least till the end of March 2018.
Last edited:
Gtk-Message: Failed to load module "canberra-gtk-module"
Gtk-Message: Failed to load module "canberra-gtk-module"
(DashMasternodeTool-0.9.16:19374): Gtk-WARNING **: Theme parsing error: gtk.css:17:21: '-gtk-outline-radius' is not a valid property name
(DashMasternodeTool-0.9.16:19374): Gtk-WARNING **: Theme parsing error: gtk.css:23:2: Missing name of pseudo-class
(DashMasternodeTool-0.9.16:19374): Gtk-WARNING **: Theme parsing error: gtk.css:35:21: Missing name of pseudo-class
(DashMasternodeTool-0.9.16:19374): Gtk-WARNING **: Theme parsing error: gtk.css:76:6: Missing name of pseudo-class
(DashMasternodeTool-0.9.16:19374): Gtk-WARNING **: Theme parsing error: gtk.css:97:18: '-gtk-icon-shadow' is not a valid property name
(DashMasternodeTool-0.9.16:19374): Gtk-WARNING **: Theme parsing error: gtk.css:113:18: '-gtk-icon-shadow' is not a valid property name
(DashMasternodeTool-0.9.16:19374): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory
Gtk-Message: Failed to load module "canberra-gtk-module"
(DashMasternodeTool-0.9.16:19374): Gtk-WARNING **: Theme parsing error: gtk.css:17:21: '-gtk-outline-radius' is not a valid property name
(DashMasternodeTool-0.9.16:19374): Gtk-WARNING **: Theme parsing error: gtk.css:23:2: Missing name of pseudo-class
(DashMasternodeTool-0.9.16:19374): Gtk-WARNING **: Theme parsing error: gtk.css:35:21: Missing name of pseudo-class
(DashMasternodeTool-0.9.16:19374): Gtk-WARNING **: Theme parsing error: gtk.css:76:6: Missing name of pseudo-class
(DashMasternodeTool-0.9.16:19374): Gtk-WARNING **: Theme parsing error: gtk.css:97:18: '-gtk-icon-shadow' is not a valid property name
(DashMasternodeTool-0.9.16:19374): Gtk-WARNING **: Theme parsing error: gtk.css:113:18: '-gtk-icon-shadow' is not a valid property name
(DashMasternodeTool-0.9.16:19374): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory
Bertrand256
Well-known member
What's your Linux distro?
Is v0.9.14 running OK on the same system?
Ah yes, same errors as 0.9.14. I think I said about these errors before. Am running Manjaro.
Bertrand256
Well-known member
Yes, in the course of half a year, two other people reported the same error, but so far I wasn't able to find the cause nor reproduce it, however, some tests indicated conflicts with other graphics software. Do you have Steam or other game engine installed on this computer?
Bertrand256
Well-known member
Short answer: not possible or at least: not without extra effort.
Longer answer: DMT depends on the PyQt5 library, which is not officially available for Raspbian OS. You would probably be able to compile the library from sources, though this would not be a very trivial task.
Hi!
Trying to transfer funds out and 0.9.17 gives me:
However an older version -- 0.9.12 -- works.
Using Ubuntu Linux, KeepKey, PIN+password.
Trying to transfer funds out and 0.9.17 gives me:
Code:
Dash address inconsistency between UTXO (1) and a HW's path: 44'/5'/1'/0/0.
HW address: Xf35...
UTXO address: XtF9...
Cannot continue.However an older version -- 0.9.12 -- works.
Using Ubuntu Linux, KeepKey, PIN+password.
Bertrand256
Well-known member
A few questions before we start digging deeper.
Did you close your Keepkey client app before trying to send funds with DMT?
If no, close it and try again.
If yes and the error still appears, let's use another method of retrieving the dash addresses for a given bip32 path with those two different DMT versions.
With each of two DMT versions, do the following:
- open the "Transfer funds from any HW address" dialog from the Tools menu
- in the "BIP32 path" field enter your masternode path: 44'/5'/1'/0/0
- click the "Load transactions" button
- read the dash address which appears in the label above
Then verify:
a) whether addresses for both versions differ
b) whether the address returned by v0.9.17 is the same as the address you've received in the first message (starting with "Xf35.."). If it differs, click the "Load transactions" a few times and check whether the Dash address returned is constant or changes after each click.[/CODE][/QUOTE]
Yes.
v0.9.12: Unspent Transaction Outputs (UTXOs) for this address: XtF9...
v0.9.17: There is no Unspent Transaction Outputs (UTXOs) for this address: Xf35...
I get the same behavior and addresses when I click "Load transactions" multiple times (in both versions).
Bertrand256
Well-known member
Thanks to @splawik21 (kudos to him
), we managed to find the reason of the issue, which are the national characters (non-ASCII) in an passphrase. It turns out that if the password contains such characters, Keepkey uses an invalid encoding (NFC instead of NFKD) - it makes it incompatible with the BIP-39 standard (https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki). In older DMT versions (< 0.9.15) that encoding was in line with the Keepkey official client, but in the new version I made it compatible with the BIP-39 standard (and Trezor). That, however, is causing such problems as yours for users who uses non-ASCII characters in an passphrase. It's abvious that we have to do something with this mess, so as a solution I'm preparing a dedicated option in the configuration, that will allow to set the passphrase encoding compatibility.
Bertrand256
Well-known member
I've published a compilation with the option I've mentioned above. For now it's published only on Keybase: https://keybase.pub/bertrand256/dash-masternode-tool/executables/0.9.17a/
In the configuration window, open the "Miescellaneous" tab and for the "KeepKey passphrase encoding" option select the first entry: "NFC...." (actually it should be selected by default).
If it works as expected, changes will be included in the next "official" release.
Last edited:
I can happily confirm, that in my case the "NFC" encoding works and I can move the funds!
Also tested with "NFKD" and there was the error as expected.
I'm also happy that I do not need to re-setup everything because of this.
So thanks a lot for a very clever solution!