Safecoin Wallet requirements brainstorming

Hope I didn’t sound too harsh; just re-read my message.

I just get this way when I see something I care alot about / think is important. So it’s definitely a complement to your project and I’m just trying to be clear about a few points.

…sorry! Doing great work!!

7 Likes

Not at all! I’m just doing some research before replying.

1 Like

I just blurred the line which mentioned about managing one single public key.

Some more thoughts regarding the transaction history. Perhaps it can contain only the recent transactions, i.e. the latest incoming transaction for each coin by only showing previous owner of each incoming tx. So in this case the app is not keeping any extra information but just showing the information kept in the coin’s SD.

I just keep thinking that it’s useful for the user to have at least this minimum information to understand its current balance and how it has been affected by the transactions made. E.g. if you are receiving payments from many people, you would need to understand if someone claiming to have sent you the coins is telling the truth, by confirming that your balance was incremented by X coins is not good enough in this scenario (specially if you are receiving the same amount from several people).

5 Likes

Seems like a fine way to go, since that’s how SafeCoin does it automatically by default already anyway

Yes, personally I think it should show your history by default. A clear and obvious ‘delete history’ button is enough imo.

3 Likes

I created this very basic safetestcoin data layout I thought I could share just for the sake of opening the discussion, and possibly towards agreeing on the one to be implemented in the first wallet app (thanks to @neo, @Seneca and @Southside for helping me in understanding some aspects of the safecoins in gral. I recommend this post to anyone trying to understand about safecoin and/or altcoins in SAFE).

Some notes:

  • SafeTestCoin’s IDs are generated by the vaults when farming.
  • AppendableData has a size limit, my understanding is that using StructuredData for the wallets would prevent some additional complexity in this regard.
  • The ID of a wallet is calculated from the PublicKey, so it contains the list of only the coins owned by the same PublicKey. Coins owned by another PublicKey shall be kept in a separate wallet.
  • If the app can generate a deterministic string, based on the account’s private information (…I didn’t dig into this to understand exactly which info and/or how though…), which can then be prefixed to the PublicKey. If we make this standard, any wallet app should be able to retrieve/import/read the wallets as long as it is provisioned with the PublicKeys.

An alternative could be just a single MutableData:

If you think this should be kept in a separate discussion please let me know or just split it.

8 Likes

It looks like your alternative will become the standard, because StructuredData and AppendableData will be combined into a new single data type, MutableData. I admire @Seneca coin mining, but maybe coins could also come into existence like they do now with Ethereum, send Ether receive coin, maybe we should also take that in to account if possible.

Sorry this is a little off topic, but when I look at coinmarketcap I see over $14B, that could all become mutable data. I hope that the tool that Maidsafe will use to translate Maidsafecoins to SAFEcoins will work across all blockchains (bitcoin Port 8333), that way we can get other coins moving from blockchain to SAFE Network data. Imagine no more waiting (yeah i know people are experimenting with lightning network etc), no more blocksize debate, more people interested in what the SAFE Network can do. :stuck_out_tongue:

4 Likes

I believe wallets should not be tied to accounts. Or, they could be throwaway, anonymous accounts, something like what BIP32 makes possible.

we can do that anyhow, there will be throwaway public/private IDs, thus their associated wallet IDs can be throwaway (or not)

4 Likes

Yea, I guess that’s the way to go.

Payments just need a signature, right? While nobody stops you from using that same private key for other things as well, there are few times when you would want to (or that a random user would assume it is.)

It is best to treat wallet keys separate from accounts.

Note: This doesn’t mean wallet keys could not be generated from account keys in a similar way as hierarchic wallets (the above mentioned BIP32) work for bitcoin; I do believe that’s a great idea, worthy of reuse.

In the Dev branch of the Core both, StructuredData and Appendabledata, not longer exist and have been replaced by MutableData so work only with MutableData seems the most intelligent.

1 Like

I am of the opinion that having the wallet address the same as the public/private ID allows greater simplicity in that people can send you coins by just knowing your public/private ID. Also you can simply generate a throwaway public/private ID and use it to send** coins anon to another wallet.

** firstly you would send the coins to the throwaway wallet (public/private) ID address then send those coins anon to another person. If you didn’t then the previous owner would not be the throwaway ID.

4 Likes

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 :joy_cat: 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