Pre-Dev-Update Thread! Yay! :D

[upstate]

This is one of the only sites I don’t block notifications from. So I don’t have to continually hit refresh.

[Wong]

Can’t sleep as result of the anticipation…

[Zoki]

via Imgflip Meme Generator

[sanju]

My calculations say, the team would give a rough deadline today (or within few weeks). Expecting beta with 6.months and full network within 1 year. Lets see how correct the analysis is.

[Zoki]

… I’m warming up my trigger finger… I’m going to get that top first post on this historic Thursday night update!!!

Edit: unless the update reduces me to a pile of jelly. My knees are already starting to wobble.

[Future]

What’s up today? (Part 1)

It’s here! Welcome to the future mates!

[anon40790172]

I guess that most work needs to be done in Crust before we’ll see the next testnet. This is the layer where computers connect over the IP-protocol. Here are the last updates:

@maidsafe

Crust

This week we mostly worked on the netsim and tokio-utp crates. netsim is currently able to only parse and construct TCP packets. We extended it a little to recognize flags (control bits) and TCP options, e.g. selective acks. Also, IPv6 is a first class citizen in netsim and now it is finally supported. uTP is another tough cookie and we are still working on graceful connection shutdown issues. In the meantime, we managed to setup CI for the tokio-utp crate which lead us to discovering new bugs. In some cases, our uTP implementation sends Reset packets back, e.g. when the connection limit is reached and we receive a new Syn packet, or when some random packet with unrecognized ID comes, etc. It turns out the Reset packet is not always correctly sent out. Although, it’s worth to mention that the fix is on the way While doing various fixes to our uTP implementation, we raised some issues on the specification: https://github.com/bittorrent/bittorrent.org/issues/83 , https://github.com/bittorrent/bittorrent.org/issues/84 . Hopefully, the rest of the community will be able to make a use of our discoveries too.

And…

@maidsafe

Crust

Another week spent on polishing our uTP implementation. Bear in mind that it’s still at its infant stage, so we keep hitting some bugs. Since last week we’ve been implementing graceful uTP connection shutdown, which will act exactly like TCP. It’s almost done, but in the meantime, we found a couple new bugs which must be fixed first:

1. in some cases, connection close sends two Fin packets instead of one - the remote peer doesn’t expect that
2. our congestion control implementation panics recalculating packet delays

Fixes for both issues are on the way and should be implemented in a matter of days. A nice side effect of those fixes is that with every change we keep adding more automated tests. Hence, tokio-utp is getting more robust and comfortable to work with

Speaking of testing, we keep investing a big piece of our time in netsim. Note that it’s still under heavy development. We’re highly experimenting; library interface, source code structure is radically changing. Currently, the documentation might be out of sync, but that’s a natural transitional stage

Have a look here for more info and the code.

Former testnets all worked with the TCP-protocol which is reliable but not as fast as you want for P2P. MaidSafe is now working on the µTP-protocol.

Another interesting quote came from David:

@dirvine

We don’t anticipate forum participation for alpha 3 or 4 as we did with 2. Resource proof is still good though as vaults that would only cause network traffic by microjoining (for a second or 2) are put off as well as nodes that just could not cope as vaults. We will close in on details of those very soon, we have just been a wee bit busy in the last few months

So no need to register on the forum and use a link etc. Alpha 3 will be open to all who want to test

[neo]

@anon40790172

Alpha 3 will be open to all who want to test

And SPAM

I cannot see any mechanism to prevent spamming of the network (add account fill er up mate again and again and again and again and …)

[digipl]

Agree. Run a Vault could be permissionless. But, without safecoin to prevent spamming, I do not see another possibility but to control the number of users (unless Maidsafe could afford to spend a large amount of money on hosting).

[Josh]

@neo

And SPAM

I cannot see any mechanism to prevent spamming of the network (add account fill er up mate again and again and again and again and …)

I was under the impression that we will not be able to upload data to Alpha 3.

[neo]

@Josh

I was under the impression that we will not be able to upload data to Alpha 3.

How do you test routing etc. The vaults will be run by maidsafe. Also the comment applied to alpha 4 too.

[Blindsite2k]

The big thing about PARSEC was it took the unknowns out of the equation. And they’ve largely worked out all the rest so it’s mostly just fitting all the pieces together and nip, tuck and smooth it all out. But it really would be nice to have a SAFE network for Christmas or earlier. I’m so sick of all the censorship on classic clear net.

[anon94252342]

According to github work in the crust is now beeing done. I assume that this is the implementation of PARSEC that is ongoing?

[dirvine]

@anon94252342

I assume that this is the implementation of PARSEC that is ongoing?

No, sorry, that is just Crust, it’s getting a lot of attention from that team. Parsec will be done by the routing team in its own repo, currently work being speced out there.

[Stark]

Since PARSEC is nearly fully coded It’s possible the team will bring with it node ageing. Seems somewhat trivial to add to A3. If adjustments need to be made it’ll just be a part of what already needs to be done for eventual beta. No slow down from here. Just tweaks that will naturally come anyway.

[neo]

@Stark

Since PARSEC is nearly fully coded It’s possible the team will bring with it node ageing. Seems somewhat trivial to add to A3. If adjustments need to be made it’ll just be a part of what already needs to be done for eventual beta. No slow down from here. Just tweaks that will naturally come anyway.

The spamming has nothing to do with consensus or ageing or adding NODES, but simply you create an account as you now (minus the invite code) and upload the maximum amount of data allowed.

Then create another account and upload the maximum data

Then create another account and upload the maximum data

Then create another account and upload the maximum data

Then create another account and upload the maximum data

Then create another account and upload the maximum data

Then create another account and upload the maximum data

Then create another account and upload the maximum data

Then create another account and upload the maximum data

And keep repeating this until no more space.

So yes the consensus and aging works in the background agreeing that the data should be stored in Maidsafe’s vaults for alpha 3 and in everyone’s vault for alpha 4.

Spamming has nothing to do with adding NODES

[drehb]

MaidSafe Dev Update - May 24, 2018 - Introducing PARSEC

The vault issue we had was zero cost to flood the network and kill it. The consensus was actually retained while not under attack like that. When the network did collapse (we took it down) then it did lose consensus, but it would in those circumstances. With no data (or very little) though we imagine that even those attacks would not be fast enough to kill a routing only network (alpha 3) as a bit problem is when there are nodes with lots of data, then copying the data around while the network g…

[neo]

@drehb The SPAM attack is not a flood attack. David was talking of the consensus being quick enough to keep up with the flood of requests. See the post he was responding to

@dlux

I think the biggest challenge was them falling out of consensus with each other when groups were under strain.

That was about falling out of consensus, not the vaults being filled up by a filling SPAM attack

So still I see nothing to protect the alpha 3 & 4 networks from being filled up if invites are not there.

[Traktion]

It points towards a test safecoin to me, perhaps with them being issued via a faucet or some such. Just having the tokens should be trivial. Perhaps swapping them for PUTs would be pretty easy too. Just thinking out loud.

[neo]

@Traktion

It points towards a test safecoin to me, perhaps with them being issued via a faucet or some such. Just having the tokens should be trivial. Perhaps swapping them for PUTs would be pretty easy too. Just thinking out loud.

For alpha 3 & 4, the easiest way is to have the invites for account creation. Unless there is something David hasn’t told us.

No need to worry about control of adding Nodes since this needs testing.