Back again soon, some dependency issues to sort, just a few moments. This will be followed with safe_farming in due course 
This may need to wait until tomorrow to publish, we have to update a few crates to remove git dependencies.
21 Likes
Jaw is on the floor right now. Amazing progress. Deduplication is in vaults now as well thanks to Rav. Things are looking solid @maidsafe!!!
Routing @adam has been coding like a boss too.
20 Likes
That’s his normal speed, he is approaching infinite mass at times 
Seriously though, he is amazingly quick.
25 Likes
Hi Alexsling, would you care to add a few lines in Introduce Yourself so we can know a little bit more about you?
A few lines is fine, nothing too cheesy…
6 Likes
Stamps feet, throws tantrum “Want it NOW!!!”
4 Likes
Done …
11 Likes
All transfer will be stored?
/// History of transfers for an identity.
#[derive(Debug, Clone, PartialEq, Eq)]
pub struct History {
id: Identity,
balance: Money,
incoming: Vec<Transfer>,
outgoing: Vec<Transfer>,
transfer_ids: HashSet<TransferId>,
}
4 Likes
Initially, there is a lot we can do here to prune or rotating keys (every xfer is a new key) and so on. What we want first is a solid & secure mechanism that allows massive scale and decimal point safecoin.
21 Likes
Also just to be clear, that history is only within a single section as things stand. Other sections will have no knowledge of any transfer history from another section (beyond a key initiating a transfer coming into its own).
So it’s not global knowledge, and not so different to the previous safecoin RFC in this regard.
15 Likes
As David and Josh say.
Each key is within a section, and sure the possibility is there to just use that one and have the section store all the transaction history. For public purposes that is good.
You could also have the client software move your money for every transfer you do, to a new key. The user experience would be unaffected, as the key transition would be managed under the hood. Additionally you could keep your signed transfers stored encrypted in the network or locally, so that you have a private and consistent history for your purposes.
What this would mean is that your wallet history would be spread out over n keys, each having just a single transfer, and where only the section responsible for it even has access to that single transfer.
There would have to be large scale collusion to build up a coherent view of these transfers.
Add to that, if we allow a purge of a zero balance key, i.e. a cmd to wipe the transfer history (and really the key as well, no reason for it to be kept), that section no longer stores any of your data. So every transfer would simply mean: move this amount there, the rest to this other key, and remove previous key and history.
That doesn’t say it’s not possible to log the trail, but it requires that most sections are compromised and colluding at that instant.
So, that is not the end of the possibilities, but that’s somewhere we can quite easily start, and takes us a good way.
20 Likes
Its funny @Nigel mentioned him as I stalk github sometimes he is the one I have watched most. You can tell when he is in the zone cause you will see multiple PRs cranked out handling tons of code. Best to just get out of the way and let brilliance go ham and then clean up and review incrementally after large efforts heh.
He gets dialed in:
9 Likes
My big doubt, How can keep transactions free, an avoid a spam attack, without pruning old transactions?
2 Likes
I’m not sure they should be free.
As long as it’s cheaper than anything else, it’s still ahead. But that’s my view.
6 Likes
define “free”
TANSTAAFL
But far more importantly thermodynamics - you dont get nothing for nothing - electricity cost for each transaction - even if “too small to measure” and infrastructure cost must be amortised.
3 Likes
Maybe it gets too complex but why not have free transfers up to a certain yet reasonable limit before you start charging micro fees? I would think that there could be some kind of accumulator that catches excess transactions or spam. I get that micro fees make sense and I’m not entirely opposed but it is against the fundamentals. But I’d rather have a healthy and functional network, so if spam can’t be dealt with in any other manner then so be it.
2 Likes
A neat trick here is the initiator (client) cannot finish a transaction until another is complete. So there is a built in throttle. We can do so much more. Key is make the client work harder than the network. That changes the game a bit and we also have resource proof, so we can make transactions hashcash like as well, so add further client side work.
It’s easy to charge a fee, but we don’t need to do that IMO,
27 Likes
Applying a timeout, or even a POW, can mitigate an spam attack but does not prevent it. An attacker can focus on increasing the transfer data stored in certain sections in order to overload them.
I find it difficult to maintain free transactions without data pruning.
4 Likes
I think that NANO is biggest cryptocurrency with no fees and they do not have these issues. Each transaction small as posibble, POW as base for antispam etc.
One vault will store only part of database for one section, So there will be many sections and each with many vaults. If history will be duplicated it should be still about 1/8 for one elders vaults? So way less than other currencies.
5 Likes
GNU Taler taxable anonymous libre economic reserves, makes it fully anonymous for users and fully taxable for sellers with some computer wizardry, I mean I can’t read the technicals well enough to prove this but this is what’s claimed. Cool concept, as I understand it it can sit on top of any currency, lile taler euro, taler dollars, taler safecoin, is built to be scalable, is coded up recently and ready for use, and it could make it easier to slip the safe network by regulators. As in yeah governements, we do provide wild anonymity, freedom and security for everyone, but if you’re worried about not getting your taxes, oblige sellers to use taler. We’ll keep our anonymity in both cases. Christian Grothoff who’s been working on it has some relatively clear youtube videos explaining it, seems like a good fellow, was considering sending him a friendly mail myself to see if he’d heard about SAFE.
Anyway, mostly wanted to say - these developments are so exciting oh my lawd, get it team! It’s awesome stuff.
9 Likes
https://github.com/maidsafe/safe-api/commit/284db2427560f83f7c96e5bf4172993802687db1
Coming along nicely… @happybeing will be even happier
13 Likes