v13.0 Testing

[qwizzie]

Show Time !!

"SPORK_16_INSTANTSEND_AUTOLOCKS": true

}

Testing instantsend autolock on simple transactions, using three seperate commands in console:

sendmany "TestDash1" "{\"ycZjKkbV3yKFWmTrC5UcoDVVkuJmh1bJFc\":0.01,\"yPHkGj64WUcj8Wt3pTJyEHM8MTFy9b8Ezp\":0.02}" 6 false "testing"

sendmany "TestDash1" "{\"ycZjKkbV3yKFWmTrC5UcoDVVkuJmh1bJFc\":0.01,\"yPHkGj64WUcj8Wt3pTJyEHM8MTFy9b8Ezp\":0.02}" 6 true "testing"

sendmany "TestDash1" "{\"ycZjKkbV3yKFWmTrC5UcoDVVkuJmh1bJFc\":0.01,\"yPHkGj64WUcj8Wt3pTJyEHM8MTFy9b8Ezp\":0.02}" 1 true "testing"

Source wallet :

They all got locked against doublespending, but not instantly confirmed.

sendmany "TestDash1" "{\"ycZjKkbV3yKFWmTrC5UcoDVVkuJmh1bJFc\":0.02,\"yVPXwLo3p4XTYU1oLJB7HMLkR3i1GmhLvH\":0.02,\"yPHkGj64WUcj8Wt3pTJyEHM8MTFy9b8Ezp\":0.02}"

Source wallet :

Conclusion :

Looks like sendmany command only adds transaction fees to one of the addresses, which i did not know. Since InstantSend Autolock on Simple transactions only use transaction fees
(it skips InstantSend fees), it looks good lock & fees-wise. They still need to get a working instant confirmation though.

Normal InstantSend transactions are also still failing the instant confirmation part (they do get locked).

 

[qwizzie]

Found something weird during testing, i created an InstantSend transaction, which got locked but not instantly confirmed (that part still does not work). But in this case it did not get an InstantSend failure notification, which i was exspecting to see in the transaction.
Instead it shows : Status: 2/unconfirmed (verified via InstantSend), broadcast through 16 nodes
(its like the successful IS lock overwrites the unsuccessfull IS confirmation in the status of transactions).

Also during testing of Automatic InstantSend on Simple transactions (through the use of sendmany command in console) some of the transactions got locked, while others did not get locked.
Automatic IS locking is not working perfectly just yet (could be Testnet related).

 

[TanteStefana]

LOL, Question for EVERYBODY

