Attention Dash Masternode Owners: Please register with the Deterministic Masternode List now

Status
Not open for further replies.

martinf

Member
Aug 21, 2015
70
38
58
I have seen a few update delays over the years with Dash, but this in my opinion would be the hardest delay to sell and also the hardest delay to defend.
A manual spork activation (basicly nothing more then a switch of a button) possibly getting delayed because of too much updating on the last day, while at the same time
having already a majority (63+ %) updated.

Sure i could live with having to wait another month (and pray that the 24H registration condition does not form a factor again), but at the same time it would undermine
my confidence in future Dash update cycles as it will introduce an element of uncertainty with future spork activations.

At this point i just pray for a miracle and hope this spork gets activated tomorrow somehow.
Yeah I think we should learn from this. In hindsight I think it's clear that the last-24h-limit was a bad idea in this case. The intention is good, but should not be combined with a fixed time limit (March 8th in this case) as we are bound to see anomalies in the registrations in the last hours. Maybe it would have been better to relax the condition to allow the 24h period to have been at any earlier point and not necessarily the last 24 hours? Not sure it would make a whole lot of more sense though.

A simple fixed percentage is probably the best anyway. Maybe 80% is a bit much? Or maybe not. Maybe I just need to be a bit more patient :D

Anyway. Let's hope we get 80% before the next cycle to rule out any potential last minute spikes ruin another month for us! We should be safe
 
Apr 23, 2017
66
26
58
Anyway. Let's hope we get 80% before the next cycle to rule out any potential last minute spikes ruin another month for us! We should be safe
Well unless our first attempt to go to Determistic masternodes doesn't fail, if it does it will take at least 2 more months for this point on.
 

qwizzie

Well-known Member
Aug 6, 2014
1,582
738
183
Well unless our first attempt to go to Determistic masternodes doesn't fail, if it does it will take at least 2 more months for this point on.
From page 1 post 1 : "If the network does not meet the below activation criteria by March 8, the team will hold off activating it until the next voting cycle begins in early April."

Only question with activating early April is if the two conditions for activation of spork 15 have been met then (in early April). If the answer is no, we risk another delay.

Worst case scenario for early April : we stall at or below 79.9% and the 24H progress gets once again too high due to masternodes updating on the last day --> Delay.
Best case scenario for early April : we reach 80% at which the 24H progress is no longer a factor (eventhough the percentage table seems to say otherwise) --> Activation.
Once we reach 80%, we will automatically activate without regard to the percentage registered within the last 24 hours.
 
Last edited:

strophy

Administrator
Dash Core Team
Moderator
Dash Support Group
Feb 13, 2016
716
415
133
The concern here about Sporking at a later date in the cycle is not for the missed payments resulting from removing 20+% of masternodes from the network, but for the proposal owners, particularly multi-month proposal owners, who need to recoup their previous vote count in time for the voting cutoff. Enabling Spork 15 resets all proposal votes and must be done early in the cycle to remain fair to all network participants.
 

qwizzie

Well-known Member
Aug 6, 2014
1,582
738
183
My concern with the spork activation mechanisme has to do with the conditions for activation. Having two conflicting conditions (where one condition can overrule the other) just
introduce uncertainty and confusion into the whole activation process.

I hope these conditions at some point get simplified or brought back to just one condition for future spork activations.
For clarity : i'm talking about the total registrations percentage versus the registrations in the last 24 hours percentage.
The registrations in the 24 hours percentage can (and currently actually do) overrule the total registrations percentage between 50% and 80%.
 
Last edited:

drakee

New Member
Aug 3, 2014
25
13
3
Denver, CO
wolfgirl.bandcamp.com
I had a question regarding the Payout address I registered for the Deterministic Masternode List. I needed to leave a small amount of Dash on that address in order to complete the registration process, for fees.

Now that my masternodes are registered, do I still need to keep some Dash parked at that address to pay for future fees, or can I let it go to 0 at this point?

Thanks!
 

Howard90

New Member
Mar 14, 2019
3
0
1
28
Hi there! It’s great site. so many topics and opinions. I used to read, basically washingtonpost, but now your site one of my favorites. Thank you!
 

strophy

Administrator
Dash Core Team
Moderator
Dash Support Group
Feb 13, 2016
716
415
133
@drakee you can empty the payment address if the masternode is already registered. But you will need to put balance back there if you want to make any transactions in the future to change the masternode configuration, or specify an alternative feeSourceAddress at that point in time.
 
  • Like
