Welcome to the Dash Forum!

Please sign up to discuss the most innovative cryptocurrency!

v12.3 Testing

Discussion in 'Testing' started by codablock, Jun 2, 2018.

  1. codablock

    codablock Official Dash Dev
    Core Developer

    Joined:
    Mar 29, 2017
    Messages:
    59
    Likes Received:
    80
    Trophy Points:
    58
    Hello everyone,

    UPDATE: 0.12.3.0-rc5 has been uploaded to Github:
    https://github.com/dashpay/dash/releases/tag/v0.12.3.0-rc5
    I've also updated the links in this post.

    Please upgrade to the new version and issue mn-start on your masternodes.

    RC5 should fix the forking issues currently seen on testnet.

    Detailed changes: https://github.com/dashpay/dash/compare/v0.12.3.0-rc4...v0.12.3.0-rc5

    -------

    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-rc5
    Release notes can be found here: https://github.com/dashpay/dash/blob/v0.12.3.0-rc5/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.

    MNOs:
    Wiki: https://dashpay.atlassian.net/wiki/spaces/DOC/pages/118162190/Masternodes+under+testnet
    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.

    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.
     
    #1 codablock, Jun 2, 2018
    Last edited: Jun 20, 2018
    • Like Like x 13
    • Winner Winner x 10
    • Informative Informative x 3
    • Useful Useful x 1
  2. TanteStefana

    TanteStefana Moderator
    Linguistic Foundation Member

    Joined:
    Mar 9, 2014
    Messages:
    2,843
    Likes Received:
    1,861
    Trophy Points:
    1,283
    Can you give us an IP address? My wallet isn't finding a chain :)` no peers to connect to? should we put devnet=??? in the dash.conf file?

    OK, for some reason my wallet just wouldn't find a peer. If you're having this problem, thephez just had me put the following in the console and it started to sync:

    addnode 108.61.192.47 add

    And suddenly I have 8 peers :D


    I started from scratch, and just in case this helps locate an issue, here is a snippet from the debug log:


    2018-06-03 02:06:32 CMasternodeSync:: processTick -- nTick 1 nRequestedMasternodeAssets 0 nRequestedMasternodeAttempt 0 nSyncProgress -0.250000 2018-06-03 02:06:36 38 addresses found from DNS seeds 2018-06-03 02:06:36 dnsseed thread exit
     
    #2 TanteStefana, Jun 3, 2018
    Last edited: Jun 3, 2018
  3. drkrooster

    drkrooster Member

    Joined:
    Dec 26, 2014
    Messages:
    52
    Likes Received:
    26
    Trophy Points:
    58
    finally!
    don't worry, appreciate you and the team sharing and hard work.
    those challenges and difficulties experience will turn into our strength going forward!
    well done! team
     
    • Agree Agree x 4
    • Like Like x 3
  4. akhavr

    akhavr Active Member
    Masternode Owner/Operator

    Joined:
    Oct 11, 2014
    Messages:
    640
    Likes Received:
    340
    Trophy Points:
    133
    Trying to sync testnet blockchain. Seems to work this time.
     
  5. AjM

    AjM Well-known Member
    Foundation Member

    Joined:
    Jun 23, 2014
    Messages:
    1,303
    Likes Received:
    564
    Trophy Points:
    283
    Win7 64bit - Dash Core v0.12.3.0-rc2

    @codablock what is that 3 seconds count down in the sending dialog OK button?
    It does not do anything, seems.

    And command-line options blockreconstructionextratxn info is not translated.

    -blockreconstructionextratxn=<n>
    Extra transactions to keep in memory for compact block reconstructions (default: 100)
     
  6. GNULinuxGuy

    GNULinuxGuy Member

    Joined:
    Jul 22, 2014
    Messages:
    111
    Likes Received:
    68
    Trophy Points:
    78
    Dash Address:
    XjkXfrYTSvdYe4738DtNVX5XfUz7qU9HnY
    Updated my dedicated tMN. Looking good so far! Very exciting! Will continue to bring more testnet nodes online and do additional tests as I have time. :)
     
    • Like Like x 1
  7. codablock

    codablock Official Dash Dev
    Core Developer

    Joined:
    Mar 29, 2017
    Messages:
    59
    Likes Received:
    80
    Trophy Points:
    58
    Do I understand you correct that everything is ok now?

    This is most likely because translations were already done and imported/merged before these features were merged. I would consider this a minor problem and assume that we're going to fix it with one of the future translation imports.
     
    • Agree Agree x 1
  8. AjM

    AjM Well-known Member
    Foundation Member

    Joined:
    Jun 23, 2014
    Messages:
    1,303
    Likes Received:
    564
    Trophy Points:
    283
    @codablock Ok, and that OK button 3 sec count down?
     
  9. codablock

    codablock Official Dash Dev
    Core Developer

    Joined:
    Mar 29, 2017
    Messages:
    59
    Likes Received:
    80
    Trophy Points:
    58
    That's from the Bitcoin backports and acts as a protection against trigger fingers. It kind of forces you to double check your TX or at least think 3 more seconds. I personally find it ok this way...never forget, in Crypto there is no "reverse my erroneous transaction" ;)
     
  10. AjM

    AjM Well-known Member
    Foundation Member

    Joined:
    Jun 23, 2014
    Messages:
    1,303
    Likes Received:
    564
    Trophy Points:
    283
    So, ok button does not work on first 3 seconds, thats ok.
     
  11. lxklyga

    lxklyga New Member

    Joined:
    May 28, 2014
    Messages:
    9
    Likes Received:
    1
    Trophy Points:
    3
    Please help! 12.3 linux ver doesn't synchronous the block! Have you ever been in such siuation!
     
  12. lxklyga

    lxklyga New Member

    Joined:
    May 28, 2014
    Messages:
    9
    Likes Received:
    1
    Trophy Points:
    3
    12.3 windows ver everthing is ok!! synchrnousing the block,transactions,receives!!all of it are ok
     
  13. akhavr

    akhavr Active Member
    Masternode Owner/Operator

    Joined:
    Oct 11, 2014
    Messages:
    640
    Likes Received:
    340
    Trophy Points:
    133
    Testnet synchronization stuck again:

    Code:
      "blocks": 99743,
    
    What I'm doing wrong?
     
  14. codablock

    codablock Official Dash Dev
    Core Developer

    Joined:
    Mar 29, 2017
    Messages:
    59
    Likes Received:
    80
    Trophy Points:
    58
    Sync issue might happen if you got unlucky and your first connection was to a node which has forked away. These are most likely non-upgraded nodes which still run 12.2.x, which does not include the fixes we did after the ASICs were turned on on testnet.
    To fix it, disconnect the first node you see in the peers list in the debug window. To get to it, click on the "connections" icon on the bottom right.
     
  15. akhavr

    akhavr Active Member
    Masternode Owner/Operator

    Joined:
    Oct 11, 2014
    Messages:
    640
    Likes Received:
    340
    Trophy Points:
    133
    Well, I've banned all non-/Dash Core:0.12.3/ nodes connections. Still stuck at block 99743. (Linux, command line)
     
  16. codablock

    codablock Official Dash Dev
    Core Developer

    Joined:
    Mar 29, 2017
    Messages:
    59
    Likes Received:
    80
    Trophy Points:
    58
    What does "Starting Block" of the first node that you're connected to say? And maybe the nodes after the first one?
     
    #16 codablock, Jun 4, 2018
    Last edited: Jun 4, 2018
  17. InhumanPerfection

    Joined:
    Apr 9, 2018
    Messages:
    43
    Likes Received:
    19
    Trophy Points:
    48
    I'm running 3 nodes
    1) On all 3 nodes mixing of 10.0001 denomination doesn't work. Message in log "CPrivateSendClient::JoinExistingQueue -- Couldn't match 0 denominations 0 1 (10.0001)". And as I can see nobody can mix 10.0001. Other denominations - ok.

    2) This appears in log on all 3 nodes (on 1 rarely, on other 2 very common):
    Caught nodes who send these dsq (all 12.3): 108.61.199.31:19999, 104.207.147.135:19999, 217.61.221.9:19999 (I caught these 3 nodes at the moment of writing - can be more, idk...)

    3) This appears in log on 2 nodes:
    In corrupted messages:
    - in nInputCount - last 32bits of masternode txid
    - in masternode index - last 32bits of nTime
    and so on.
    Clearly there is no nInputCount field in the dsq message and other fields are moved
     
    • Informative Informative x 1
  18. UdjinM6

    UdjinM6 Official Dash Dev
    Dash Core Team Moderator

    Joined:
    May 20, 2014
    Messages:
    3,614
    Likes Received:
    3,526
    Trophy Points:
    1,183
    That is most likely related to the fact that we are having slightly different 12.3/70209 nodes on the testnet, should fix itself once more people/nodes are upgraded.
     
  19. akhavr

    akhavr Active Member
    Masternode Owner/Operator

    Joined:
    Oct 11, 2014
    Messages:
    640
    Likes Received:
    340
    Trophy Points:
    133
    So far, the only 0.12.3 node, I'm connected to, has just 46229 blocks:

    Code:
    'version', 'subver', 'startingheight'
    [(70208, u'/Dash Core:0.12.2.3/', 135647),
     (70208, u'/Dash Core:0.12.2/', 101855),
     (70208, u'/Dash Core:0.12.2.3/', 135647),
     (70209, u'/Dash Core:0.12.3/', 46229),
     (70208, u'/Dash Core:0.12.2.2/', 102503),
     (70208, u'/Dash Core:0.12.2.3/', 136235)]
    
     
  20. AjM

    AjM Well-known Member
    Foundation Member

    Joined:
    Jun 23, 2014
    Messages:
    1,303
    Likes Received:
    564
    Trophy Points:
    283
    Doesnt that startingheight mean that the blocks start from there?
     
  21. codablock

    codablock Official Dash Dev
    Core Developer

    Joined:
    Mar 29, 2017
    Messages:
    59
    Likes Received:
    80
    Trophy Points:
    58
    Can you try to disconnect one node after another until you get one on top that has a correct starting block height. All the nodes you are connected to are forked or on a too old version.

    startingheight is the block height reported by the node at the time of connecting to it. It's a good indicator to see if you are connected to forked (master) nodes, because if this number is too low, the other nodes seems to think that it is at the correct chain tip. This at least applies to masternodes you have connected to, as they will disconnect you immediately if they believe that they're not at the chain tip, not sure about regular nodes.
     
    • Like Like x 1
  22. t0dd

    t0dd Active Member
    Masternode Owner/Operator

    Joined:
    Mar 21, 2016
    Messages:
    137
    Likes Received:
    123
    Trophy Points:
    93
    Dash Address:
    XyxQq4qgp9B53QWQgSqSxJb4xddhzk5Zhh
    For Fedora/CentOS/RHEL folks that are comfortable with systemd (managing a node like a sys-admin)... my builds of 12.3 are updated and available in the test repos. Starting point: https://github.com/taw00/dashcore-rpm and then read the README.binaries.md document, which will then lead you to the .../documentation tree.

    Just install the toddpkgs-dashcore-repo.fedora.rpm or toddpkgs-dashcore-repo.centos.rpm package to enable the repos (as described on that page). You'll then have to switch to the test repos...

    ```
    # Fedora...
    sudo dnf config-manager --set-disabled dashcore-stable
    sudo dnf config-manager --set-enabled dashcore-testing
    sudo dnf list --refresh|grep dashcore

    ```

    ```
    # CentOS/RHEL
    sudo yum-config-manager --disable dashcore-stable
    sudo yum-config-manager --enable dashcore-testing
    sudo yum clean expire-cache
    sudo yum list|grep dashcore

    ```

    Disclaimer: These builds are not fully endorsed by dash core group, though I have been building, using, and supporting them (as a community member) for years (there is even instruction how to build the RPMs yourself if you like). Ping me if you have any questions. -t0dd
     
    • Informative Informative x 1
    • Useful Useful x 1
  23. codablock

    codablock Official Dash Dev
    Core Developer

    Joined:
    Mar 29, 2017
    Messages:
    59
    Likes Received:
    80
    Trophy Points:
    58
    • Like Like x 3
  24. UdjinM6

    UdjinM6 Official Dash Dev
    Dash Core Team Moderator

    Joined:
    May 20, 2014
    Messages:
    3,614
    Likes Received:
    3,526
    Trophy Points:
    1,183
    Please update to rc3 even if you are already running some older 12.3 node - it includes final min protocol bump i.e. you are going to fork off once spork10 is ON again. This update is mandatory for all nodes (MNs, mining and regular nodes). If you are still running 12.2 MNs, make sure to issue "masternode start-all" command from 12.3 wallet after upgrading both local and remote nodes.
     
  25. AjM

    AjM Well-known Member
    Foundation Member

    Joined:
    Jun 23, 2014
    Messages:
    1,303
    Likes Received:
    564
    Trophy Points:
    283
    @UdjinM6 @codablock

    Win7 64bit - v0.12.3.0-rc3

    Instantsend does not work.


    EDIT: But receiving end says it does work.

     
    #25 AjM, Jun 9, 2018
    Last edited: Jun 9, 2018
  26. codablock

    codablock Official Dash Dev
    Core Developer

    Joined:
    Mar 29, 2017
    Messages:
    59
    Likes Received:
    80
    Trophy Points:
    58
    0.12.3.0-rc4 has been released, please see the UPDATE in the top post.
     
  27. AjM

    AjM Well-known Member
    Foundation Member

    Joined:
    Jun 23, 2014
    Messages:
    1,303
    Likes Received:
    564
    Trophy Points:
    283
    Win7 64bit - v0.12.3.0-rc4

    Now InstantSend works ok.
     
    • Like Like x 1
    • Winner Winner x 1
  28. Antti Kaikkonen

    Antti Kaikkonen Active Member

    Joined:
    Jun 20, 2017
    Messages:
    207
    Likes Received:
    144
    Trophy Points:
    103
    What risk does this reduce? Someone accidentally doing a double spend transaction?

    Also the RC4 still doesn't appear to use HD wallet by default. Will this be implemented in the final release or not?
     
  29. codablock

    codablock Official Dash Dev
    Core Developer

    Joined:
    Mar 29, 2017
    Messages:
    59
    Likes Received:
    80
    Trophy Points:
    58
    Sorry, forget to mention one crucial thing for the double spend: It only applies to 0-conf+0-fee (actually, low-fee) transactions. Currently, when calling sendrawtransaction your node will accept low-fee transaction into the local mempool but then very likely fail to relay it. This is because other nodes probably won't accept/relay 0-fee transactions. If at the same time a conflicting transaction is sent to the network, it will be fully propagated and at some point arrive on your own node...which will then drop that TX because it already has the 0-fee TX in the local mempool (first seen relay policy). So, your node won't notice that every other node in the network doesn't even know about the original TX and eventually the conflicting TX will be mined.
    With sendrawtransaction rejecting low-fee TXs by default, this at least shouldn't happen by accident...for example when a block explorer blindly forwards raw transactions entered into some text field on a web page (that's what happened in the video).

    There are still some parts missing here, especially in the UI.
     
    • Like Like x 1
    • Agree Agree x 1
    • Informative Informative x 1
  30. Antti Kaikkonen

    Antti Kaikkonen Active Member

    Joined:
    Jun 20, 2017
    Messages:
    207
    Likes Received:
    144
    Trophy Points:
    103
    Thanks for explaining.

    A few months ago I succesfully send a 0-fee transaction using the standard GUI. It was included in block after a few blocks. I thought that 0-fee transactions are relayed if all of the inputs are old enough to prevent spam. Am I wrong or has this behavior been changed recently? If I'm correct then shouldn't createrawtransaction only prevent you from creating a 0-fee transaction if the inputs are too recent?
     
    • Like Like x 1

Share This Page