sorry I missed answering your question It shouldnt be a problem. A single hard coded contact should be enough for bootstrapping outside startup phase. It all depends on whether churn brings the system down to its startup phase(less than grp_size nodes), if above it, then a single current node from a network that’s holding invariant should be able to get new peers accepted ok.
Ok, there need to be strictly more than 4 nodes holding each chunk. Is this the problem you are referring to?
Then, how about a less ambitious goal with stopping 1/3 of the nodes. 1/3 is not a random number, it is the upper limit of misbehaving nodes ratio to keep consensus with PARSEC. This could prove that existing other routing parts are ready to manage this limit.
Before launching the experiment, I can check that:
- each quadrant has less than 8 nodes (to ensure that a group is larger than or equal to a quadrant)
- each quadrant will have strictly more than 4 surviving nodes (to ensure that each chunk is held at least 5 times)
Would these conditions ensure success of the experiment?
- There are not enough nodes to do it right now: second condition means at least 20 surviving nodes, and 1/3 ratio means 30 initial nodes. There are currently only 17 nodes and I am not willing to provide the 13 missing ones.
- I think it can work with less nodes than that, but it’s hard to prove that each chunk has 5 surviving nodes storing them when these nodes don’t belong to the same quadrant.
Yes, quadrants are:
- prefix 00 (SW area in galaxy)
- prefix 01 (NW area in galaxy)
- prefix 11 (NE area in galaxy)
- prefix 10 (SE area in galaxy)
Only 15 nodes now and 9 are mine. This is hopeless. I am thinking about stopping the whole experiment.
This is why I wanted to have more non-techies be able to join
Doesn’t have to be hopeless.
It is relatively simple to install with Raspberry pi. Install raspbian, download the files from from below to for example, home/pi , name folder for example “app”.
In desktop mode, replace files with the same name, in the created folder in home/pi, as these files.
Next configure raspberry pi to start in command line mode, instead of desktop mode.
https://www.raspberrypi.org/documentation/configuration/raspi-config.md (3. Boot options.)
Restart Raspberry pi
type this in the command line mode, if you did choose, home/pi/app, as folder location.
klick “enter” and the vault should start.
If you need further help, leave a comment.
If anyone think I missed somehting, leave a comment.
@maidsafe-Z390-GAMING-X, pinging you again (whoever you are): Your node is still trying to connect to the network but never succeeded. Additionally to what I already mentioned, now you need to create a log file with following command:
Well, in the end is only an experiment. For my part, besides the home vault, I wanted to try how they behaved with different providers.
Btw, are you playing with yours vaults?
No, I am not. Normally I announce what I am about to do.
Your node had probably a network problem. This has happened on 2 of my nodes (in 1 month and a half). Each time I received a notification of the problem from Hetzner.
Pity, was one of the vaults that hadn’t been restarted since the beginning a month ago.
New start and everything seems fine.
Thankyou this sounds like something even I could attempt! will have a go and get back to you with how it goes, exciting stuff!
After 16 days my vault died…
thread 'main' panicked at 'key not found', libcore/option.rs:1008:5 note: Run with `RUST_BACKTRACE=1` for a backtrace.
Sounds good, hope the installation goes smooth. Remember to also have atleast 32Gb free space after Raspbian is installed, so either atleast 64GB USB or 64GB SD-card.
Later this year (a few months) my internet is being upgraded to 100/40 so I will be able to have one or more vaults.
By using a vpn I can get around the one per subnet limitation.
I’ve been meaning to join in for weeks now but I’ve been so insanely busy. The tutorials you’ve provided seem really straightforward and I’m probably half through them though I’ll probably start from scratch once I’m freed up but I still intend on participating.
Just signed up with Hetzner so I should be rejoining at the weekend so long as I can work out what to do. Is it possible to run multiple vaults from a single VM? Seem to remember the answer is no.
No, it isn’t. In nominal mode this would work, but in case of dropping nodes they must be able to sustain arrival of many new chunks.
I don’t like this workaround, because your nodes will be sharing the same bandwidth. So they might be unhelpful when we need them.
Well the min is 6Mbit/s up and 2 or even 3 sharing 40Mbit/s up should be fine
My VPN handles 50Mbits/s
As you mentioned if a quadrant is a Section and it has less than grp_size(8 assuming thats the case) nodes, then it’d be triggering a merge anyways and the groups would overlap prefixes during the Pfx change to parent prefix. So not sure how’re you’re getting a section to < grp_size before the test without incurring a prefix change. Is the merge trigger setup differently here?
Just to be clear. upper limit is strictly < 1/3rd or you’d loose super majority…
So given a member len of 6, if we loose 1/3rd(churn/malice/…) -> 2 members concurrently, it can stall progression.
This is not what I meant.
When I wrote my post there were 2 sections: prefix 0 and prefix 1, and a quadrant was half a section: prefix 00, prefix 01, prefix 11 and prefix 10.
If each quadrant has at most 8 nodes then any group is necessarily larger than a quadrant (this is intuitive, I cannot prove it mathematically). This means that if each quadrant has at least 5 surviving nodes after the big drop experiment, then any chunk will still be held by 5 nodes, which is enough consensus to keep it.
An example configuration for dropping 10 nodes over 30 (1/3) could be:
|quadrant||total nodes||dropped nodes||remaining nodes|
Each section keeps 10 nodes (5 + 5).