Reactions: drakee

qwizzie

Well-known Member
Aug 6, 2014
1,582
738
183
Quick question about spork 16 (InstantSend Autolocks) and the Dash Core windows v0.13.2 wallet :

When spork 16 activates and enables Automatic InstantSend on Simple Transactions (somewhere after spork 15 activation), will the Dash Core windows wallet require a full sync (blockchain sync + additional data sync) before it locks the input amounts on simple transactions automatically?
Or can it lock input amounts of simple transactions automatically, when its just synced to the blockchain and is still busy syncing additional data ?
 

Curacao

New Member
Feb 23, 2017
16
3
3
28
Hi Everyone,

We've been struggling to start our masternode with the DIP003 protocol. With the last step as mentioned on this page we're getting the below error:
Code:
bad-protx-key-not-same (code 16) (code -1)
We're using the same address (newly generated) for both the owner and voting address, tried different ones as-well. We've tried swapping out different variables (keys), with no luck as we keep hitting that same error.

We're out of clues and at this point any advice would be greatly appreciated.
 

bhkien

Active Member
Mar 31, 2014
462
286
133
Canada
vietriches.com
Hi Everyone,

We've been struggling to start our masternode with the DIP003 protocol. With the last step as mentioned on this page we're getting the below error:
Code:
bad-protx-key-not-same (code 16) (code -1)
We're using the same address (newly generated) for both the owner and voting address, tried different ones as-well. We've tried swapping out different variables (keys), with no luck as we keep hitting that same error.

We're out of clues and at this point any advice would be greatly appreciated.
Currently spork 15 isn’t activated so that voting address must be same with owner address. You can update different voting address after spork 15 activated.
 

Curacao

New Member
Feb 23, 2017
16
3
3
28
As clearly mentioned in our post, we've tried using the same keys, we've tried all possible combination and keep hitting that same error.
 

qwizzie

Well-known Member
Aug 6, 2014
1,582
738
183
As clearly mentioned in our post, we've tried using the same keys, we've tried all possible combination and keep hitting that same error.
you mentioned "with the last step" you hit that errorcode... which step is that exactly ?

Prepare a ProRegTx transaction ?
Sign the ProRegTx transaction ?
Submit the signed message ?




 
Last edited:

Curacao

New Member
Feb 23, 2017
16
3
3
28
you mentioned "with the last step" you hit that errorcode... which step is that exactly ?

Prepare a ProRegTx transaction ?
Sign the ProRegTx transaction ?
Submit the signed message ?

When executing the last command:
Code:
protx register_submit ***
 

qwizzie

Well-known Member
Aug 6, 2014
1,582
738
183
When executing the last command:
Code:
protx register_submit ***
that command consists of two parts :

  • tx: The serialized transaction previously returned in the tx output field from the protx register_prepare command
  • sig: The message signed with the collateral key from the signmessage command
Make sure tx is copied within its specific brackets --> ""

example of wrong usage :

"tx":
"030001000191def1f8bb265861f92e9984ac25c5142ebeda44901334e304c447dad5adf6070000000000feffffff0121dff505000000001976a9149e2deda2452b57e999685cb7dabdd6f4c3937f0788ac00000000d1010000000000c7fd27022913dd8505ae701e0fd56625c3fa9d2ff47802225faae562389e492c0100000000000000000000000000ffff8c523b334e1fad8e6259e14db7d05431ef4333d94b70df1391c601d2c43f022eeceaaf09532d84350feb49d7e72c183e56737c816076d0e803d4f86036bd4151160f5732ab4a461bd127ad8e6259e14db7d05431ef4333d94b70df1391c600001976a914adf50b01774202a184a2c7150593442b89c212e788acf8d42b331ae7a29076b464e61fdbcfc0b13f611d3d7f88bbe066e6ebabdfab7700", "collateralAddress": "yPd75LrstM268Sr4hD7RfQe5SHtn9UMSEG",

example of right usage :

