Testnet Changelog - December 24th, 2020

Development Updates
81

Got a fun little hack for storing large files.

Previously I’ve maxed out at 160 MB using
$ safe files put /path/to/file
for immutable data, which took 45 minutes to upload. Files larger than that failed to upload.

But we can store large files like this:

$ cat /path/to/my/big/file | safe seq store -

I tested it using random data of a fixed size (500 MiB):

$ dd if=/dev/urandom of=/tmp/data.bin bs=1M count=500
$ cat /tmp/data.bin | safe seq store -

Writing the initial 500 MiB file using dd took 13.4736s (311 Mbps)

Completion of the cli command took 32s (131 Mbps) but the nodes were still computing and their chunk stores empty. As far as the client is concerned, the file has fully uploaded at this point.

The chunk was written to the node chunk store after 167s (25 Mbps) but the nodes were still computing.

The nodes stopped computing after 186s (22 Mbps). This is the ‘true’ upload time, although the client never knows it.

This stores on the nodes as a single large chunk (need to fix that for the real network) and does not use self-encryption to break it down into smaller pieces.

This isn’t going to be possible (I assume) in the real network but just thought it was nice to find a way to store large files on the network. Also a good reminder that people will be trying all sorts of weird stuff and won’t necessarily follow the intentions of the api/cli.

18 Likes
82

Thanks for your work.

9 Likes
83

Could be user error but I couldn’t see that working…

$ cat ./sample2.txt | safe seq store -
...awaiting data that will be stored from STDIN

used instead this below but having come in from restarting the existing baby nodes, I got errors first attempt and then restarted auth and setup new account seemed to work but too fast and safe cat doesn’t show the file??

$ safe seq store <(cat ./sample2.txt)
[2021-01-10T10:22:34Z ERROR sn_client::client::transfer_actor] Error receiving SignatureShare: Unexpected: CmdError received: Transfer(TransferValidation(Unexpected("Logic error \"Key does not exist among locks.\""))) - ClientError::Unexpected::{"CmdError received: Transfer(TransferValidation(Unexpected(\"Logic error \\\"Key does not exist among locks.\\\"\")))"}
[2021-01-10T10:22:34Z ERROR sn_client::client::transfer_actor] Error receiving SignatureShare: Unexpected: CmdError received: Transfer(TransferValidation(Unexpected("Logic error \"Key does not exist among locks.\""))) - ClientError::Unexpected::{"CmdError received: Transfer(TransferValidation(Unexpected(\"Logic error \\\"Key does not exist among locks.\\\"\")))"}
[2021-01-10T10:22:34Z ERROR sn_client::client::transfer_actor] Error receiving SignatureShare: Unexpected: CmdError received: Transfer(TransferValidation(Unexpected("Logic error \"Key does not exist among locks.\""))) - ClientError::Unexpected::{"CmdError received: Transfer(TransferValidation(Unexpected(\"Logic error \\\"Key does not exist among locks.\\\"\")))"}
[2021-01-10T10:22:34Z ERROR safe] sn_cli error: [Error] NetDataError - Failed to store Public Sequence data: Unexpected: CmdError received: Transfer(TransferValidation(Unexpected("Logic error \"Key does not exist among locks.\""))) - ClientError::Unexpected::{"CmdError received: Transfer(TransferValidation(Unexpected(\"Logic error \\\"Key does not exist among locks.\\\"\")))"}

Having restarted auth and setup a new account then worked

