• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

V12.1 Testnet Launch Thread

Status
Not open for further replies.
Given the latest testing release is dated Aug 17th, I wouldn't say his estimate was off. That said, I'm really hoping to see a new testnet release this weekend!
My bet is 1-2 week from now (official pub test), but who knows...
 
Does anyone know what the new "secret" features we were supposed to get are? Have these been released yet? Asking because I haven't been to testnet in a while.

Pablo.

So far i can tell they updated Dash to latest Bitcoin, integrated Sentinel, optimized the code and they are in the proces of adding / testing superblocks.
At the time Sentinel was not public, so it could refer to that as secret feauture .. i'm not sure.
I guess we just have to wait and see.
 
Last edited:
Yep, I'm also subscribed to their Github, however Sentinel has been a known quantity for months. I wonder if that really was what they meant.

Pablo.
 
some details to make this easier :
Tx to spiralus for the writeup and pointing this out

* Default Dash network protocol listen port is 19999 (instead of 9999)
* Bootstrapping uses different DNS seeds.
"test.dnsseed.masternode.io","testnet-seed.darkcoin.qa","testnet-seed.dashpay.io"
* A different value of ADDRESSVERSION field ensures no testnet Dash addresses will work on the production network. (140 rather than 76)
(On 12.0.x is was 139 and was changed to 140 for 12.1.x)
* The protocol message header bytes are 0xcee2caff (instead of 0xbf0c6bbd)
 
some details to make this easier :
Tx to spiralus for the writeup and pointing this out

* Default Dash network protocol listen port is 19999 (instead of 9999)
* Bootstrapping uses different DNS seeds.
"test.dnsseed.masternode.io","testnet-seed.darkcoin.qa","testnet-seed.dashpay.io"
* A different value of ADDRESSVERSION field ensures no testnet Dash addresses will work on the production network. (140 rather than 76)
(On 12.0.x is was 139 and was changed to 140 for 12.1.x)
* The protocol message header bytes are 0xcee2caff (instead of 0xbf0c6bbd)

i'm still a little confused. Does that mean yes? it is safe?

Thanks in advance.
 
i'm still a little confused. Does that mean yes? it is safe?

Thanks in advance.

save as in how ?
start new wallet - do the testnet things nessacery in QT and ready to go
I do not understand the question - what does your MAC has to do with this ?
 
save as in how ?
start new wallet - do the testnet things nessacery in QT and ready to go
I do not understand the question - what does your MAC has to do with this ?
Apologies, let me rephrase. Is it safe to run main net and test net on the same machine (in my instance, a mac).
 
Apologies, let me rephrase. Is it safe to run main net and test net on the same machine (in my instance, a mac).

Testnet uses sub-folder and should not intersect with mainnet wallet in any way. v0.12.1.x binaries are more or less stable so should be pretty safe. However reindex is required at first start of v0.12.1.x so please be careful and do not run it on mainnet (accidentally) or you'd have to reindex mainnet blocks via v0.12.0.x to make it work again.

EDIT: actually v0.12.1.x even uses another folder - DashCore - so chances to break mainnet blocks are ~zero :)
 
That's weird, last night I started my two tMNs with the MN tab, my remote MNs didn't actually say they started, but the wallet assured me they were started, so I just left everything as is. Now I just noticed that they never did start up, and my wallet shows them as having not started.
It looks like the "success" message is merely a broadcast success, essentially just saying that you have a functioning dash.conf/masternode.conf, and they passed all the sanity/collateral check tests and the broadcast was "success." Zero communication actually occurs with the remote/MN daemon. So, the "success" message is a bit deceptive and really has nothing at all to do with the MN being activated or not.

It'd be nice if there was true, closed-loop active feedback, where the remote MN daemon pings back the client with ack (eh, not the best idea), or (better idea) messages the network and the client notices, saying that the remote now recognizes it's MN status, without having to monitor all the remote debug.log files to see it. Maybe. Kinda like monitoring for IX lock messages... In fact, it looks like most of this is in place, it just doesn't reach the UI in an appropriate manner. Shouldn't be hard to do...

Currently, the broadcast is all we get, and if the daemon doesn't go active, it falls off in 70+ minutes. Dashninja can help the operator notice this because we know ping times, and if your node's "last seen" time is 30 minutes, you might get it fixed before having to rebroadcast.

So, there's workarounds on mainnet... But it would be better if there was actually some positive correlation that didn't require para-network services and logfile ogling...
 
Last edited:
Status
Not open for further replies.
Back
Top