They still exist in routing and in ffi, and I don’t believe MaidSafe has any intention to remove structured data.
Not sure, the RFC are not very clear in this aspect. Maybe the devs can enlighten us.
What is certain is that is purged from the core…
https://github.com/maidsafe/safe_core/pull/403/commits/9aa4d7a87cd1c9e90301dae3168534af4b31e883
1 Like
Sorry for the lack of input into this thread guys, I should really have been more on the ball with this one, a few other things have been draining my time of late. We should now have plenty of input to pull together an initial Request For Proposal (RFP). I’ll do that through the course of next week and I’ll post once complete. Thanks again!
6 Likes
Are you saying that mutable data can be used as a hedge for transactions on bitcoin ecosystem? Bitcoin has massive problem right now, with number of transaction going through, and backlog continues to rise. Will this solve this major problem?
Wouldn’t this, if set as default, introduce privacy issues? The sender could keep a copy of the transfer as a receipt (let’s say they have it countersigned by others for proof) and then they have proof they paid to you. (I’m not saying that’s usually a problem, but it could be.)
If you give them a throwaway wallet address, this isn’t possible.
Saying “couldn’t somebody just create a throwaway address when they really need it?” is the same thing we have on the current internet, when everybody has the option to use PGP if so they decide, and this is why I’m convinced nothing but a “paranoid by default” approach is acceptable. Let’s learn from bitcoin here: single-use addresses; it’s prudent.
Note that we could still make an exception, if necessary, just as people use bitcoin addresses for donations or businesses; all I’m arguing about is the default behavior.
There’s no need to reinvent what we can borrow. Bitcoin gets an amazing number of things right, it has a huge amount of brainpower behind it, it would be a shame to not learn from it.
1 Like
They can do that with any wallet ID and/or public/private ID. If you are “known” by one public ID and you give them (another) ID for your wallet then they can record the match up. So having the IDs the same is no loss of privacy.
They could but the ID only relates to the one transactions as you realise. I say this to point out why not use a throwaway public/private ID???[quote=“Tim87, post:25, topic:11812”]
Saying “couldn’t somebody just create a throwaway address when they really need it?” is the same thing we have on the current internet, when everybody has the option to use PGP if so they decide, and this is why I’m convinced nothing but a “paranoid by default” approach is acceptable. Let’s learn from bitcoin here: single-use addresses; it’s prudent.
[/quote]
What I don’t understand from all your reasoning is that a throwaway wallet ID (your concept) is just as difficult as a throwaway public/private ID. They are JUST a pair of keys, then any SD behind it
Lets take the concept of a throwaway wallet ID that is separate.
You have x amount of coin with your account.
- what address is in the owner ID of the coin, since you need the private key to operate them
- So HOW do you then associate the coins you wish to send with your throwaway key pair (ID)
- If you sent the coins to the other person with the current owner (which becomes prev owner in the SD) then they can track you
- So then you have to transfer the coins you wish to send to your throwaway address
- then send them
But there is no difference if you use a throwaway public/private ID
So for simplicity sake just made the ID the same? Yes they may have different uses, but they are JUST IDs (key pairs) What name (wallet, private ID) you give them is just the purpose you are using them for at the moment.
Also there is no reason or compulsion for you to use the ID you used for your throwaway wallet ID for any other purpose.
The idea was that when not used as a throwaway ID the need to remember multiple IDs just for one transaction is unnecessary. public ID xyz is their wallet ID. If throwaway then never use that ID again either as a wallet ID or as a public/private ID
I have never talked of any DNS or petname given to the ID
2 Likes
I think we got sidetracked by semantics 
I fully agree that it doesn’t matter if we call a given pair of keys a “single-use wallet address” or a “throwaway account.”
What I want is that we don’t automatically establish a tie between an “account” (something a person is known by) and a “wallet address” (something he gives out to receive money through.)
That is, when I send or request money, I expect that nothing will refer to me by my publicly known id unless I specify otherwise (and not the other way around.) Paranoia is a good default policy for something like SAFE.
As for remembering the ids: there will be no need; all this needs to be handled internally by the wallet, without the user ever seeing any of the gory details (again: BIP32 or something similar can help.) And this is why this argument belongs in this thread.
1 Like
I never said or implied it would be tied to an account
It was ALWAYS a generated public/private ID that was used. It is up to the user to “tie” it to an account by maintaining it in their account info. The Public/private ID does not indicate an account.
Just like any wallet ID a public/private is only held by the account for as long as the user wishes it to. Once the user “throws” away the ID there would be no link.
And unless the user tells someone there is NO WAY to find out which account from an ID (wallet, public, private ID)
1 Like
Then we’re in full agreement 
2 Likes
That is why I could never understand why you saw a problem, I realised it must have been that you thought I was saying something else.
The key is that any ID does not indicate an account unless its the account ID.
2 Likes
As explained in RFC 47 – MutableData, we want to combine StructuredData and AppendableData into a new single data type, MutableData, similar to HashMap.
Existing data types don’t support granular access control which is required for mobile platforms where access to the network through an intermediary like SAFE Launcher is complicated: each app would have to receive full permissions to modify and fetch data on a user’s behalf and private keys to sign it. This compromises security and allows malicious apps to get full access to the user’s data.
To mitigate that,
MutableDataprovides fine-grained access control and more narrow-scoped data operations. This data type is an evolved version ofAppendableData. It combinesStructuredDataandAppendableDatafeatures and improves the network efficiency, saves bandwidth, and provides a standardised approach for apps to fetch and mutate data in the network.
MutableData is expected to cover all the features of StructuredData and AppendableData, so that’s why we are removing these data types 
6 Likes
That’s not totally true. A great feature of SDs is missing in MDs: the signatures:
-
There could be several of them (multi-sig)
-
They were automatically computed
-
They were stored inside the structure
-
They were automatically checked by the vaults
-
Anyone could statically check them to verify the validity of a SD without any context
A signing key list and a signature list should be added to each MD entry to retrieve this feature (in struct Value). These lists are empty when this feature is not used, so the added cost is minimal.
This way each entry would act like a SD. The key is now composed of 2 parts, the MD name and the entry key. I see benefits to this and no drawbacks: when we don’t need the entry key then we can use a constant string. For example, this is how session packets have been reimplemented: previously they were stored in a SD keyed by the computed locator, now they are stored in a MD keyed by the same and the entry key is the constant string “login”.
I even think that a compatibility layer could be developed to emulate SDs over MDs so that existing rust programs using SDs could still compile and run.
The list of fields to be included in the data to be signed is to be chosen carefully but it should be something like:
-
from MD part: name and tag
-
from entry part: key, content, version and signing keys
Edit: I am thinking now that change of ownership is also important to keep. This could be done by adding 2 signing key lists (owners and previous owners) instead of one. The aim is to be able to store transactions in the network, one kind of them being safecoins transactions.
But the problem then is how to synchronize this with the change of permissions in MD?
A simpler solution would be to keep SDs as they were before (with previous owner key restored).
2 Likes
The trust here is established by group-consensus. We trust the validity of data by the virtue of it being accepted and hence stored by the Data-Managers (vaults). The way mutation flow is currently routed ensures this. An app can mutate data on the behalf of the owner and the app would not have owner’s secret-sign-key to sign the data. Instead what we now have is owner/Authenticator going to its MaidManagers and telling them that if a mutation-request comes from app-pub-sigin-key then allow that mutation (except transfer of ownership request, which MaidManagers ensure only the account-holder (the owner) can do).
Now when app routes its request via the owner’s MaidManager, the MaidManagers check if the app-pub-sign-key (from the incoming msg) is listed with them. The signature verification would have been done by routing before handing over the msg to vaults. These two combined ensure only the valid apps can have their mutation requests forwarded to data-managers.
Once it reaches the data-managers, who enforce that the request is coming from a group authority of MaidManagers, they use the requester field which would contain the app-pub-sign-key (already validated by Maid-Managers) to verify if this requester (the app) has appropriate permissions to mutate the data.
There is explanation here too if it helps.
Change of ownership is still possible - infact there is already an rpc (request msg) corresponding to it. Currently the maid-managers enforce that only the owner can do it and the data-managers enforce that the group-authority forwarding the request is the maid-manager of the requester field. These two combined ensure only the owner is allowed to transfer ownership.
We will further think whether to lift this restriction in certain scenarios like transfer of ownership is also allowed by someone else, say B, (who does not own the data) if the transfership request was signed by the owner. We might put a restriction that B is allowed this only if B himself is the new owner. But this is not being discussed for the current iteration and may or may not land in future.
Previously if A transferred ownership to B then A would keep himself in the prev-owners list and B in the owners field. After the transfer, any update of data by B would blank out the previous-owners field (the act of populating previous-owner-field indicated ownership transfer). Thus there was no permanent record of ownership transfers previously too - only till B did not update the data (or transfer it again). Also this however did not indicate that B accepted it - A could transfer to any B. Only if B updated the data and hence its signature present in the signatures field (and this act would blank out prev-owners-field) would mean that B truly accepts the ownership/owns it.
9 Likes
I have a more generic question about this. Can it be said that (unless we’re dealing with content-addressed immutable data blocks), pretty much everything is verified and decided not by static checks, but by group-consensus?
2 Likes
As of now we are all here saying that a wallet app should message the recipient’s wallet app providing the coins’ IDs that were sent, so it can verify the recipient is the new owner of the coin/s, and add them to the recipient’s wallet (coins’ IDs index).
I’m thinking in the scenario where a recipient could act badly claiming that he/she didn’t receive the coins, perhaps saying that the coins’ IDs were not received so he/she cannot deliver the goods/product in exchange. And probably the sender doesn’t have the coins’ IDs either, since due to privacy issues discussed above in this post, it’s not keeping the tx history thus not keeping the IDs of the coins already sent/transferred.
Is the purpose of this concept of the recipient explicitly accepting an ownership transfer, by signing it, to reduce/mitigate this issue?
2 Likes
I think I understood your discussion with @neo, so I hope I don’t bring it back to square one with this.
I was thinking that perhaps in order to receive coins you can decide to share 1) just a public key, the pk to be set as the owner of the coin, 2) a public name/ID, any name/string you choose which doesn’t necessarily links to your account or to you as a person/individual:
- A public key (pk) which the sender’s app just uses to set the new owner of the coins to tansfer.
- A public name/ID could be chosen by the user, the wallet app creates a MD with a XoR name based on it, exactly the same way as the email demo app does it today (although I think this could/should be handled now with the publicNamesContainer so you can also decide which app has access to read/write it).
This MD contains a list of public keys that the user decided to publish to receive coins. This list is administered by the user thru the wallet app itself, so it can add/remove keys as he/she wishes, or he/she can decide to throw the whole MD away and create new ones with a new public names/IDs.
The sender’s wallet app, can use this public name/ID to fetch (thru the publicNamesContainer) any of the public keys published there and send the coins.
This MD can also include some metadata to describe preferences or purpose each key shall be used for, as a hint for the sender’s wallet app when choosing one of them (if there were more than one key in the list of course).
In either case, we can have both the wallet MD’s and messages MD’s XoR names to be based on the public key (perhaps with some predefined or deterministic prefix/suffix). This way just based on the pk the recipient’s wallet app knows where to store the list of coins’ IDs owned by that pk, and both the sender’s and recipient’s wallet apps know where the messages shall be exchanged for a tx.
1 Like
Previously this could be done with SDs: the new owner’s signature could be added to the list of signatures. This is to mitigate the risk emphasized by @bochaco, the previous owner would put the SD only when the receiver has added his/her signature’s to the list (in addition to sender’s one). There is a regression because we cannot do this anymore with MDs,
Yes, but new MDs do no solve this problem either.
In conclusion I would say that a new data structure is yet to define to manage ownership transfer correctly.
1 Like