1. are you a MNO?
2. Are you part of core?
3. Are you a programmer or work in the field? (even if yes, I'm sure the next question may apply)
4. Are you confused as F*ck?

OK, well, I have a suggestion for the writers of the "how to". First, if you are going to send people back to "the 3rd step above" make sure it's marked "step 3" and maybe we should color coordinate outputs. I'm beyond frustration, and am now in hysterical laughter. Seriously, we need to make this less daunting by being clearer. I'm going to try, and hopefully I can help?

 

[qwizzie]

Looks like we moved up a stage (see page 1, post 1 we are now at stage 5), this is how i look at these stages (i assume this is what TanteStefana is talking about in above post)

Phase 1 : Stage 1
Phase 2 : Stage 3 - 4 - 5
Phase 3 : Stage 8

We are at stage 5. and I will update this line every time we move forward to the next stage.

We will have to perform full testing of all functionality in stages 1., 3. - 5. and 8. (so, 3 times in total). This includes:

What/how to test:

- 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.
- There were improvements in PrivateSend, please test if mixing still works for you. It is very likely that mixing will not be working as expected in deployment stage 1. and 2.
- Check if InstantSend is still working (it might fail in the beginning as not enough MNs are available/upgraded atm)
- Starting with stage 3., test if automatic InstantSend locks for simple transactions are working as expected.
- Run a masternode or two, make sure it is paid. We're happy for everyone that also participates in the whole upgrade process from normal/old MNs to the deterministic MNs. Instructions on how to upgrade can be found here: https://docs.dash.org/DIP3-masternode-upgrade

I will wait for next software version update before resuming testing, as a lot of changes / fixes have been applied looking at Github.

Edit : the stages do look a bit confusing on first page (1., 3. - 5. and 8.), and colorcoding current stage is not a bad idea. Also when we reach a new stage (stage 8), a new post alerting testers about this would be helpfull.

 

[TanteStefana]

I got a final output after issuing the protx register_submit tx sig . Is this used for anything? When I search for my MN on my dip3 MN tab, it shows as enabled. However, when I go to my MN, and type in dash-cli masternode status, it says it's not enabled

Not sure if something went wrong? I've gotten no payments either, however, it's only been a short time, HOLY COW! So the deterministic MN list actually tells you WHEN you will be paid? (says block 272739) ???? That must mean being paid has nothing to do with being in a quorum? or .... what was the original reason to need to make payouts as random as possible... I am pulling a blank, but it was so something couldn't be played.... ??? damn my brain, I read the paper, but ugh, don't remember....

Anyways thanks for help/ or letting me know it's correct?

Oh, and no, @qwizzie it's the actual instructions on how to update. It's hard to follow, and I kind of think it ought to be like a text book for dingbats like me, and program language illiterates. When I see something like "derived in step 5 above", I need to fins a "step 5" somewhere, not wonder where to start counting, what is going on... I get so easily confused and that's why I think things should be just outlined better, with the explanations kind of being secondary... I'm trying to see if I can make it easier for a dingbat like myself to follow, if I do, I'll post it here?!

Why? Because I think it's a good thing to have anyone running nodes, even if they're not professionals in the field, because that results in a more decentralized network of non-institutionalized interests. It may be up to them to secure their nodes, but it seems to me that badly cared for nodes lose out on payments and that, basically, the incentives are aligned. We don't really need to worry about how well a node is run, IMO, especially if we help MNOs with clear and easy to follow instructions.

 

[TanteStefana]

"size of db cache" this isn't "Dash Drive" is it? What db would this be talking about please?

Also, after I set my mixing preferences and hit "start mixing" my wallet lagged quite a bit. ,,, eh, but it recovered

Note: that's pretty cool how mixing can be done in several "threads" I presume, 1x per input size?

 

[TanteStefana]

So my MN shows in my qt wallet as enabled, but it hasn't been paid. It "says" it was paid block 27150 we're now on block 271885 and my next payment is to be 27951. My server side running dashd says this:

:~$ dash-cli masternode status
{
"outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
"service": "64.193.62.206:19999",
"status": "Not capable masternode: Masternode not in masternode list"
}

Now I know @xkcd told me I had to run a normal MN first, but I couldn't get it to start.so I just went ahead and finished the upgrade process. Is this my problem? I don't know why I couldn't start it as a regular masternode, though I never did download an old version. Is that why? Thanks for any comment, I'm going to research now, sorry for asking questions first, LOL, I'm just so short on time all the time


I get:

"AssetID": 4,
"AssetName": "MASTERNODE_SYNC_GOVERNANCE",
"AssetStartTime": 1543178253,
"Attempt": 6,
"IsBlockchainSynced": true,
"IsMasternodeListSynced": true,
"IsWinnersListSynced": true,
"IsSynced": false,
"IsFailed": false


If that's helpful?

 

[xkcd]

Hi @TanteStefana It seems your masternode hasn't finished syncing yet. Check it is on the latest block with dash-cli getblockcount, then make sure your sentinel is running. Then make sure your QT is wallet is synced to the latest block and on 13.0RC4 and send the start alias command to it. Watch the status go into PRE_ENABLED and then ENABLED. But that will never happen until dash-cli mnsync status shows "AssetName": "MASTERNODE_SYNC_FINISHED", This is easier to work through on Discord so DM me there if you like.

I suspect your MN is at the latest block, in which case you can try to shut it down and delete the peer.dat start it with dashd -reindex and check it in an hour or so. If it is on the correct chain, then try stopping and starting it again, also make sure your port is open eg 19999 ie by accessing it from another machine. If all is OK and none of it helps, then stop it again and delete all the *.dat expect wallet.dat (though it should be empty!) and start it again.

 

[TanteStefana]

Thanks so much to @xkcd for helping me find my usual idiocy (it was my masternode.conf in the wrong folder (not testnet3 folder) Ugh! LOL, I can't say enough how much I appreciate the help I get in this community!!

 

[codablock]

RC5 has just been published: https://github.com/dashpay/dash/releases/tag/v0.13.0.0-rc5

Please update ASAP, and if possible before we reach block 274000. This release includes an incompatible upgrade (a fork) that happens at exactly this block. If you don't upgrade fast enough, you'll be stuck at this block or shortly after it.

If you get into this situation, do the upgrade when you find time and look at the output of the RPC command "getchaintips 4". One of the resulting entries should be an invalid block somewhere around block 274000. Copy the hash of that block and call "reconsiderblock <blockhash>" (AFTER you've upgraded).

RC5 includes a few important changes:
1. It will disconnect all 12.x nodes after DIP3 has activated throught the BIP9 deployment (which already happened on testnet, so it will disconnect immediately)
2. We implemented all necessary changes to on-chain consensus which are required to roll out LLQMs (DIP6) after the v13 release on mainnet.
3. To properly test the on-chain consensus changes from 2., we added a so called "dummy DKG", which we'll activate later with SPORK_17_QUORUM_DKG_ENABLED
4. Multiple improvements/fixes for mixing

After enough people have reported updating to this version, and after we see enough (a couple 100) DIP3 MNs being registered, we'll activate SPORK_15_DETERMINISTIC_MNS_ENABLED.

 

[qwizzie]

Testing with RC5
Number of Masternodes : 544 (PS comp 377 / active 377)

Mixing

I notice some very sporadic PrivateSend Collateral Payment transactions getting locked (some do, some dont). The other transactions created during mixing (PrivateSend Denominate etc) dont get locked like that.
Is that correct behaviour or should locking be excluded for PrivateSend Collateral Payment transactions ?

Autolock Column

The autolock column has a dropdown arrow with three options :

All
...
...

Is that normal or are we missing some namefields here ? Also when i set the display language to Dutch, the dropdown arrow then shows these three options :

...
...
...

Looks like the "All" text field got lost in translation.

Transaction confirmation during mixing

I still have transactions created during mixing that wont get confirmed. Some of the PrivateSend transactions are from 45 minutes ago, while more recent mixing transactions do get confirmed.

Mempool

Mempool transactions still vary per wallet (some wallets says 30 transactions, some wallets say 26 transactions). I'm not sure if that is normal behaviour.

InstantSend

Both Automatic IS on Simple Transactions & nomal IS transactions still dont get instant confirmation
(this part has not worked in any stage so far !).

Also when sending normal IS transaction there is no failure notification of IS anymore in the transaction, it just says "Verified with InstandSend" eventhough the IS confirmation failed.

 

[codablock]

Looks like a crash on initial-sync slipped into RC5: https://github.com/dashpay/dash/issues/2507
If anyone seens his node crash on initial sync, revert to rc4 and let it sync past block 264000. Then stop syncing and continue with rc5. tMNs which were already synced when they upgraded are not affected, so you can continue as usual. rc6 will contain a fix for this crash.

 

[TanteStefana]

Hi ya'all again I am confused about something. It took me a while to set up my testnet MN, but in that time, I received 3 mining payouts. The mining payouts went to my first wallet address in my qt wallet which is also the collateral address. I set up my mining rewards to go to a different address and I don't think I've gotten a MN reward yet (finally got it working last night, and the QT wallet says 0 operator rewards.

So.... why am I getting mining rewards? As far as I know, I'm not mining? How do I check to see if I'm mining in my wallet please? It's very strange! I've gotten 3 so far?!

The only other thing I can think of is that I managed to get a MN running non-DIP3 and the spork wasn't set yet, though my server side said my MN wasn't working but of course it was a 0.13 wallet...

Can I check to see if my wallet is mining? Thanks

 

[strophy]

Hi ya'all again I am confused about something. It took me a while to set up my testnet MN, but in that time, I received 3 mining payouts. The mining payouts went to my first wallet address in my qt wallet which is also the collateral address. I set up my mining rewards to go to a different address and I don't think I've gotten a MN reward yet (finally got it working last night, and the QT wallet says 0 operator rewards.

So.... why am I getting mining rewards? As far as I know, I'm not mining? How do I check to see if I'm mining in my wallet please? It's very strange! I've gotten 3 so far?!

The only other thing I can think of is that I managed to get a MN running non-DIP3 and the spork wasn't set yet, though my server side said my MN wasn't working but of course it was a 0.13 wallet...

Can I check to see if my wallet is mining? Thanks

It sounds like you did successfully get a tMN working. The rewards appear as mining rewards because they are taken from the coinbase transaction generated by the miner and shared 50/50 with the masternode (with 10% put aside for the budget). It's the famous 45/45/10 Dash budget split.

Even if you set up your reward to go to a different address, this only takes effect when the Spork 15 is enabled and the deterministic masternode list is in effect. Until then, everything continues using the old system in "compatibility mode".

All of this information is available in the documentation: https://docs.dash.org/en/latest/masternodes/understanding.html#dip3-masternode-changes

 

[TanteStefana]

Thank you @strophy I didn't realize we haven't started using the new system in testnet! As usual, I got confused, LOL. Thanks!

just one more stupid question if I may ... how can I tell if I'm running 0.13.0 rc5 ? I can see it in the qt wallet, but I can't see it with dash-cli getinfo Is there another way to check, or do I have to trust that I successfully installed the latest version? I ask because I did screw something up, and there was a dashd already installed, and I couldn't tell if I upgraded correctly so I did it again slowly and carefully.... thus I think I have the right version running, but is there a way to tell? Thanks

 

[xkcd]

@TanteStefana Here are some ways you can determine the version of your MN

dashd -version|head -1
dash-cli -version

 

[xkcd]

Hi @qwizzie You have mentioned a number of times on this forum issues with IS that are as yet unresovled, but I wonder if you know that it seems to have changed now in 13.0 compared to 12.3. Changes are:
1) IS locked TXes no longer show as 5 confs on the confirmation column on the QT wallet.
2) IS locked TXes are denoted in blue text on the Transactions tab and Overview tab of the QT wallet.
3) IS locked TXes will have a key/check icon when successfully locked.

