• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Dash Core v0.13 on Mainnet

Liz R

Liz R

Active member
wPueZvA.png


Dash Core Group is pleased to share that Dash Core v0.13.0 binaries are released and ready for deployment on mainnet by node operators.

This software release focuses on improving consensus methods on the Dash network, and includes the following highlights:
  • Automatic InstantSend, which will improve the speed of most transactions at no additional cost;
  • The deterministic masternode list, which will provide a single source of truth for clients validating transactions;
  • 3 masternode keys: owner, operator and voting;
  • Special transactions to accommodate non-financial transactions on the blockchain; and
  • Several improvements to private transactions, including speeding up the mixing process, as well as introducing an additional denomination of .001 Dash.
Read more about these features in the Dash Core v0.13.0 Product Brief and download the binaries from the Dash website.

❗Important Message for Partners and Network Operators

We ask partners, network operators, and other stakeholders to please begin upgrading as soon as possible. We also ask that network participants who have not already done so, to please fill out this 3 question survey to further inform our rollout plan.

Detailed release notes can be found here. We’ve also assembled an integration guide with details on Dash Core v0.13.0 Transaction Types, intended to act as a reference point for implementation. As a reminder, these new transactions are not “backwards compatible” with existing cryptocurrency development libraries. Our initial research indicates that in most cases at least a minor patch will be required to allow for continued processing of block / transaction data after the activation of DIP 002: Special Transactions. Activation will occur after 80% of blocks have signaled readiness within an approximately ~1-week window. In order to enable a seamless transition, Dash Core Group is focused on ensuring that as many of these development libraries are updated as possible. Informational sessions are available to partners interested in learning more about integration with Dash Core v0.13.0. Please contact the support desk if you need assistance with the upgrade.

Masternodes must update before the activation of spork 15 in order to continue receiving block rewards. The exact date of spork 15 activation will be announced at a later time, once enough masternodes have registered as deterministic masternodes (DIP3). Please check out our update guide for masternodes. Please note that masternode operators must also update Sentinel.

Congratulations to the core development team on this tremendous step forward for the Dash network. 2019 is already shaping up to be a big year for Dash.
 
Last edited:
MNO's
please be sure to update v13 MN with Version Number: 70213 (change in DMT) otherwise MN will not start !

A6Vd90F.png


on Dashninja looking like that:
PuwHR6L.png
 
Last edited:
For folks that platform on Red Hat/Fedora based distributions...

0.13.0 has been long in testing and was rolled into the stable repositories quite promptly after the release (though delayed for a few hours due to a packaging hiccup). Unfortunately my documentation lagged by a day. But they have finally caught up as of a few hours ago. They are a summary (sometimes a pedantic summary) and are not intended to fully replace the excellent and more complete official documentation, but walking through the more tailered documents I provide may help avoid some confusion since some configuration and tooling is different.

I need folks to poke me hard if they find issues in the docs. Take your time. Update when you are ready, but please inform me if you find an error or omission in the process documents for my Fedora builds.

https://github.com/taw00/dashcore-rpm/blob/master/documentation/README.md

Thanks!
-t0dd

P.S. CentOS7/RHEL7 are no longer supportable build targets for v0.13.0. Plan accordingly.
 
Hi, I'm unable to compile Dash 0.13.0 due to the following error:

Code: 
  CXX      bls/libdashconsensus_la-bls.lo
In file included from bls/bls.cpp:5:0:
bls/bls.h:14:27: fatal error: chiabls/bls.hpp: No such file or directory
 #include <chiabls/bls.hpp>
                           ^
compilation terminated.
 
Figlmüller said:
Hi, I'm unable to compile Dash 0.13.0 due to the following error:

Code: 
  CXX      bls/libdashconsensus_la-bls.lo
In file included from bls/bls.cpp:5:0:
bls/bls.h:14:27: fatal error: chiabls/bls.hpp: No such file or directory
 #include <chiabls/bls.hpp>
                           ^
compilation terminated.
Click to expand...

Are you building using the "depends" folder as described here? This is the only supported way of building now and it ensures that the proper dependencies are used (rather than relying on what may be installed on your machine).
 
thephez said:
Are you building using the "depends" folder as described here? This is the only supported way of building now and it ensures that the proper dependencies are used (rather than relying on what may be installed on your machine).
Click to expand...