$ safe seq store <(cat ./sample3.txt)
Public Sequence stored at: "safe://hyryyyy31x4dxaf37bahtf1nr3pjcceurkrmqqf9yxcbk6p7a59p77dpkccnmy"
$ safe cat safe://hyryyyy31x4dxaf37bahtf1nr3pjcceurkrmqqf9yxcbk6p7a59p77dpkccnmy > ./testout
$ safe cat safe://hyryyyy31x4dxnr3pjcceurkrmqqf9yxcbk6p7a59p77dpkccnmy > ./testout ; cat ./testout
Public Sequence (version 0) at "safe://hyryyyy31x4dxaf37bahtf1nr3pjcceurkrmqqf9yxcbk6p7a59p77dpkccnmy":
/dev/fd/63
$safe://hyryyyy31x4dxaf37bahtf1nr3pjcceurkrmqqf9yxcbk6p7a59p77dpkccnmy?v=0 > ./testout ; cat ./testout
Public Sequence (version 0) at "safe://hyryyyy31x4dxaf37bahtf1nr3pjcceurkrmqqf9yxcbk6p7a59p77dpkccnmy?v=0":
/dev/fd/63

Noting there pulling the file back with safe cat is some talk of /dev/fd/63
afaik /dev/fd is some pseudo filesystem reference but that’s not the file data ??

4 Likes
84

I found the same. I don’t think it’s being stored in the network as very few new chunks are added to the nodes - also it happens very quickly.

Summary