Points 2 and 3 are transient, ie they will disppear after the TX has enough confirmations. On testnet this is 6 confs and on mainnet this is 24 confs. As real confs are accumulated, you will see the confs column change from a gray ? to a clock face, that fills as it accumulates more confs and turns into a blue check mark after 6 or more confs have been recieved. This is how it works from now on and your IS locked inputs should be immediately spendable. I am looking for someone to test this with, perhaps Agnew will join me.

For your reference, here is the pull request for the new UI https://github.com/dashpay/dash/pull/2433 and here is the parameter that sets the IS lock time, search for consensus.nInstantSendKeepLock on this page https://github.com/dashpay/dash/blob/master/src/chainparams.cpp


IS Locked same as 12.3 5 auto confs.

Hmm! I just tested this for myself and counted the confs, the key/check mark disappeared after 8 (2 + 6) confs, so I am guessing on mainnet it would be 30 (24 + 6) confs. Maybe a Core Dev can confirm this?

 

[qwizzie]

Hi @qwizzie You have mentioned a number of times on this forum issues with IS that are as yet unresovled, but I wonder if you know that it seems to have changed now in 13.0 compared to 12.3. Changes are:
1) IS locked TXes no longer show as 5 confs on the confirmation column on the QT wallet.
2) IS locked TXes are denoted in blue text on the Transactions tab and Overview tab of the QT wallet.
3) IS locked TXes will have a key/check icon when successfully locked.

