Proposal “dash-masternode-tool-continuation“ (Completed)Back
| Title: | DashMasternodeTool - development continuation |
| Owner: | Bertrand256 |
| Monthly amount: | 20 DASH (425 USD) |
| Completed payments: | 3 totaling in 60 DASH (0 month remaining) |
| Payment start/end: | 2018-05-18 / 2018-08-16 (added on 2018-05-05) |
| Final voting deadline: | in passed |
| Votes: | 0 Yes / 0 No / 0 Abstain |
Proposal description
This is aproposal to continue the development of the DashMasternodeTool application in full-time mode.
DashMasternodeToolis an open source application, that helps to perform the most important activities of the Dash masternode operator. The source code
and documentation are available on GitHub: https://github.com/Bertrand256/dash-masternode-tool
Pre-proposal: https://www.dash.org/forum/threads/dashmasternodetool-development-continuation-pre-proposal.36815/#post-183438
About me
I've been working on developing DashMasternodeTool for about a year. Since October 2017, thanks to the funding from the Dash budget, I'm working on this project in an exclusive (full-time) mode.
Here are the features implemented at that time:
The latest version of the application was released several days ago: https://www.dash.org/forum/threads/gui-tool-for-running-masternode-with-trezor.13748/page-10#post-182892
Further development plans
Let me start with the features related to the recently announced improvement proposals (DIP3, DIP4), composing Deterministic Masternode List. Their implementation will eliminate the need of broadcasting the 'Start masternode' message after each reconfiguration of a masternode (or its longer unavailability) - the operation that is currently the main function of the DashMasternodeTool application. This is undoubtedly great news for all MNOs, because from that moment the operations controlling a masternode (start, moving to another server, etc.) will not depend on access to the private key controlling the masternode collateral.
In the new reality, access to the collateral private key will be needed only once - when sending the initial ProRegTx transaction. This operation will be tied to the transfer of 1000 Dash and it will certainly be supported by the official Dash Core app. Not all details are already known, but it seems, that to avoid having to send 1000 Dash from a hardware wallet (which I hope are used by most MNOs) to an address controlled by Dash Core (in order to send an initial ProRegTx transaction from there) we will probably need suport of external tools. For this reason, if signing such a new transaction type will be possible with Trezor/Ledger/Keepkey hardware wallets (I will analyse this), it will be implemented in DashMasternodeTool. In addition, I plan to implement support for two new roles resulting from DIP3 and DIP4: Operator and Voter.
The implementation of the above features will have absolute priority, but it will only start when the supporting Dash Core test version appears and the TESTNET will be ready for it. Because the dates are not yet known, I will start by implementing further interesting ideas, that the members of the community suggested to me:
As the dynamics in this area is huge, let's not treat this list too rigidly - I am always open to suggestions from the community, so if something more important appears, it will have priority over the less important features.
Budget
Input information:
Costs:
Overall: (17.73 + 1.237) * 3 + 5 - 1.6 = 60.3 Dash
Per month: 20.1 Dash
DashMasternodeToolis an open source application, that helps to perform the most important activities of the Dash masternode operator. The source code
and documentation are available on GitHub: https://github.com/Bertrand256/dash-masternode-tool
Pre-proposal: https://www.dash.org/forum/threads/dashmasternodetool-development-continuation-pre-proposal.36815/#post-183438
About me
I've been working on developing DashMasternodeTool for about a year. Since October 2017, thanks to the funding from the Dash budget, I'm working on this project in an exclusive (full-time) mode.
Here are the features implemented at that time:
- Support for Ledger Nano S
- Support for Trezor T
- Improvements in the Payment window
- Improvements in the Proposals window
- Encryption of application configuration files with the use of hardware wallets
- Switching between different configurations
- Support for Dash Testnet
- Extending the status of the masternode by information about its balance and the queue position
- Initialization and recovery wizard for hardware wallets, useful for initializing Trezor devices on offline computers
- Creation of custom firmware supporting Dash testnet and a wizard dedicated to performing an easy installation of firmware in hardware wallets
- Support for multiple HW devices of the same type (Trezor, KeepKey) connected to the app at the same time
- Providing additional RPC nodes for MAINNET and TESTNET
- Significant improvement of the app's documentation
- Many other smaller fixes and improvements
The latest version of the application was released several days ago: https://www.dash.org/forum/threads/gui-tool-for-running-masternode-with-trezor.13748/page-10#post-182892
Further development plans
Let me start with the features related to the recently announced improvement proposals (DIP3, DIP4), composing Deterministic Masternode List. Their implementation will eliminate the need of broadcasting the 'Start masternode' message after each reconfiguration of a masternode (or its longer unavailability) - the operation that is currently the main function of the DashMasternodeTool application. This is undoubtedly great news for all MNOs, because from that moment the operations controlling a masternode (start, moving to another server, etc.) will not depend on access to the private key controlling the masternode collateral.
In the new reality, access to the collateral private key will be needed only once - when sending the initial ProRegTx transaction. This operation will be tied to the transfer of 1000 Dash and it will certainly be supported by the official Dash Core app. Not all details are already known, but it seems, that to avoid having to send 1000 Dash from a hardware wallet (which I hope are used by most MNOs) to an address controlled by Dash Core (in order to send an initial ProRegTx transaction from there) we will probably need suport of external tools. For this reason, if signing such a new transaction type will be possible with Trezor/Ledger/Keepkey hardware wallets (I will analyse this), it will be implemented in DashMasternodeTool. In addition, I plan to implement support for two new roles resulting from DIP3 and DIP4: Operator and Voter.
The implementation of the above features will have absolute priority, but it will only start when the supporting Dash Core test version appears and the TESTNET will be ready for it. Because the dates are not yet known, I will start by implementing further interesting ideas, that the members of the community suggested to me:
- Changing the view in the main application window into a full list of masternodes.
- Retrieving additional information related to masternodes and the servers they run on, such as the current block number, free server RAM, disk space, etc.
- Security/privacy features, such as support for collateral controlled by paper wallets.
- Commenting on proposals in the proposals window (I'll poll the community about this).
- Support for different passphrases for each masternode.
- Wizard allowing quick and easy installation and configuration of a masternode.
As the dynamics in this area is huge, let's not treat this list too rigidly - I am always open to suggestions from the community, so if something more important appears, it will have priority over the less important features.
Budget
Input information:
- Price of Dash: 485$
- Left from my previous proposal: 1.6 Dash (doc translation/proofreading)
- Months: 3
Costs:
- My salary: 8600 $/mo = 17.73 Dash/mo
- Proofreading and translation of documentation: 600$/mo = 1.237 Dash / mo
- Proposal fee reimbursement: 5 Dash
Overall: (17.73 + 1.237) * 3 + 5 - 1.6 = 60.3 Dash
Per month: 20.1 Dash
Show full description ...
Discussion: Should we fund this proposal?
Submit comment
|
No comments so far?
Be the first to start the discussion! |
DashMasternodeTool - development continuation by Bertrand256
https://dashwatch.org/files/1532769242651.pdf
DashMasternodeTool - development continuation by Bertrand256
https://dashwatch.org/files/1530055497758.pdf
DashMasternodeTool - development boost by Bertrand256
https://dashwatch.org/files/1522220254116.pdf
This is a must for a MN that travels without a wallet and needs to vote while on the road.
No one has brought it up yet. Your price is at $485 per dash. Most worry about Dash going up and the contractor making "more". I see that you are significantly "less" in compensation to do the lower Dash value. I would be happy to vote yes to a follow-on proposal.
Thank you,
@DashRacer
Yes, such large variations of the agreed amount expressed in FIAT, we're dealing with lately, are a completely new experience compared to the normal contractor's job, but in return we have the opportunity to support the creation of something great.
But I also believe, that - probably like most of us - the future Dash price movement will be up, so it will compensate the current deficit resulting from the lower-than-expected rate. My proposal extends over a period of three months, so there is a time for it.
Note I wrote "private send" in the heading and meant to write "instant send"
It would be good to have a dedicated forum section for issues with DMT.
On a different note - Are there any plans to develop the core wallet to improve features/functionality specifically to include more control over mixing inputs? (i.e. allowing user to select the denominations and extend mixing beyond 8 rounds, etc.).
Support of hardware wallets in a program is usually carried out by including their official API libraries into the program's code. Inclusion of such "foreign" code into Dash Core causes you to lose control over the quality and security of the whole. Additionally, some of the hw APIs sometimes change so much, that it results in destabilization of the current functionalities and affects your roadmap in an unpredicted way, which then becomes dependent on third parties.
I suppose that these risks are to severe for Dash Core, but on the other hand, it is much easier to mitigate them in not-that-important app as DashMasternodeTool.
As for your questions regarding mixing, unfortunately I don't have any knowledge about plans related to this area.
One request: Could you please release a Snap/Flatpack for Linux users? Would be much nicer than running from a zip.
I will check the possibility of preparing binaries for Linux in these formats.
solarguy
Of course yes!