/safe$ tree -hD ~/.safe/node/baby-fleming-nodes/ | grep ‘Jan 10’
│ │ └── [ 12K Jan 10 20:36] immutable
│ │ └── [ 8 Jan 10 20:36] used_space
│ ├── [ 96 Jan 10 20:36] reward_public_key
│ ├── [ 64 Jan 10 20:36] reward_secret_key
│ └── [1.0K Jan 10 20:36] sn_node.log
│ │ └── [4.0K Jan 10 20:36] immutable
│ │ └── [ 8 Jan 10 20:36] used_space
│ ├── [ 96 Jan 10 20:36] reward_public_key
│ ├── [ 64 Jan 10 20:36] reward_secret_key
│ └── [1.0K Jan 10 20:36] sn_node.log
│ │ ├── [4.0K Jan 10 20:36] immutable
│ │ │ └── [ 8 Jan 10 20:36] used_space
│ │ ├── [4.0K Jan 10 20:36] login_packets
│ │ │ └── [ 8 Jan 10 20:36] used_space
│ │ ├── [4.0K Jan 10 20:37] mutable
│ │ │ ├── [ 470 Jan 10 20:37] 0100000064beeba97ad5a9c48a40da9f43180b62eee34848303e2ff3b516264acbd0f42f1405000000000000
│ │ │ └── [ 8 Jan 10 20:37] used_space
│ │ └── [4.0K Jan 10 20:41] sequence
│ │ ├── [ 716 Jan 10 20:41] 0000000085dd793236bb381e6264eba20efcb769f0a1cd90b716a9fcf210d145c1d8e083b004000000000000
│ │ └── [ 8 Jan 10 20:41] used_space
│ ├── [ 96 Jan 10 20:36] reward_public_key
│ ├── [ 64 Jan 10 20:36] reward_secret_key
│ ├── [407K Jan 10 20:46] sn_node.log
│ └── [4.0K Jan 10 20:46] transfers
│ ├── [3.5K Jan 10 20:37] 0380ac00dfeaec632b923ca5630033396bfeb85479c261e3c4feb5c648c8ac4e.db
│ ├── [1.8K Jan 10 20:41] 93f39eff443e8901f8ee645ea98c6305605b0464b693fc1b95c6c605664e9b0f.db
│ ├── [2.2K Jan 10 20:46] c54f54a56cfd319c5d9ef4dc4cdebfdbaa78652d280bc8390201c4a3e4d6d02b.db
│ │ ├── [4.0K Jan 10 20:36] immutable
│ │ │ └── [ 8 Jan 10 20:36] used_space
│ │ ├── [4.0K Jan 10 20:36] login_packets
│ │ │ └── [ 8 Jan 10 20:36] used_space
│ │ ├── [4.0K Jan 10 20:37] mutable
│ │ │ ├── [ 470 Jan 10 20:37] 0100000064beeba97ad5a9c48a40da9f43180b62eee34848303e2ff3b516264acbd0f42f1405000000000000
│ │ │ └── [ 8 Jan 10 20:37] used_space
│ │ └── [4.0K Jan 10 20:41] sequence
│ │ ├── [ 716 Jan 10 20:41] 0000000085dd793236bb381e6264eba20efcb769f0a1cd90b716a9fcf210d145c1d8e083b004000000000000
│ │ └── [ 8 Jan 10 20:41] used_space
│ ├── [ 96 Jan 10 20:36] reward_public_key
│ ├── [ 64 Jan 10 20:36] reward_secret_key
│ ├── [402K Jan 10 20:46] sn_node.log
│ └── [4.0K Jan 10 20:46] transfers
│ ├── [3.5K Jan 10 20:37] 0380ac00dfeaec632b923ca5630033396bfeb85479c261e3c4feb5c648c8ac4e.db
│ ├── [1.8K Jan 10 20:41] 93f39eff443e8901f8ee645ea98c6305605b0464b693fc1b95c6c605664e9b0f.db
│ ├── [2.2K Jan 10 20:46] c54f54a56cfd319c5d9ef4dc4cdebfdbaa78652d280bc8390201c4a3e4d6d02b.db
│ │ ├── [4.0K Jan 10 20:36] immutable
│ │ │ └── [ 8 Jan 10 20:36] used_space
│ │ ├── [4.0K Jan 10 20:36] login_packets
│ │ │ └── [ 8 Jan 10 20:36] used_space
│ │ ├── [4.0K Jan 10 20:37] mutable
│ │ │ ├── [ 470 Jan 10 20:37] 0100000064beeba97ad5a9c48a40da9f43180b62eee34848303e2ff3b516264acbd0f42f1405000000000000
│ │ │ └── [ 8 Jan 10 20:37] used_space
│ │ └── [4.0K Jan 10 20:41] sequence
│ │ ├── [ 716 Jan 10 20:41] 0000000085dd793236bb381e6264eba20efcb769f0a1cd90b716a9fcf210d145c1d8e083b004000000000000
│ │ └── [ 8 Jan 10 20:41] used_space
│ ├── [ 96 Jan 10 20:36] reward_public_key
│ ├── [ 64 Jan 10 20:36] reward_secret_key
│ ├── [398K Jan 10 20:46] sn_node.log
│ └── [4.0K Jan 10 20:46] transfers
│ ├── [3.5K Jan 10 20:37] 0380ac00dfeaec632b923ca5630033396bfeb85479c261e3c4feb5c648c8ac4e.db
│ ├── [1.8K Jan 10 20:41] 93f39eff443e8901f8ee645ea98c6305605b0464b693fc1b95c6c605664e9b0f.db
│ ├── [2.2K Jan 10 20:46] c54f54a56cfd319c5d9ef4dc4cdebfdbaa78652d280bc8390201c4a3e4d6d02b.db
│ │ ├── [4.0K Jan 10 20:36] immutable
│ │ │ └── [ 8 Jan 10 20:36] used_space
│ │ ├── [4.0K Jan 10 20:36] login_packets
│ │ │ └── [ 8 Jan 10 20:36] used_space
│ │ ├── [4.0K Jan 10 20:37] mutable
│ │ │ ├── [ 470 Jan 10 20:37] 0100000064beeba97ad5a9c48a40da9f43180b62eee34848303e2ff3b516264acbd0f42f1405000000000000
│ │ │ └── [ 8 Jan 10 20:37] used_space
│ │ └── [4.0K Jan 10 20:41] sequence
│ │ ├── [ 716 Jan 10 20:41] 0000000085dd793236bb381e6264eba20efcb769f0a1cd90b716a9fcf210d145c1d8e083b004000000000000
│ │ └── [ 8 Jan 10 20:41] used_space
│ ├── [ 96 Jan 10 20:36] reward_public_key
│ ├── [ 64 Jan 10 20:36] reward_secret_key
│ ├── [394K Jan 10 20:46] sn_node.log
│ └── [4.0K Jan 10 20:46] transfers
│ ├── [3.5K Jan 10 20:37] 0380ac00dfeaec632b923ca5630033396bfeb85479c261e3c4feb5c648c8ac4e.db
│ ├── [1.8K Jan 10 20:41] 93f39eff443e8901f8ee645ea98c6305605b0464b693fc1b95c6c605664e9b0f.db
│ ├── [2.2K Jan 10 20:46] c54f54a56cfd319c5d9ef4dc4cdebfdbaa78652d280bc8390201c4a3e4d6d02b.db
│ │ └── [ 12K Jan 10 20:36] immutable
│ │ └── [ 8 Jan 10 20:36] used_space
│ ├── [ 96 Jan 10 20:36] reward_public_key
│ ├── [ 64 Jan 10 20:36] reward_secret_key
│ └── [1.0K Jan 10 20:36] sn_node.log
│ │ └── [ 12K Jan 10 20:36] immutable
│ │ └── [ 8 Jan 10 20:36] used_space
│ ├── [ 96 Jan 10 20:36] reward_public_key
│ ├── [ 64 Jan 10 20:36] reward_secret_key
│ └── [1.0K Jan 10 20:36] sn_node.log
│ │ └── [ 12K Jan 10 20:36] immutable
│ │ └── [ 8 Jan 10 20:36] used_space
│ ├── [ 96 Jan 10 20:36] reward_public_key
│ ├── [ 64 Jan 10 20:36] reward_secret_key
│ └── [1.0K Jan 10 20:36] sn_node.log
│ │ └── [4.0K Jan 10 20:36] immutable
│ │ └── [ 8 Jan 10 20:36] used_space
│ ├── [ 96 Jan 10 20:36] reward_public_key
│ ├── [ 64 Jan 10 20:36] reward_secret_key
│ └── [1.0K Jan 10 20:36] sn_node.log
│ ├── [4.0K Jan 10 20:36] login_packets
│ │ └── [ 8 Jan 10 20:36] used_space
│ ├── [4.0K Jan 10 20:37] mutable
│ │ ├── [ 470 Jan 10 20:37] 0100000064beeba97ad5a9c48a40da9f43180b62eee34848303e2ff3b516264acbd0f42f1405000000000000
│ │ └── [ 8 Jan 10 20:37] used_space
│ └── [4.0K Jan 10 20:41] sequence
│ ├── [ 716 Jan 10 20:41] 0000000085dd793236bb381e6264eba20efcb769f0a1cd90b716a9fcf210d145c1d8e083b004000000000000
│ └── [ 8 Jan 10 20:41] used_space
├── [ 96 Jan 10 20:36] reward_public_key
├── [ 64 Jan 10 20:36] reward_secret_key
├── [432K Jan 10 20:46] sn_node.log
└── [4.0K Jan 10 20:46] transfers
├── [3.5K Jan 10 20:37] 0380ac00dfeaec632b923ca5630033396bfeb85479c261e3c4feb5c648c8ac4e.db
├── [1.1K Jan 10 20:36] 8699477b5270ce57898ad596a4fb7d130fdd0d0c1a9d13226f2de497e54a88f6.db
├── [1.8K Jan 10 20:41] 93f39eff443e8901f8ee645ea98c6305605b0464b693fc1b95c6c605664e9b0f.db
├── [2.2K Jan 10 20:46] c54f54a56cfd319c5d9ef4dc4cdebfdbaa78652d280bc8390201c4a3e4d6d02b.db

