v14.0 Testing

codablock

codablock

Active member
Release candidate v0.14.0.0-rc5 is ready for testnet! :)

Github release candidate: https://github.com/dashpay/dash/releases/tag/v0.14.0.0-rc5
Release notes are not ready yet and will be prepared in the next few days. Post will be updated.
Gitian sigs can be found here: https://github.com/dashpay/gitian.sigs

Before testing:
Make sure you made a backup of your mainnet datadir somewhere or at least a backup of wallet.dat/dash.conf;
Or use the -datadir and -conf parameters to use completely different directories.

This release deploys LLMQ DKGs, LLMQ based ChainLocks and LLMQ based InstantSend. A detailed product brief is currently in the works and will be published in the next days. LLMQ based InstantSend is experimental at the moment and it's not fully clear yet if we'll enable it on mainnet or not. Another large improvement is the removal of ALL legacy code related to the old masternode system.

When we see enough MNs being upgraded, we'll enable spork17 again (disabled for now, due to the old dummy DKG causing banning of v13 nodes) so that DKGs start to work. We should see the first real LLMQs build shortly after that. As we had the dummy DKGs running on testnet for a while, v14 nodes will believe that there are already plenty of working LLMQs on-chain, while in reality these are all not functional. It will take about 24 succesful DKGs until we have all active LLMQs replaced with real/functional ones.

When enough LLMQs have been created, we'll enable spork19, which will activate ChainLocks in passive/testing mode. We should see ChainLocks forming then, but not being enforced. Only after we cause BIP9 (bit4) activation for DIP8/ChainLocks, ChainLocks will start to get enforced. At this point, we can start to test 51% protection (everyone is free to try to reorg the chain).

At the same time (or a bit later), we'll activate spork20, which switches InstantSend to use the new/experimental LLMQ-based InstantSend. We can then test if things like retroactive signing, chained locks, ... are working. We will post more instructions/descriptions at that time if necessary.

We expect this upgrade to be quite seamless compared to the v13 release, as there are not so many on-chain consensus related changes involved. Also, we expect that integration partners shouldn't even notice the upgrade happening this time. It should be as simple as replacing binaries and restarting dashd. Only if the new features are needed, partners would have to look into new RPC fields from get(raw)transaction and getblock.

Additionally, the usual testing should be performed to make sure everything works as expected:
- Check if normal transactions are still working, perform some automated load testing if you want
- Check if creating and voting on proposals work. Also check if winning proposals get paid and other don't.
- Test if PrivateSend is working. Make sure to use the recently added multi session support.
- Check if InstantSend is still working. We'll start with the old system and later switch to the LLMQ based InstantSend system, both need to be tested
- Run a masternode or two, make sure it is paid. Please note that DIP3 is fully active on testnet, which means that the legacy masternode system is not present anymore. This means that you should NOT try to setup a classical/legacy masternode (no masternode.conf, no "masternode start", ...) but instead directly start with a DIP3 masternode by registering it via protx RPC commands (or use DashMasternodeTool). Instructions can be found here: https://docs.dash.org/DIP3-masternode-upgrade (Ignore that these guides assume that you're upgrading from a legacy MN!)

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/
For now, only the faucet at https://test.faucet.dashninja.pl/ is known to be well funded. It should have enough for everyone.
Edit: + http://faucet.test.dash.crowdnode.io/

MNOs:
Wiki: https://docs.dash.org/en/stable/developers/testnet.html#masternodes
DIP3 upgrade instructions: https://docs.dash.org/DIP3-masternode-upgrade
Sentinel : https://github.com/dashpay/sentinel/tree/develop

