Nothing yet, it is just a placeholder at the moment.

GUI wallet preview.  Wallet is currently under testing (by me and others).  Expect some changes before final release.  Here is a preview of how things look now.

It is a good question but it happened with lot of successful projects in the early days.

I can try to offer a psychological explanation.  It is a known fact from psychological testing that humans perceive a "loss" of a certain fixed cost to be more painful emotionally than the same "gain" in terms of cost.  For example, experiments show that people will expend more efforts to avoid losing a bet of a certain amount than they will in attempting to win the bet for the same amount, and in general have to be offered a higher reward to balance out the potential loss even when the odds are 50/50.  This is called "loss aversion" and if you search that term online you can find out a lot more about it.

I think what we see here is potentially a "reverse loss aversion".   In practice when faced with a project like the Dero Project people see a lot of unknowns and a high potential reward if they "get on board" but also the potential for a loss if they are wrong about "getting on board".  Worse, they fear they will be "scammed" if they get on board and it turns out those fears are right, i.e. "taken for a fool".  The potential loss here is experienced as much more painful than the potential reward for "getting it right", even though the risk/reward ratio is quite low [edit: very low]

Second, a lot of people (though not everyone) see the choice of getting on board or not as a "leap of faith"; they have to have "faith" in the underlying tech or "faith" in the developer team.  In reality this should be a purely rational decision.  You do your research, look at the evidence for the soundness of the project, and make your decision based on your evidence.  This is how George Soros and Warren Buffet made their billions; not by taking "leaps of faith".  But in reality we are emotional creatures and most of us have to see our decisions in emotional terms and experience them that way, too, which makes purely rational decision-making really (really) difficult.

So what happens to those people who see the choice as a "leap of faith" but are not prepared to make that leap, for whatever reason?  Or did make the investment but have a "loss of faith" when they read misinformation or lack of information a certain way and also see prices go down (as they have done recently) but not enough of a loss of faith to simply cut their losses and move on?  Well, some (by no means all, but a small but vocal minority) feel the "closeness" of the painful outcome of making the leap and getting it wrong, and basically express that negative emotional outcome by "FUDDING" the project, that is, by making vocal their fears as a way of offsetting them, of being "right" in at least this way.  No evidence is required for this because evidence (a part of rational decision making) is entirely beside the point.  What matters is vocalising fears and validating them by having others also start vocalising them, without paying much if any attention to evidence.

In case it is not blindingly obvious, I am not endorsing ANY of this.  I am just trying to offer a psychological explanation for a phenomenon a lot of people have been asking about.  It is logical, from this perspective, that a high potential reward, even with low risk, will increase the FUD factor.

So what exactly is the issue here, then?  Perhaps that is as intended, to compensate for the lower emission rate before?  I have read again, and more carefully and slowly than before, Serena and Mojo’s Medium article.  It is clear to me that they have only presented partial information as to what went wrong in the relationship between them and Capt.  After that careful reading, I can say with some confidence that there is no actual evidence of wrongdoing on Capt’s part.  Sure, there is the stuff about possibly using John McAfee, and perhaps using premine on a different schedule than before, and appointing members of DCAB rather than letting the community handle that entirely themselves, and Serena seemed to react (internally) very badly to these things.  But there is not even circumstantial evidence that Capt has acted dishonestly, and certainly not the sort of evidence you’d need to conclude that Dero is a ‘scam’ project, not even close.  Furthermore, it may be that Capt has his own reasons for not liking the way Serena/Mojo handled moderation, or thought they were doing things out of their remit, or any other number of things.  He hasn’t commented on those, but we can assume that he has his own side of the story, completely untold here. 

The unlocking of the premine, and the combination of anon devs and no source yet released, sure these are issues as have been discussed here a lot already, but these issues were already known before Serena and Mojo let themselves loose.  The issues of block times were not raised before, but anyone might have noticed those issues earlier as the data was already there.  The single new piece of information to come out of all that was the McAfee connection.  And it isn’t even certain that this is what Capt was going to do; it was just an idea he was toying with.

I have yet to collate the evidence that Serena and Mojo themselves operated a scam; I still think that is unlikely (though I would like to look at their communications, in combination with Capt’s, through the pumping and subsequent dumping period, to see if there is any circumstantial evidence).  The provisional conclusion I have come to so far is:

- Capt likes to run this project along his own terms and according to his own preferences, and does not run it as a community project in the way that Serena, and possibly Mojo, originally conceived of and perhaps thought they had signed up to when joining the project

- Capt is also willing to change the way things work, adapting to changing conditions, as time goes along; which S/M interpreted as “going back on commitments or ideals” rather than flexibly changing the way the project was run to adapt to changing circumstances (e.g. the ASIC stuff and McAfee)

- Serena, and to a lesser extent Mojo, went beyond their remit in trying to control the way the project was run, according to their ideals rather than Capt’s preferences

- Communication between S/M and Capt started to break down as a result of this, and Capt communicated less with them the more important information of the project, and this made the frustrations of S/M worse

- It got to a point where they found the working conditions intolerable and abruptly left, causing all the mayhem we have experienced

I am not passing judgment on the way they handled this or on them as people, I am just trying to come to an objective viewpoint about what happened.  I also understand less clearly Mojo’s role in all of this; it looks like he increasingly came under the spell of Serena’s thinking, but it is not clear.  As far as it goes though I think the above interpretation fits the facts as we know them.

For us as a community, there are these outstanding issues I think, in no particular order:

1. the locking of premine
2. the changing emission rates
3. the marketing with McAfee and possibly spending part of premine earlier than original stated
4. the main devs anonymity
5. the opening of source to outside audit
6. the forming of a foundation
7. adding Dero to new exchanges


Capt has issued statements on issues 4, 5, and 6.  (Personally I don’t care if devs remain anonymous if all other issues are adequately dealt with, but that’s just me.)  If people are not sure to trust his statements, it would be good to go over all past statements on this thread - *his* statements and not Serena’s and Mojo’s - to evaluate the likelihood of his honouring his commitments in these two regards.  Note that a significant portion of what people complained about when they complained about the project not meeting goals were based on Serena and Mojo’s statements as community managers/moderators, and not Capt’s statements directly.  All that needs to be parsed out.

Regarding 1, 2 and 3, I think we should collectively ask him for some sort of statement on these matters.  Perhaps this is a matter for the DCAB.  Magicsmoker is active here on this thread and is a member of DCAB; perhaps he would like to comment on this?  Regarding 1, Capt has made some efforts to show that premine is intact (as of 12 July I think) but this doesn’t really go far enough; a more robust method of verifying that premine is intact is needed than a dated screenshot, and also some sort of statement about the future locking of stages of the premine as we originally conceived (even if an official statement to the effect that premine will remain unlocked for whatever reasons).

Regarding 7, I think it is too early to worry about this.  We need to wait until other issues are resolved.

What is significance of this?  Why did it happen?  I don’t full understand the Serena allegation that it means coins were “hidden mined” and siphoned off to an unknown wallet.  For this explanation to make sense, there would have to be other evidence.  As it stands, it means emission curve is lower, that’s all.  What is the other evidence concerning this issue?  What is Capt’s statement about it (if any)?

Community Advisory Board was already formed, privately I believe

I wouldn't interpret that as snarky.  I don't think Capt is a native speaker of English.  Substitute "able" for "capable" and there is no tone of snarikiness IMO.  No reason for him to be snarky, either.  It's unmotivated.

There's a lot of FUD on here now.  I know for a fact there are many supporters of this project who understand the technical achievements and the potential, but they are choosing to stay away from here right now.  Hopefully once Atlantis is released and the doubters silenced we can return to some normalcy here, because it used to be a nice place to hang out, and it would be nice if was again.

Wait...  MagicSmoker claimed he was banned?  I'm putting the quotes back in there because I'm struggling to see where he said that.

Actually I think it is better to keep the filenames static with these alpha builds that are updated often.

It makes it easier to update, when you know a new release is out, you just run the same command again

wget http://seeds.dero.io/testnet/dero_linux_amd64.tar.gz

(or whatever works for your version)  without needing to check the new filename and change the command possibly across multiple systems or in a script etc

Well kudos to Capt - a nicer chap than me 