Points 2 and 3 are transient, ie they will disppear after the TX has enough confirmations. On testnet this is 6 confs and on mainnet this is 24 confs. As real confs are accumulated, you will see the confs column change from a gray ? to a clock face, that fills as it accumulates more confs and turns into a blue check mark after 6 or more confs have been recieved. This is how it works from now on and your IS locked inputs should be immediately spendable. I am looking for someone to test this with, perhaps Agnew will join me.

For your reference, here is the pull request for the new UI https://github.com/dashpay/dash/pull/2433 and here is the parameter that sets the IS lock time, search for consensus.nInstantSendKeepLock on this page https://github.com/dashpay/dash/blob/master/src/chainparams.cpp


IS Locked same as 12.3 5 auto confs.
View attachment 9103

Hmm! I just tested this for myself and counted the confs, the key/check mark disappeared after 8 (2 + 6) confs, so I am guessing on mainnet it would be 30 (24 + 6) confs. Maybe a Core Dev can confirm this?

1) IS locked TXes no longer show as 5 confs on the confirmation column on the QT wallet.

That is because the InstantSend confirmation part is failing, which means it will just confirm through proof of work. This means we get a lock symbol (key figure) indicating that transaction got locked,
and a grey question mark indicating that its not yet confirmed (failure of instant verification) :

