UPDATE: 0.12.3.0-rc4 has been uploaded to Github:\ https://github.com/dashpay/dash/releases/tag/v0.12.3.0-rc4\ I’ve also updated the links in this post.
Please upgrade to the new version and issue mn-start on your masternodes.
RC4 includes a few PrivateSend fixes and a protobump (mn-start required). It also includes a change in the sendrawtransaction RPC to reduce the risks behind the 0-conf+0-fee double spend that was recently shown by Vin Armani. The double spend shown by him is actually known since a long time and not a Dash only problem but affects many other coins. And even though it’s not even a real bug/vulnerability (merchants should never trust in simple 0-conf+0-fee transactions…that’s why we have InstantSend), we decided to reduce the risk by disallowing 0-fee transactions in sendrawtransaction by default (can be allowed through a parameter).
InstantSend should now also work better on testnet when large parts of the network have not yet upgraded. Please test this.
Detailed changes: https://github.com/dashpay/dash/compare/v0.12.3.0-rc3...v0.12.3.0-rc4
After a lot of unfortunate things happening one after another and getting into our way of releasing 12.3, we are finally at a point were we can go to public testing on testnet. For this, we created a 12.3 release candidate (v0.12.3.0-rc2) which can now be downloaded from the Github release page.
Github release candidate: https://github.com/dashpay/dash/releases/tag/v0.12.3.0-rc4\ Release notes can be found here: https://github.com/dashpay/dash/blob/v0.12.3.0-rc4/doc/release-notes.md
One of the efforts we did in the last days was to fix and re-establish Gitian building and signing. This is not fully done yet, as there seems to be some non-determinism when the final windows setup.exe is built. We will investigate/fix this in the future. The actual binaries however (which are inside the setup.exe) match between Gitian builds and are signed as well. Gitian sigs can be found here: https://github.com/dashpay/gitian.sigs
Before testing:\ Make sure you made a backup of you mainnet datadir somewhere or at least a backup of wallet.dat/dash.conf/masternode.conf;\ Or use the -datadir and -conf parameters to use completely different directories.
What/how to test:\
- Check if normal transactions are still working, perform some automated load testing if you want\
- There were improvements in the governance system, please create a few proposals and check if everything looks correct and that you get proper payouts (or no payouts when votes are missing). Make a note in this thread if you need votes for a proposal.\
- There were improvements in PrivateSend, please test if mixing still works for you\
- Check if InstantSend is still working (it might fail in the beginning as not enough MNs are available/upgraded atm)\
- Run a masternode or two, make sure it is paid;\
- Generally, this release does not include so many new things, but instead includes a large list of improvements, refactorings and bug fixes. So the testing should ensure that everything old still works as expected.
What else you can do:\
- Report serious issues (crashes/hangs/GUI glitches) : https://github.com/dashpay/dash/issues/new
Testnet tools (explorers, faucets, pools): https://www.dash.org/forum/threads/testnet-tools-resources.1768/\ NOTE: Most faucets were dry recently, but a few devs now started to automatically fund these faucets. At the moment, at least http://test.faucet.masternode.io/ should have enough tDASH for everyone.
NOTE: Make sure you pulled Sentinel from
develop branch and changed network to
sentinel.conf. If you already have a mainnet masternode on the same server, do NOT run testnet masternode in the same datadir as your mainnet masternode (i.e.
.dashcore). Create new folder specifically for testing (e.g.
.dashcore_test) and make sure you use
-datadir=<yourtestnetdatadirhere> cmd-line parameter for dashd and dash-cli. You’ll also need a separate crontab line for testnet Sentinel. If you are not 100% sure what you are doing, I’d recommend setting up a new machine/instance for testing purposes only instead of reusing your mainnet server.
We’re very sorry for the delay, and we’ll try to change a few things so this doesn’t happen again. For example, we’ll now distribute knowledge/experience about the release process a little bit more. This is one of the reasons you see me instead of @UdjinM6 doing this post now (another reason is that his internet connection is horribly limited since a few days/weeks). Another thing we did now is to remove the dependency on Bamboo for doing releases. It has gone down a few weeks ago and left us in a state were we could not do a proper Gitian release anymore…add this together with missing time of multiple team members, missing experience in the release process, bad internet connections, ASICs on testnet (which shouldn’t be a problem anymore after a few fixes we did) and you get the perfect mix of circumstances to get to the delay we got. We learned a few things about our weak spots here, let’s try to fix them.