• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

GUI tool for running Masternode with Trezor

Maybe an off topic question, would a tool for searching through past votes and finding other MNs that voted the same as your own be possible? Delegating votes could be a great feature but it doesn't seem to be used much, wondering if being able to find other MNs with closely matched voting history and saying "vote the same way" would be a useful feature, either delegated or just in-app. Thanks.

@xkcd Is working on something like with his MNOWatch tool, but perhaps open a fresh discussion for this?
 
Maybe an off topic question, would a tool for searching through past votes and finding other MNs that voted the same as your own be possible?
As the data on inactive proposals is not stored anywhere on the Dash network, creating such a feature that works independently isn't feasible. The only option is to do it within a site that stores the historic results in its database, such as DashCentral or Dash Nexus.

Delegating votes could be a great feature but
Configuring a voting delegate configuration in DMT has been possible for some time. For this, in the field "User role" you need to select only the field "Voting" and fill in all active fields.
 
DashMasternodeTool v0.9.26-hotfix4 released
Binaries: https://github.com/Bertrand256/dash-masternode-tool/releases/tag/v0.9.26-hotfix4

Changes:
  • Fixed an error occurring when signing transactions with Trezor using the latest firmware: "Required field 'amount' was not received".
  • Fixed an error in the firmware update wizard for Trezor devices.
BTW, I would like to let you know, that in a separate thread I am working on my last proposal from a few months ago. Although I was hoping to finish it sooner, nevertheless it's good that the most important part (i.e. adapting to the latest versions of Qt, Trezor, Ledger, Keepkey libraries) is already completed. Now, I'm working on new features.
 

The hashes for the mac release don't match.

On the releases page, this is the hash you list:

shasum -b -a 512 DashMasternodeTool_0.9.26-hotfix4.mac.dmg
4e511269e9416515d6ebcbc9fa8b51a377f9f51b76d65252fd604614b0a76525e3de8cd4e4401ecd8af389ab5cdb4954580ccf9fb2ad064c4df5fdc14e2c0d40 *DashMasternodeTool_0.9.26-hotfix4.mac.dmg

This is what I get:

shasum -b -a 512 DashMasternodeTool_0.9.26-hotfix4.mac.dmg
1665163027d49772e2da6f830b4c5e8d834112cd1e1e941912fd7531e4e89ccb8cf247d87012cbd5ccc22f40e199ab76109c9e2cb0cbf2401526b3d7a4e6b179 *DashMasternodeTool_0.9.26-hotfix4.mac.dmg

Is it just me, or is there a mistake? Thanks.
 
The hashes for the mac release don't match.

Yes you are right. Due to a typo, I was re-generating the GPG message and unintentionally re-created the dmg file, which unfortunately I didn't upload to Github along with a new GPG message. A regenerated Mac dmg file, even from the same input files, gives a different binary output, hence a different hash.

Just a moment ago I have uploaded a mac dmg file with a hash matching the signature, i.e.: 4e511269e9416515d6ebcbc9fa8b51a377f9f51b76d65252fd604614b0a76525e3de8cd4e4401ecd8af389ab5cdb4954580ccf9fb2ad064c4df5fdc14e2c0d40.

Thanks for letting me know and sorry for the confusion.
 
DashMasternodeTool v0.9.27 released
Binaries: https://github.com/Bertrand256/dash-masternode-tool/releases/tag/v0.9.27

Changes:
  • A new way of presenting masternode data in the main window - masternode list.
  • Masternode details moved to a separate page/view.
  • A view showing a set of information about the Dash network.
  • Retrieving masternode information from the Dash network based on IP/port when adding
    a new masternode entry.
  • A new window acting as a container for all application tools (Toolbox).
  • Hardware wallet settings
    • Interface for the "Passphrase always on device" option for Trezor T.
    • Interface for setting the "Wipe code" option for Trezor One/T - an additional PIN, the
      entering of which will wipe the device memory (details).
    • Interface for configuring an additional method of securing Trezor T devices - an SD
      card that must be present to start the device (details).
  • Interface to the wallet seed recovery method for Trezor One with increased security, based on the word matrix.
  • Tool to help creating the "rpcauth" string, which allows starting RPC interface on a server without leaving
    password to the interface on the server.
  • Removing the strict setting of the hardware wallet type in the app configuration in favor of the dynamic selection
    of the device from the currently connected ones.
  • Adapting to the latest versions of communication libraries for Trezor, Keepkey and Ledger and
    for PyQt.
  • Adapting communication module to Dash v0.17.
  • Other, numerous improvements and fixes.
