Great to see more technical exposure and engagement! I’m happy to have you here and discussing interesting ideas.
This topic grew quickly but here are my answers which took longer to type than the speed at which the topic grew so apologies for any duplicates.
Can they collude? This is discussed in Analysing the google attack and it turns out to be very difficult to actually collude on the safe network.
And even if they can collude, would they? The cost to do so is more than the benefit. Like bitcoin miners doing a 51% attack, it’s most likely if they’re in a position to do that attack there’s almost certainly more utility in being a benevolent / neutral actor than a malicious one and undermining the very network which forms the basis of their investment.
Could this happen alongside the existing mechanism for transfer, like a third-party neighbourhood watch service?
The overhead to keep history is probably not too high, but why include it if it’s not needed?
Currently datachains are designed to track the history of network participation (vaults joining and departing the network), but it may be extended to track history of data, specifically safecoin.
I don’t think the history mechanism is necessary, but I can see the appeal and reckon even if it’s not natively included someone will implement it and store coin history on the network for their own use anyhow. Whether this actually happens depends if coin history is valuable or not!
I think this is true in some sense but there’s a distinction to be made here which is quite economically difficult to grok (I have not yet fully grasped the economic interplay of safecoin). The safe network does not have consumers directly paying service providers. The users pay the network, then the network pays the service providers. The user and service provider are related, but not directly. So in this case the users pay the network [to record they own the token] and the network pays the vaults [to record the owner of the token]. This is the payment flow, not the data flow! It’s important because it’s not like a section dealing with high tx volume is necessarily paid more for that. This affects the economic relationships and behaviours of all actors.
This mechanism is also important because it makes ‘network operations on data’ fungible. So the security of one piece of data is the same as any other. It’s not like adding safecoin history necessarily makes it more secure, since the history is subject to the same security conditions as the safecoin itself. So just secure the safecoin in the first place.
It’s a tricky question with no direct answer. But a lot of conversation in these topics.
There are a few aspects, but ultimately the answer is ‘maybe they will collude’ which I know is unpleasant, but that’s just how it is.
These things make collusion difficult:
-
XOR space addresses cannot easily be mapped to IPs. It can be done but it’s not easy. And even if you do know all the IPs for the section you want to collude with, how do you actually contact those vault operators and coordinate with them? It’s possible but it’s definitely not easy. Maybe there will be some out-of-band behaviour that allows collusion to be coordinated, eg safe_vault_collusion_service.exe that runs alongside safe_vault.exe…?!
-
The network nodes are regularly moving so collusion is temporal. Collusion now does not mean collusion in the future.
-
There are punishments to vaults for not cooperating, which may be costly. It takes a lot of work to become influential over section decision making (see the ‘vault ageing’ feature). If the collusion attempt fails, it would be very costly to the misbehaving vaults. It’s a bit of a prisoners dillema type situation. Honest nodes have incentives to weed out malicious colluders, so they may say “I’ll collude” but then don’t and punish the colluders.
-
MutableData objects (which is what safecoins are stored as) have a version number that’s incremented each time the owner changes. If two transactions with the same version number come in, there’s a race condition that must be resolved. I don’t know the details of that resolution, but the ‘double spend’ idea depends on that race concept. A second spend five minutes later would simply be rejected because a) the signature from the old owner doesn’t match the new owner and b) the version bit would not be incremented correctly. That version flag for mutable data is a very important mechanism and is worth reading more about.
If it’s possible then yes it may inflate the currency, but never more than the number of coins the section is responsible for. If there are one hundred sections, any particular section is responsible for (on average) 1% of all coins. The more sections, the less coins each one is responsible for. So a very large network may have most sections only being responsible for a few coins.
Again, it’s a shitty answer because you don’t want to admit coins can be minted for free but they can (if collusion is possible).
However, due to the way coins are issued, there should be even distribution of coins across xorspace (within a certain variation). If a particular section has issued way more than they should have it would be detectable. Likewise if client balances suddenly changed due to colluders taking ownership it would be detectable.