Version 12.1 Release

Status
Not open for further replies.
eduffield

eduffield

Core Developer
Mar 9, 2014
1,084
5,323
183


Hello Everyone,

It is with great excitement that the development team has just released our much anticipated version 12.1 of the Dash Core client. This release is our most extensive release to date, after which the development team will be able to focus fully on Evolution. Once again, Dash is delivering first-in-cryptocurrency functionality that further differentiates us in the market, and enables an entirely new model for supporting the Dash ecosystem in exciting new ways.

Our original plan was to include a more limited set of functionality within our 12.1 release. However, as we discovered ways to accelerate development by including more functionality within one release, we significantly expanded the original scope. As a result, many new capabilities are now included within 12.1, that puts us well ahead of our original roadmap.

12.1 is by far the most extensively and methodically tested release we’ve ever completed. A large team of volunteers and core development team members have been testing, bug fixing, and implementing performance improvements for months, in the largest testnet environment we’ve ever assembled. In fact, even in our testnet environment, we successfully tested loads many times larger than Bitcoin’s maximum capacity. We are also managing all of the activities surrounding the release – including the release of a new website – in a coordinated fashion. In short, we anticipate the smoothest release to date.

Here is an abbreviated list of the enhanced functionality included in the version 12.1 release:
  • Based on bitcoin 0.12.1 with RBF off
  • PrivateSend multi-session mixing to speed mixing times
  • InstantSend multi-quorum
  • Entirely new object-oriented governance system Sentinel
  • Cleaner user interface with new theme
  • New tab for masternode information and management
  • Improved automatic backups on wallet launch
  • Automatic backups when keypool nears exhaustion
  • Approximately 10x faster wallet load speed
  • Numerous new or improved RPCs
  • Enhanced proof-of-service (PoSe) implementation
  • Additional (optional) indexes from Bitpays fork
  • Bug fixes and security improvements
Other changes:
  • Lowered InstantSend & PrivateSend fees due to exchange rate increases
  • Changed PrivateSend denominations – 100s removed and 0.01s added
  • IPv4 is now manditory for masternodes
  • Default data directory changed to DashCore (Windows / Mac) & .dashcore (Linux)
Who is required to update?

It is imperative that ALL users of the dash client update to the most recent version of the client as soon as possible. End users, miners, pool operators, exchanges, and masternode owners have until Sunday, February 12th to update. After that date, we will switch completely to the new version as soon as our engineers determine it is safe to do so, and older versions of the software will drop off the network.

How to update?

Regular users simply need to download and install an updated version of their wallet software. Note that a reindex is required the first time you launch the new software. Instructions can be found here: https://dashpay.atlassian.net/wiki/display/DOC/Updating+to+12.1+-+Users

With the addition of Sentinel, there are additional software components required for the operation of masternodes. These include database software and the Sentinel software, which are separate from the Dash daemon. As a consequence of these changes, we recommend that masternodes have a minimum of 1GHz CPU, 1 GB RAM, 20 GB storage, and 400 GB / month of bandwidth. Beyond these minimums, we recommend even higher specifications for the most reliability. Masternode upgrade instructions and hardware recommendations can be found here: https://dashpay.atlassian.net/wiki/display/DOC/Updating+to+12.1+-+Masternodes

What are the main benefits to the new version?

For our end-users, there are a number of new benefits, including a more stable network, faster PrivateSend mixing, and easier access to network information.

There are also many enhancements to the new governance system. Although we are initially deploying a replica of 12.0’s governance system on the new platform, our new system is capable of change and feature enhancements to enable us to scale our governance and funding model over time, without requiring any disruptive software upgrades. We will initially run the 12.0 replica for a couple of months before using this capability to introduce new governance features.

Lastly, there are many new technologies essential for Evolution. Most of these are under-the-hood, but extremely valuable new components for our future releases.

What’s next?

The Dash development team will initially focus on ensuring a smooth rollout of v12.1 to the network. With the testing already performed we believe the transition will be swift and smooth. Should any issues arise, the entire team stands ready to mitigate any issues on mainnet.

