Dash Core v0.13 on Mainnet

Liz R

New Member
Mar 2, 2018
30
117
33


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:

tungfa

Grizzled Member
Foundation Member
Masternode Owner/Operator
Apr 9, 2014
8,898
6,747
1,283
MNO's
please be sure to update v13 MN with Version Number: 70213 (change in DMT) otherwise MN will not start !



on Dashninja looking like that:
 
Last edited:

t0dd

Active Member
Mar 21, 2016
150
132
103
keybase.io
Dash Address
XyxQq4qgp9B53QWQgSqSxJb4xddhzk5Zhh
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.
 
  • Like
Reactions: tungfa

Figlmüller

Member
Sep 2, 2014
89
48
58
Vienna, Austria
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.
 

thephez

Active Member
Dash Core Group
Jan 23, 2016
141
102
93
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.
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).
 

Figlmüller

Member
Sep 2, 2014
89
48
58
Vienna, Austria
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).
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.
 

strophy

Administrator
Dash Core Group
Dash Support Group
Feb 13, 2016
794
519
163
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.
 

Figlmüller

Member
Sep 2, 2014
89
48
58
Vienna, Austria
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?
 

qwizzie

Grizzled Member
Aug 6, 2014
2,117
1,294
1,183
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?
* 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:

Figlmüller

Member
Sep 2, 2014
89
48
58
Vienna, Austria
* 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).
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?
 

qwizzie

Grizzled Member
Aug 6, 2014
2,117
1,294
1,183
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?
Good questions, I leave these for a dev team member to answer...
 

nmarley

Administrator
Dash Core Group
Jun 28, 2014
369
427
133
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)?
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.


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?
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
 

UdjinM6

Official Dash Dev
Dash Core Group
May 20, 2014
3,639
3,537
1,183
...
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)?
...
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.
...
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.
 

Figlmüller

Member
Sep 2, 2014
89
48
58
Vienna, Austria
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.
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.
 

qwizzie

Grizzled Member
Aug 6, 2014
2,117
1,294
1,183
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:

UdjinM6

Official Dash Dev
Dash Core Group
May 20, 2014
3,639
3,537
1,183
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 ?
...
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).

...
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 ?
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.
 
  • Like
Reactions: qwizzie

qwizzie

Grizzled Member
Aug 6, 2014
2,117
1,294
1,183
Is there a way to monitor the support for v.0.13 under miners ? Maybe some chart exists these days ?
If there is no way to monitor this, then can we at least get some info from time to time about the percentage of miningpools that upgraded ? (There should be an DCG internal doc about that somewhere)

From Post 1 :
Activation will occur after 80% of blocks have signaled readiness within an approximately ~1-week window.
Am i correct in assuming that the mentioned 80% of blocks could mean a few months and that the mentioned "1 week window" is to occur after those few months ? Or does this whole DIP0003 activation phase only takes a week ? (Which is remarkably short for a miners upgrade)
 
Last edited:

tungfa

Grizzled Member
Foundation Member
Masternode Owner/Operator
Apr 9, 2014
8,898
6,747
1,283
Is there a way to monitor the support for v.0.13 under miners ? Maybe some chart exists these days ?
If there is no way to monitor this, then can we at least get some info from time to time about the percentage of miningpools that upgraded ? (There should be an DCG internal doc about that somewhere)

From Post 1 :


Am i correct in assuming that the mentioned 80% of blocks could mean a few months and that the mentioned "1 week window" is to occur after those few months ? Or does this whole DIP0003 activation phase only takes a week ? (Which is remarkably short for a miners upgrade)
couple of weeks - same as always ; )
13 chart on http://178.254.23.111/~pub/Dash/Dash_Info.html (as always ; )
 

qwizzie

Grizzled Member
Aug 6, 2014
2,117
1,294
1,183
couple of weeks - same as always ; )
13 chart on http://178.254.23.111/~pub/Dash/Dash_Info.html (as always ; )
Strange, i clearly remember previous upgrades that required miners support up to 80% taking a lot more then a few weeks.
Edit : v12.2 took exactly 12 days for miners and masternodes to upgrade to a sufficient level, so i think i remembered older
updates (before v12.2) mostly as taking a very long time.

Anyways, thank you for the chart link.

Edit : Miners support after 5 days still at 0 % according the chart.
Masternode support is building up nicely, currently at 21,2% according https://www.dashninja.pl/masternodes.html
 
Last edited:

diymusic

New Member
May 31, 2017
1
0
1
54
When I am trying to run "protx register_prepare" I got an error message "non-wallet or invalid address". I can confirm this address by using "validateaddress" that it's from my own wallet. Do I after to do this only after DIP003 is activated?
 

UdjinM6

Official Dash Dev
Dash Core Group
May 20, 2014
3,639
3,537
1,183
When I am trying to run "protx register_prepare" I got an error message "non-wallet or invalid address". I can confirm this address by using "validateaddress" that it's from my own wallet. Do I after to do this only after DIP003 is activated?
Yes, you should start it via usual "masternode start-<smth>" command only for now and wait for DIP0003 to register it as a deterministic one. This post above https://www.dash.org/forum/threads/dash-core-v0-13-on-mainnet.43130/#post-205630 outlines the migration process pretty good.
 

qwizzie

Grizzled Member
Aug 6, 2014
2,117
1,294
1,183
Current v0.13 update progress :

45% of the masternodes updated (https://www.dashninja.pl/masternodes.html)
4,2% of the miners now show support for v0.13 (http://178.254.23.111/~pub/Dash/Dash_Info.html (v13 adoption)
Edit : miners support % seems subject to change at the moment, should be more clear in a few days

Miners support has started to increase the last hour and large exchanges have began updating their wallets
(Kraken did that today for its Dash wallet, through a planned maintenance session).

I suspect miningpools and large exchanges were waiting to see if there were any last minute hotfixes before
starting their update procedure. V0.13 has been remarkably stable so far.
 
Last edited:
  • Like
Reactions: GrandMasterDash

camosoul

Grizzled Member
Sep 19, 2014
2,261
1,130
1,183
Current v0.13 update progress :

45% of the masternodes updated (https://www.dashninja.pl/masternodes.html)
4,2% of the miners now show support for v0.13 (http://178.254.23.111/~pub/Dash/Dash_Info.html (v13 adoption)
Edit : miners support % seems subject to change at the moment, should be more clear in a few days

Miners support has started to increase the last hour and large exchanges have began updating their wallets
(Kraken did that today for its Dash wallet, through a planned maintenance session).

I suspect miningpools and large exchanges were waiting to see if there were any last minute hotfixes before
starting their update procedure. V0.13 has been remarkably stable so far.
The testing of 0.13.0.0 release candidates was extraordinary, because the changes were sweeping.

DASH has stepped out of the mold and taken the first step along it's own path. No more training wheels.

The coders have proven themselves, beyond all doubt.

It remains to be seen if the rest of the staff will rise to the occasion or let this, as so many other opportunities, be squandered. But, if so, it'll be different this time. In the past, they've simply let opportunities presented by the market pass them by. This time, they will be letting the project's own creation falter if they continue to be bureaucratic dead weight...

Evolution is nice, but they damn well better FINALLY DO SOMETHING WITH IT or all this hard work and consternation is pointless.

By all means. Prove me wrong. I look forward to it. Nothing would please me more than to eat my own pessimistic words over the last few years.