v13.0 Testing

qwizzie

Well-known Member
Aug 6, 2014
1,802
952
183
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).
 
Last edited:

qwizzie

Well-known Member
Aug 6, 2014
1,802
952
183
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).
 
Last edited:

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,871
1,863
1,283
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?
 
Last edited:

qwizzie

Well-known Member
Aug 6, 2014
1,802
952
183
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.

 
Last edited:

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,871
1,863
1,283
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.
 
Last edited:

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,871
1,863
1,283
"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 :p

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

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,871
1,863
1,283
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?
 
Last edited:

xkcd

Active Member
Masternode Owner/Operator
Feb 19, 2017
356
329
133
australia
mnowatch.org
Dash Address
XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
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

Grizzled Member
Foundation Member
Mar 9, 2014
2,871
1,863
1,283
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

Active Member
Mar 29, 2017
100
154
93
37
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

Well-known Member
Aug 6, 2014
1,802
952
183
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.
 
Last edited:

codablock

Active Member
Mar 29, 2017
100
154
93
37
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

Grizzled Member
Foundation Member
Mar 9, 2014
2,871
1,863
1,283
Hi ya'all again :p 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

Administrator
Dash Core Group
Dash Support Group
Feb 13, 2016
786
496
133
Hi ya'all again :p 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

Grizzled Member
Foundation Member
Mar 9, 2014
2,871
1,863
1,283
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 :D
 
Last edited:

xkcd

Active Member
Masternode Owner/Operator
Feb 19, 2017
356
329
133
australia
mnowatch.org
Dash Address
XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
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.
upload_2018-11-29_17-57-6.png


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?
 
Last edited:

qwizzie

Well-known Member
Aug 6, 2014
1,802
952
183
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.
 
Last edited:

xkcd

Active Member
Masternode Owner/Operator
Feb 19, 2017
356
329
133
australia
mnowatch.org
Dash Address
XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
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

Well-known Member
Aug 6, 2014
1,802
952
183
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).
 
Last edited:

xkcd

Active Member
Masternode Owner/Operator
Feb 19, 2017
356
329
133
australia
mnowatch.org
Dash Address
XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
Hi @qwizzie I did some more testing with @strophy and yes, it appear IS works correctly, though the UI is changed. I sent him >4 inputs to avoid the auto-IS and he attempted to send back to me before getting a confirmation, when he went to his coin control, the coins where not there, so he is unable to use them. If however, I send him coins that are IS locked, they appear in his coin control and he is able to send them back to me. So, I gotta conclude that IS is working correctly, but just the UI has changed. Try some tests for yourself. Be careful of one thing however, if you send to yourself, or attempt to use change from a TX you just created, you can spend the zero conf DASH. This seems to be a feature from Bitcoin that allows transaction chaining and is OK to do so long as you control all the inputs, specifically the first one.
 

qwizzie

Well-known Member
Aug 6, 2014
1,802
952
183
Hi @qwizzie I did some more testing with @strophy and yes, it appear IS works correctly, though the UI is changed. I sent him >4 inputs to avoid the auto-IS and he attempted to send back to me before getting a confirmation, when he went to his coin control, the coins where not there, so he is unable to use them. If however, I send him coins that are IS locked, they appear in his coin control and he is able to send them back to me. So, I gotta conclude that IS is working correctly, but just the UI has changed. Try some tests for yourself. Be careful of one thing however, if you send to yourself, or attempt to use change from a TX you just created, you can spend the zero conf DASH. This seems to be a feature from Bitcoin that allows transaction chaining and is OK to do so long as you control all the inputs, specifically the first one.
Strange that dev-team did not mention this from start (or responded to my many posts on this matter) as it is a rather large visual change when using InstantSend. This will definetely need some explaining once this hits mainnet or it will just create a lot of confusion.
 
  • Like
Reactions: xkcd

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,871
1,863
1,283
Thank you again @xkcd I couldn't find time to work on this until just now, I was running the correct version, now I need to update! LOL

Can't wait to see how spork 15 works out!
 

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,871
1,863
1,283
Aw, pooty! Forgot to continue mixing after the upgrade, so close to 100% yet so far! LOL
 

codablock

Active Member
Mar 29, 2017
100
154
93
37
We've enabled spork15 and it got activated on block 277730. We've entered stage 8 now and are running in full deterministic mode now :)
We already foud a few issue which we'll fix in RC7, but testing can generally continue (except for proposal testing...)
 
  • Like
Reactions: TaoOfSatoshi

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,871
1,863
1,283
I see a user issue: First, once DIP3 is locked in, the My Masternode tab shows "last seen" from that point and never updates again (is sentinel dead then?) And I feel this will alarm a lot of MNOs 2nd is the DIP3 tab requires a MNO user to insert search words/numbers to see how their MN is doing as you can only find your PoSe score there, or last paid block, or future pay block#s You can also check there if your payee address is correct and operator rewards are correct. This is possibly good info to keep an eye on, as who knows if someone can hack you? Change the payee, etc...

@codablock I may see a solution. 1. have the DIP3 tab give an auto filter check block for what's in your MN.conf so you can quickly filter your personal node/nodes for that info rather than typing them in one by one, and 2. give a final readout of "no longer needed" in the "last seen" spot of the "My Masternode " tab?
 

DAOMN

Member
Mar 30, 2017
76
25
58
I am still a noob, but I just wanted to pop in and thank all of you who are working your a$$€s off on this very ambitious project. Wow, just wow!
 
  • Like
Reactions: xkcd

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,871
1,863
1,283
Join in on the fun, @DAOMN :D I'm off to a dinner, but if you want to spin up a MN I'm sure we can all pitch in some t-dash :D I have about 240 I can send :D Best way to see what is going on is to participate in Testnet. Although I'll be gone a few hours, I'm happy to walk you through it all, I ask the dumbest questions all the time, so no question is too stupid for me to help out :D

To start, first make sure you're not running your own full core wallet, if you are, wait for me :D
second, download the windows.zip file at the link on the first page and pull out dash-qt, put it somewhere easy to find.
You can start it up, then shut it down, and find your .dashcore folder in c:/Users/yourname/AppData/Roaming/DashCore and open dash.conf with notepad++ (right click and choose open with notepad++) This is a very useful tool, and based off windows notepad :) Free to download :)

Just add testnet=1 on the first line, then save, close, and restart the dash-qt wallet.

Now you have to wait an hour or three for it to sync, then we can have fun :)
 
Last edited: