• 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

@Bertrand256
I am also having the following error on mac:
“DashMasternodeTool.app” can’t be opened because Apple cannot check it for malicious software.
Because Apple doesn't know the software, they are a little bit careful, but you can circumvent their hesitancy by the following sequence of actions:
1. open your Applications folder with finder
2. locate the DashMasternodeTool.app item
3. right click and then choose Open
2023-05-15_12-50-19.png


This has to be done only once per any new version.
 
  • Like
Reactions: kot
I have never had this problem before. It works now - thanks for the tip Bertrand!
 
DashMaternodeTool v0.9.34 released
Binaries: https://github.com/Bertrand256/dash-masternode-tool/releases/tag/v0.9.34

This release addresses a few issues reported after releasing v0.9.33:
  • Support the old BLS scheme when showing the configuration-to-network discrepancies to avoid the "Operator public key mismatch..." warning;
  • Respect the vote Signal and Weight fields when drawing the voting progress chart (proposals);
  • Fixed an error that appeared when using the "Fetch MN data" feature;
 
@Bertrand256 can you please give us some data on how many unique masternodes use your servers instead of doing it manually?

I suppose the logic might be, how many masternodes are still running that used DMT during setup?
 
Last edited:
@Bertrand256 can you please give us some data on how many unique masternodes use your servers instead of doing it manually?

I suppose the logic might be, how many masternodes are still running that used DMT during setup?
I have no such data. Neither on the RPC nodes nor in the application itself is there any logging to identify masternodes that are created using the DMT's so called "automatic method". I think, the only way to check this would be to see what protx register transactions have been paid by the addresses of the wallets associated with these RPC nodes, but this would not show the use of the automatic method with the user's own RPC node (if that's of interest to you as well) and well, and it would require quite a lot of work to get the data. If you are interested, I can PM you wallet addresses of the public RPC nodes, so you will be able to do these verifications.
 
DashMaternodeTool v0.9.35 released
Binaries: https://github.com/Bertrand256/dash-masternode-tool/releases/tag/v0.9.35

Changes:
- Update service now works with v19 fork not activated (currently on mainnet)
- Masternode registration feature now uses the old BLS scheme until the v19 fork full activation
- Numerous improvements of the Update Payout Address, Update Operator Key, Update Voting Key and Update Service windows
- Added ability to select Dash address from hardware wallet in dialogs related to masternode registration
- Added configuration options for the lower and upper limit of the random time offset, added to voting time to improve privacy
- Added ability to generate and store private keys ed25519, related to Platform Node Id
- Added ability to display developer contact information
- Protx-related dialogs: removing newline characters when copying text from the helper text box for manual commands
- Protx-related dialogs: added buttons to copy a manual command to the clipboard
- Protx-related dialogs: enabling operation without a network connection to RPC servers
 
No logging yet to get a handle on how many unique masternodes are setting up via your service?

MNOs gave up their privacy the moment they use your servers (instead of doing it manually themselves) so I think it's okay to add further logging.
 
DashMaternodeTool v0.9.36 RC-1, released
Binaries: https://github.com/Bertrand256/dash-masternode-tool/releases/tag/v0.9.36-rc1
This is a prerelease version!

Fixed a few minor issues and added a new feature to display all masternodes in the Dash network with filtering. Since DMT keeps information also about deleted masternodes in its internal database, with this feature you can even view masternodes that are no longer on the network, but which DMT once "saw". If you run the application on a fairly regular basis (every 1-2 weeks is enough), you will have access to most of the archived masternodes, which can be helpful doing some analysis.

2023-06-15_15-08-49.png
 
Last edited:
This should actually be helpful for some users to troubleshoot various situations. I realized recently that some DMT users don't use a Dash Core desktop wallet at all and rely on external sites like dashninja to get info on their MN. However, dashninja does not display PoSe-banned nodes, which makes their situation a bit more difficult.
 
DashMaternodeTool v0.9.36 RC-1, released
Binaries: https://github.com/Bertrand256/dash-masternode-tool/releases/tag/v0.9.36-rc1
This is a prerelease version!

Supplement to the previous post:
  • This new feature can be turned off in the app's configuration dialog, making the app to look like earlier versions
  • After pressing the "Columns" button, when the "Masternodes (network)" tab is active you will have the option to change what columns are to be displayed/hidden and in what order (initially, many of them are hidden). Here is the list:
    • Id: identifier in the internal database
    • IP/Port
    • Ident: masternode identifier being used in the 'masternode list' command, i.e.: collateral hash - collateral index)
    • Status
    • Type: Regular or HighPerformance
    • Queue position: position in the payment queue
    • Payout address
    • Last paid time
    • Last paid block
    • Protx: protx transaction hash
    • DMT active: 1 if the masternode is active, 0 if inactive (currently not seen in the Dash blockchain)
    • DMT creation time: the time when the masternode was first seen by DMT
    • DMT deactivation time: the time at which the masternode stopped being seen by DMT (then "DMT active" was set to 0)
    • Registered height
    • Platform Node Id
    • Platform P2P port
    • Platform HTTP port
    • Collateral hash
    • Collateral index
    • Collateral address
    • Owner address
    • Voting address
    • Operator pubkey
    • PoSe penalty
    • PoSe ban height
    • PoSe ban time
    • PoSe revived height
    • Operator reward
  • By clicking on the column header you can turn on sorting or change the sort order
 
Could you include a "vote the numbers" feature into the voting section of DMT?
The mechanism seems to be quite complex, and for now I don't know how this idea of separate proposals, but constituting a group, was to be presented in the user interface. I wonder if it is better to wait for Dash Platform and with it try to implement some kind of a voting contract with more voting capabilities.

Altenatively, and as long as DMT is opensource, if I code that stuff will you add it to the upcoming release of DMT?
Yes, it would be possible, but in the implementation I suggest a direction that will give people the opportunity to work in one of two scenarios: a) in the traditional way (at it is now) and b) with the "vote the numbers" functionality. Technically, it would look like this: we create a copy of the voting on proposals window and it is on it that we make changes related to "vote the numbers". Which proposals window would be used would depend on a configuration option.
 
No logging yet to get a handle on how many unique masternodes are setting up via your service?

MNOs gave up their privacy the moment they use your servers (instead of doing it manually themselves) so I think it's okay to add further logging.
Here's why, for now, I'm not even considering implementing this:
  • I have communicated both in the application documentation and in my various statements that no such logging is taking place, and I have absolutely no intention of breaking the given promise.
  • I don't see how collecting such information could be of any value to MNOs.
  • My take on the privacy issue is that even if I share a little bit of private data (e.g., to be able to perform payment card or crypto transactions), it doesn't at all mean that I don't care about protecting all other information. On the contrary, I share as little as possible and I think I'm not the only one.

I may be wrong about some things, so my question is what value you see (for MNOs) in collecting this kind of information. Probably you see something I don't.
 
I may be wrong about some things, so my question is what value you see (for MNOs) in collecting this kind of information. Probably you see something I don't.
I have concerns about single points of failure, or limited options, and I suspect DMT falls into this category when setting up a masternode.

In the past I called this "centralization" but on reflection I think others were not understanding the nuances in using this word. So yes, DMT and the servers might be "decentralized" yet also be a single point of failure for many people. From a technical point of view, yes, masternodes can be setup without DMT but is this the case in practice? I mean, you setup this service to make things easier for people, which means it's probably complicated / tedious without it. The set of people willing to participate in the dash network AND has the confidence to work without DMT is, I'm guessing, quite small.

The recent chain halt is a good example of a single point of failure, which others may term "centralization". Not to say the network is physically centralized but clearly masternodes have no alternative to dashd.

The value to the network is to prove or disprove that DMT can be categorized as "critical infrastructure", and perhaps spur development of alternatives.
 
Yes, it would be possible, but in the implementation I suggest a direction that will give people the opportunity to work in one of two scenarios: a) in the traditional way (at it is now) and b) with the "vote the numbers" functionality. Technically, it would look like this: we create a copy of the voting on proposals window and it is on it that we make changes related to "vote the numbers". Which proposals window would be used would depend on a configuration option.

Thats great!
I will try to code a demonstration....
 
I have concerns about single points of failure, or limited options, and I suspect DMT falls into this category when setting up a masternode.

In the past I called this "centralization" but on reflection I think others were not understanding the nuances in using this word. So yes, DMT and the servers might be "decentralized" yet also be a single point of failure for many people. From a technical point of view, yes, masternodes can be setup without DMT but is this the case in practice? I mean, you setup this service to make things easier for people, which means it's probably complicated / tedious without it. The set of people willing to participate in the dash network AND has the confidence to work without DMT is, I'm guessing, quite small.

The recent chain halt is a good example of a single point of failure, which others may term "centralization". Not to say the network is physically centralized but clearly masternodes have no alternative to dashd.

The value to the network is to prove or disprove that DMT can be categorized as "critical infrastructure", and perhaps spur development of alternatives.
The scenario you're describing goes far beyond the realm of Dash and cryptocurrencies in general, because virtually any tool that helps in some activity that is used by a significant percentage of a certain population (whether it be the Trezor wallet, Discord messenger, Dash forum, or even the Windows operating system) starts causing the "problem" you've mentioned.

Every tool creates more or less dependency, but it wouldn't be very wise to refrain from using it (and lose greater efficiency) just for this reason. It is certainly worth bearing in mind the need to maintain a balance between benefits and dependency, but in my opinion in the case of DMT it has not been significantly disturbed and is - in my opinion - miniscule. Even if 100% of MNOs used it (to me the number is about 30%), the scenario when the app stops working at all, causes very little destabilization - the Dash network works uninterrupted, and if sometimes an MNO needs to perform some action in which DMT normally assists him, with the help of the community he will quickly manage to do it manually. A much bigger potential problem ot that kind would be, for example, after losing the ability to use Discord, which is not that unlikely.

We also need to keep in mind that the implementation of such additional logging would cause what is observed in quantum physics: affecting the observed object. After adding such a function, certain part of users would stop using either the app or the RPC servers (I personally would probably consider it), which would affect exactly the aspects that you would like to be measured.

In my opinion, each additional tool that makes the use of the Dash network easier, causes more interest in this ecosystem and thus makes it stronger.
 
  • Like
Reactions: kot
What would it mean to the network if you, the sole decider in this, has miscalculated. Well, I suppose it is your prerogative, No one can make you do stuff, but maybe you will reconsider.

If your analogy is correct then the world will survive without dash because we have bitcoin, ethereum and Solana. Instead of Windows we have Mac, linux and BSD. Instead of WhatsApp we have Signal Private Messenger. And so on. But no, I am talking about the dash ecosystem.

Allow me to direct you to this coordinated worldwide crackdown where 76 countries worked together to take down the infrastructure of scammers:


That was from March 2022, It's not inconceivable to suggest that further crackdowns are larger and more thorough.

How many unique masternode owners do you think there are? We can say with some confidence there is less than a thousand, perhaps just a few hundred. Based on this alone, I think the dash masternode network is already in a fragile state of failure. It is not like mining where anyone else is free to contribute, the masternode network depends on near real time IP activity; known locations dependent on 1000 dash collateral.

To some extent we can say this about other networks, albeit without collateral requirements. But this is not about "other networks", no less than alternatives to Windows or WhatsApp messenger. We are specifically here for the dash network.

The standard response to the above scenario is that the price would crash and other people would start running nodes. I disagree entirely. When a masternode owner is charged, they may not reveal all their nodes.... true, investigators might be incompetent... but realistically, they are not. If you have never been subjected to interrogation or search warrants, you will just have to take my word for it. Never underestimate the enemy.

In the event of a coordinated take down of the masternode network, dash is all but dead. The pool of potential replacement MNOs will shrink 100x when the dash brand is publicly shamed and dragged through the mud. It would be brutal and a wake up call to others. In such situations, with few or no CEXs, where will people obtain 1000 dash, even if it were pennies? From that small pool, whom will be confident and competent to setup a masternode without DMT? Just to be clear, not the maintenance of masternodes but the setup of masternodes.

I understand others here are ready to challenge this, but those people have nothing to say when you look at the shit show of the dash chain halt. Those people put all their faith in the product "dashd" developed by DCG. Unfortunately, without radical change here, I believe history will repeat itself.
 
Back
Top