{"id":52779,"date":"2020-06-12T01:03:36","date_gmt":"2020-06-12T01:03:36","guid":{"rendered":"https:\/\/www2019.dash.org\/?p=52779"},"modified":"2021-09-18T11:41:58","modified_gmt":"2021-09-18T11:41:58","slug":"product-brief-dash-core","status":"publish","type":"post","link":"https:\/\/wp.dash.org\/news\/product-brief-dash-core\/","title":{"rendered":"Product Brief: Dash Core Release v0.16.0 (now on testnet)"},"content":{"rendered":"
DashCore v0.16 is a major release and will be a mandatory upgrade for all masternodes. Version 0.16 introduces a number of improvements to Dash, including performance optimizations, wallet user interface enhancements, greater stability, and numerous enhancements through Bitcoin backports. Below are a few key highlights of this release. Comprehensive details can be found in the release notes.<\/p>\n
Quorum load has been significantly reduced when recovering signatures. The new system initially sends signature shares to a single deterministically selected node, instead of propagating signature shares to every node until one has enough to recover the signature. After one second, if the recovered signature has not appeared, the signature share is sent to another deterministically selected node and this process repeats until a recovered signature is present. This way only the recovered signature needs to be propagated and verified by all members. This optimization is expected to reduce the load by several orders of magnitude.\u00a0Read more<\/a><\/p>\n Network threading has been optimized by eliminating unnecessary repetition of loops through all nodes by implementing event polling (epoll) on Linux. This efficient event notification system will reduce the overhead of the socket handler thread to nearly nothing. This optimization only impacts linux implementations and is specifically impactful for masternodes which handle a large number of connections.\u00a0Read more<\/a><\/p>\n Proof of Service (PoSe) for Masternodes is enhanced by ensuring a minimum protocol version is running. During the distributed key generation (DKG) process, a masternode will verify that the Dash port of other masternodes is open and accepting connections. In addition, the protocol version will be checked to ensure it is above the minimum required version. If either of these conditions are not met, the offending masternode will be flagged as a bad quorum member. This feature will be activated by spork 21 once 60% of the masternodes have upgraded to version 0.16.\u00a0Read more<\/a><\/p>\n This release also introduces over 650 updates from Bitcoin v0.16 as well as some updates from Bitcoin v0.17. This includes a number of performance improvements, dynamic loading of wallets via rpc, support for signalling pruned nodes, and a number of other updates that Dash users will benefit from. Bitcoin changes that do not align with Dash\u2019s product needs, such as SegWit and RBF, are excluded from our backporting. For additional detail on what\u2019s included in Bitcoin v0.16, please refer to their\u00a0release notes<\/a>.<\/p>\n PrivateSend code has been refactored, removing outdated logic, and changing mixing logic to be simpler and on average provide better privacy. PrivateSend mixing rounds used to have a random number of participants between three and five. In v0.16, this logic has changed. It is no longer random, but instead, a masternode will accept up to five participants and will fall back to using three or four participants if there isn\u2019t enough liquidity at that moment.<\/p>\nNetwork Threading Improvement<\/h2>\n
Minimum Protocol Check<\/h2>\n
Bitcoin Backports<\/h2>\n
Code Cleanup<\/h1>\n
PrivateSend Code Refactoring<\/h2>\n
PrivateSend Create Denominations Improvement<\/strong><\/h2>\n