2) IS locked TXes are denoted in blue text on the Transactions tab and Overview tab of the QT wallet.
3) IS locked TXes will have a key/check icon when successfully locked.

For your reference, here is the pull request for the new UI https://github.com/dashpay/dash/pull/2433

I'm well aware of these changes, i mentioned the key/check icon a few times now in my previous posts. I also referenced that github pull.

https://www.dash.org/forum/threads/v13-0-testing.41945/page-2#post-202132
https://www.dash.org/forum/threads/v13-0-testing.41945/page-2#post-202292

Points 2 and 3 are transient, ie they will disppear after the TX has enough confirmations. On testnet this is 6 confs and on mainnet this is 24 confs.

UdjinM6 also mentioned that this key icon disappears on testnet after 6 confirmations and on mainnet after 24 confs.

https://www.dash.org/forum/threads/v13-0-testing.41945/page-2#post-202419

As real confs are accumulated, you will see the confs column change from a gray ? to a clock face, that fills as it accumulates more confs and turns into a blue check mark after 6 or more confs have been recieved. This is how it works from now on and your IS locked inputs should be immediately spendable

And no, this is not how it suppose to work from now on.. we are simply missing IS confirmation so far. The locking is working okay, the instant confirmation of InstantSend transactions is not.

InstantSend should confirm a IS transaction within 2 seconds to 5 confirmations, but its clearly failing that both in normal IS transactions and in simple transactions that are converted
to automatic IS transactions through spork 16.

I suspect Testnet currently has difficulty reaching concensus on instant confirmation through its quorums, so it falls back to proof of work.

 

[xkcd]

I just now tested IS with @strophy and it seems to work fine for us, I think the UI has changed though. He sent me 1 tDASH with IS, I got the IS lock and before any on chain confirmations could occur I selected that input from coin control (0 confs) and sent it alone back to him. This I was allowed to do, but it did not auto-IS lock, so it's right working as it should right?

 

[qwizzie]

I just now tested IS with @strophy and it seems to work fine for us, I think the UI has changed though. He sent me 1 tDASH with IS, I got the IS lock and before any on chain confirmations could occur I selected that input from coin control (0 confs) and sent it alone back to him. This I was allowed to do, but it did not auto-IS lock, so it's right working as it should right?

So instead of 5 confirmations in transactions during IS transactions, we now only get that temp lock symbol and transactions fall back to unconfirmed till first proof of work confirmation ?
I definetely dont like that, it feels like going back visually (UI wise).