030001000191def1f8bb265861f92e9984ac25c5142ebeda44901334e304c447dad5adf6070000000000feffffff0121dff505000000001976a9149e2deda2452b57e999685cb7dabdd6f4c3937f0788ac00000000d1010000000000c7fd27022913dd8505ae701e0fd56625c3fa9d2ff47802225faae562389e492c0100000000000000000000000000ffff8c523b334e1fad8e6259e14db7d05431ef4333d94b70df1391c601d2c43f022eeceaaf09532d84350feb49d7e72c183e56737c816076d0e803d4f86036bd4151160f5732ab4a461bd127ad8e6259e14db7d05431ef4333d94b70df1391c600001976a914adf50b01774202a184a2c7150593442b89c212e788acf8d42b331ae7a29076b464e61fdbcfc0b13f611d3d7f88bbe066e6ebabdfab7700

Make sure the sig is fully copied as well and that there is a space between tx and sig.

If this does not help i suggest you re-do the protx register_prepare command from start, making sure both ownerKeyAddr and votingKeyAddr are the same (as you did the first time) and make sure you use the BLS public key with the operatorPubkey. Also check if you need to use feeSourceAddress (which needs to have some small funds) to get this transaction through.
 
Last edited:

Curacao

New Member
Feb 23, 2017
16
3
3
28
Hi Qwizzie,

We didn't use brackets (""), and we're pretty sure everything was copied correctly. Prepared everything in notepad window so just copy pasted into the dash debug window. Yeah we're out of clues as well.
 

qwizzie

Well-known Member
Aug 6, 2014
1,582
738
183
Hi Qwizzie,

We didn't use brackets (""), and we're pretty sure everything was copied correctly. Prepared everything in notepad window so just copy pasted into the dash debug window. Yeah we're out of clues as well.
Strange to see "bad-protx-key-not-same (code 16) (code -1)" in the "Submit the signed message" step (the final step). Hopefully a dev team member can provide a better explanation for these two error codes.
(i'm out of clues myself at this point)
 

qwizzie

Well-known Member
Aug 6, 2014
1,582
738
183
Hi Qwizzie,

We didn't use brackets (""), and we're pretty sure everything was copied correctly. Prepared everything in notepad window so just copy pasted into the dash debug window. Yeah we're out of clues as well.
Are you registering your masternode with v0.13.2 ? If yes, have you put the BLS priv key in the dash.conf ? (both on local and on your server) and restarted the server ?

Dash Community,

We are pleased to announce the release of Dash Core v0.13.2 to mainnet. This release contains several optimizations to Dash Core v0.13 to provide an easier user experience for masternode owners as well as fix a few bugs the team found during the initial rollout. This upgrade is non-mandatory, but is recommended for all users.

Below are a few highlights of this release.

Mandatory “masternodeblsprivkey” field when configuring and running a masternode
This field was not mandatory in previous versions that had to function with and without DIP3 (Deterministic Masternode List) activated. Now that DIP3 has activated, this field will be required to ensure that masternode owners enter their operator key. This field will check that the format of the key entered is valid, and return an error if the key format is incorrect.
 

Curacao

New Member
Feb 23, 2017
16
3
3
28
Hi qwizzie,

That might just be it, we'll try that. In the wiki it isn't clearly mentioned that the bls private key should also be added to the client's dash.conf file. We'll follow up.
 

Curacao

New Member
Feb 23, 2017
16
3
3
28
Hi everyone,

We've managed to get the MN up again. Indeed we needed to put the BLS Priv key in both the MN as client config. That was our mistake. This wasn't clearly mentioned in the wiki page. Thank you all for your assistance!
 

johnyj

New Member
Sep 23, 2017
5
0
1
40
Hi, I just updated masternode following the guide, and "dash-cli masternode list" is showing my mn, but the owner address and voting address have changed to something else which is not in my registration tx message, how is that possible?
 

johnyj

New Member
Sep 23, 2017
5
0
1
40
I just followed the guide, no DMT, done from a PC client 0.13.2 without any problem in the process. Is it possible for some to intercept my tx and change the owneraddress to something else?

In my understanding of cryptocurrency, a signed message is not possible to change dramatically even with transaction malleability, I guess it is a listing problem?
 
Last edited:

qwizzie

Well-known Member
Aug 6, 2014
1,582
738
183
When exactly will Spork 15 be activated?

I think I found the answer here:
https://blog.dash.org/spork-15-activation-april-2-2ee937afb64d

"Therefore we now plan to activate spork 15 on April 2, the day after the next super block payout."
Yep, in 2 days. Spork 16 will follow soon after that. And in 10 days (more or less) we will have our annual blockreward reduction (-7.1%) also.
Link : https://stats.masternode.me/network-report/226667

So a few important events coming up in a short time period.
 
Last edited:
Status
Not open for further replies.