Maybe the excerpt from a mail I typed the other day will help.
struct safecoin {
std::vector<PublicIdHash> current_owners; // this gives us multisig as coins only release to new owner when >= majority of current owners sign
std::vector<PublicIdHash> previous_owners;
std::vector<signatures> signatures; // signatures of previous owners (who have actually signed the new owners are valid (they sign coinid+new_owners)
}
So only signed id’s can sign the coin over to the new owner. (the signed Id in this case is the current owner who can replace the previous owners signatures), I have shown the struct like this for simplicity, but essentially you do not need to keep the older signatures (it’s for show here) V1.0 will possibly maintain the signatures as it adds another layer of checking for now (overly pedantic with security)
Looking at the coin you an get the previous owners id → retrieve their public key and confirm the current owner has been signed by previous owner(s).
The transaction managers will accept a message signed by the new owner (by retrieving the public key and confirm signed request) to transfer ownership to new owner(s). We may test not keeping the signature but the public keys, so you can replace sign+prev owner with a vector of public keys (it’s faster) but has potential drawbacks.
If the coin has not finished being transferred (in a multisig) any previous owner can withdraw their signature to sign over (for contracts that break down etc.). Limbo coins will not be able to be transferred (by default they are locked with the algorithm itself, not physically)
There is an opportunity to replace all of this with integers alone, so the ints would be 64 bit and it is a case of transferring a number which is way more efficient, but we are still analysing the implications right now. If a single group were compromised with the second scheme then it would mean all coins in trouble. In the initial scheme then only a members coins could get into trouble (very limited even at that). At the moment any compromised group (yes if somebody did join over time with 3 times the network size or more) then it is a DOS type attack or vandalism and not theft. So its good to keep that paradigm in place.
So the in future will be possible to switch to the int value alone, then subdivision is instant and super super simple, We jut probably need the balance of slow and steady → high efficiency.
Switching to such a scheme could easily be done in real time with the clients all converting old safecoin to new safecoin (everyone’s client would automatically do this if we decided on this action). So it would be painless but a version number upgrade for sure. Its a reason I am not too worried about subdivision and workload, the answer as ever will be fundamental and more efficient again.
In terms of the vandalism or traffic attack described then it is on the attacker to sign the transaction (which is computationally more heavy that checking) so the way to defeat this kind of DOS thing (or traffic amplification attack) is to make it cheap for the network and expensive for the attacker. I think we are OK there.