Screenshots: https://github.com/Bertrand256/dash-masternode-tool/blob/master/doc/v0.9.27-changes.md
 
Excellent, looks much better now.

Can I just say though, when voting there is a dialog with the options "Cancel" and "Yes". It says "Yes" even when I'm voting No! :-D Maybe it should be "Cancel" and "OK"?
 
Nice to see my Ledger Blue get regnoniced as a Ledger Blue instead of a Ledger Nano.

Edit : only during 'Connect Hardware Wallet' my Ledger Blue gets correctly labeled / identified, during 'Transfer Funds' the Ledger Blue still gets mislabeled as a Ledger Nano.
No problem with the functionality though.
 
Last edited:
In DMT, where can I see the dashd version number for each masternode? Can add as a column option / append to Status?
 
In DMT, where can I see the dashd version number for each masternode? Can add as a column option / append to Status?
There is currently no API to retrieve this information from the network. One of the very few methods of getting this information, would be to create some kind of a scanning feature, communicating each masternode on list and getting this information by pretending to be a remote dash daemon. This would be very inefficient for a desktop app like DMT.
 
There is currently no API to retrieve this information from the network. One of the very few methods of getting this information, would be to create some kind of a scanning feature, communicating each masternode on list and getting this information by pretending to be a remote dash daemon. This would be very inefficient for a desktop app like DMT.

I see, but Dash Ninja seems to do it:

https://www.dashninja.pl/?mnregexp=<IP4-ADDR>
 
I see, but Dash Ninja seems to do it:

https://www.dashninja.pl/?mnregexp=<IP4-ADDR>
Yes, but it is a server running 24/7 which can scan masternodes all day long. In contrast DMT is run occasionally and most likely only for a few minutes.

Not that it is impossible to implement this feature inside DMT, but on one hand, the experience wouldn't be that great because scanning of, let's say 20 masternodes, would probably take several minutes (or maybe more) and on the other hand it would require quite a lot of coding.

For that reason, the most reasonable way to show this information by the app would be to use data from dashninja, but the downside is that it makes the app dependent on that external service.

For me, important question is how many MNOs see this feature as a valuable one? Does it solve any important problem or is it rather a nice to see, but not very important information?
 
Libc6 out of date here:
Code:
dlopen: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /tmp/_MEI8Th2Lq/libpython3.8.so.1.0)

I'm probable running a too out of date distro to expect up to date software to run at this stage though (ubuntu 16.04).
 
Yes, but it is a server running 24/7 which can scan masternodes all day long. In contrast DMT is run occasionally and most likely only for a few minutes.

Not that it is impossible to implement this feature inside DMT, but on one hand, the experience wouldn't be that great because scanning of, let's say 20 masternodes, would probably take several minutes (or maybe more) and on the other hand it would require quite a lot of coding.

For that reason, the most reasonable way to show this information by the app would be to use data from dashninja, but the downside is that it makes the app dependent on that external service.

For me, important question is how many MNOs see this feature as a valuable one? Does it solve any important problem or is it rather a nice to see, but not very important information?

That's fair enough. It's a shame the API can't expose this info. How about "Statoshi functionality", is that related in any way?

 
I'm probable running a too out of date distro to expect up to date software to run at this stage though (ubuntu 16.04).
Yes, I had problems building the app on ubuntu 16.04, like it was done in previous versions, so this time I had to build it on ubuntu 18.04 and it is the lowest supported ubuntu version right now. Those problems are most likely caused by the requirements of the latest version of packages used in v0.9.27, but I hadn't enough time to dig deeper, so it's just my guess. Anyway, I will be trying to find a workaround to run it on ubuntu 16.04, as I know there are still people using that release.
 
Back
Top