Thanks for the time succ. 
Spent way more time on this site than I wanted to. My objective: drawing a shape that wouldn’t twist or turn when left to float.
3 Likes
I think they have all the ideas for the parts … they just have to figure out how they go together, so code, debug, code, debug.
2 Likes
There is easier question: how much work left for non-DBC testnet?
1 Like
Very good. 
Yes its important to stress that the clients (online or offline) do the transactions (digital, paper, engraved whatever), the network simply (eventually) validates them.
I have got that right, yes?
If I have got it right then we should be making a very big deal about this.
9 Likes
Can users make several linked transactions and then validate them together?
If not, then it does not matter too much in which proportions work is distributed between clients and network.
Anyway there will be no transactions without user (owner, client) or without network activity.
They can do, as long as they have stored the SpentBook which, in addition, can have as many inputs and outputs as you wish.
Not sure why you are thinking this, if the clients do 99% of work and network 1% then surely that is better than the converse? So you are thinking something I am missing I recon.
1 Like
Is it possible in offline mode to send token from user 1 to user 2, then from user 2 to user 3.
Then in online mode store SpendBook entries and validate these two transaction by network?
It is internals, which users do not think about generally.
If such implemetation gives users more possibilities, it is good.
If it is just optimization, then users may be interested in speed comparison. But what they will compare it with? With unreleased alpha versions of network?
It’s more related to a thing called amplification attack or spam, where it’s cheaper for clients to do stuff than the network to fulfil it. So clients making network do work cheaply is bad, in places where clients do more work/pay more etc. then it’s OK.
Not really, the output DBC needs section sig to be valid so the outputs are not valid until the network validates them. Given the SpentBook entry signed means if you can store that then there is no way to change the transaction.
So I would say grey water here, but potentially there are some neat ideas we could have in this area? We are focussed on the stable impl v1 though, and this may be an extension?
6 Likes
In general, users will see stability as a whole, they can’t link it to implementation details.
So I agree that offloading more work to clients may improve some characteristics of the network, but it will affect users only indirectly.
I think about situations, where whole country gets disconnected for several hours or days.
So if clients can do something on their own, it theoretically can be used to make such events less destructive.
I’ve been out of the loop for some time.
What happened? Where are the test nets?
1 Like
Switch to dbc to increase performance, bug cleaning for a few months now. Waiting on new stable network
3 Likes
I’m sorry but I’m at the point the whole DBC explaination given in this post doesn’t really make sense. What exactly is the point of reissuing a second key from the first ower key and why is it needed and how does it work in plain english? I mean I’m struggling to keep up at this point.
1 Like
Anonymise the transactions that someone receives. Even if you know the public key and scan the Spendbook, the second key allows you to hide these transactions.
3 Likes
Thank you for the heavy work team MaidSafe! I add the translations in the first post 
Privacy. Security. Freedom
8 Likes