In the end I had 172M chunks.
Thank you for putting this together ! I will be happy to experiment more
12 Likes
And especially to you for setting this up, good to get clarification 
17 Likes
Yes it was good while it lasted. I couldnât get it working on Windows though, possibly because the Maidsafe versions were previously installed and in the PATH.
5 Likes
Thanks for trying again @tfa
I ended up with 662 chunks totalling 51Mb
Hopefully the solution is not too far away.
8 Likes
Following on from Trafffic sizes on the SAFE network topic, 85% of chunks for my node were less than 100K in size. Real network will have more large chunks but thought this was an interesting thing to observe anyhow.
| Chunk Size | Number of chunks |
|---|---|
| 0-100K | 483 |
| 100-200K | 26 |
| 200-300K | 9 |
| 300-400K | 10 |
| 400-500K | 12 |
| 500-600K | 11 |
| 600-700K | 3 |
| 700-800K | 3 |
| 800-900K | 9 |
| 900K-1M | 5 |
13 Likes
A quick count gives thes eyeballed numbers
| Chunk Size | Number of chunks |
|---|---|
| 0-100K | hunners |
| 100-200K | 27 |
| 200-300K | 12 |
| 300-400K | 16 |
| 400-500K | 8 |
| 500-600K | 14 |
| 600-700K | 7 |
| 700-800K | 3 |
| 800-900K | 9 |
| 900K-1M | 9 |
Showing very very roughly similar distribution. The sample size is far too small to make any real meaningful judgements though.
13 Likes
Thanks @tfa was nice to get some extra play time.
10 Likes
Thanks, @tfa! Itâs a shame my router couldnât connect, but it is good to see a replica test network go through the motions.
Presumably, this experiment should make it easier to launch the next iterations too? Iâm happy to help where I can there too.
5 Likes
Sure? I wouldnât bet on it.
1 Like
A suggestion for @Maidsafe: Could you implement the possibility to use a SafeKey secret key in the --to part of safe keys transfer command?
The use case is to give users only one element so that they can do everything from this unique element. Currently they can create an account and transfer from but they cannot transfer to.
1 Like
Thatâs not a valid use case, nobody would be giving you a secret key to receive a transfer, well, nobody should.
3 Likes
When folk start storing music, videos and hi-res images then I would certainly expect the proportion of 1Mb chunks to rise.
Can I call them fully-filled chunks- or should we call them âefficientâ?
1 Like
A SAFE messaging application, similar to whatsapp, could generate billions of small chunks every day, a email app too, a forum app tooâŚ(and a Safe github app tooâŚ)
I still think itâs more likely to have a lot of small chunks than big ones.
3 Likes
Well, this is what I did for the community network: give each user a secret key.
This context is very specific, but more generally if I am the owner of a secret key shouldnât I be able to refill it with a transfer command?
But I repeat my use case:
Another way to do this would be that the safe transfer command use accountâs default SafeKey as the destination when the --to option is omitted. Would this be more acceptable?
1 Like
I think the correct way to do it is first ask your users to generate a key pair:
$ safe keypair
Key pair generated:
Public Key = aaaa2ee8646f4dfbb2b9d570e1ee29dfbb23712b4ba735b66ecc40510b8a11d398a0c329a5bab9b74ba449df1abe38b7
Secret Key = 3078f414584e6982ddc5fcb06d2b735bc3967c25610613ac2f42123dcfab7200
And they can share with you only the public key, which you then use to transfer some coins to:
$ safe keys create --pk <their public key>
New SafeKey created at: "safe://hbyyyybb9dgzwwpw1yrpf9k56adokp8kjmexu1frdarzkk49czzyf9u63p"
$ safe keys transfer 10.5 --from <your sk> --to safe://hbyyyybb9dgzwwpw1yrpf9k56adokp8kjmexu1frdarzkk49czzyf9u63p
Success. TX_ID: 3708952997132589517
After that they can then create their accounts using their secret key.
6 Likes
Thats the way we do it for now, but @tfaâs use case sounds much simpler for n00bs.
1 Like
Itâs almost the same, instead of you giving them an SK, ask them to give you a PK, generating the keypair is straight forward (safe keypair cmd), specially if they plan and will use the CLI afterwards they should be able to do that.
5 Likes
Yes , makes sense. In any case by the time we get around to n00b adoption @JimCollinson will have provided a nice simple GUI. Forget I ever mentioned itâŚ
7 Likes
It sounds like good practice, better avoiding to create the habit of sharing private keys
7 Likes
The problem is that I want a simple distribution procedure where I simply give a string stored in a Google sheet without being connected to the network.
But users can do themselves what you have just proposed.
I cannot test right now, but the procedure could be:
- they create a temporary account using the procedure in the OP
- they create a keypair and a safe key like you propose
- they transfer all the funds from my secret key to their safe key URL
- they create the final account funded by their safe key secret
Later if their account needs a refill I can provide a new secret key and they just have to move the funds to their safe key URL.
Note: I still think that an omitted --to argument should move the fund to the default safe key of the account. Otherwise users have to memorize the safe key URL, in addition to credentials (unless there is a way to get it that I donât know).
EDIT (second version, no need to create a temporary account):
I tested this procedure that the user should follow with the secret key given to him and it worked:
- Create a personal SafeKey:
./safe keys create --pay-with <given key> - Get balance of given key:
./safe keys balance --sk <given key> - Transfer the whole balance to personal SafeKey:
./safe keys transfer --from <given key> --to <personal SafeKey URL> <given key balance> - Start authenticator daemon:
./safe-authd start - Create account:
./safe auth create-acc --sk <personal SafeKey secret key> - Connect to account:
./safe auth login --self-auth
If the user writes down carefully the personal SafeKey URL, the account can be refilled later with a new secret key given to him with ./safe keys transfer --from <new key> --to <personal SafeKey URL> <new key balance>.
Implementing a default --to argument as funding the account default SafeKey would avoid memorizing the SafeKey URL.
EDIT:
Note that the 3 first commands can be merged in one single command when you know the cost of creating a SafeKey, which is 1 nano (0.000000001 safecoin): ./safe keys create --preload 0.000001999 --pay-with <given key>
This is only one additional command compared to the op that ensures:
-
safety of your funds (I canât take back the funds I have given to you).
-
possibility to refill your account
7 Likes