Guys, that’s awesome for us all. We were waiting long time for test release and now it is here, congrats to all participants, they done very hard and precise work here.
I tried the test testnet release but have problem with safe auth unlock step from your tutorial.
safe networks switch fleming-testnet
Switching to ‘fleming-testnet’ network…
Fetching ‘fleming-testnet’ network connection information from ‘https://sn-node.s3.eu-west-2.amazonaws.com/config/node_connection_info.config’ …
Successfully switched to ‘fleming-testnet’ network in your system!
If you need write access to the ‘fleming-testnet’ network, you’ll need to restart authd, unlock a Safe and re-authorise the CLI again
safe node join
Joining network with contacts {188.166.146.65:36220, 138.68.138.75:59177, 138.68.142.144:55064, 178.62.80.163:57378, 138.68.154.35:49429, 138.68.152.156:51182, 178.62.58.241:42766, 46.101.72.229:52737, 46.101.48.69:55130, 139.59.181.74:12000, 46.101.78.184:41244, 138.68.138.179:51519, 138.68.146.15:34651, 138.68.146.110:58306, 188.166.169.192:47334, 138.68.131.119:50694, 138.68.142.76:38701, 138.68.139.28:40613, 178.62.101.46:59428, 138.68.131.218:57691, 46.101.55.62:53141, 138.68.133.17:37599, 138.68.154.164:44520, 46.101.1.135:58214, 46.101.17.63:38981, 138.68.139.187:33546, 138.68.141.132:36390, 46.101.93.86:56133, 138.68.139.58:38972, 138.68.131.228:40591, 188.166.146.115:41339, 138.68.137.198:43750, 138.68.137.76:34625} …
Creating ‘/home/bbx/.safe/node/local-node’ folder
Storing nodes’ generated data at /home/bbx/.safe/node/local-node
Starting a node to join a Safe network…
Launching with node executable from: /home/bbx/.safe/node/sn_node
Version: sn_node 0.35.2
Using RUST_LOG ‘sn_node=debug’
Node to be started with contact(s): [“188.166.146.65:36220”,“138.68.138.75:59177”,“138.68.142.144:55064”,“178.62.80.163:57378”,“138.68.154.35:49429”,“138.68.152.156:51182”,“178.62.58.241:42766”,“46.101.72.229:52737”,“46.101.48.69:55130”,“139.59.181.74:12000”,“46.101.78.184:41244”,“138.68.138.179:51519”,“138.68.146.15:34651”,“138.68.146.110:58306”,“188.166.169.192:47334”,“138.68.131.119:50694”,“138.68.142.76:38701”,“138.68.139.28:40613”,“178.62.101.46:59428”,“138.68.131.218:57691”,“46.101.55.62:53141”,“138.68.133.17:37599”,“138.68.154.164:44520”,“46.101.1.135:58214”,“46.101.17.63:38981”,“138.68.139.187:33546”,“138.68.141.132:36390”,“46.101.93.86:56133”,“138.68.139.58:38972”,“138.68.131.228:40591”,“188.166.146.115:41339”,“138.68.137.198:43750”,“138.68.137.76:34625”]
Launching node…
Node logs are being stored at: /home/bbx/.safe/node/local-node/sn_node.log
safe auth create --test-coins
Passphrase:
Password:
Sending request to authd to create a Safe…
Safe was created successfully!
safe auth unlock
Passphrase:
Password:
Sending action request to authd to unlock the Safe…
Error: AuthdError: ClientError: Requested data not found
I tried restarting safe auth and no changes. Even created the vaults. Help is needed. Thank in advance.
For the step 5 i get the error in log:
[sn_node] ERROR 2021-04-11T10:13:23.884295696+02:00 [src/bin/sn_node.rs:110] Cannot start node due to error: Routing(TryJoinLater)
I followed the exact same steps as you and got the same problem. Tried on Windows and Linux. Hopefully after some well earned rest the team will be looking into all the logs and reports and hopefully this will be resolved for the next iteration.
My node has not gotten any chunks in about 22 hours. I wonder if it could be elder already, but I guess that’s not likely after very brief active period and only 4 chunk saved. I take it down now, and try to join again.
My log here (is there a preffered way to format these logs and how is it done?):
[sn_node] INFO 2021-04-10T15:08:58.548823547+03:00 [src/bin/sn_node.rs:104]
Running sn_node v0.35.1
[sn_node] ERROR 2021-04-10T15:09:29.026385371+03:00 [src/bin/sn_node.rs:110] Cannot start node due to error: Routing(TryJoinLater)
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00[sn_node] INFO 2021-04-10T15:09:20.847595514+03:00 [src/event_mapping/mod.rs:46] Handling RoutingEvent: MessageReceived { content: “000500…”, src: Section(b8da0d…), dst: Node(80857d…) }
[sn_node] INFO 2021-04-10T15:09:20.870560448+03:00 [src/node/handle.rs:36] Handling NodeDuty: WriteChunk
[sn_node] INFO 2021-04-10T15:09:20.871463635+03:00 [src/chunks/chunk_storage.rs:73] TRYING TO STORE BLOB
[sn_node] INFO 2021-04-10T15:09:20.872178564+03:00 [src/chunk_store/mod.rs:100] Writing chunk
[sn_node] INFO 2021-04-10T15:09:20.875416432+03:00 [src/chunk_store/mod.rs:104] consumed space: 790540
[sn_node] INFO 2021-04-10T15:09:20.875656296+03:00 [src/chunk_store/mod.rs:105] max : 2147483648
[sn_node] INFO 2021-04-10T15:09:20.875696380+03:00 [src/chunk_store/mod.rs:106] use space total : 0
[sn_node] INFO 2021-04-10T15:09:20.889996843+03:00 [src/chunk_store/mod.rs:125] Writing chunk succeeded!
[sn_node] INFO 2021-04-10T15:09:20.890442926+03:00 [src/node/handle.rs:36] Handling NodeDuty: No op.
[sn_node] INFO 2021-04-10T15:10:07.080016316+03:00 [src/event_mapping/mod.rs:46] Handling RoutingEvent: MessageReceived { content: “000500…”, src: Section(b8da0d…), dst: Node(80857d…) }
[sn_node] INFO 2021-04-10T15:10:07.099212924+03:00 [src/node/handle.rs:36] Handling NodeDuty: WriteChunk
[sn_node] INFO 2021-04-10T15:10:07.099306669+03:00 [src/chunks/chunk_storage.rs:73] TRYING TO STORE BLOB
[sn_node] INFO 2021-04-10T15:10:07.099415927+03:00 [src/chunk_store/mod.rs:100] Writing chunk
[sn_node] INFO 2021-04-10T15:10:07.102425843+03:00 [src/chunk_store/mod.rs:104] consumed space: 790556
[sn_node] INFO 2021-04-10T15:10:07.102502442+03:00 [src/chunk_store/mod.rs:105] max : 2147483648
[sn_node] INFO 2021-04-10T15:10:07.102544370+03:00 [src/chunk_store/mod.rs:106] use space total : 790540
[sn_node] INFO 2021-04-10T15:10:07.121930468+03:00 [src/chunk_store/mod.rs:125] Writing chunk succeeded!
[sn_node] INFO 2021-04-10T15:10:07.122082799+03:00 [src/node/handle.rs:36] Handling NodeDuty: No op.
[sn_node] INFO 2021-04-10T15:10:21.135453598+03:00 [src/event_mapping/mod.rs:46] Handling RoutingEvent: MessageReceived { content: “000500…”, src: Section(b8da0d…), dst: Node(80857d…) }
[sn_node] INFO 2021-04-10T15:10:21.151185240+03:00 [src/node/handle.rs:36] Handling NodeDuty: WriteChunk
[sn_node] INFO 2021-04-10T15:10:21.151254558+03:00 [src/chunks/chunk_storage.rs:73] TRYING TO STORE BLOB
[sn_node] INFO 2021-04-10T15:10:21.151339564+03:00 [src/chunk_store/mod.rs:100] Writing chunk
[sn_node] INFO 2021-04-10T15:10:21.154509773+03:00 [src/chunk_store/mod.rs:104] consumed space: 790572
[sn_node] INFO 2021-04-10T15:10:21.154569559+03:00 [src/chunk_store/mod.rs:105] max : 2147483648
[sn_node] INFO 2021-04-10T15:10:21.154597007+03:00 [src/chunk_store/mod.rs:106] use space total : 1581096
[sn_node] INFO 2021-04-10T15:10:21.171026192+03:00 [src/chunk_store/mod.rs:125] Writing chunk succeeded!
[sn_node] INFO 2021-04-10T15:10:21.171171538+03:00 [src/node/handle.rs:36] Handling NodeDuty: No op.
[sn_node] INFO 2021-04-10T15:15:18.460474411+03:00 [src/event_mapping/mod.rs:46] Handling RoutingEvent: MessageReceived { content: “000500…”, src: Section(866496…), dst: Node(80857d…) }
[sn_node] INFO 2021-04-10T15:15:18.460709495+03:00 [src/node/handle.rs:36] Handling NodeDuty: WriteChunk
[sn_node] INFO 2021-04-10T15:15:18.460748912+03:00 [src/chunks/chunk_storage.rs:73] TRYING TO STORE BLOB
[sn_node] INFO 2021-04-10T15:15:18.460818622+03:00 [src/chunk_store/mod.rs:100] Writing chunk
[sn_node] INFO 2021-04-10T15:15:18.460865983+03:00 [src/chunk_store/mod.rs:104] consumed space: 6008
[sn_node] INFO 2021-04-10T15:15:18.460893516+03:00 [src/chunk_store/mod.rs:105] max : 2147483648
[sn_node] INFO 2021-04-10T15:15:18.460918165+03:00 [src/chunk_store/mod.rs:106] use space total : 2371668
[sn_node] INFO 2021-04-10T15:15:18.474461895+03:00 [src/chunk_store/mod.rs:125] Writing chunk succeeded!
[sn_node] INFO 2021-04-10T15:15:18.474532612+03:00 [src/node/handle.rs:36] Handling NodeDuty: No op.
In todays world it have become very common to mask bad logic or arguments by just throwing positive/negative charged words infront of the point someone wants to make. It would be wanted if arguments would consist more of examples of why something or results/outcome is wanted or not wanted, trying to avoid just throwing different charged words as an argument.
A bit late but - Congrats to the whole team and community for getting the project to this stage . This testnet is a bit above my tech level so will just watch the forum for progress.
Question - Could I use the safe browser to visit sites made on this testnet and download files etc…? Is that possible to get involved without touching a command line?
Maybe this is the expected behavior: a section keeps exactly 7 elders and only when a section splits then 7 adults are suddenly promoted to make a total of 14 elders, 7 in each of the formed sections. If this is true then I see 2 problems:
We don’t know if the new elders are fit for the job.
The new elders were perhaps apt for managing data as adults, but maybe will not be so good to manage their new duties, we just don’t know.
If they were promoted incrementally when the number of adults increases then the section would get some time to test them and assess if they are fit for their new job and possibly demote them otherwise.
All this would be done progressively while the section grows before the split. When the split occurs we would know that we have 14 perfectly capable elders.
The adults would be selected (or relocated) to permanently balance the 2 halves so that we get at the end 7 elders in each section-half ready to manage a new section.
The split becomes a big bang.
Previously a split was practically a non-event. If I remember correctly the figures in previous test nets a section would split when it had 22 nodes or more with 11 nodes in each section-half. For example suppose that a section had 21 nodes, 10 managing half of the section and 11 or more managing the other half.
If a new node appeared in the first half. Then the section split in 2 but each node continued to manage the same data in the same XOR space as before (because there were responsible of data for which they were the 8th nearest node or less, and each section-half had more than 8 nodes).
So, there was no sudden increase of load in any of them.
Of course this principle has to be transposed in the new system because there are 2 kinds of nodes: elders and adults. One possibility could be that a section splits when:
it has 14 elders or more with at least 7 elders in each section-half (ELDER_SIZE constant)
if has 28 nodes or more with at least 14 nodes in each section-half (RECOMMENDED_SECTION_SIZE constant).
(both conditions must be met to trigger the split)
An added advantage I forgot to mention is that the supplementary elders before the split would help the section. Yesterday connection to section 1 was longer than to sections 00 and 01. I guess this was because there was only 7 elders to manage half the network, whereas there was 14 elders to manage the other half.
Anybody running the test net on a ODROID-C4? I just ordered one to give it a try. Its an ARM 64 bit. I love the low energy usage and yet high computing output. I think thats an often Over looked aspect of the network: the fact that it can run on low powered machines if all goes well. This will definitely be my marketing angle, as the safe network is so much better than bitcoin for the environment.
I know, I’m late to the party, but… This is amazing!
Thank you @maidsafe for all your hard work to make this vision a reality!
And let me just emphasize this awesome documentation on the details of the testnet and how to participate.
My experience when trying to join as a node
I’ve periodically tried to join as a node with the following script from above:
until grep -q "Handling NodeDuty" ~/.safe/node/local-node/sn_node.log; do safe node join; sleep 30; done
When I looked at the logs at the beginning, there was the familiar Routing(TryJoinLater) error. Then after approx. an hour, I randomly looked at the logs again and the following error appeared. Error message
[sn_node] ERROR 2021-04-11T16:49:53.975103705+02:00 [src/bin/sn_node.rs:110] Cannot start node due to error: Routing(Network(IgdNotSupported))
After that I looked at the logs a few more times, but there was only the Routing(TryJoinLater) error again. So maybe IgdNotSupported error only appeared when the network was ready to accept me (but then rejected me, because it doesn’t like me )?
Seems I’m late to the party, but the first to encounter the IgdNotSupported error!? At least I’m first in something, I guess.
Friendly reminder to all the testers
When you encounter an error, please fill in the spreadsheet with the details, if you can. This makes it much easier for the devs to analyze bugs and improve the network.
Thank you!
Here is the link again: SN Testnet Review
We’d touched on this a while back in terms of smoothing out splits. Things get complicated. More elders in any capacity increases the burden of any decision. So then you either have 14 nodes acting as elders, and every decision or churn takes a lot longer. Or still only 7 elders and 7 adults which are still essentially adults, just first in the queue, which is basically where we are at the moment.
Routing should be doing what it can to determine acceptable elders (which atm I believe boils down to node age; which I feel probably becomes more accurate a measure over time; though probably alone never perfect). But it could/should be doing anything we think is relevant (testing bandwidth? cpu etc…)
Some of what elders do should eventually be passed to adults anyway (CRDT data storage eg), so that’ll smooth out what is passed around at split. Balanced sections at split will also help ensuring that there’s definitely some knowledge of data in a section (rather than falling entirely back on AE).
I wonder it would be interesting to know the turn over of nodes… will such measures of stability be visible going forward? If the network is disrupted or just busier all of a sudden, how will that be apparent. What network metrics are possible?.. will it only be that elders know what they know - or will the sum of the nodes stats be communicated?
You could also set ELDER_SIZE to 5, which has been the chosen value for a long time. This way the number of elders would oscillate between 5 and 10, values that are near current value (7).
In this current testnet I would not measure any speeds to be honest. It’s gonna be treacle, but still way faster than a blockchain. To get a good measure though we need the AE implemented in full as things now look to hang and timeout (they should not timeout).
. This testnet is a bit above my tech level so will just watch the forum for progress.
This is amazing! 
)?
