My bet is 1-2 week from now (official pub test), but who knows...
V12.1 Testnet Launch Thread
- Thread starter eduffield
- Start date
- Status
I saw your question, just didn't have an answer
qwizzie
Well-known member
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:
Puji Bagus Siswantoro
New member
hello
Aha, good good...I think you are safe, and it was a good bet
AndyDark
Well-known member
No this is just testnet deployment. Public beta will be after the testnet phase, timing based on the testnet results. Needs thorough testing, no need to rush public beta.
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)
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)
halso
Active member
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 ?
halso
Active member
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
camosoul
Well-known member
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