Dash Core v0.13 on Mainnet

[camosoul]

Why take long time? No! Not take long time! Farang pee bah!

There are several layers to this update, each layer equating roughly to the full process of previous upgrades. There's going to be a lot of entropy added by MNOs being unsure how to properly upgrade, too. Especially once DIP3 hits... If this is pulled off in merely 12 days, it'll be freakin' amazing.

You don't need me to explain this to you, of course, but a simplified explanation why it's taking longer, yet going much more smoothly, seems in order. For the benefit of the onlookers.

DASH is waayyy over the heads of the average cryptotard. They don't even notice or comprehend most of what's going on in this project. All they understand is hash algos, block rates, and ouija boards... OK, most of them don't even understand that much...

 

[f8192]

Can we activate v14 features (ChainLocks) without waiting these miners to update their software? As far as I understand, 51% mining attack won't be a problem

 

[qwizzie]

Can we activate v14 features (ChainLocks) without waiting these miners to update their software? As far as I understand, 51% mining attack won't be a problem

Interesting question, although your question is more related to a future update (v.0.14, currently being coded on testnet).

Let me refrase it as follows : once we have activated all DIPS and sporks from v.013 on mainnet and finished testing V0.14 on testnet
and are at the stage of implementing v.0.14 on mainnet, will that v0.14 require 80% of miners support before activation like v0.13 ?

(i refrase your question this way, because we cant introduce v0.14 on mainnet before v.0.13 has been fully activated)

 

[qwizzie]

I have been thinking of a way to reach miners and miningpools faster and more efficient, when there are updates that specifically involve miners/miningpools. Updates dat involve DIPS or updates where miners/miningpools need to signal a readiness to the network (80% ).

What if DCG makes a specific mining update thread which is locked for comments, pinned for visibility and only shows the updates that are relevant to miners /miningpools ? Miners/miningpools should then be encouraged to put a watch on that thread, after which they get informed automatically when new updates for miners are added by DCG in that thread. They will receive that information in the form of an alert flag in the dash.org/forum and through an email.

The same (making an official seperate update thread, locked for comments) can also be done for masternode owners, where DCG can put important update information, like spork activation or further steps into an update process which are relevant for masternode owners.

The watch option of threads can be an important tool to reach certain groups (miners / masternode owners) and people are perhaps more inclined to use it if it directly impacts their core activity and when the alert and email are only about their core activity (the current official announcement thread is too broad for that).

 

[qwizzie]

Approx 1 week to lock-in DIP3 (if it stays at or above 80%)
Approx 1 week to activate DIP3
Then activation of sporks 15 & 16

 

[camosoul]

Approx 1 week to lock-in DIP3 (if it stays at or above 80%)
Approx 1 week to activate DIP3
Then activation of sporks 15 & 16

[wet fart noises]

STAYS at/above 80%. That borders on impossible...

Regardless of "be patient" nonsense, Miners simply should not have this authority. MasterNodes should.

0.13.1.0 is out...

 

[qwizzie]

What happens during DIP3 lock-in, if percentage on the hourly graph briefly drops below 80% during the 4032 block window / lock-in period ? Does that block window reset or will it just continue adding, once miners signal above 80% again ?
Update : eventhough the hourly graph briefly dipped to 79% yesterday, the lock-in still occurred today. Which means i can safely conclude it will just continue adding. Which is good to know for future DIP updates.
Is there a way for us to check if DIP3 lock-in has actually ocurred ? (we should be pretty close to it by now)
Update : ./dash-cli getblockchaininfo (i forgot about this command). It would be nice to have this info displayed through a DIPS tab here : http://178.254.23.111/~pub/Dash/Dash_Info.html (next to our SPORKS tab).
Is it possible for future DIP updates to shorten the lock-in and activation time period a bit ? For example setting it to a 2016 block window ? (3 / 4 days)

 

[tungfa]

Dash '13 locked_in' occurred (dip3)
'13 Activation' will take place Block Height 1,028,160
(next Wednesday morning UTC time/ Late Tuesday night in the US,7 days from now)
You can then start registering your MN on the deterministic Masternode list, we will poste Guides and Updates beforehand

 

[tungfa]

Dash DMT 0.9.22 released , please update , you will need that new version for MN registration
https://github.com/Bertrand256/dash-masternode-tool/releases/tag/v0.9.22

 

[tungfa]