Please note that all existing multi-month budgets will not migrate to the new version. For proposal owners with payments remaining, you will need to submit a replacement proposal on the new budget system. We plan to run the new budgeting system with the same functionality as 12.0 for a couple of months before proposing any changes to the network.

In parallel, we are ramping up our development resources to implement Evolution. The specifications for the entire system are now complete and agreed across the DashCore and Evolution teams. This marks a major milestone in the project as we move from proof of concept, design, and testing into a full-fledged implementation. Several new full-time frontend and backend developers were recently hired. By the beginning of April, we will be up to at least seven full-time developers just within the DashCore and Evo teams, plus at least a dozen part-time contributors. So things should move very quickly with a thoughtfully designed foundation to build upon.

With the Evolution design complete, we know that it will be a significant undertaking. In fact, Evolution represents such an extensive redesign and overhaul of the Bitcoin code, that it likely requires more development than the original Bitcoin code itself. Once complete, there will be no denying that Dash offers the most advanced, feature rich, and consumer-oriented solution on the market.

While Evolution is under construction, we will continue to focus significant energy on our business development efforts. Expect much more activity as we work to implement new services onto our network.

Downloads:

https://www.dash.org/get-dash/

Official Documentation:

https://dashpay.atlassian.net/wiki/display/DOC/Dash+v12.1+-+2017-02-05

A heartfelt thanks to everyone who contributed over the past 18 months toward this release as well as the new website. There are simply too many contributors to mention here.
 
  • Like
Reactions: John.Huisamen, Chadrick, martelo and 22 others
camosoul

camosoul

Grizzled Member
Sep 19, 2014
2,261
1,130
1,183
Setting up the new MN stuffs was way easier than I expected... Now, if only there were a way to broadcast a start from the Trezor... :p
 
A

akhavr

Active Member
Oct 11, 2014
837
414
133
MN doesn't work for me:

Code: 
$ venv/bin/python bin/sentinel.py
Invalid Masternode Status, cannot continue.

$ ~/dashcore-0.12.1/bin/dash-cli masternode debug
Not capable masternode: Invalid protocol version
Everything synced, no suspicious lines in debug.log

Code: 
$ ~/dashcore-0.12.1/bin/dash-cli mnsync status
{
  "AssetID": 999,
  "AssetName": "MASTERNODE_SYNC_FINISHED",
  "Attempt": 0,
  "IsBlockchainSynced": true,
  "IsMasternodeListSynced": true,
  "IsWinnersListSynced": true,
  "IsSynced": true,
  "IsFailed": false
}
What I'm doing wrong?

Upd. Looks like I've got invalid `masternode.conf`. Restarted and syncing

Upd2. Fixed, my fault
 
Last edited:
stan.distortion

stan.distortion

Well-known Member
Oct 30, 2014
959
585
163
akhavr said:
MN doesn't work for me:

Code: 
$ venv/bin/python bin/sentinel.py
Invalid Masternode Status, cannot continue.

$ ~/dashcore-0.12.1/bin/dash-cli masternode debug
Not capable masternode: Invalid protocol version
Everything synced, no suspicious lines in debug.log

Code: 
$ ~/dashcore-0.12.1/bin/dash-cli mnsync status
{
  "AssetID": 999,
  "AssetName": "MASTERNODE_SYNC_FINISHED",
  "Attempt": 0,
  "IsBlockchainSynced": true,
  "IsMasternodeListSynced": true,
  "IsWinnersListSynced": true,
  "IsSynced": true,
  "IsFailed": false
}
What I'm doing wrong?
Click to expand...
Start with "masternode start-alias" and whatever alias you configures in masternode.conf, ie. "dash-cli masternode start-alias mn0". Your old starts are still being seen by the network and so causing the invalid protocol message. You should only need to use "start-alias" for a protocol update btw, use "start-missing" for normal restarts.
 
  • Like
Reactions: akhavr
A

akhavr

Active Member
Oct 11, 2014
837
414
133
A

akhavr

Active Member
Oct 11, 2014
837
414
133
stan.distortion said:
It is, about 8 lines up from the bottom ;)
Click to expand...
Well, yeah... But first goes start-missing, which is confusing (why look further when answer is already here? ;) )

