Unlike hardware, with code it’s easy and cheap to add features. For a car manufacturer, even changing something as peripheral as a wing mirror means retooling a production line, testing aerodynamics, coordinating the global supply chain, and so forth, whereas the software equivalent can be written by a single developer in an afternoon. That’s beautiful, but it’s also dangerous: it’s always much easier to add than it is to subtract, and bloat creates more bloat — it’s self-multiplying. That’s why, strange as it may seem, we’re much prouder of the code we manage to strip out than the extras we add in.
From the outside, that might look like digging holes and then filling them in again, but actually it’s about sculpting each chunk of material til it’s as light as can be. That’s the bit that takes time, skill and precision. But because in the Safe Network every part is intimately connected with every other, the benefits of that effort eventually spread network wide.
Which is all fine and dandy until we want to demonstrate some important feature that is dependent on all that intricate chiselling going on upstream. DBCs v0.1 are now done, but DBCs are intimately connected with everything else. DBCs allow us to pay for storage, storage needs reliable handover, handover needs … etc. That’s why, as mentioned last week, we’ll be looking at a demonstration payment-only network that’s independent of the work underway elsewhere, one that doesn’t stray too far from the path we’re already on.
General progress
@Chriso is simplifying the CLI, removing the old node command and renaming the node safenode — thanks for all the naming suggestions BTW 
.
@Anselme has added a reason field to SpentProofs, written by the client and checkable by elders without requiring a signature. This should mean we don’t need elders to sign data, eliminating at a stroke the ‘old key attack’ vector, where a bad actor with a previous key can validate data. He has also cleaned up some odd loops in AE gossip logic.
Meanwhile, @joshuef has improved relocation logs to remove a couple of bogus and confusing errors that were making flows hard to track, and also tweaked node age for the same reason.
@Qi_ma has been refactoring section peers so we have membership logic in one solid place. This should help prevent issues centred around membership churn.
And @oetyng has been working on the payment network, the reason for which is given below.
A payment-only network
There are hard tech problems we are solving, and this is the real work of the project. But at the same time, we have some parts that already work well, one of those being our DBC technology. The payment network is a way to showcase—step by step—the attributes, features and performance of DBCs while we wait for our other innovations to mature.
We also want to be able to test and refine the UX, check for unexpected glitches, and work on other areas of the design.
A test payment network will be a way of emulating the way DBCs will be used on the Safe Network, one that’s independent of data storage while remaining as close as possible to the overall network design, with its safeguards against Sybil attacks, DDoS and the rest.
As stated in the intro: we want to make sure it fits as closely as possible with the rest of the design, while still being able to function as a standalone prototype. That way, we can take our learnings and just drop them back in.
Having a functioning payment-only network also has some tantalising potential to help us address some additional challenges:
- Demonstrate and market some of the groundbreaking technology we have been working on. Getting eyes on the project and excitement for what is to come.
- Directly benchmark performance against incumbent currencies.
- Demonstrate the USPs over incumbents e.g. performance, unique abilities of DBCs, environmental credentials, etc.
- Reignite interest in a project that some may have forgotten about.
- Pilot exchange integration and acceptance of the economic tech ahead of full launch, where it will be critical to Network growth and accessibility.
- Build out a node base ahead of full launch.
So all-in-all, it’s worth the feasibility assessment we are undertaking, as it could be a useful tool along the way to launch.
Testing… testing…
It would also be a way to spread risk, and tackle problems in a staged and coordinated way; as a big bang launch of both a payment and data network would naturally have more potential points of failure.
Whereas a separate payments network could be piloted and iterated upon without the combined risk. We can learn from it and continue to build. It’s not the full vision, but one part of a series of products that we can build, and will continue to build as we work towards that vision. A more agile approach if you will.
We need to work out how to secure it at each baby-step to avoid the inevitable spammers and attacks, but it’s full of promise.
Useful Links
Feel free to reply below with links to translations of this dev update and moderators will add them here:
Russian ; 
German ; 
Spanish ; 
French; 
Bulgarian
As an open source project, we’re always looking for feedback, comments and community contributions - so don’t be shy, join in and let’s create the Safe Network together!
for going for the payment network first. Although this is only a small part of the SafeNetwork, it would probably turn out to be the most advanced cryptocurrency out there, right off the bat.
). In fact the entire team is dedicated through and through to the fundamentals.