1 Like
85

fwiw it works ok for me. Here’s my full session (already logged in)

$ echo "my test value" > /tmp/test.txt
$ cat /tmp/test.txt | safe seq store -
...awaiting data that will be stored from STDIN
Public Sequence stored at: "safe://hyryyyyazcy7a3dm7i4onqtfh4i9rhx869jpe4wp8g754b8qgnxkbipspjonmy"
$ export SEQURL=safe://hyryyyyazcy7a3dm7i4onqtfh4i9rhx869jpe4wp8g754b8qgnxkbipspjonmy
$ safe cat $SEQURL
Public Sequence (version 0) at "safe://hyryyyyazcy7a3dm7i4onqtfh4i9rhx869jpe4wp8g754b8qgnxkbipspjonmy":
my test value
$ safe cat $SEQURL > /tmp/test2.txt
$ cat /tmp/test2.txt 
Public Sequence (version 0) at "safe://hyryyyyazcy7a3dm7i4onqtfh4i9rhx869jpe4wp8g754b8qgnxkbipspjonmy":
my test value

Interesting that you get some pseudo filesystem reference instead of the file data. Wonder what causes it?!

edit: the redirection like this
safe seq store <(cat /tmp/test.txt)
stored the same value you have:
/dev/fd/63
Looks like it only works with the pipe not the redirection.