stan.distortion said:
The script mentioned at the very bottom is well worth a look btw, it makes setting up and managing a masternode much easier. It's not been updated for 12.1 yet but should be ready in a day or two.
Click to expand...
Yup, but I don't want my masternodes to stale for a day or two ;)
 
  • Like
Reactions: stan.distortion
TroyDASH

TroyDASH

Well-known Member
Jul 31, 2015
1,254
797
183
Great work guys, and special thanks to everyone who has been helping out in Slack, and for those step-by-step upgrade guides.

eduffield said:
There are also many enhancements to the new governance system. Although we are initially deploying a replica of 12.0’s governance system on the new platform, our new system is capable of change and feature enhancements to enable us to scale our governance and funding model over time, without requiring any disruptive software upgrades. We will initially run the 12.0 replica for a couple of months before using this capability to introduce new governance features.
Click to expand...
Please note that all existing multi-month budgets will not migrate to the new version. For proposal owners with payments remaining, you will need to submit a replacement proposal on the new budget system. We plan to run the new budgeting system with the same functionality as 12.0 for a couple of months before proposing any changes to the network.
Click to expand...
@eduffield Could you elaborate on the procedure for implementing governance "enhancements" that 12.1 is capable of adding? If it does not involve a disruptive software upgrade then what exactly *does* it involve? Assuming the upgrade completes smoothly, does the team have any ideas or plans that can be shared for what sorts of governance enhancements you might want to implement in the near future?

Thanks...
 
  • Like
Reactions: GNULinuxGuy, stan.distortion and tungfa
Walter

Walter

Active Member
Masternode Owner/Operator
Jul 17, 2014
234
221
103
IPv4 is a retrograde step IMHO but having read the arguments for/against I understand the reasoning behind the decision and I accept that it's just an extension of the VHS vs BETAMAX argument... VHS was inferior but it held the majority of market share, and that was all that mattered. That's the way it goes...

Walter
 
  • Like
Reactions: JGCMiner and stan.distortion
camosoul

camosoul

