Hi @anon40006692,
@neo has beaten me to the punch there but I’ll step into the ring as well.
As it stands there isn’t another Crust test scheduled but if that changes we won’t be shy letting everyone know about it. More to come on our thoughts after the results analysis next week…
David.
I just wanted to say that you’re doing a great job keeping everyone informed, responding to questions, etc. That is all! 
Just curious, is there a chance we will see tunneling through common nodes in a crust test v2.1 to get around the symmetric Nat issue? Is it even possible currently or is it unnecessary given the number of connections achieved through other means ?
Haha - nice idea! - the little it makes sense it would still be a joy to see a 100% connection rate
Hmm, tunneling reminded me of the payment routing issue on the lightning network. Figuring out how to connect from here to there can get difficult.
Not in the Safe Network.
Lightning network is based on a P2P destructured network so finding the route becomes extremely complicated (basically a NP Hard problem).
Safe is based on a structured P2P network, also known as a third generation network, where finding the optimal route is very simple since every node is in a specific position.
Yes, SAFENetwork could actually provide a lightning network implementation, I believe. It could mean lightning transactions could happen without both peers online, with the lightning transactions stored off chain until the receiver goes online.
I’m not a lightning expert though, so I could be missing something! 
This is just the crust layer though. Isn’t it still unstructured at the crust layer?
Reading a bit about lightning, it sounds like it requires both sender and receiver to sign the transaction, which is why it needs to be done with both parties online with the current implementation.
With SAFENetwork acting as a persistent store, it could provide an additional option; a SAFENetwork message could be sent to the recipient, who could counter sign and message back to the sender. Since messages do not require both parties to be online, this would make lightning network much more usable for most people who either aren’t online 24/7 and/or don’t want to use/trust a 3rd party service.
It would be a rather good feature to add to lightning/Bitcoin and illustrates another use case for the underlying SAFENetwork technology.
In this Medium article, I found this sentence to be confusingly arranged:
“SAFE-Fleming itself only requires Crust to provide the ability for computers to connect via direct connections or through what is known as UPnP connections (where an individual carries out manual port-forwarding using his or her router in order to connect to the Network).”
UPnP is automatic if enabled, so I think the manual configuration part is actually referring to the first part of the sentence about direct connections. Maybe just reversing the order in the sentence would be easier to read?
“SAFE-Fleming itself only requires Crust to provide the ability for computers to connect via UPnP connections or through direct connections (where an individual carries out manual port-forwarding using his or her router in order to connect to the Network).”
I watched this series about Lightning Network and its limitations, which add food for thought: How Bitcoin Lightning Channels Work - YouTube
It sounds like there are big issues around connectivity (NAT traversal) and scalability (routing). While SAFENetwork would help with direct LN transactions (where a channel exists directly between both parties), I don’t think it will help LN with its other issues.
However, direct LN transactions across an open channel would be improved by SAFENetwork for a few reasons:
So, perhaps SAFELightning would be an interesting product, as long as it was worth the channel setup cost. It would also bring other advantages:
I do not think that, without the LNs making profound structural changes in their design, the Safe Network can manage that kind of transactions.
I think it would be less difficult to create an altcoin (SafeBTC), inside the network, pegged to bitcoin in a 1:1 ratio.
The user would exchange bitcoins for SafeBTC that would be added to their wallet allowing transactions to any user safely and quickly with minimal cost. When the user decides, these SafeBTC are reconverted into BTC again by adding a transaction to the BTC blockchain.
The big difficulty is how the bitcoin<->SafeBTC conversion is implemented and who store and manages the private keys (possibly a multisign of several different groups).
Yes, you may well be right. A peg is certainly simpler. I know that side chains seek to do just that, but I haven’t read into the technical details of how coins are 'moved between chains.
I think it would be easier to just use MAID as the portal through which safecoin can be exchanged with off network blockchains. Automating this process within a network protocol also fixes the human issues related to ownership of the keys as well as the initial transition from MAID to SAFE at network launch since there would be no need to burn those beautiful MAIDs. All of the off-network infrastructure for trading MAID for other tokens has already been built, might as well make use of it until there are direct fiat pairs for SAFE or XSC or whatever people end up labeling it.
Good thinking @jlpell.
There are just so many benefits with this approach.
Additionally; IMO there’s noone better suited than MaidSafe, to implement the gateway to the network economy - at network level from the start.
This is something far too important to trust any random player with, or just hoping that “the market” will solve it - there are no guarantees that they/it would, neither in good time nor in a good way.
One might think that additional features will delay the release even more, but I doubt there will be a faster onboarding of XSC-owning users than if MaidSafe already now plans and sets out to manage this part.
I don’t think it would be a big difference in dev time. A method for managing a “burn” address to handle a one time transfer will take the same amount of work initially. Not reusing that code for the benefit of a long term conversion mechanism would be a shame. The additional work that would be needed is to allow transfers out of the network back to MAID blockchain addresses.
That’s exactly my point. And that it would not be wise to just hope for some apt entity to show up and provide us with the long term conversion mechanism - that event seems very likely to take longer time, than any additional work needed for the long term use case. Better take the rudder in this case.
For it to work we need a bidirectional connection between Maid and Safecoin, something that is not planned, and two conversions for any user of BTC or Altcoin (Coin<->Maid<->Safecoin). Problematic, not only because of the work added to users and the lack of anonymity (decentralized exchanges are scarce) but because it implies, in many countries, tax declarations.
I think the point is, that it should be added to the plan.
It has to start somewhere, and it is no news that rapid growth of users is essential for the stability and success of the network. What is your proposal for an easier on-boarding of users? And a fully anonymous one?
If we can choose between increasing likelihood of network success and avoiding some (initial) tax declarations, the choice is quite simple IMO.
But if you have an idea for how to solve both, then of course that would be even better
And would not it be better to offer to the users of the largest network a much better option than the Lighning Network?
Would not that mean huge advertising for the Safe Network?
And if we talk about the technical aspects, if we are able to implement a bidirectional conversion between Maid and Safecoin (which needs a transaction in the BTC blockchain), what prevents a conversion between BTC and an Altcoin that lives inside Safe?