NOTE: Make sure you pulled Sentinel from `develop` branch and changed network to `testnet` in `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.
 
Last edited:
This post is a quick guide to help you get setup for testing this release.
It assumes you already have DASH 13.x installed on your system and this installation purposely avoids touching that install and your user data. This post is Windows centric.
Never run a test build (RC) on mainnet. Don't trust it with your mainnet wallet and real DASH !
Click to expand...
Always verify the signatures and authenticity of the DASH executables you download from dash.org, we skip this step for testnet/RC builds, don't skip it when installing the final version
Click to expand...


Just in case backup your mainnet wallet.dat and masternodes.conf files !!!

Create a new directory somewhere on your computer. I will create it on my Desktop. Call it Dash-test
You now have a directory with a path similar to this, note that User will be your username C:\Users\User\Desktop\Dash-test

In the Dash-test folder create a new folder and call it data double click that and in the data folder create a New Text document and edit it and add the following line
Code: 
testnet=1
Save the file and now rename it to dash.conf

Go back one directory to the Dash-test folder and load this page https://github.com/dashpay/dash/releases/
Find the latest version of 64 bit windows ZIP file, NOT the installer! Remember, you do not want to overwrite your regular 13.x Dash! Example for RC1 is dashcore-0.14.0.0-rc1-win64.zip
Download this zip and extract the contents into the Dash-test folder.

You should now have two folders in you Dash-Test folder, dashcore-0.14.0 and data.

Double click dashcore-0.14.0 and double click bin. Create a short cut to dash-qt.exe. Cut the shortcut and go back (up) two folders to Dash-test and paste it there. So the shortcut is now in the same place as the two dash folders, one from the zip and one that you created.

Edit the shortcut. You only have to change the Target. Make the target look like below, you will have to change User for your username when setting the -datadir.
Code: 
C:\Users\User\Desktop\Dash-test\dashcore-0.14.0\bin\dash-qt.exe -debug=1 -testnet=1 -datadir=C:\Users\User\Desktop\Dash-test\data
The important things here are the location of -datadir and -testnet=1 flag. We want to make sure this version of Dash stays well away from your mainnet Dash !
Click Apply and OK. If your username has spaces in it, try putting the Dash-test on C:\ otherwise you need to put " around -datadir flag.


upload_2019-3-29_12-4-3.png

upload_2019-3-29_12-3-34.png




At this point if Windows allows you to save the shortcut it means it has no errors and you can double click it to start syncing and testing. Check that it is writing data to the data folder. You can ask in the #testnet channel on discord for some free tDASH.

Updating to latest RC

Shutdown the test wallet. Download the latest zip from the site above, extract the contents to the Dash-test folder, click Yes to overwrite/replace existing files. Launch the wallet using the Shortcut you created and note the version of the startup splash screen.


Cheers !

-X
 
Last edited:
If I receive a transaction with wallet offline, and then start the Core, the wallet does not show the transaction in the list, unless it is confirmed in blockchain
UPD: and there are problems with sending money during that time
 
Last edited:
f8192 said:
If I receive a transaction with wallet offline, and then start the Core, the wallet does not show the transaction in the list, unless it is confirmed in blockchain
Click to expand...

Myself and GNULinuxGuy were able to reproduce this bug.
 
@f8192 @xkcd as far as I know, this is the behavior we always had when receiving a TX while being offline. This is only different on SPV wallet which do a BIP35 mempool request on startup.
Or did you verify that this behavior is different on other version of Dash, e.g. on 0.13.2?
 
The format for the `masternode list full` and `info` commands has changed. Was this intentional? And looking at the help text there seems to be a bunch of changes to the list command. Is there documentation somewhere related to this? Or should I file a bug?

Options and formats for 0.14...
Code: 
$ dash-cli help masternode list
[removed irrelevant help text]
  full           - Print info in format 'status payee lastpaidtime lastpaidblock IP'
                   (can be additionally filtered, partial match)
  info           - Print info in format 'status payee IP'
                   (can be additionally filtered, partial match)
  json           - Print info in JSON format (can be additionally filtered, partial match)
  lastpaidblock  - Print the last block height a node was paid on the network
  lastpaidtime   - Print the last time a node was paid on the network
  owneraddress   - Print the masternode owner Dash address
  payee          - Print the masternode payout Dash address (can be additionally filtered,
                   partial match)
  pubKeyOperator - Print the masternode operator public key
  status         - Print masternode status: ENABLED / POSE_BANNED
                   (can be additionally filtered, partial match)
  votingaddress  - Print the masternode voting Dash address



Options and formats for 0.13...
Code: 
$ dash-cli help masternode list
[removed irrelevant help text]
  activeseconds  - Print number of seconds masternode recognized by the network as enabled
                   (since latest issued "masternode start/start-many/start-alias")
  addr           - Print ip address associated with a masternode (can be additionally filtered, partial match)
  daemon         - Print daemon version of a masternode (can be additionally filtered, exact match)
  full           - Print info in format 'status protocol payee lastseen activeseconds lastpaidtime lastpaidblock IP'
                   (can be additionally filtered, partial match)
  info           - Print info in format 'status protocol payee lastseen activeseconds sentinelversion sentinelstate IP'
                   (can be additionally filtered, partial match)
  json           - Print info in JSON format (can be additionally filtered, partial match)
  lastpaidblock  - Print the last block height a node was paid on the network
  lastpaidtime   - Print the last time a node was paid on the network
  lastseen       - Print timestamp of when a masternode was last seen on the network
  owneraddress   - Print the masternode owner Dash address
  payee          - Print the masternode payout Dash address (can be additionally filtered,
                   partial match)
  protocol       - Print protocol of a masternode (can be additionally filtered, exact match)
  keyid          - Print the masternode (not collateral) key id
  rank           - Print rank of a masternode based on current block
  sentinel       - Print sentinel version of a masternode (can be additionally filtered, exact match)
  status         - Print masternode status: PRE_ENABLED / ENABLED / EXPIRED / SENTINEL_PING_EXPIRED / NEW_START_REQUIRED /
                   UPDATE_REQUIRED / POSE_BAN / OUTPOINT_SPENT (can be additionally filtered, partial match)
  votingaddress  - Print the masternode voting Dash address


Side note: RC2 available in test repo: https://github.com/taw00/dashcore-rpm
 
Last edited:
RC2 (https://github.com/dashpay/dash/releases/tag/v0.14.0.0-rc2) has just been released. Changes in RC2 only affect masternodes, so please upgrade masternodes.
The most important change is a fix for the intra-quorum communication which skipped deterministic connections to nodes with the same IP as already connected nodes. The local IP was also skipped, even if the other MN was running on another port. This resulted in many LLQM members not being able to propagate their DKG contributions, making all DKGs fail.
 
codablock said:
as far as I know, this is the behavior we always had when receiving a TX while being offline. This is only different on SPV wallet which do a BIP35 mempool request on startup.
Or did you verify that this behavior is different on other version of Dash, e.g. on 0.13.2?
Click to expand...
Same behavior on 0.13.2. Sorry, I thought it was a bug
 
codablock said:
@f8192 @xkcd as far as I know, this is the behavior we always had when receiving a TX while being offline. This is only different on SPV wallet which do a BIP35 mempool request on startup.
Or did you verify that this behavior is different on other version of Dash, e.g. on 0.13.2?
Click to expand...
Agreed. This isn't a new issue. My primary concern with it is, I think most would expect IS transactions to show up in this instance. I suppose this is a lot less of an issue because of our plans to extensively use DAPI, but still noteworthy and a potential design concern.
 
Last edited:
I have just made a transaction with 57 inputs. It should not be an autolock case, but it have been locked automatically. Do we have changes on that?
UPD: The IS-lock is still active after 47 blockchain confirmations. And apparently not going to be removed anytime soon, hmmmmmmm.
 
Last edited:
f8192 said:
I have just made a transaction with 57 inputs. It should not be an autolock case, but it have been locked automatically. Do we have changes on that?
UPD: The IS-lock is still active after 47 blockchain confirmations. And apparently not going to be removed anytime soon, hmmmmmmm.
Click to expand...
You have just successfully tested LLMQ-based InstantSend, which is currently enabled on testnet ;)

RC3 has just been released and can be found here: https://github.com/dashpay/dash/releases/tag/v0.14.0.0-rc3
Everyone please upgrade. We will start signalling the BIP9 deployment for DIP8 next week, which will also trigger an incompatible change in on-chain data and make 0.13 and pre-RC3 0.14 nodes fork off.
 
Wow, thats cool
So, are we going to have every dash transaction IS-locked after spork20 activation on mainnet? Without any exceptions, like number of inputs or anything else?
 
Last edited:
codablock said:
@f8192 can you give me the transaction ID of these TXs and also the output of "getrawtransaction <txid> 1"?
Click to expand...
There are 3 unconfirming txs in my wallet, the first one is 2f82a026c08b8a1714e6db6f042e03aee00e254564d0d770b6059dfa465bf4e2 (raw attached below)
UPD: It looks like I can't publish it, although the node is connected and fully synced. And the wallet reports that it is published
UPD2: There is something strange happening, I'm only connected to v0.13 nodes
UPD3: I waited some time and my node connected to a few v0.14 nodes (while still being connected to a few v0.13). I published same transaction again, and it worked. Was not able to do that for 2 days..
ojM7n8p.png

Code: 

{
  "hex": "0200000001350492a74f33ea450ae15fa93cd2a285419121e5559e55d518df1d3450f6c0860b0000006b4830450221008b98089664f38d61cc6edfc69b0c1986b804b0afbe74006784a4465beb7d86740220040baa3d7e2e1e1e006ba4bc56085f6ba3928d2eb0d301db8200e0ededc32aac012103ac6cba668d401d3040ac5384e67f45e39617b0b26a78d19ee940e283bbd7cdd0feffffff0c10f19a3b000000001976a91426d5886b88c39d1e4b97e7c7c77bddc8fc9cf61c88ac10f19a3b000000001976a91431dce473cf89f61927e152c4e7d0a3af91f2037588ac10f19a3b000000001976a914358ecabac298410e7ee7c1b0349fc1d6b5f95efb88ac10f19a3b000000001976a914719cbd82a0c5898b39556b6fe50603118146385c88ac10f19a3b000000001976a91486e1481f4abe733deb29d752fb20df3baa83915788ac10f19a3b000000001976a914984bc1ae3cb28f8321ea467fc2685a21d87bd26588ac10f19a3b000000001976a91498d3ccb14baf1ef6efc6d2e8621e17317ab6a45888ac10f19a3b000000001976a914ba7ef8463888a367f95a286eae711fb48bc1bd6588ac10f19a3b000000001976a914d1ef62e3b4a972092b87d7a228381cee4e41216488ac10f19a3b000000001976a914de01d1eee52e60dbd102d1ecb2c0c1928ab67b8688ac10f19a3b000000001976a914fd20aaf625e2ce37bd4c9b0f3a01724c011e0c7f88acd81fc268e50000001976a9147489b494e1da131ea2bdb14cdb3f30ff7a70ccc188acd3230100",
  "txid": "2f82a026c08b8a1714e6db6f042e03aee00e254564d0d770b6059dfa465bf4e2",
  "size": 566,
  "version": 2,
  "type": 0,
  "locktime": 74707,
  "vin": [
    {
      "txid": "86c0f650341ddf18d5559e55e521914185a2d23ca95fe10a45ea334fa7920435",
      "vout": 11,
      "scriptSig": {
        "asm": "30450221008b98089664f38d61cc6edfc69b0c1986b804b0afbe74006784a4465beb7d86740220040baa3d7e2e1e1e006ba4bc56085f6ba3928d2eb0d301db8200e0ededc32aac[ALL] 03ac6cba668d401d3040ac5384e67f45e39617b0b26a78d19ee940e283bbd7cdd0",
        "hex": "4830450221008b98089664f38d61cc6edfc69b0c1986b804b0afbe74006784a4465beb7d86740220040baa3d7e2e1e1e006ba4bc56085f6ba3928d2eb0d301db8200e0ededc32aac012103ac6cba668d401d3040ac5384e67f45e39617b0b26a78d19ee940e283bbd7cdd0"
      },
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 10.00010000,
      "valueSat": 1000010000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 26d5886b88c39d1e4b97e7c7c77bddc8fc9cf61c OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91426d5886b88c39d1e4b97e7c7c77bddc8fc9cf61c88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "yPrnL1zhnmBWKTcRms3YFKgVnhWa31WJ6k"
        ]
      }
    },
    {
      "value": 10.00010000,
      "valueSat": 1000010000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 31dce473cf89f61927e152c4e7d0a3af91f20375 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91431dce473cf89f61927e152c4e7d0a3af91f2037588ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "yQs6aUWtVd7KSnXsA9QqFdpe1XnDscw3Fs"
        ]
      }
    },
    {
      "value": 10.00010000,
      "valueSat": 1000010000,
      "n": 2,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 358ecabac298410e7ee7c1b0349fc1d6b5f95efb OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914358ecabac298410e7ee7c1b0349fc1d6b5f95efb88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "yRCdij4jQ3eLzViLxbjf54ZviVhoLd3yEa"
        ]
      }
    },
    {
      "value": 10.00010000,
      "valueSat": 1000010000,
      "n": 3,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 719cbd82a0c5898b39556b6fe50603118146385c OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914719cbd82a0c5898b39556b6fe50603118146385c88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "yWgAyPHguEzmpeux8wp6v6xosmHijkAB8b"
        ]
      }
    },
    {
      "value": 10.00010000,
      "valueSat": 1000010000,
      "n": 4,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 86e1481f4abe733deb29d752fb20df3baa839157 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91486e1481f4abe733deb29d752fb20df3baa83915788ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "yYcdGksNjtcGSyMX4X935BJo86fuyEjD3w"
        ]
      }
    },
    {
      "value": 10.00010000,
      "valueSat": 1000010000,
      "n": 5,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 984bc1ae3cb28f8321ea467fc2685a21d87bd265 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914984bc1ae3cb28f8321ea467fc2685a21d87bd26588ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "yaCiK26UuMSc8B2Ec44mNTBa7MqtbiZuZH"
        ]
      }
    },
    {
      "value": 10.00010000,
      "valueSat": 1000010000,
      "n": 6,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 98d3ccb14baf1ef6efc6d2e8621e17317ab6a458 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91498d3ccb14baf1ef6efc6d2e8621e17317ab6a45888ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "yaFXHTHtB12D6thLBv5ajNgdsdcDpf7NFa"
        ]
      }
    },
    {
      "value": 10.00010000,
      "valueSat": 1000010000,
      "n": 7,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 ba7ef8463888a367f95a286eae711fb48bc1bd65 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914ba7ef8463888a367f95a286eae711fb48bc1bd6588ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "ydKYduEU5GHaUx37MbF4uVnga1sp4CznWZ"
        ]
      }
    },
    {
      "value": 10.00010000,
      "valueSat": 1000010000,
      "n": 8,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 d1ef62e3b4a972092b87d7a228381cee4e412164 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914d1ef62e3b4a972092b87d7a228381cee4e41216488ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "yfTUr9SqmRefKUV2WCbNvBoafiNcnofesj"
        ]
      }
    },
    {
      "value": 10.00010000,
      "valueSat": 1000010000,
      "n": 9,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 de01d1eee52e60dbd102d1ecb2c0c1928ab67b86 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914de01d1eee52e60dbd102d1ecb2c0c1928ab67b8688ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "ygZK3FPEV2JFRrKyZP21i6N2E7RCy1aJsM"
        ]
      }
    },
    {
      "value": 10.00010000,
      "valueSat": 1000010000,
      "n": 10,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 fd20aaf625e2ce37bd4c9b0f3a01724c011e0c7f OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914fd20aaf625e2ce37bd4c9b0f3a01724c011e0c7f88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "yjPrwY3FafaURSbCKaFdZio8wKfGiGPmYa"
        ]
      }
    },
    {
      "value": 9853.05063384,
      "valueSat": 985305063384,
      "n": 11,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 7489b494e1da131ea2bdb14cdb3f30ff7a70ccc1 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9147489b494e1da131ea2bdb14cdb3f30ff7a70ccc188ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "yWweCPoyEAmjtC7aFozH9FTSfc4H7QhWhn"
        ]
      }
    }
  ],
  "instantlock": false,
  "chainlock": false
}
 
Last edited:
@f8192 Thanks for reporting this. Just confirmed on my local node that there is indeed some tendency to only connect to 0.13 nodes. Turns out the reason is that most masternodes are running on non-default (19999) ports, which makes the address selection algorithm prefer non-masternodes, which are still mostly on 0.13. A fix will be included in the next RC, until then, I'd advice to disconnect as many 0.13 nodes necessary to get a 0.14 connection.
 
You must log in or register to reply here.
Back
Top