Grizzled Member
Sep 19, 2014
2,261
1,130
1,183
jimbit said:
IPv4 is now manditory for masternodes ???
Click to expand...
They were ambiguous about this right up to the last second...
jimbit said:
this hurts :(
Click to expand...
Yup. And it makes DASH look stupid. It's the sort of thing we'd expect from Apple, Bitcoin, or the US Government.

They keep claiming some "network fragmentation" nonsense, but it's just not reality... I ran dual stack and pure IPv6 nodes previously, and the dual stackers acted as bridges when bound to IPv6. thouogh not intended by design, this treatment worked perfectly as it was, and was flatly denied knowing that few people would actually examine it and find that the claim is bullshit.

There is a lot of "retrograde" happening as the false problems behind "adoption" are being hammered instead of examining the real problems.

It's a lot like having a car that won't run, so you check that the gas tank has gas in it... It's a bit low, so you fill it up. The car still won't run. So you just squirt gas in the windows and all over it, seal up the trunk so you can make a big pool of gas back there... They have no grasp of the greater marketplace, so they just keep on doing the one thing they do know....

Clearly the problem is elsewhere, but since they know nothing about engines, they just keep squirting gas on everything hoping that'll fix it. It's reached an extreme that they're starting to put inherent advantages on the chopping block in order to create more places to put more useless gas...

This is amplifying the Vendor Hostility problem. But, since they have no clue of the marketplace at large, they simply imagine that the Vendor Hostility problem doesn't exist. The extremism of it is stating to show in many details of the project, the IPv4 horseshit is only a minor point of exposure.

Continuing to expand Snowflake-desirable feature set was merely a waste of time before. Now, they're actually planning to remove Vendor-desirable features in order to create even more Snowflake-desirable features. What will this do for Adoption? Nothing. There will just be a bunch more whiny, clueless Snowflakes standing around with nowhere to use their DASH, repeatedly asking "Golly, I wonder why Vendors won't accept Crypto payments..." I'm telling you why. Pay attention!

They are either unwilling, or unable, to notice the problem, and it is growing unchecked...

If one were to put on the tinfoil hat, one might conclude that they're trying to force ATMs into relevancy...

I've done all the research needed to create a 3rd Party retail payment service backed by DASH. But, the direction DASH keeps moving would destroy such a service. Any sane business person would realize that it's a guaranteed bad move to invest in a venture for which the foundational entity is trying to destroy such venture. There's no future in it, so why would someone do it?

There's a chance that a more diverse model could exist, subsidizing the DASH/Retail element from it's primary business. But, again; why? Where's the incentive to create a parasitic sideshow?

I could be doing this by tomorrow. But, why do I want to waste money on a dead end project that DASH is openly and willfully trying to destroy before it is even created? BitPay or Coinbase could do it, but, again; why? Sure, you could sell it to them on being the first service of Crypt in Retail that actually works... But when they realize, as they mus, that DASH wants to undermine the inherent qualities of crypto that make it desirable for such use in the first place... That'd be a stupid move for them to make, which is why they haven't made it.

IX is still initiated backwards.

Payments planned to be reversible in the future, by an arbitrary 3rd party which has already demonstrated Vendor Hostility.

This model already exists. It's called Visa.
tungfa said:
that is correct
Click to expand...
Interpretation: We don't care @jimbit
tungfa said:
sorry laaa
Click to expand...
Interpretation: Fuck you, @jimbit
 
Last edited:
Figlmüller

Figlmüller

Member
Sep 2, 2014
89
48
58
Vienna, Austria
Got huge problems compiling on a Debian Stable build server. Can't do a git-pull. Thousands of merge conflicts. Total disaster.
Cloned again from github, but I cannot compile due to missing libraries. Would be nice if you would list changed requirements for compilation somewhere.

Code: 
"g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.
Makefile:5418: recipe for target 'libbitcoin_server_a-init.o' failed
make[2]: *** [libbitcoin_server_a-init.o] Error 4"
 
thelazier

thelazier

Active Member
Jan 5, 2015
240
184
103
Thailand
Dash Address
Xreiza1qGJMT5BpW6BDtRJqwtcBSxGwWYN
Figlmüller said:
Got huge problems compiling on a Debian Stable build server. Can't do a git-pull. Thousands of merge conflicts. Total disaster.
Cloned again from github, but I cannot compile due to missing libraries. Would be nice if you would list changed requirements for compilation somewhere.

Code: 
"g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.
Makefile:5418: recipe for target 'libbitcoin_server_a-init.o' failed
make[2]: *** [libbitcoin_server_a-init.o] Error 4"
Click to expand...
Possibly be killed because out of memory. please also check notes for buiding in doc/build-unix.md.
 
Figlmüller

Figlmüller

Member
Sep 2, 2014
89
48
58
Vienna, Austria
thelazier said:
Possibly be killed because out of memory. please also check notes for buiding in doc/build-unix.md.
Click to expand...
Thanks for the reply. Yes, according to the docs: "It is recommended to have at least 1 GB of memory available when compiling Dash Core". Never had problems compiling on machines with 2GB. Since 12.1 G++ eats memory like corn flakes.

I have increased the VM memory to 3072GB, but it's still eating up all the RAM and Swap. nvm, I'll just assign 16GB. Should be enough.
 
S

Sebastian

New Member
Feb 9, 2017
1
0
1
32
What happens to the Hardware wallets like Trezor and Ledger when Feb 12th hits with all 12.1...?
 
flare

flare

Grizzled Member
May 18, 2014
2,286
2,404
1,183
Germany
Sebastian said:
What happens to the Hardware wallets like Trezor and Ledger when Feb 12th hits with all 12.1...?
Click to expand...
Technically it is possible now to start masternodes from a HW wallet - but it is not very user friendly yet.

If you are into Python/hacking you can use https://github.com/chaeplin/dashmnb by @chaeplin - @dark-sailor was succesful with it. Otherwise you'll need to wait some weeks for more mature solutions to hit the market.
 
Status
Not open for further replies.
Top Bottom