V12.1 Testnet Launch Thread

Status
Not open for further replies.
AjM said:
https://www.dash.org/forum/threads/august-2016-development-update.10018/
Evans message was Aug 2, so, pub testing is 2 weeks late.
Click to expand...
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 said:
Will this also negate the previously mentioned reindex by pulling chain again in new root working directory?
Click to expand...
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?
 
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 :)
 
Last edited:
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
 
halso said:
Any news on when 12.1 testnet will be released?
Click to expand...

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
 
AjM said:
Umh, so i lost my bet, typical:)
Click to expand...

:(

well we've been testing solid for last 5 days so technically it's on testnet! you just need to get your hands dirty to join in. sorry about that. it will be easier soon with the docker process. there's still some issues to fix so the focus is on that. it's coming along good though, things are coming together :)
 
AndyDark said:
:(

well we've been testing solid for last 5 days so technically it's on testnet! you just need to get your hands dirty to join in. sorry about that. it will be easier soon with the docker process. there's still some issues to fix so the focus is on that. it's coming along good though, things are coming together :)
Click to expand...
No problem, i mean typical for me when i bet for something.;)
 
AndyDark said:
:(

well we've been testing solid for last 5 days so technically it's on testnet! you just need to get your hands dirty to join in. sorry about that. it will be easier soon with the docker process. there's still some issues to fix so the focus is on that. it's coming along good though, things are coming together :)
Click to expand...
can you explain what docker is? Are the remaining issues with sentinel? if so, can we delay sentinel until 12.2, and release 12.1 now?
 
halso said:
can you explain what docker is? Are the remaining issues with sentinel? if so, can we delay sentinel until 12.2, and release 12.1 now?
Click to expand...

Hey @halso

Docker is an optional setup process that will make setting up 12.1 Masternodes easier and more automated for users who want that https://www.docker.com/customers. Creation of the manual / docker setup process for 12.1 masternodes is being lead by MooCowMoo who made the DashMan setup process.

Re: Sentinel - a few people have asked about Sentinel and why 12.1 has been late.

Sentinel is an autonomous agent running on 12.1 masternodes that automates governance tasks designed originally by Evan and taken forward and maintained by Nathan Marley: https://github.com/nmarley/sentinel

Few reasons for the delay:

1. Feature scope - Sentinel is essentially a component of Evolution code that will grow into DashDrive in a future release. we had to balance between wanting to develop advanced uses of Sentinel with the need to release 12.1 early. Often the 12.1 release lost in that equation until recently we feature locked and decided to run with the current because of the delay to 12.1. It means 12.1 isn't really taking full advantage of all the features, Sentinel is just replacing the existing governance system, and automating tasks like budget finalization and Dash Core (as it's called now) is agnostic to governance objects making it easier to build out the features we want in the future.
2. Because Sentinel is a new component that runs on a Masternode, this release is more than just updating the core client as usual and I don't think we factored in all the various work outside of that (like deployment, maintenance, op sec) to the original time estimates and which is a lot of the work over the last week - Sentinel needs to be easy to deploy and setup for MNOs.
3. Testing - don't think we factored in enough time, again testing with 2 components in the mix is more involved than the usual core client testing
4. Teams - this is the first time the core team and evo backend-team really got together and make their code work together (because a lot of Evo code isn't just in the core client). Now we are pretty efficient at working together and that is good for the future too.

So basically Sentinel is new software for future use that has added overheads in different angles to get the first version working and different teams coming together. The good news is we've passed those hurdles and can now do the test phase through to mainnet release. There's also a huge amount of improvements in Core that have built up too so it should be a good milestone release all round to bring core up to date and lay the foundations we need for the Evolution alpha.

In terms of where we are right now this is the notes from yesterdays meeting which explains it faster probably:

upload_2016-9-21_13-0-55.png



Cheers,
Andy
 
AndyDark said:
Hey @halso

Docker is an optional setup process that will make setting up 12.1 Masternodes easier and more automated for users who want that https://www.docker.com/customers. Creation of the manual / docker setup process for 12.1 masternodes is being lead by MooCowMoo who made the DashMan setup process.

Re: Sentinel - a few people have asked about Sentinel and why 12.1 has been late.

Sentinel is an autonomous agent running on 12.1 masternodes that automates governance tasks designed originally by Evan and taken forward and maintained by Nathan Marley: https://github.com/nmarley/sentinel

Few reasons for the delay:

1. Feature scope - Sentinel is essentially a component of Evolution code that will grow into DashDrive in a future release. we had to balance between wanting to develop advanced uses of Sentinel with the need to release 12.1 early. Often the 12.1 release lost in that equation until recently we feature locked and decided to run with the current because of the delay to 12.1. It means 12.1 isn't really taking full advantage of all the features, Sentinel is just replacing the existing governance system, and automating tasks like budget finalization and Dash Core (as it's called now) is agnostic to governance objects making it easier to build out the features we want in the future.
2. Because Sentinel is a new component that runs on a Masternode, this release is more than just updating the core client as usual and I don't think we factored in all the various work outside of that (like deployment, maintenance, op sec) to the original time estimates and which is a lot of the work over the last week - Sentinel needs to be easy to deploy and setup for MNOs.
3. Testing - don't think we factored in enough time, again testing with 2 components in the mix is more involved than the usual core client testing
4. Teams - this is the first time the core team and evo backend-team really got together and make their code work together (because a lot of Evo code isn't just in the core client). Now we are pretty efficient at working together and that is good for the future too.

So basically Sentinel is new software for future use that has added overheads in different angles to get the first version working and different teams coming together. The good news is we've passed those hurdles and can now do the test phase through to mainnet release. There's also a huge amount of improvements in Core that have built up too so it should be a good milestone release all round to bring core up to date and lay the foundations we need for the Evolution alpha.

In terms of where we are right now this is the notes from yesterdays meeting which explains it faster probably:

View attachment 2681


Cheers,
Andy
Click to expand...


So is it possible to hack the sentinel python script to start voting using numbers?

Where the votes are preserved, in the blockchain or in a simple database?
 
Status
Not open for further replies.
Back
Top