GUI tool for running Masternode with Trezor

Bertrand256 said:
I confirm that there is some problem with reading/processing transactions data in the "Masternode Addresses" view mode.

As a workaround, follow these steps:
1. select the "View as: Wallet Account" item in the upper left part of the dialog
2. wait until the fetching transaction data is finished (the "Fetching transactions" label disappears)
3. switch back to the "View as: Masternode Addresses" mode

Now, the UTXOs for the selected masternode address should be visible.
Click to expand...
Unfortunately, this does not work around the problem.

All it does is pull TXes from account #1. MN collaterals are on random 0 - 999999999 accounts at random 0 - 999999999 address. Trying to seek data and check for address use would take forever in that format... Where is it getting this info from? It's not going clearnet to a block explorer, is it? Seems to go too fast for that...

I don't think that viewing "as account" is going to work with the way I store collateral.

It's as if it's ignoring the HD path provided...

I'm able to use the old 0.12.x.x start broadcast when upgrading nodes to 0.13.0.0 while DIP3 is still not in effect. So, it seeks out the HD path properly there, and on the TRANSACTIONS tab. It's just not doing it in the SEND and DETAILS tabs... ?? Result being unable to extract payments...

0.9.2 worked flawlessly... Something didn't translate...
 
Last edited:
Also, I sent logs to your protonmail a few days ago. bertrand256 username was reported as disabled by protonmail when I tried to send... I used b256 and it worked... Release appeared to be signed by that one alone.
 
camosoul said:
I don't think that viewing "as account" is going to work with the way I store collateral.
Click to expand...
From what I guess the paths you are using are, let's say non-standard - part of the path specifying the account number does not start from 0 ' in simplified notation or 2147483648 in full notation. I'd like to create the conditions similar to yours, so can you confirm if the account number is lower or greater that 2147483648 (you can do it via DM)?

What I can say now, is that DMT currently does not handle cases where accounts are used in a different way than described in this document BIP44: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#account-discovery, i.e. if create gaps between account 0' and the ones you are using.
Despite this, I think I can handle it somehow.

Until then, you can use version 0.9.20 in parallel, because the wallet implemented in it is not based on BIP44 and there is absolute freedom in choosing the BIP32 path.

camosoul said:
Also, I sent logs to your protonmail a few days ago. bertrand256 username was reported as disabled by protonmail when I tried to send... I used b256 and it worked... Release appeared to be signed by that one alone.
Click to expand...
Ah, it was you, I just did not know who to associate with. I confirm that the logos have arrived. Thanks.
 
Bertrand256 said:
...freedom in choosing the BIP32 path.
Click to expand...
The troubles of too little freedom are always worse than the troubles of too much... Due to this dynamic, there is no such thing as too much freedom...

Apparently, that applies here as it applies to everything else.

It seems that was the very intent of the Masternode Address View...

Fixing that seems better than a band-aid on top of a work-around.

Wallet Account View seems to be working exactly as you intend it to; following the standard. Don't break it when the whole point of the Masternode Address View is to do this task...
Bertrand256 said:
Ah, it was you, I just did not know who to associate with. I confirm that the logos have arrived. Thanks.
Click to expand...
I posted a message to this thread with a similar subject line included so you'd know... Maybe you're not a Ren and Stimpy fan... ;-)
 
Last edited:
Bertrand256 said:
I confirm that there is some problem with reading/processing transactions data in the "Masternode Addresses" view mode.
Click to expand...
It seems you created both modes for a reason.

Fixing this problem directly makes more sense than trying to band-aid a work-around intended to use a specific standard.

Why not simply use what appears on the Transactions tab to select on the Send tab?

It almost seems like a problem of too much segregation of the user interface. Why do these two things need separate tabs when they work better together on the same pane, like 0.9.2 does it?

It seems to be mostly working, just not all in the same spot... And having different tabs where they don't need to be separated is an organizational annoyance itself...
 
Last edited:
Important information about starting v0.13 masternodes with DMT.

A lot of people are confused about how to currently start v0.13 masternodes, which is mainly due my unfortunate wording in the "Start masternode" button label, but also the nuances about DIP3 and Spork 15 activation.

So, I'd like to summarize the information provided earlier: starting v0.13 masternode should be done in a traditional way, ie by pressing the <Start masternode with hardware wallet> button. Please note that the name of the button is misleading: "<= 0.12" should not be there. The feature associated with the button also applies to v0.13 masternodes and now it is the only thing you should do in DMT to start a masternode. As for the <Send ProRegTx> button: it will not work until DIP3 activation. If you try to use it, you will see the error "bad-tx-type (code 16)".