Besides which... the whole point of the testnet is that members of the community are invited to help test the network.  If you don't like the way this is being done you are free to stay away.  No-one is forcing  you to contribute.

The dev team are dealing with some pretty major issues.  To complain that they are not naming the files correctly according to some convention you like, especially when you can easily see how old the files are - they are all datestamped so verifying whether you have the latest version is as easy as checking whether a new version has been uploaded since you last checked - and especially given that the team alerts everyone when a new version is ready to be downloaded (if you are alpha testing you should be on the slack or discord testnet channels) - is maybe getting the priorities a wee bit in the wrong order...

Ok, fine, no problem, not trying to pick a fight.  Just trying to offer a rational explanation for observed behaviour.  I imagine the dev team are working under extreme time pressure right now and are just not doing stuff they consider non-essential.  However if you have different explanation for observed behaviour feel free to offer it. 

I think when you are in alpha version and almost constantly producing new builds, it just slows you down keeping track of file naming versioning  

Not only that, I made a mistake.  It is a dual processor system, the L3 cache is per processor, not total, so it is 55 x 2 = 110 MB, i.e. 55 threads by the 2MB rule which is larger than the total number of threads available so 44.

I'm not sure this is good advice for all cases.  I have a 44 core machine with 55 MB of L3 cache.  Mining with 27 threads (55 / 2) I get about 62% of the hashrate I get by mining with 44 threads.  (I have turned hyperthreading off, so have not tried with 88 threads, but I doubt that would see better performance, and it could well be worse.)

Thanks MagicSmoker for the guide, I think people will find that very useful.

Note that the Windows way of syncing to a timeserver could cause problems.  If you find that even after checking to make sure that Windows is set to update the clock, and has (it claims) updated the clock, you still get complaints about the clock being out of sync from the daemon, come back here and we will try to solve that problem.

It's not that simple.  "Buy the rumour, sell the news."  Also, ASIC miners may choose this time to unload their bags once they realise for sure that mining is over on Dero.  So there might be increased supply.  At the same time lots of Dero supporters will stop being on the markets where they have been swapping other coins they have been mining for Dero, and turn their attention back to mining Dero, so there might be reduced demand on the exchange.  So do not be surprised if there is a price drop, even a significant one.

At the same time, it could go the other way.  Lots of people may be waiting on the sidelines to buy in once they have seen the Atlantis proof of the pudding.  Times like these are times of uncertainty for markets, not certainty.  I am not making predictions, just urging caution.

What's with that earlier quote that Inlite brought up though Serena:

"Our devs even built an asic-resistant algo generator that can produce hundreds of new algos/second."

In retrospect it seems like it was at least an odd thing to have said, and isn't a statement you're currently holding to.  Seems like it needs a bit of explanation.  From my understanding, there are two possibilities:

(1)  There is/was an algo generator that could change the algo as often as you like - but each change would still require a daemon update and a soft fork.  Basically it plays with some parameters and the new algo is fairly trivially different from the old one, but this change was at the time thought to be enough to throw ASICs off the network until a new hardware update of the ASIC (new ASIC) was developed.

(2)  The algo referred to is a POW algo that could change itself hundreds of times a second and would in some way be self-replicating and ASIC resistance without needing any daemon updates or forks

My impression is that (2) seems like science fiction and can't be what you meant.

That leaves (1).  Producing a new algo that differ from the old by just a few different parameters isn't really producing a new algo so that is stretching the facts a bit, and in any case, ASIC mining is more sophisticated than you then realised and/or has become more sophisticated, and you now realise that these kinds of trivial changes are not sufficient to build ASIC resistance anyway, since ASICs can be built to accommodate them.  Given that the new algo (Atlantis / Dero-DAG) is new and therefore there will be no ASIC for it for a while at least, you want to just wait to do more research on this before making further commitments.  But the new algo is not inherently ASIC resistant; there is nothing about it that will make it particularly difficult for bitmain to develop a new ASIC for it given a bit of time, just as they have done for other CN algos.  Therefore you don't (any more) claim native ASIC resistance, but you are open to doing this going forward, if it proves technically possible.

Comments?

What's to stop the network from becoming infiltrated by "bad actors" who upvote each other even though they are producing energy from coal?