V12.1 Testnet Launch Thread

Status
Not open for further replies.

AjM

Well-known Member
Foundation Member
Jun 23, 2014
1,341
575
283
Finland
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...
 
  • Like
Reactions: AndyDark

qwizzie

Well-known Member
Aug 6, 2014
1,628
780
183
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:
  • Like
Reactions: MangledBlue

fible1

Well-known Member
Dash Core Team
Masternode Owner/Operator
May 11, 2014
710
722
163
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.
 
  • Like
Reactions: MangledBlue

AndyDark

Well-known Member
Sep 10, 2014
353
705
163
Are we talking about the public Beta?

Pablo.
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.
 

fible1

Well-known Member
Dash Core Team
Masternode Owner/Operator
May 11, 2014
710
722
163
Sounds reasonable :).

Pablo.
 

tungfa

Administrator
Dash Core Team
Moderator
Foundation Member
Masternode Owner/Operator
Apr 9, 2014
8,902
6,729
1,283
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)
 

halso

Active Member
Apr 27, 2016
439
235
113
Sydney, Australia
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.
 

tungfa

Administrator
Dash Core Team
Moderator
Foundation Member
Masternode Owner/Operator
Apr 9, 2014
8,902
6,729
1,283
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 ?
 

halso

Active Member
Apr 27, 2016
439
235
113
Sydney, Australia
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).
 

UdjinM6

Official Dash Dev
Dash Core Team
Moderator
May 20, 2014
3,637
3,536
1,183
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 :)
 

tungfa

Administrator
Dash Core Team
Moderator
Foundation Member
Masternode Owner/Operator
Apr 9, 2014
8,902
6,729
1,283
Apologies, let me rephrase. Is it safe to run main net and test net on the same machine (in my instance, a mac).
the boss beat me to it :rolleyes:
 

camosoul

Grizzled Member
Sep 19, 2014
2,261
1,130
1,183
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:

camosoul

Grizzled Member
Sep 19, 2014
2,261
1,130
1,183
https://www.dash.org/forum/threads/august-2016-development-update.10018/
Evans message was Aug 2, so, pub testing is 2 weeks late.
Yeah, but I think there's a whole bunch of stuff being added to 0.12.1.0 that was not originally meant to be in 0.12.1.0 at the time he made that statement.

Also, bringing some of the 0.12.2.0 guys up to speed is probably sucking up a lot more time than expected.

Evolve, adapt, improve, overcome...

I hope 0.12.1.0 makes me eat some of my words. Hoping for blockchain-only mini-DAPI pilot and a budget that is less retarded...
 
Last edited:
  • Like
Reactions: AjM

camosoul

Grizzled Member
Sep 19, 2014
2,261
1,130
1,183
EDIT: actually v0.12.1.x even uses another folder - DashCore - so chances to break mainnet blocks are ~zero :)
Will this also negate the previously mentioned reindex by pulling chain again in new root working directory?
 

UdjinM6

Official Dash Dev
Dash Core Team
Moderator
May 20, 2014
3,637
3,536
1,183
Will this also negate the previously mentioned reindex by pulling chain again in new root working directory?
For mainnet you mean? Yes, if you start from scratch, no, if you first copy Dash folder to DashCore (like I did) to speed things up and save some bandwidth. This will allow you to use both 0.12.0.x and 0.12.1.x on mainnet separately but I would highly encourage you not to do so unless you completely understand what you are doing or at least have wallets.dat from both folders backed up properly.
 
  • Like
Reactions: camosoul

camosoul

Grizzled Member
Sep 19, 2014
2,261
1,130
1,183
Inclusion of an abstain is nice, but it's usefulness will be determined by how null is then handled...

A topic that's lost the limelight, that kinda concerns me... With multisession mixing going much faster, will DS (PS) become vulnerable to timing analysis? TrafficIn <---> TrafficOut will be easier to correlate due to not being spread out and random. The weird and unpredictable combining hesitations historically in IX actually added quite a lot to it's obfuscation because it did not draw upon any external entropy source and was kinda weird and unpredictable all on it's own, kind of like what adding white noise could do for TOR. Could it be that fixing what stupid, impatient users perceive as a failing, might actually break it? Or at the least, reduce it's effectiveness? Making it run fast and smooth may actually be a bad thing?
 
Last edited:

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,862
1,854
1,283
I don't think so, camo, as there is no tell tale timing to be done. The coins are mixed, normally well before use. So lets say you took your mixed coins and bought something at Overstock.com. Those coins you used could be traced back to you, by Overstock or possibly a 3rd party such as a government spying on Overstock's wallets. So, sure, you've exposed, say 3 10's and 2 one's.

Now this is why I want to see multi session continue, because imagine this:

You mixed with 3 people, and if they can trace a denomination to you, and to another person, they can find out the 3rd person, who might need privacy. (now, I do understand that to get both pieces of info out of 3 from the same mix is pretty hard, but still, it bothers me) I'd still like to see 2 or 3 rounds done just in case. With the future inability to trace ip addresses or wallet origin, the plan was to do only one round. Of course if there are more people mixing, no problem. Also, if it's free, and the system can re-mix constantly, without user interaction, that'd also be really cool (with lots of inputs at a time > ie: more than 3).

Actually, that doesn't matter does it? Thinking on it, they still won't know where the coins came from. My mind has been thinking this wrong for a long time. There is still a wall. All they can know is what was done after the mixing, not who owned what before still..... so yah, the mixing is pretty solid.

But as far as timing, it doesn't help to know when a person actually mixed via when they spent, that info is there, but means nothing. You can see when they mixed their spent output by simply looking at the blockchain, but you can't see where it came from once you hit that mixing wall.

Basically, you're creating freshly minted coins as far as it's history is concerned. What you do with those coins, can be seen by the recipient, and anyone that recipient shows that info to. If they have no info on you, then you're still invisible, but if they have to mail something to you, or email to you, etc... they obviously have that, and normally that's not a problem :)
 
Last edited:

camosoul

Grizzled Member
Sep 19, 2014
2,261
1,130
1,183
I wasn't suggesting that multisession should be avoided. I was just suggesting that there might be some considerations to bring it back to being a mess on purpose. :p
 

AndyDark

Well-known Member
Sep 10, 2014
353
705
163
Any news on when 12.1 testnet will be released?
Still fixing some final Sentinel issues. I think core is ready though.

It's actually on testnet already but the MN setup process is unfriendly and involves building code from git. If you want to get involved today i can post instructions.

@flare is working on the docker process that will enable easy setup which should be ready this week I think but he can configm. We might want to delay 'official' testnet release until then, but you can get involved now if you want.

Andy
 
Status
Not open for further replies.