After the DIP3 activation (it may take a few weeks), you can start registering DIP3 masternodes by clicking the "Send ProRegTx" button. You should do this before Spork 15 is activated to stay in payment queue, but there will be enough time for this if you do not unnecessarily delay it after the payment cycle ends.
 
camosoul said:
Fixing that seems better than a band-aid on top of a work-around.
Wallet Account View seems to be working exactly as you intend it to; following the standard. Don't break it when the whole point of the Masternode Address View is to do this task...
Click to expand...

Without going into details, let me just say that the reason is some unhandled scenario deep inside the code that I intend to handle as soon as I finish more urgent stuff.

When implementing this, I do not need/plan to remove any existing features, because everything has its purpose, i.e. there are people who need a given function.
 
Bertrand256 said:
Without going into details, let me just say that the reason is some unhandled scenario deep inside the code that I intend to handle as soon as I finish more urgent stuff.

When implementing this, I do not need/plan to remove any existing features, because everything has its purpose, i.e. there are people who need a given function.
Click to expand...
Since the ability to launch the old way will only cause confusion in the future, I'll assume the fix will be out when DIP3 goes active, and be combined with the elimination if the old braodcast methods.

...which beggs the question... Does it look like miners are going to go 80% anytime soon? Or is this upgrade never going to happen because miners can control it by simply refusing to upgrade?

Much like sporks still being manual... DASH needs a conscious distributed consensus mechanism for triggering this. DASH can't continue to cede this power and authority to people who merely plug in a box for profit and don't know or care how this negatively impacts the project/network. They don't even know an upgrade is happening...

Miners are distributed, but unconscious.
Sporks are conscious, but centralized.

MNs need a way to say "alright, fuckers, it's been long enough [flip switch, punt the bad actors]" to miners and other MNs... This upgrade will still be pending when 0.14.0.0-rcNN is ready...

Let's not forget, the budget can't fund DASH anymore... Time wasted is more precious than ever.
 
Last edited:
DMT v0.9.22 beta1 has been published.

Binaries: https://github.com/Bertrand256/dash-masternode-tool/releases/tag/v0.9.22-beta1

Note, that this is a beta version that I hope a few people will test to help me spot any problems before publishing the "stable" version at the end of the week. Despite this, the version should work correctly with mainnet in most cases.

The most important change concerns MNOs whose masternode is managed by a separate entity - the operator. In most such cases, it is probably the operator who is responsible for the operator private key generation. The public key associated with it is then handed over to the owner, who uses it in the DIP3 masternode registration process (publishing ProRegTx transaction). In this version, DMT supports such a scenario: after launching the ProRegTx wizard, you need to change the operator key type to "public" by clicking on the "use pubkey" link as in the screenshot below:

upload_2019-2-18_10-40-7.png


upload_2019-2-18_10-42-21.png


Other improvements
The "Start Masternode using hardware wallet" (A) and "Send ProRegTx" (B) buttons are now shown/hidden depending on the status of the DIP3 and Spork 15 network parameters:
  1. Both, DIP3 and Spork15 are inactive (currently on mainnet): only the button A is visible. Masternodes are started in a "traditional" way.
  2. DIP3 is active, Spork 15 is inactive (on mainnet in a few days): both buttons are visible. Starting masternode (eg after protocol upgrade or after a long mn inactivity) is done first by clicking A and after a while by clicking B.
  3. Both, DIP3 and Spork 15 are active: only the B button is visible. Starting masternode is done in a new way: by sending ProRegTx transaction.
This version also includes several other fixes, e.g. regarding the wallet feature. @camosoul, I appreciate if you verify whether the version fixes problems you had with the wallet feature.
 
Bertrand256 said:
This version also includes several other fixes, e.g. regarding the wallet feature. @camosoul, I appreciate if you verify whether the version fixes problems you had with the wallet feature.
Click to expand...
Previously reported issue remains unchanged. Same symptoms/problem persist. Not clear on how to help you with it...

EDIT: no, something has changed. MOST of the same problems persist. However, unchecking the "hide collateral" button on the "send" tab does show the collateral now, which it previously failed to do. But, none of the payments show. There's nothing for me to select. Yes, a payment is sitting there, shown properly in status and "transactions" tab.

