Proposal “dash-masternode-tool-continuation-2a“ (Completed)Back
| Title: | Dash Masternode Tool - Sept-Dec 2018 - support for Deterministic Masternodes |
| Owner: | Bertrand256 |
| Monthly amount: | 152 DASH (4571 USD) |
| Completed payments: | 2 totaling in 304 DASH (0 month remaining) |
| Payment start/end: | 2018-12-17 / 2019-02-14 (added on 2018-12-12) |
| Votes: | 930 Yes / 32 No / 16 Abstain |
Proposal description
* UPDATE (1st February, 2019): I've extended the scope of this proposal by January within the same funds, which results in a further reduction of my involvement costs per month.
This proposal concerns the continuation of the development of the Dash Masternode Tool (DMT) program in the period September-December 2018.
Background
DMT is a program that supports MNOs in performing some important activities related to masternodes if its collateral is controlled by a Trezor, KeepKey or Ledger type of hardware wallets. Over the last year, the development of the program was financed by Dash Treasury through the acceptance of my two proposals. The last one, covering the period from June to August 2018, was focused on the v0.12.3 protocol support, providing user support in the process of migration to this version, and starting work on supporting Deterministic Masternode Lists, described in the document DIP-3.
Due to extensive scope of the last of these topics, I was continuing work on it after the end of the duration of my last proposal up to the present day. I estimate that further works will be carried out until end of December or a bit longer - a lot depends on when the the Dash v0.13 software (which introduces deterministic masternodes) will be launched on mainnet and what challenges it will create.
In terms of financing my involvement, I decided to take a risk and change my approach: instead of asking for payment "in advance" - right after the end of the duration of the previous proposal, I decided to apply for funds after completing some part of the works, that is: now. There were several reasons for this decision, but the most important is that it's is much easier to calculate the costs for past period than for the future, when I do not know whether I will be involved in the project 100% or a little less. The disadvantage of this approach (for me) is the risk of MNOs not accepting my proposal and thus me not receiving any reimbursement at all, which is quite likely if you take into account the tight budget, we are currently dealing with. I am aware of it and I will not have any complaints about it if it happens - I am in this project because I believe that Dash has a bright future ahead, despite the current problems of the crypto industry.
The scope
Back to the scope of the proposal, i.e. handling of DIP-3 masternodes. We now know the details of the default migration process of "old" masternodes to "new" if their collaterals are controlled by harware wallets and if the funds are to remain "untouched". Without going into details, this process will require several manual steps, including entering commands in the Dash-Qt debug console. This will not be a major problem for tech savvy users, however, from my conversations with MNOs, I know that some of them do not feel confident in this kind of activities and may have a problem with this process. The upcoming changes planned for v0.13 are so important for the whole Dash ecosystem that the problems of individual MNOs can accumulate and in some way become a bigger problem, which is why I want to help in eliminating at least this one. The features that I am preparing in DMT in this area are therefore focused on the simplification of the process and are dedicated to a group of less-skilled users or, in general, to people who prefer to click rather than to enter commands.
The initial DMT version that includes the functionality of migration to DIP-3 masternodes has been released a few days ago, so anyone can now test the process on testnet and make sure that the process on mainnet will proceed without any surprises. Executables of this (beta) version are available here: https://github.com/Bertrand256/dash-masternode-tool/releases/tag/v0.9.21-beta5
The target (production) version of DMT, supporting the above processes, will additionally have several earlier promised functionalities that I have been working on in the meantime, including: significantly improved wallet with the history of transactions and their values expressed in USD, which some MNOs want to use for tax purposes.
Because Dash testnet is officially supported only by Trezor hardware wallets, MNOs using Ledger Nano S or Keepkey to control their mainnet masternodes, can use the Trezor emulator to perform the required tests on testnet. To make it easier, I prepared executable version of the emulator, which I've published on GitHub,. The post on this subject can be found here: https://www.dash.org/forum/threads/gui-tool-for-running-masternode-with-trezor.13748/page-11#post-203917
Budget
Due to the tight budget, I decided to cut my monthly reward up to the amount of 6500$, to postpone clearing the costs of infrastructure which I incurred and divide the payment into two cycles.
Input:
Amount: 6500 * 3 / 65 = 300 + 5 Dash
Monthly: 152
Cycles: 2
Additional information
The method of supporting migration to the DIP-3 masternodes proposed by me in DMT will require covering the costs of ProRegTx transactions sent on behalf of users who decide to use this option. If nothing changes and this option will be available in mainnet, I will cover the costs myself, but then I will ask Dash Treasury for a refund. However, these costs should not be greater than a few Dash.
This proposal concerns the continuation of the development of the Dash Masternode Tool (DMT) program in the period September-December 2018.
Background
DMT is a program that supports MNOs in performing some important activities related to masternodes if its collateral is controlled by a Trezor, KeepKey or Ledger type of hardware wallets. Over the last year, the development of the program was financed by Dash Treasury through the acceptance of my two proposals. The last one, covering the period from June to August 2018, was focused on the v0.12.3 protocol support, providing user support in the process of migration to this version, and starting work on supporting Deterministic Masternode Lists, described in the document DIP-3.
Due to extensive scope of the last of these topics, I was continuing work on it after the end of the duration of my last proposal up to the present day. I estimate that further works will be carried out until end of December or a bit longer - a lot depends on when the the Dash v0.13 software (which introduces deterministic masternodes) will be launched on mainnet and what challenges it will create.
In terms of financing my involvement, I decided to take a risk and change my approach: instead of asking for payment "in advance" - right after the end of the duration of the previous proposal, I decided to apply for funds after completing some part of the works, that is: now. There were several reasons for this decision, but the most important is that it's is much easier to calculate the costs for past period than for the future, when I do not know whether I will be involved in the project 100% or a little less. The disadvantage of this approach (for me) is the risk of MNOs not accepting my proposal and thus me not receiving any reimbursement at all, which is quite likely if you take into account the tight budget, we are currently dealing with. I am aware of it and I will not have any complaints about it if it happens - I am in this project because I believe that Dash has a bright future ahead, despite the current problems of the crypto industry.
The scope
Back to the scope of the proposal, i.e. handling of DIP-3 masternodes. We now know the details of the default migration process of "old" masternodes to "new" if their collaterals are controlled by harware wallets and if the funds are to remain "untouched". Without going into details, this process will require several manual steps, including entering commands in the Dash-Qt debug console. This will not be a major problem for tech savvy users, however, from my conversations with MNOs, I know that some of them do not feel confident in this kind of activities and may have a problem with this process. The upcoming changes planned for v0.13 are so important for the whole Dash ecosystem that the problems of individual MNOs can accumulate and in some way become a bigger problem, which is why I want to help in eliminating at least this one. The features that I am preparing in DMT in this area are therefore focused on the simplification of the process and are dedicated to a group of less-skilled users or, in general, to people who prefer to click rather than to enter commands.
The initial DMT version that includes the functionality of migration to DIP-3 masternodes has been released a few days ago, so anyone can now test the process on testnet and make sure that the process on mainnet will proceed without any surprises. Executables of this (beta) version are available here: https://github.com/Bertrand256/dash-masternode-tool/releases/tag/v0.9.21-beta5
The target (production) version of DMT, supporting the above processes, will additionally have several earlier promised functionalities that I have been working on in the meantime, including: significantly improved wallet with the history of transactions and their values expressed in USD, which some MNOs want to use for tax purposes.
Because Dash testnet is officially supported only by Trezor hardware wallets, MNOs using Ledger Nano S or Keepkey to control their mainnet masternodes, can use the Trezor emulator to perform the required tests on testnet. To make it easier, I prepared executable version of the emulator, which I've published on GitHub,. The post on this subject can be found here: https://www.dash.org/forum/threads/gui-tool-for-running-masternode-with-trezor.13748/page-11#post-203917
Budget
Due to the tight budget, I decided to cut my monthly reward up to the amount of 6500$, to postpone clearing the costs of infrastructure which I incurred and divide the payment into two cycles.
Input:
- Dash price (12 Dec 2018): 65 $/Dash
- Effective number of months worked in the period September - December 2018: 3
- Proposal cost reimbursement: 5 Dash
Amount: 6500 * 3 / 65 = 300 + 5 Dash
Monthly: 152
Cycles: 2
Additional information
The method of supporting migration to the DIP-3 masternodes proposed by me in DMT will require covering the costs of ProRegTx transactions sent on behalf of users who decide to use this option. If nothing changes and this option will be available in mainnet, I will cover the costs myself, but then I will ask Dash Treasury for a refund. However, these costs should not be greater than a few Dash.
Show full description ...
Discussion: Should we fund this proposal?
Submit comment
|
No comments so far?
Be the first to start the discussion! |
I would like to let you know that I've extended the scope of this proposal by January within the same funds, which results in a further reduction of my involvement costs per month.
Dash Masternode Tool - Sept-Dec 2018 by Bertrand256
https://dashwatchbeta.org/r/JAN19/DASH-MASTERNODE-TOOL-CONTINUATION-2A
DashMasternodeTool - development continuation by Bertrand256
http://bit.ly/DWDMTDEC18
I voted yes, this thing is extremely useful. Can you please implement a dark theme into the tool? I basically check it everyday and have dark theme on all of my systems. Thank you for the valuable contribution.
I'd like to see more proposals for "already done" work (refunds) like this one. It shifts the risk that project won't be completed from Dash budget to the project owner, which is a good thing as Dash budget is not really meant for VC-like speculation, otherwise it would be called Dash fund instead of Dash budget. I believe this way of requesting funds would also help project owners approval rates as well, as it's much easier to get funds when you can prove results and effectiveness. Also, in times when budget is tight, proposal can always be resubmitted and is more likely to get funded than resubmitted proposal for advance project which got turned down the first time.
After witnessing some unsuccessful proposals and lost funds in the last two years, I began to like the idea of shifting the risk from the MNOs to the proposal owner. However, I am aware that not every proposal owner can apply this approach.
Thank you on behalf of the community for providing a very valuable tool.
Voring Yes!!!