My bet is 1-2 week from now (official pub test), but who knows...
V12.1 Testnet Launch Thread
- Thread starter eduffield
- Start date
-
- Tags
- 12.1 masternode trezor testnet
- Status
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.
Pablo.
I think you are safe, and it was a good betIs that a fact?
One week, September 18 and i may loose my 'bet'
Aha, good good...I think you are safe, and it was a good bet
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)
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).
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
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:
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:
Will this also negate the previously mentioned reindex by pulling chain again in new root working directory?EDIT: actually v0.12.1.x even uses another folder - DashCore - so chances to break mainnet blocks are ~zero
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.
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?
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:
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
Now this is why I want to see multi session continue, because imagine this:
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:
smth like this https://github.com/dashpay/dash/pull/909 ?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.
Any news on when 12.1 testnet will be released?smth like this https://github.com/dashpay/dash/pull/909 ?
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