Hi,
I figured that out too. The deps took ages to compile. Is there a way to exclude qt?
And: I used BerkleyDB > 4.8 before - this will be in conflict now, as the "depends" contain BerkleyDB 4.8, right?
Also, even though proper dependencies are being used to build dash-core - they are still being linked only, right? Do I need to install the proper versions on my linux boxes? That's what I would not like to do, as the Debian repo is usually a little behind regarding libs and their newest (or older) versions.
 
Hi @Figlmüller I'll attempt an answer...

You can skip building Qt by specifying "make NO_QT=1" in the depends folder. I also managed to speed it up a lot by adding more jobs with e.g. "make -j4" to match how many processor cores are available.

If you built with a different version of BerkeleyDB in the past you will have wallet incompatibilities.

I'm not 100% sure about how the linking works. I've been trying to build portable binaries on macOS recently with a user on Discord without much success. Maybe devs can answer that one.
 
Hmm, ok. The build works fine here with the new depends arch. Looks like the libraries have been linked statically - thus increasing the binary size. LDD shows no deps on local libs except the essential ones (libc, ...)

Anyways, what is the supposed way to start a masternode now? The protocol version changed with 0.13.0 and I am yet not able to register the masternodes as deterministic ones using
protx register_submit because Spork15 is not active. Should I start nodes the old way using the masternode start command?
 
Figlmüller said:
Hmm, ok. The build works fine here with the new depends arch. Looks like the libraries have been linked statically - thus increasing the binary size. LDD shows no deps on local libs except the essential ones (libc, ...)

Anyways, what is the supposed way to start a masternode now? The protocol version changed with 0.13.0 and I am yet not able to register the masternodes as deterministic ones using
protx register_submit because Spork15 is not active. Should I start nodes the old way using the masternode start command?
Click to expand...

* do a masternode start the old way (step 1 in upgrade guide). Make sure you end up with protocol 70213 and that you update sentinel as well. I use dashninja.pl to verify my protocol and to monitor the overall progress of this update on our network. Dashninja.pl shows only the masternode progress by the way, not the miners progress.
* wait for activation of DIP003 (could take awhile as step 1 is proceeding slowly on the network and also needs support from miners)
You can check if DIP003 is activated by using command getblockchaininfo
* after activation of DIP003 you can start registering your Masternode as a DIP003 Masternode (step 2 in upgrade guide)
* wait for activation of spork 15

Both the activation of DIP003 and of Spork 15 should be announced from DCG on various communication channels to the Dash community, so Masternode owners know when to proceed next (step 2) and know when everything is finished and activated (spork 15).
 
Last edited:
qwizzie said:
* do a masternode start the old way (step 1 in upgrade guide). Make sure you end up with protocol 70213 and that you update sentinel as well. I use dashninja.pl to verify my protocol and overall progress of this update on our network. It shows only the masternode progress, not the miners progress.
* wait for activation of DIP003 (could take awhile as step 1 is proceeding slowly on the network and also needs support from miners)
You can check if DIP003 is activated by using command getblockchaininfo
* after activation of DIP003 you can start registering your Masternode as a DIP003 Masternode (step 2 in upgrade guide)
* wait for activation of spork 15

Both the activation of DIP003 and of Spork 15 should be announced from DCG on various communication channels, so Masternode owners know when to proceed next (step 2) / know when everything is finished and activated (spork 15).
Click to expand...

Thanks for your explanation and clarifying the order of the steps!

I have a few more questions:

If one has not sent the registration yet, how come the fields "owneraddress" and "votingaddress" are already filled out? (according to the masternode list)
Where do the addresses come from (after starting the masternode the old way)?

Also: As far as I understand, the "old" way of starting a masternode will be obsolete after Spork15 - together with the masternode private key.
So once Spork15 is active, masternode owners will be able to adjust their config templates and remove those obsolete entries, right?
 
Figlmüller said:
Thanks for your explanation and clarifying the order of the steps!

I have a few more questions:

If one has not sent the registration yet, how come the fields "owneraddress" and "votingaddress" are already filled out? (according to the masternode list)
Where do the addresses come from (after starting the masternode the old way)?

Also: As far as I understand, the "old" way of starting a masternode will be obsolete after Spork15 - together with the masternode private key.
So once Spork15 is active, masternode owners will be able to adjust their config templates and remove those obsolete entries, right?
Click to expand...

Good questions, I leave these for a dev team member to answer...
 
Figlmüller said:
If one has not sent the registration yet, how come the fields "owneraddress" and "votingaddress" are already filled out? (according to the masternode list)
Where do the addresses come from (after starting the masternode the old way)?
Click to expand...

