It is with great pleasure that the development team brings you the much anticipated version 12 release of the Dash Core client. This release implements numerous features the Dash community has requested, such as the decentralized budget system and the removal of the reference node. In fact, by virtually any measure this is our most extensive release to date. It also establishes ground-breaking functionality that further differentiates our cryptocurrency and enables an entirely new model for supporting the Dash ecosystem in exciting new ways.
Not only is this the broadest set of changes we’ve ever deployed in one release. It is also the most extensively and methodically tested release we’ve ever done. An extended team of volunteers have been helping the core development team to manage and test this release since long before I even announced public testing on June 12th. While we don’t expect the code to be bug-free (no software ever is) this should be one of the most stable releases we’ve deployed.
- Here is an abbreviated list of the enhanced functionality included in the version 12 release:
- Incorporated Bitcoin Core version 0.10 https://bitcoin.org/en/release/v0.10.0
- Implemented the first decentralized budget system and ability to fund Dash projects directly from the block rewards (details can be found in the “What is the Decentralized Budget System?” section below)
- Implemented a new decentralized masternode payment consensus system, which will enable the removal of the reference node that was needed to facilitate fair distribution of masternode rewards
- Improved the speed and reliability of Darksend anonymization
- New masternode payment/winners/budgets syncing strategy
- Platform independent masternode ranking system
- Masternode broadcasts, pings and winners now use the inventory system
- Transaction indexing is enabled by default for all clients
- Improved implementation of Instant Transactions (IX) block reprocessing to find and remove invalid blocks
- Increased IX success rate to nearly 100% and transaction locks are more secure than before
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. Users have until September 5th to update. After that date, anyone running an old client will no longer be on the valid chain.
How to update?
QT: When updating the client, you will need to reindex the blockchain. To do this, start the wallet with option ‘-reindex’ in the command line or create a shortcut to the wallet and append “-reindex” to the shortcut target by right-clicking in the shortcut and selecting ‘Properties’.
Daemon: To update the daemon, you will need to restart with the –reindex flag.
In the v12 update, we’ve automatically enabled the transaction index by default. This will allow your client to pull up any transaction from the blockchain. This is mainly used in DarkSend and the decentralized budget system.
What is the Decentralized Budget System?
In decentralized projects like Dash, funding has proven a significant issue. Even the mighty Bitcoin frequently struggles to attract and fund sufficient resources through donations alone. We plan on fixing that in a 100% decentralized and sustainable way. With Bitcoin, 100% of the block reward is allocated to miners. While mining is an important component that secures transactions, it is not the only requirement for a healthy network as Bitcoin’s recent struggles with funding have demonstrated.
We believe that the block rewards belong to the network first, and should be used to fulfill more than just one of the many needs of a healthy network. Developers, miners, masternode operators, legal council, marketing, and merchant services are only some of the potential needs of a healthy network and all deserving of funding when worthwhile projects are identified. With Dash, anyone can now introduce funding proposals directly to the network itself, on which the masternode community (who are essentially the network owners / operators) will vote. Approved budgets are then paid similar to how miners are paid… directly from the blockchain rewards. In accordance with our original proposal that the community approved in May, we will gradually transition the block reward allocations through February to eventually provide for a budget of about 8000 DASH per month to fund proposals.
The Dash development team will initially focus on ensuring a smooth rollout of v12 to the network. We hope with all the testing already performed that the number and severity of bugs will be minimal, but we plan to do extensive testing during and after deployment to remedy any issues that arise.
Next, we plan to test the budgeting system. At the very beginning we will have only the core team submit a few proposals so we can make sure everything works perfectly. We are counting on masternode owners supporting this staged deployment procedure… your votes are needed to make this work.
Further down the road, the core team has numerous ideas we are evaluating for the next major release. The budget system enables entire categories of functionality that weren’t possible without it and we plan to take some time to develop a longer-term strategy for the next several releases, in line with Dash’s vision and mission.
I look forward to hearing everyone’s feedback on the new functionality. It has been a challenging yet rewarding few months, and I’ve enjoyed working with everyone that has helped manage the project, supported testing, and contributed ideas. The Dash community is as organized and professional as ever thanks to everyone’s contributions. The next six months will bring new challenges, but I’m excited to see that we are better equipped than ever to tackle them and have both a governance and funding system in place to support entirely new possibilities. I hope you are as excited as I am to see what’s coming next. Enjoy version 12!
Full Description Of Budget System:
Can I make a proposal and submit it to the system?
Once the initial proposals have been tested and funded, the budgeting system will be enabled for the entire community. The amount of funds available initially will be relatively low, and we suspect there are a backlog of ideas that community members are hoping to submit. For this reason, getting your proposal funded immediately may be challenging. However, as the allocation away from miners and toward proposals progresses, more and more projects will succeed in obtaining funding.
How to use the budget system:
Thanks to who contributed to this release, at least:
As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/dash/)
We are excited to announce the release of Dash Core v0.11.1! We have decided to push out InstantX in a separate release because it’s working perfectly on testnet and our other changes to the masternode network will take some time to complete.
This release includes a full implementation of InstantX, a new version of enforcement that works with the updated Bitcoin architecture, huge improvements to Darksend, many more languages supported, lower bandwidth usage and a fully implemented sporking framework.
For more information about how InstantX works, checkout our whitepaper: https://www.dashpay.io/wp-content/uploads/2014/09/InstantTX.pdf
This release implements two hard forks, so all users must update ASAP. The network will fork in 1 week or when 80% of miners have updated.
v0.11.1 utilizes a fully implemented version of InstantX. To try InstantX, use the QT wallet and simply click the “InstantX” checkbox when sending money. Funds send using InstantX will gain 5 masternode-level confirmations within seconds from the network, then within an average of 1.25 minutes a 6th block-level confirmation will make funds spendable on most websites.
InstantX is automatically enabled and this means when using the daemon, the API will show transactions as confirmed as soon as the masternode network successfully locks them in place.
To disable InstantX, simply start the daemon/client with –instantxdepth=0. This will be the equivalent of running in a pure proof-of-work mode.
InstantX does not support sending via the API at this point. This will be included in a future version.
To use InstantX, simply check the “InstantX” box, then send money normally.
On the transaction screen, it should update within a few seconds from the question mark icon to the clock
To see more information about the state of InstantX, double click the transaction.
Possible messages include:
“Verified via InstantX”: This means network locks are in place and the money is safe
“InstantX verification in progress – X of 25 signatures” : This means the network is currently processing your transaction and your client is waiting on more signatures from masternodes
“InstantX verification failed” : The network failed to validate the transaction. In this case, normal proof-of-work will occur.
Requirements / Feature Breakdown:
- Inputs used must have 5 block-level confirmations in order to send via IX
- To lock a transaction via IX, 15 of 25 elected masternodes must respond by voting
- Transaction locks are lost when restarting the client and only last for an hour
- Transactions must pay a fee of 0.01 DASH to use IX
- Once a transaction lock is in place, conflicting transactions will be rejected if in blocks or relayed as a normal transaction.
- InstantX is designed to work nearly all of the time. I expect it will work on about 98%+ of transactions in it’s present form. If it fails, the transaction will simply fall back to normal proof of work.
Various improvements have been made to Darksend, such as the fully implemented “DSTX” message. This means that when anonymizing funds, Darksend transactions are first class citizens in miner’s blocks and will be included immediately. Other stability issues were also fixed.
v11.0’s implementation of enforcement was not compatible with the newer Bitcoin architure. Recently we moved from the Litecoin code base, to the new Bitcoin codebase. This exposed some edge cases within the Bitcoin code that caused enforcement to stop working consistently.
This has been fixed in v11.1, but will require all users update so we remain on the same fork. Enforcement will be activated as soon as 80% of the network has updated (usually a couple days).
Thanks to Vertoe and the community for spear heading this project, the client now fully supports over 20 languages such as Portuguese, German, Russian, Polish, Spanish, Vietnamese, French, Italian, Catalan, Chinese, Danish, Finnish, Swedish, Czech, Turkish and Bavarian (and many more).
Full release notes:
11.1.19 Core – All Users
Thanks to who contributed to this release, at least:
– Holger Schinzel
– Mario Müller
– Alexandre Devilliers
– Stuart Buck
– Tiago Serôdio
– Lukas Jackson
Discussion of the announcement at Dashtalk
We are thrilled to begin admitting members to the Dash Foundation today. We are asking for your money in the form of both dues and donations, so an explanation is in order.
The Foundation is an Arizona nonprofit corporation and future 501(c)(6) organization (hopefully–we are in the process of applying for recognition of exemption). Its purpose is to promote, protect and standardize Dash. The Foundation doesn’t own the Dash project–the community does. The Foundation is here to help. We believe that organizing fundraising efforts will be beneficial, but everyone is free to continue contributing in whatever manner is most convenient.
We have broken down the broad mission of promoting, protecting and standardizing Dash into more specific objectives:
1. Support the development of the Dash protocol. We must ensure that the development team has the resources it needs to maintain Dash’s status as the most innovative cryptocurrency in the world.
2. Empower the community. Many members of the community already perform valuable tasks. Our goal is to assist them in as many ways as possible.
3. Educate the public. We will engage in educational and promotional activities in an effort to bring Dash to a much wider audience.
4. Represent. The Foundation can speak for Dash when and where such representation is appropriate.
Becoming a Member
There are two types of members: individual and industry. Individual members can choose to pay dues annually or become lifetime members. Both people and entities can become industry members. Neither class of members receives any perks, really, other than the right to vote for board directors (this may change when Dash is on its way toward world domination). For now, it’s best to think of membership as an act of support.
We feel membership should be within the reach of as many people as possible, so one can join for as little as 10 DASH. This doesn’t mean that we can’t use additional funds–if you are able and willing, please consider donating more. If you aren’t interested in becoming a member but would like to donate, that is completely OK, too.
We want to be very open with the community, so please, feel free to contact us with any questions you may have. It’s your foundation. Propulsion has agreed to create a subforum on Dashtalk.org for Foundation-specific discussions. This forum will be open to the public, but only members will be able to post.
The Foundation is governed by its bylaws and a conflict of interest policy. These documents are available on our site for anyone that is interested. The board of directors holds meetings periodically, and is in regular contact when they are not meeting.
Foundation funds will be stored in multisignature wallets and all Foundation addresses will be public. Dashs will not be anonymized, so everyone will be able to see how they are being spent. Bitcoins will not be anonymized either … not that this is even possible!
The Dash Foundation Board of Directors
Due to some issues that were brought up by a researcher, we’ve revised the Darksend protocol extensively to enhance the anonymity provided. It’s very important that all clients on the Dash network update.
Users Required To Update:
Changes made in this release:
– Masternodes can now make a limited number of zero-fee transaction for Darksend. These are special transactions that require a signature that only the masternodes can create.
– Darksend now has no fees to track what-so-ever, all that will ever be in Darksend transactions are Darksend denominations.
– Added queue gaming protection
– Clients remember which masternodes they’ve connected to in the past and won’t use them against.
– Dsee/Dseep messages have been fixed so they only take newer signatures than the one they have
– 2 different kinds of client crashes have been fixed
– Split up main.cpp into core.cpp
– Split up darksend.cpp into masternode.cpp, activemasternode.cpp and instantx.cpp
– Added modular ProcessMessages for Darksend, Masternodes and InstantX
– Client can now join sessions with any other users
ATTENTION: POOL OPERATORS
This update includes a fork, all daemons and stratum deployments must update their code to pay the correct masternodes and correct reward amounts.
***EDIT (12/19/14): Outdated links have been removed. Please update to the most current version from the Downloads page or GitHub repository.***
Immediately: Enforcement will be turned off, allowing for pools to update their software without risk of orphaned blocks
Oct 23, 2014: Rewards will step up to 25%. Dash users are encouraged to contact pools that have not updated and politely ask them to update.
Nov 14, 2014: Enforcement will be turned on, any pools that have not update will have their blocks rejected.
Who Needs To Update?
All Dash users must update their clients.
Part of securing the Dash network is creating a strong and healthy network of full nodes to back it up. These nodes provide many tasks for users such as propagating messages, syncing clients and mixing users funds via Darksend.
To make the network resistant to attack we required these nodes to hold 1000DASH (these coins are held in a completely trustless way in cold storage in most cases, so they can’t be stolen). In return for holding the coins and running the node, these users are paid 20% of the block reward.
Security for Darksend and InstantX is provided by selecting masternodes deterministically from the total set, then using multiple of these nodes to make decisions. Vastly greater security becomes possible when you add more nodes due to the cost associated with controlling a majority of said nodes. For statistical analysis of this please checkout the InstantX whitepaper .
Increasing Rewards Schedule
With this release we will progressively change the reward to incentivize the creation of more masternodes, this should strengthen the network and protect it from sybil attacks making it more expensive for attackers to control an important portion of the nodes.
This is also key for instant transaction confirmations to be a reality, the network needs to be robust enough to handle a large amount of transactions as we strive for adoption on real world applications. The features that give value to Dash need to be protected as that is what will ensure the long term success of the project for the benefit of all Dash supporters, current and those that will join DASH in the future.
*Currently there are 900 active masternodes. Numbers are expected to increase as profitability rises.
** ROI calculation is ((1/t)*b*(r*s)*365)/1000
t = Total number of masternodes
b = Blocks per day on average (576 for Dash)
r = Average reward per block
s = Masternode mining share
Steady Payments and Proof-of-Service
Another issue in the past has been the volatility in return due to the random nature of masternode payments. This is being dealt with by creating an algorithm to pay the masternodes evenly. Each masternode can expect a payment every N blocks with a variance of about 10%.
Also included in this release is a framework that we can build a true proof-of-service platform on. This means only masternodes actually providing services will be paid for those services.
To only pay active masternodes, pay masternodes evenly and ensure that all pools pay the correct node and amount we’ve introduced a new type of node, the reference node. This node has a special key that allows it to tell the network which nodes get paid, on which blocks in the future. Anyone on the network can verify these nodes are doing their job (i.e. not tampering with the results) by running the code and comparing the payee’s due to the deterministic algorithm used. In case of DDOS or a service failure, the network default to paying random masternodes as it does now.
This setup is non-exploitable and will serve as a mechanism of enforcement till we can revisit this in the future. A better future solution would be an in-blockchain voting mechanism like RC3 or a second blockchain updated by the miners that stores the masternode list.
Flare’s Trustless Masternode Hosting Service:
How To Guide:
How To Guide 2:
Just for fun:
Recently after open sourcing, Darksend has been undergoing an exhaustive evaluation of it’s security to many different kinds of attacks. This update includes over 15 measures to prevent abuses of the system and keep it healthy.
To prevent such attacks, we require users to post a collateral payment to the masternode they wish to use. Parts of the Darksend process in the past were not using this protective measures and were quickly identified and attacked. This update includes many improvements to the way collateral is used to make attacking expensive.
One of the notable improvements is that collateral transactions pay the fee directly to miners. This creates a situation where to double spend attack the collateral transaction, one would have to pay a higher fee to the miners. Since the collateral fee is payed to the miners already, double spending attacks against the system are impossible.
We had to take a short detour from InstantX to focus on Darksend after it gained enough attention to be actively attacked by our competitors. Now that we’re confident of the security of the system, we’ll be moving back to working on InstantX.
The first version of InstantX will be a soft-fork. It will simply show when transactions have been successfully validated by the observer network. This will give us some real world testing of the framework.
We have some other projects and exciting things in the works. We’ll be announcing those in the following months.
October 21, 2014 Update: 15.14 Adds a fix for a DOS style attack against the masternode list that was attempted earlier today. This attack didn’t result in any harm to the network or extra payments for the attacker.
October 22, 2014 Update 15.15:
There have been some masternode stability problems (masternodes not staying active on the network) for some users, this was caused by the masternode operators changing the masternodeprivkey and then starting the masternode again. This lead to some of the networking have one pinging key and parts of the network having another. This update fixes that issue and will allow masternodes to change that key. Because of this issue clients were flagging peers as misbehaving, eventually leading to them being banned, causing network fragmentation, which lead to other issues on the network.
An alternative solution is to move the 1000DASH input to a brand new address that the network has not seen. Then start the masternode normally. Once the network updates to v15.15, we won’t have these issues anymore.
At block 158,000 masternode rewards will jump to 25%, if more than 80% of the network is updating and paying the correct rewards enforcement will be activated then. From the looks of it, we’re very close to those numbers already. Once enforcement is active, payments will be completely 100% fair and equal between all masternodes.
October 22, 2014 Update 15.16:
After some more inspection I found there were multiple Masternode announcement messages propagating around the network. This update filters out all but the newest one to ensure the list is correct and up-to-date. It’s not manditory to update, but please do if you can. Last update till InstantX