Issues relating to the "details" tab remain unchanged (the state of the "hide collateral" button has no impact, expected). It says balance and received are zero. Other data accurate.

The "transactions" tab still seems to be functioning properly, and it shows the entire history accurately.

EDIT AGAIN: Not sure what happened, but it now shows accurate data in "details" tab and "send" tab. Maybe it was just a REALLY long delay for some reason? I'm not sure. but it wasn't working initially, about 10 minutes on it's working. Program was not exited and reloaded. It just spontaneously displayed accurately. Seems to be working appropriately so far...

MOAR EDIT: Error after extracting/sending a payment. Payment does get sent, but this weird error pops up. Basically, hit send, it shows green success, and this error pops up at the exact same moment. Click OK and life appears to go on normally...

DIP3 button not active now, so can't test the other weird stuff that was happening. It's 4am. Sleepie time

Screenshot_2019-02-18_15-12-53.png
 
Last edited:
DMT v0.9.22 has been published.
Binaries: https://github.com/Bertrand256/dash-masternode-tool/releases/tag/v0.9.22

Added
  • DML registration wizard: the possibility of using public keys
    for the operator and Dash addresses for the owner and voting.
  • Main window: the possibility of displaying private keys in the form
    of: Dash address, public key and public key hash (for diagnostics).
  • Wallet: the possibility of adding/hiding any BIP44 account (use
    context menu). Please note, that if there is a gap between the account
    added and the last one used (having a transaction history), the
    official client app for a given hardware wallet (eg Trezor online
    wallet) will not show it.
  • Wallet: the possibility o hiding accounts.
  • Wallet: signing messages with any address.
  • Wallet: showing incoming and not yet confirmed UTXOs (from mempool).
  • Wallet: initially select the masternode address ("Masternode address"
    mode) that is currently selected in the main window.
Changed
  • Main window: the user's role is morphed into three independent
    roles - owner, operator and voter - one can choose any combination of
    them.
  • DML registration wizard: support for the 'feeSourceAddress' field
    in the protx prepare call (added in Dash Core rc11).
  • Main window: suport for deterministic masternodes in the masternode
    status area.
  • Main window: the visibility of the buttons associated with starting
    masternodes depends on the status of DIP3 and Spork 15.
  • Wallet: improved refreshing of the UTXO list as a result of reading
    new transactions.
Fixed
  • Proposals: fixed an issue that caused some proposals to not be
    displayed.
  • Wallet: issues with fetching transactions and showing UTXOs for
    BIP44 accounts that are beyond the scope of the standard BIP44
    account discovery method.
  • Fixed several other minor issues.
 
In the meantime, I've published three versions with quick fixes for a few issues reported by MNOs:
  • "Deadlock detected" problem when sending a transaction from wallet while new transactions data are being fetched from the network
  • "Error while broadcasting vote message" problem with voting after DIP3 activation
  • "Unknown USB interface" error when connecting to Keepkey on Windows

Binary versions of the latest fix are available under the same URL: https://github.com/Bertrand256/dash-masternode-tool/releases/tag/v0.9.22
 
DMT v0.9.23 has been published.
Binaries: https://github.com/Bertrand256/dash-masternode-tool/releases/tag/v0.9.23

Please use this version to review for what proposals you need recast your votes (it removes from the application cache votes sent before the spork 15 activation). It also has a GUI support to change the voting private key, which may be needed by some MNOs.

Here are the main changes in one picture:
 

Attachments

  • 2019-04-27_16-15-37.png
    2019-04-27_16-15-37.png
    240.5 KB · Views: 280
GrandMasterDash said:
If not, perhaps it could?
Click to expand...

Yes, it would be possible to implement some additional verification mechanisms of the masternode configuration into the program, but after reading the discussion, I begin to conclude that it would not be the best approach. The point is, that the Dash functionalities planned for the coming months will require masternode to provide much greater availability/QoS than it was before. This in turn will face the mn operators to deal with problems that could have been ignored until now, which will require some technical knowledge about the operating system running the Dash daemon and a lot of knowledge about the specifics of the Dash network. People without such knowledge trying to administer masternode sooner or later will get into trouble. For such people, it is probably better to outsource this task to professional vendors (operators). Here I do not mean people who want to learn it, because almost everyone can do it. I mean people who do not want to (because it is beyond their interest) or simply do not have time for it.
 
You must log in or register to reply here.
Back
Top