These entries are populated with the address from the "masternode private key" entry in the dash.conf file on the masternode, which you refer to in your next question. It's just displaying the address instead of the private key (for what I hope are obvious reasons). I'm assuming this is filled in order to maintain JSON output compatibility once Spork 15 is activated. You can think of the current "MN privkey" as both voting and operator key. I'm not sure why "owner key" is set to this, since to me it seems it's more of what "operator key" really is.


Figlmüller said:
Also: As far as I understand, the "old" way of starting a masternode will be obsolete after Spork15 - together with the masternode private key.
So once Spork15 is active, masternode owners will be able to adjust their config templates and remove those obsolete entries, right?
Click to expand...

Sort of. You'll need to instead add a BLS private key, which replaces this current one. Instructions here:

https://docs.dash.org/en/latest/masternodes/dip3-upgrade.html#enter-the-bls-key-on-the-masternode
 
Figlmüller said:
...
If one has not sent the registration yet, how come the fields "owneraddress" and "votingaddress" are already filled out? (according to the masternode list)
Where do the addresses come from (after starting the masternode the old way)?
...
Click to expand...
nmarley said:
These entries are populated with the address from the "masternode private key" entry in the dash.conf file on the masternode, which you refer to in your next question. It's just displaying the address instead of the private key (for what I hope are obvious reasons). I'm assuming this is filled in order to maintain JSON output compatibility once Spork 15 is activated. You can think of the current "MN privkey" as both voting and operator key. I'm not sure why "owner key" is set to this, since to me it seems it's more of what "operator key" really is.
...
Click to expand...
Let me correct this ^^^ a bit. These entries are derived from pubKeyMasternode which is a part of masternode announcement message (mnb). But yes, they are not used until spork15, so you can ignore them for now.
 
nmarley said:
I'm assuming this is filled in order to maintain JSON output compatibility once Spork 15 is activated. You can think of the current "MN privkey" as both voting and operator key. I'm not sure why "owner key" is set to this, since to me it seems it's more of what "operator key" really is.
Click to expand...

Okay, thanks. Maintaining JSON scheme validity seems reasonable :)

Btw, do you know what measures are in place to verify the resources loaded and compiled by the new `depends` system?
Previously we just used the dependencies installed on the build server which we could have audited (by package+sig) in regards of security and compliance (license). We are thinking of the troubles introduced by infected dependencies. Some projects using various package managers (npm) already suffered from this.

The new system now loads its dependencies from various sources which makes it difficult for us to do full offline builds within an isolated environment.
 
If a masternode owner choose to use a different walletaddress for receiving his mn payments,
how does that exactly work with regards the necessary "mining" confirmations ? (104 conf before spendable)
specifically when that different address for receiving mn payments turns out to be a hardware wallet address
or an exchange wallet address ?

Once spork 15 activates and automatic instantsend on simple transactions activates on our network,
what level of transaction fees is recommended for hardware wallets (low-medium-high are the options i think)
as the speed of confirmation benefit associated with the high level becomes largely obsolete then for small transactions as they get instantsend anyways.. should we keep it on low level ?
 
Last edited:
qwizzie said:
If a masternode owner choose to use a different walletaddress for receiving his mn payments,
how does that exactly work with regards the necessary "mining" confirmations ? (104 conf before spendable)
specifically when that different address for receiving mn payments turns out to be a hardware wallet address
or an exchange wallet address ?
...
Click to expand...
There is no special rules for this case, will require 101 confirmations like any other coinbase outputs. That's a network-wide rule and I believe all exchanges and wallets handle this properly (they don't even have to care if this is a MN payment or a miner reward, what matters is that it's fresh new coins from coinbase).

qwizzie said:
...
Once spork 15 activates and automatic instantsend on simple transactions activates on our network,
what level of transaction fees is recommended for hardware wallets (low-medium-high are the options i think)
as the speed of confirmation benefit associated with the high level becomes largely obsolete then for small transactions as they get instantsend anyways.. should we keep it on low level ?
Click to expand...
Minimal fee (1000 duff/kb or 1 duff/b) should work just fine already. Each wallet uses its own fee estimation algo/rates they are comfortable with (to balance cheap txes vs "why my tx is not confirming" support requests) and most of it is inherited from bitcoin and its issues with full blocks, so fees are a higher than they could be "just in case" I guess.
 
You must log in or register to reply here.
Back
Top