- Feb 13, 2017
- Dash Address
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 showedWhat is the version number of your Trezor's firmware?
I have a few other questions/suggestions: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
DashMasternodeTool file is a compiled executable with python sources and interpreter inside it - you just need to execute it like a normal linux program.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?
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...DashMasternodeTool file is a compiled executable with python sources and interpreter inside it - you just need to execute it like a normal linux program.
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?Ah yes, same errors as 0.9.14. I think I said about these errors before. Am running Manjaro.
Short answer: not possible or at least: not without extra effort.Is it possible to run DMT on a raspberry pi?
Dash address inconsistency between UTXO (1) and a HW's path: 44'/5'/1'/0/0. HW address: Xf35... UTXO address: XtF9... Cannot continue.
A few questions before we start digging deeper.Hi!
Trying to transfer funds out and 0.9.17 gives me:
Dash address inconsistency between UTXO (1) and a HW's path: 44'/5'/1'/0/0.
Yes.Did you close your Keepkey client app before trying to send funds with DMT?
v0.9.12: Unspent Transaction Outputs (UTXOs) for this address: XtF9...Then verify:
a) whether addresses for both versions differ
I get the same behavior and addresses when I click "Load transactions" multiple times (in both versions).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.
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.I get the same behavior and addresses when I click "Load transactions" multiple times (in both versions).
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/I get the same behavior and addresses when I click "Load transactions" multiple times (in both versions).
I can happily confirm, that in my case the "NFC" encoding works and I can move the funds!If it works as expected, changes will be included in the next "official" release.
Thank you for confirming that the solution works for you.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!
A few words about the priorities, because it may not be obvious to everyone.I'm not sure I want this to be a full-on wallet. Personally, I'm happy to withdraw individual UTXOs. Please consider priorities; I'm more interested in pre-proposal discussions / analysis and I think DMT could be a good tool for that i.e. not having to jump between DMT and web browser.
To avoid working on an "echo chamber" solution I will prepare a poll to verify what is the interest in such a solution among MNOs. If there is interest I will consider the implementation of this seriously.I think a DMT proposal forum would be relatively easy to setup. Tbh, I don't care if the comments are managed from a central server, we can deal with decentralization at a much later date. Nor do I care that much about diluting the discussion; if you like, that is true decentralization e.g. proposals are discussed on discord and forums, and some people (such as myself) barely bother with discord. But if you're really determined not to dilute the conversation, you could build an API for others to use.
But anyway, the point is, by building a forum, we get tight integration with hardware wallets, which is most MNOs. Indeed, there has been much discussion about filtering out trolls.