3 Likes
86

Having restarted and created a new safe I find that cat myfile | safe seq store - works for smallish files. You get the ..awaiting data that will be stored from STDIN message but only briefly, but for the 500MB file it just crashes my system and thereafter the same Safe gives lots of ‘data out of order’ type errors.

2 Likes
87

Ah… I was too impatient seeing

…awaiting data that will be stored from STDIN

thought it was waiting on user input not working against the cat stream.

So, that does work :+1:

but on a 1.1GB it’s not enough “money”

[2021-01-10T21:44:47Z ERROR safe] sn_cli error: [Error] NetDataError - Failed to store Public Sequence data: Data error → Not enough money to complete this operation - ClientError::DataError → InsufficientBalance

4 Likes
88

Yes I get this too. I tried to figure out how to increase the wallet balance (without hacking the source code, just using cli) but couldn’t work it out.

If anyone works out how to issue and pay yourself more test coins please do post the instructions here. cli docs are here but don’t seem to cover this.

1 Like
89

Possibly covered here? Can't create test coins. Not enough money

90

Huh?
I always did this to create more coins
eddy@hal9000:~$ safe keys create --test-coins --preload 1534000000

And send that to the wallet balance, but that’s probably not what you mean.

3 Likes
91

Ah nice, this is just what I was looking for!

But I have another question. When I do
$ safe auth create --test-coins
how do I add more coins to that account rather than create a new key?

If I create a new key like you do, I can’t use that to pay for my uploads. I still get “Not enough money” error when I try to upload a 1 GB file.

I appreciate we can send from the new key to the account using safe keys transfer, but how do I get the original account key to send to? What is the --to value?

3 Likes
92

I could be wrong, maybe you can find it.
However I’m sure I read since this release that for now it is hidden in this test network.

1 Like
93

Im unfortunately at work so can really answer atm. This is just a guess have you tried.

$ safe auth create --test-coins --preload 10000000

Gotto go

1 Like
94

I tried this, it did not work.

I thought I had a workaround to fund the account, but balance is still not as expected. The workaround process is a bit long-winded but here it is:

safe auth create --help
shows there’s a --sk flag available. Let’s use it!

Get a key pair (start a network, call safe keys create and keep the output, kill the network, start a fresh network).

Create a new account with the previously generated keys.
safe auth create --test-coins --sk <secret key>

At this point we expect the key to have some coins. Let’s check:
safe keys balance
This shows a balance of 0 so something seems wrong.

We can send more test coins to the account using
safe keys create --test-coins --preload 4294967295
safe keys transfer 4294967295 --from <prior sk> --to <account pk>

Checking the balance again, the transfer worked.
safe keys balance
SafeKey's current balance: 4294967295.000000000

Try uploading 1 GB
cat /tmp/1GB.dat | safe seq store -

Bit of a hack… and in the end I still got “Not enough money” error. I suspect the --sk flag during account creation is not associating the key to the account, but that’s just a guess.

