Hey @Scorch, will answer this in a bit, need to brush the teeth of a little boy here now 
13 Likes
Going straight to the question of setting the reward key:
The internal reward cmd RegisterWallet is used for the very first register when a node joins the network.
There is no client API for updating it currently, but there is another internal cmd called SetNodeWallet, which would be called when that API is in place. So I suggest using that one instead, the same way you described above, it should work. Just let me know if any issues 
So, to the first questions:
Rewards are more or less done and working; when a node gets relocated the section actors completes a transfer from the section funds to the reward key. But there are a few kinks with the messaging since the recent changes are so new. We’re picking them off one by one, and then we will be able to stress the rewards feature a bit as well and fix what ever shows up, before we’re ready to go with testnet.
21 Likes
You’re a legend, thanks! I ran across the SetNodeWallet command at some point, but misinterpreted the difference while reading the source.
I’ll give it a shot and come back if I hit a hitch.
Update: Currently works for Elders as described. Will continue tinkering, but I’ve got something to go on now 
15 Likes
Wonderful update Maidsafe team! Thanks as usual for your hard work. 
13 Likes
What is the approach to rewards?..
I was just wondering it could be made more complex than needed. Tracking everything and making rewards absolute relative to work done, could be a mare and liable to strain and brittle errors. I was just out for a long walk and pondering the complexity of economics and reflecting that businesses sign up workers and pay them not do not waste time and energy navel gazing for the exact reward deserved because over time the assumption is fair reward for fair work - and typically by banding, rather than more refined. The important moment for tracking, is the customer pays their bill for the work they request… payment to worker can be less exacting.
Perhaps potential to relax the complexity as an optimisation of what is worth the effort. The priority must surely be to serve the user and write data as fast as possible… the finance and HR departments in any organisation are not the sharp end of scalpel and matter less in the immediate short term - but are important more over the medium and long term. In the case that a node is expected to be present at time+1, perhaps delay in reward is no unreasonable… and even a reduced average payment across the board wold work well?..
It could be that I’ve missed more talk of this but it’s less interesting aspect too but perhaps needs a thinking round the houses, if there are alt options for making it simpler.
2 Likes
Hey @davidpbrown ,
The reward calculation is dead simple. Every time a node is relocated, it gets a payment at the dst section corresponding to its age and the network size at that point (there’s an assumed correlation between network size and the token value, thus reward payout decreases with network size).
The more complex part, what has been under work for some time now, is the decentralized nature of the section funds, and a robust handling of them (reward payout and transition of them as Elders change). Such payout is what’s been running end to end successfully for the first time last week, while transition was seen a few weeks earlier.
Edit: Some clarification.
23 Likes
How about “Keep Calm and Get SAFE”?
4 Likes
really catchy!
2 Likes
DevUpdates look like a neverending story. So many years have passed and nothing reached production. Do you have concrete plans to deploy something usable, where people can deploy their apps and start creating value for the users, without fear that it will disappear in several weeks because of new test network?
2 Likes
Yes, testnet soon ish, beta 6 weeks to 6 months or longer after that.
3 Likes
Test nets with PARSEC, half a year ago or so, were literally being released. But PARSEC was deemed too slow. You might call that utilizing the test net to find something wrong; test net success!
Now the team are saying the new test nets are finally close, without PARSEC, and with AT2 (way faster and less bulky than PARSEC) along with a whole slew of other 3-4 letter tech names/concepts that make my head spin. But the important part is that these parts work much more fluidly with each other, and the team is saying that there shouldn’t be another huge PARSEC incident.
You can only be optimistic—and paradoxically battle-hardened with experience in a field that no other project has even come close to experiencing—so as to wait patiently with fervor that results will start happening.
Also I’m pretty sure David meant “Test nets in 6 weeks at maximum” / “Beta more like 6 months [at maximum]”. I’m not so sure about the 2nd “at maximum”. IMO the best case scenario i.e. via successful test nets will be when people start writing home about them; then, bam, suddenly Beta.
10 Likes
I expect a testnet within 6 weeks and then head to beta (we need upgrades though). Beta is not gonna be less than 6 weeks and could be 6months or more away. We don’t know yet, but these are my personal opinions given the state of play just now. I am more confident as the team is more cohesive and communicative now. We are more a unit and see what each other are doing.
It’s software though and until it’s there, then all we can really say is that it’s coming
27 Likes
How about Fleming?
That should be the testnet looking stable. There may be more than 1 of them. It’s likely there will be but I only expect bugs, not bits we have short circuited. The data types are getting some attention but that’s nice and smooth.
12 Likes
Oops! Browser section added at the bottom of the OP 
9 Likes
Thank you for the heavy work team MaidSafe! Challenge reality itself!
I add the translation into Bulgarian in the first post 
11 Likes
