OR we have to trust the network to tell us if the update is worth it. The update may come from someone we don’t know and therefore can’t trust but if the network can run the update in parallel, benchmark, test, then perhaps we can trust the networks decision. That is all easier said than done though 
3 Likes
What if you had to release a version that could not be updated or fixed outside the choice not to use it?
If there are time machines might be harder to seal the nework, will always be an arms race anyway?
Is a consensus lock good enough when picking that lock will pick all locks? Seems like a upgrade is a sealed fork (one that can"t be upgraded) that people migrate or somehow bridge work over to.
But how do we know we can trust any version asside from consensus double check of code plus time?
An update may appear to function properly, but introduce deanomyzing back doors that some government has forced a software team to include. Any updates will be suspect in that regard, which is why the bitcoin model is rather nice. The update is put out there for all to see and discuss, and is installed manually by those who feel it is worth it.
Manual updates should keep state actors from applying such pressure in the first place, since shenanigans will be quickly identified by the community (hopefully). Automatic updates seems like it would invite state actor attention to the software team(s).
6 Likes
Or we rely on a world wide network of developers to give their opinions of the update. You know decentralised. OR we do both The network code says yes and The devs world wide say yes
@lynx, I think you asked a question with the answer in mind and missed the alternatives.
Yes exactly. It may work better than previous updates but introduce backdoors or even malware, honestly I doubt any automatic system short of a full blown (not existing) AI could have a chance. Although it should be possible for the code to automatically give a tick for required functionality is better than current, but cannot be sure if some backdoor introduced by changing one or two lines of code.
And then we have NEW functionality. How is current software supposed to evaluate it? @Jean-Philippe
2 Likes
One way is a double update. So put in the new code in version 2, but that code is for when version 3 is available. So when we update to version 3 then the code is there to understand it. This also allows future upgrades to be know before they happen and also allows a version 2 node to understand version 3 data etc.
1 Like
And the issue is that a bad actor version could do this too. Under the guise of adding some useful functionality of course.
So how is the network code supposed to distinguish between the 2?
Are we then back to the decentralised developers giving their tick of approval for any proposed upgrade?
Yes, I agree, but I was answering the specific point of how to have the current network “see” new code in the future. That allows an upgrade path, but it does not have any effect on evaluating that code, yet 
2 Likes
Unfortunately I forgot to add the bit about what I said above. Sorry.
1 Like
As Fleming will involve some basic version of data storage and farming, how we can get initial test coins ?
3 Likes
Well there could be a few methods. Maybe similar to the invite, but get a certain amount of test coins.
For alphas test coins will not survive past the alpha version and so gifting some coin so others not in the forum so they can create accounts should not be an issue or a problem to those on the forum to gift a fraction of a coin.
Maybe each vault started will be gifted a coin for being a node and then earn farming rewards.
Maybe by asking
Maybe per IP address
There are a number of ways and each will have some problems so it will be a case of working out the easiest for both the dev team and the users.
We will probably be told when or just before the alpha is released for testing.
5 Likes
We have got answer in dev update today:
1 Like