edit: The --sk flag does nothing. It is not used in the code (see this function which does not use sk). This is also the same function where the output of the account keys is suppressed (2 months ago in this commit). I’m going to uncomment the account keys so I can fund the account and upload larger files. See if there’s a limit.

5 Likes
95

I honestly don’t know the answer to this, I do get an error when I do this.
eddy@hal9000:~$ safe auth create
Passphrase:
Password:
[2021-01-11T09:13:26Z ERROR safe] sn_cli error: Please use --test-coins option, other options not implemented yet.

Other options not implemented yet, might be the answer at the moment.

Since this is still under development, we can have the CLI to generate some test-coins and use them for paying the cost of creating a Safe. Maybe the test-coins generated is just enough to pay for the Safe, no idea how to check it’s balance or send it more test-coins atm.

I have the same question, because you don’t get a priv/pubkey that’s tied to the Safe.

Just a random thought, it would be nice to create tokens on the SAFE Network this easy:
safe keys create --shitcoin xyz :partying_face: --preload 10​000000000​000​000000000000000000000000​000000​000000​000​000000000000000000000000000000​000000000​000000000

If you could have free transactions, but your cpu/gpu is used to initiate the tx

1 Like
96

I got to uploading larger files by changing (source)

-const DEFAULT_TEST_COINS_AMOUNT: u64 = 777_000_000_000;
+const DEFAULT_TEST_COINS_AMOUNT: u64 = 4294967295_000_000_000;

Trying to display the account keys ended up being more tricky than it was worth.

With this I could do some tests on large files. I used my desktop with 64 GB memory for this, since 16 GB on the laptop was going to be a bottleneck.

Keep in mind these tests are kinda silly, they’re not going to be possible on the real network, but pushing nodes to extreme stress can sometimes uncover useful things along the way.

Started with trying to upload a 5 GiB file using the
cat /tmp/5gb.dat | safe seq store -;
hack.

Creating the file to upload using dd took 117s (this is an indicator of disk speed so gives some point of comparison)

client took 145s
chunk never stored
cpu idle after 145s

max memory consumed was 25.6 GB (nodes never got started on this chunk so this is all memory consumed by the cli).

nodes cannot process this and did no work, cpu use stayed very low, ultimately failing at the nodes with “Error deserializing Client msg”:

[sn_node] INFO 2021-01-11T20:24:23.928531348+11:00 [src/node/mod.rs:229] unimplemented: Handle errors.. Logic error "Error deserializing Client msg"

But the nodes did return an xorurl which the cli printed out, kinda odd. Fetching it would not work since no nodes stored any chunks.

Then tried uploading a 2 GiB file. The nodes didn’t balk at this like 5 GiB but were ultimately not successful at storing it.

dd took 46s

client took 97s
chunk never stored
cpu idle after 498s (34 Mbps)

Maxed out 64 GB Memory (got to 540 M swap)

nodes did a lot of work trying process this, but they failed with “Not enough space”:

[sn_node] INFO 2021-01-11T20:35:36.814288921+11:00 [src/node/node_duties/messaging/network_sender.rs:134] Sent to section with: MsgEnvelope { message: CmdError { error: Data(NetworkOther("Not enough space")), id: MessageId(16a602..), correlation_id: MessageId(42c648..), cmd_origin: Client(46412b..) }, origin: MsgSender { entity: Entity::TransientSectionKey::Bls(b42f83..)Section(Metadata), sig: None }, proxies: [] }

I think it’s just a bit too close to this limit once other account data is factored in:

const DEFAULT_MAX_CAPACITY: u64 = 2 * 1024 * 1024 * 1024; (source)

Anyway I’m satisfied that I’ve pushed this hack as far as I want. There’s a few errors to look into a bit further perhaps, but overall this hack isn’t gonna last and doesn’t represent realistic situations so there’s not much point getting too invested in it.

4 Likes
97

Hmm… is there any way to make the default amount of testnet testcoins impossible to change? I would not like to see testnet go down because of free spam.