Dash Services - are you updated to ver 13 ?!
DIP3 activation coming in under 500 blocks (~20h) from now. Please update to follow the majority chain and stay operational.
(If you upgrade after DIP3 activation, you have to reindex which will add extra time to your downtime.)

 

[tungfa]

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

https://www.dash.org/forum/threads/...-the-deterministic-masternode-list-now.43668/

 

[qwizzie]

So i have upgraded my masternode to a deterministic masternode and its showing up as one in the Masternodes DIP3 tab.
I created a new address that functions both as owner address and as voting address (same address).

How does the voting actually takes place now ? Because thats just an address i created...
Is my old masternode voting priv key still in play ? How exactly do i vote or what changes with voting when spork 15 activates ?

 

[Tomek]

Does dashqt needs to be upgraded as well? I am stuck at 1028180 block. Several blockexplorer as well. I can not find any node that has more blocks as well.

 

[tungfa]

y

Does dashqt needs to be upgraded as well? I am stuck at 1028180 block. Several blockexplorer as well. I can not find any node that has more blocks as well.

you need to update to 13 ! (you are on an old wallet)
https://www.dash.org/forum/threads/dash-core-v0-13-on-mainnet.43130/

 

[gadado]

Sadly I got no answer on my burning registration question over on bitcointalk. So hopefully more luck here,

Could use some help understanding that.

So from that masternode registration description page:

Quote
-------------------------
collateralHash: The txid of the 1000 Dash collateral funding transaction
collateralIndex: The output index of the 1000 Dash funding transaction
ipAndPort: Masternode IP address and port, in the format x.x.x.x:yyyy
ownerKeyAddr: The new Dash address generated above for the owner/voting address
operatorPubKey: The BLS public key generated above (or provided by your hosting service)
votingKeyAddr: The new Dash address generated above, or the address of a delegate, used for proposal voting
operatorReward: The percentage of the block reward allocated to the operator as payment
payoutAddress: A new or existing Dash address to receive the owner’s masternode rewards
feeSourceAddress: An (optional) address used to fund ProTx fee. payoutAddress will be used if not specified.
------------
(reference let out .. no links allowed as new user)


Using a Masternode Host service I understand that I have to wait first for the BLS operatorPubKey send from the hoster bevor I can start with that registration.
Let's say I have it.

Then there are 3 Wallets in play
Wallet (A) Masternode Host on the Host Service
Wallet (B) The 1000DASH Collateral Wallet
Wallet (C) My General Operation Wallet I want to use for everything (getting the fees, voteing etc)

Best case I will never ever have to open Wallet B after. So for this case I asume I have to do this:


* ownerKeyAddr I create on B
Question 1) could I create one on C instead?

* votingKeyAddr I create on C

* payoutAddress I create on C

* feeSourceAddress an Address with DASH on it from where I send the transaction..so if I do it from B one from B if I do it from C one from C

Question 2) Can I prepare and send the transaction entierly from wallet C or is it recommended to do it from B?

Question 3) After all this can I restart the masternode if required in the future from my C Wallet? I guess not or is this depending on the ownerKeyAddr if this one is form C or B?

Edit: Question 4) instead waiting on the host service for sending the BLS pup key..can I generate the BLS key pair on my C Wallet and give that info to the host service? So I could start without haveing to wait first.

Thanks for the help

The masternode service provided the BLS keys now so question 4 is obsolete. But would be interesting to know.

My most burning question is of course question 1 in connection with if this will allow me to restart a masternode from my C wallet and never have to touch the 1000DASH collateral wallet again. That would be very neat!

 

[gadado]

Decided to create all the addresses on Wallet C.

protx register_prepare seems to do fine.

When I try to submit the on my collateral wallet sign message with protx register_submit it tells me:

bad-protx-key-not-same (code 16) (code -1)

What does this mean? The tx is a copy past and the signed message should be correct too as far as I can tell.


Edit: Ah found the answer somewhere in the forum. votingKeyAddr has to be identical to ownerKeyAddr.

Thanks to Figlmueller.

Well I read the doc before but it says:
generate an address..."It must also be used as the voting address if Spork 15 is not yet active".

So I thought as long as spork15 is not active it will use the one address and later automatical the other that you provided. Seems no. You have to provide the same address. :/

 

[gadado]

And the next wired thing:

When I try to reuse the feeSourceAddress for a second MN it says Missing inputs despite seeing still enough DASH on that address.
(the protx registration transfer seems to have placed the rest back to that adress)
Moved it to another address and a part of it back -> still doesnt work.
Used the other address -> works
Does each need an own SourceAddress? Wired thought thats a one time trash address just to pay the one time fee.

 

[JGCMiner]

And the next wired thing:

When I try to reuse the feeSourceAddress for a second MN it says Missing inputs despite seeing still enough DASH on that address.
(the protx registration transfer seems to have placed the rest back to that adress)
Moved it to another address and a part of it back -> still doesnt work.
Used the other address -> works
Does each need an own SourceAddress? Wired thought thats a one time trash address just to pay the one time fee.

I recommend joining one of the discord’s (invite links at the bottom of the new homepage).

You will likely get help more quickly there.

 

[gadado]

I recommend joining one of the discord’s (invite links at the bottom of the new homepage).

You will likely get help more quickly there.

Yes thanks. I have my troubles with discord. Tried it in the past. It looks like a messi chatt room to me with no structure. Don't understand how someone can find relevant information there and why it is so wide spread this days. But yes if bitcointalk is dead and dash.org is dead and discord is the place to go for help then guess I will have to bite in that sure apple in the future.

I got my MN registered now. Strange that of this 1000 of MNs owners hardly anyone seems to have questions about that registration process.
It doesn't looks to me that everyone understand the new addresses and what is possible to do and what not.

 

[JGCMiner]

Yes thanks. I have my troubles with discord. Tried it in the past. It looks like a messi chatt room to me with no structure. Don't understand how someone can find relevant information there and why it is so wide spread this days. But yes if bitcointalk is dead and dash.org is dead and discord is the place to go for help then guess I will have to bite in that sure apple in the future.

I got my MN registered now. Strange that of this 1000 of MNs owners hardly anyone seems to have questions about that registration process.
It doesn't looks to me that everyone understand the new addresses and what is possible to do and what not.

We got tons of questions on Discord which is why I suggested you head over there. Messy yes, but many find it easier to get (and give) help in real time, per say. Different stokes for different folks though so don’t feel like I am pressuring you or anything.

And I am glad you got your node registered.

 

[Antti Kaikkonen]

And the next wired thing:

When I try to reuse the feeSourceAddress for a second MN it says Missing inputs despite seeing still enough DASH on that address.
(the protx registration transfer seems to have placed the rest back to that adress)
Moved it to another address and a part of it back -> still doesnt work.
Used the other address -> works
Does each need an own SourceAddress? Wired thought thats a one time trash address just to pay the one time fee.

Maybe the fee source input is required to have a certain amount of confirmations? Just guessing.

 

[strophy]

Hi @gadado

I suspect you prepared multiple transactions using the same feeSourceAddress, then tried to sign and broadcast them sequentially. Because the tx field output from register_prepare is the actual transaction exactly as it is broadcast on the network, it will spend a specific UTXO on that address as an input. Since you (probably) prepared all the registration transactions at the same time, they are trying to double spend the same UTXO for the transaction fee, which is not permitted by the network. Only the first transaction will succeed. You will need to run register_prepare again to use a different UTXO on the same address for your subsequent registration transactions.

Hope this makes sense, good luck!

 

[gadado]

Hi @gadado

I suspect you prepared multiple transactions using the same feeSourceAddress, then tried to sign and broadcast them sequentially. Because the tx field output from register_prepare is the actual transaction exactly as it is broadcast on the network, it will spend a specific UTXO on that address as an input. Since you (probably) prepared all the registration transactions at the same time, they are trying to double spend the same UTXO for the transaction fee, which is not permitted by the network. Only the first transaction will succeed. You will need to run register_prepare again to use a different UTXO on the same address for your subsequent registration transactions.

Hope this makes sense, good luck!

You are correct. Exactly what I did or tried to do. Yes makes sense. So I could have finished the first registration in complete and only after that start preparing the next with the same feeSourceAddress.

I solved it by creating multiple feeSourceAddresses. For each one.

Because of that for me strange behaviour I was a bit worried after that the feeSourceAddress might be something bound to the registration you have to keep but I see that is not the case. That's good.

Thanks for your answer.

 

[gadado]

Byway I really like the solution with a Wallet C (created all new addresses on C).

With all the relevant addresses on Wallet C, C is a Command Wallet seeing and controlling all the Masternodes and the Masternodes Collaterals itself can stay in cold storage. That's what I call a neat progress!