• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Pre-Proposal: Modular Networking Backend for Dash Core

ol

New member
Abstract

This is a proposal to improve Dash Core software by making its networking support more modular, resilient and extensible. Adding an extension for working on top of I2P, (an anonymous overlay network) is also included in this proposal.

This will allow to use a network protocol that prevents oppressive regimes and other adversaries from disrupting Dash network and damaging trust in Dash. Also, this will open a way to add extensions for other network protocols for better resilience and performance.

The Problem

The current Dash Core software uses TCP-based protocol inherited from Bitcoin. Implementation of this protocol is hardcoded into the software. It uses fixed port number (9999) for mainnet. The same protocol is used for communication between all full nodes, including masternodes. All communication is performed in cleartext, without any measures to conceal identity of participating nodes or content of messages passed between them.

Although existing protocol allows quite efficient communication, it does not prevent the Dash network from malicious interference and censorship by powerful adversaries. Until now, this was not a big problem in practice, but situation may change when Dash becomes a major payment system big enough to compete with national currencies of states with oppressive regimes that can afford large-scale network filtering.

Current Dash inter-node protocol is very easy to filter because of its use of fixed port number. But even if Dash switches to dynamic port numbers, its protocol is still vulnerable to deep packet inspection: every message starts with a header that is easily distinguishable as Dash protocol header.

Government-mandated ISP-level filtering can disrupt all or most nodes in a whole country, rendering Dash network unavailable without using special measures like VPNs. But there is a threat much more sinister than that: filtering at a border, like Chinese Great Firewall does. This can cause a long-lasting network split that leads to blockchain fork with disastrous consequences.

Imagine if a large part of Dash network becomes isolated. This part has enough full nodes and masternodes to keep functioning independently. It develops its own blockchain fork with enough blocks mined that transactions in this fork are treated by merchants as confirmed. Then after days or weeks of total isolation, a node that has connectivity to both parts of the network suddenly appears. It starts announcing a longer valid blockchain fork that contains no blocks that were mined in isolated part, making all transactions in those blocks unconfirmed again. Essentially, merchants suddenly lose money that were considered safely received long ago, causing irreparable damage to trust in Dash.

A way for Dash nodes to circumvent censorship and filtering is needed to prevent disastrous long-term blockchain forks and other attacks against Dash network.

The Solution

I propose to perform the following work on improving Dash Core software.
  1. Design and implement a framework for modular networking backends.
  2. Refactor code implementing current networking protocol into a module within this framework.
  3. Implement additional networking module allowing inter-node communication through I2P (Invisible Internet Project), an anonymous overlay network that provides even higher level of anonimity than Tor and is extremely difficult to block.
  4. Write documentation on implementing other networking backend modules.
I2P is truly distributed overlay network without a single point of failure. Compared to Tor, I2P
  • doesn't use dedicated directory servers to store list of available nodes;
  • uses packet switching instead of circuit switching, allowing better resilience;
  • routes inbound and outbound traffic using different routes, making traffic analysis much harder;
  • mixes parts of messages from different peers with control messages together, making traffic analysis much harder;
  • uses several transports based on TCP and UDP.
Benefits to Dash

As a result of this project, Dash will be improved in the following ways.
  1. Ability to circumvent restrictive network filters and prevent blockchain forks caused by them.
  2. Ability to have fully anonymous nodes running over I2P only. Fully anonymous masternodes will be theoretically possible, but further discussion is needed whether to allow them.
  3. A facility for easy extension by writing other modules if necessary, implementing various network protocols. This extensibility allows unlimited possibilities of protocols not only for privacy and anonimity, but also for performance and resilience: datagram-based protocols (including multicast), non-IP based protocols etc., but these ideas are out of scope of this proposal.
The Proposal

A salary for one person team to work for 4 months is needed to complete this project.
Monthly salary will be €4500 per month, or €18000 total.
At current rate of €50 per Dash it's 90 Dash per month or 360 Dash total.

The deliverable of this proposal will be Dash Core node software that has a framework to be extended with network protocol modules and has two networking modules implementing:
  • existing TCP-based protocol;
  • a new protocol that works on top of I2P.

The Timeline

The estimated work timeline is following.
  1. Writing an abstract base for modular networking backends — done already.
  2. Preparing proposal for changing serialisation format of network address in existing inter-node protocol and various cache files to be variable-size and include protocol label — 2 weeks.
  3. Abstracting away addressing (making CNetAddr class and all classes inheriting it universal and not specific to TCP) — almost done, 3 weeks more needed.
  4. Implementing changes to network address serialisation — 3 weeks.
  5. Completely moving current networking protocol implementation to modular networking backend — 3 weeks.
  6. Writing networking backend for I2P — 4 weeks.
  7. Writing documentation on writing other networking backends — 2 weeks.
This work introduces breaking change of network protocol to allow use of universal addresses that are not specific to TCP/IP. This change requires approval from Dash Core Team. Preparing a DIP for that is probably needed. There's still time until 1.0 (Evolution) release, but it's better to make breaking changes earlier. This is the only breaking change needed, so it has to be done as quickly as possible before stable release.

The Team

I am Oleg Girko, experienced C++ developer and former Dash Core team member. I was working on networking code refactoring, so I know this code quite well. Also, I have background in Linux system administration, network administration, networking, grid computing, system and network security.

I think, a short-term software development project like this with narrow and well-defined scope is ideal for one-person team.

I need funding to complete this work, so I can concentrate on it and work full-time without being distracted by need to do other work to support my subsistence during this period of time.

Contacts

If you have questions or suggestions about this proposal, please leave a comments in this thread.

Also, you can contact me using the following channels.
You can follow development progress here:
https://github.com/OlegGirko/dash/commits/modular_net_backend
But be careful if you check out this branch: I'm going to rebase it a lot before submitting pull requests.

Update. Added a link to Github branch.
Update. Added short summary of I2P benefits.
Update. Increased required amount in Dash to adjust to Dash price fall.
Update. Proposal submitted: https://www.dashcentral.org/p/modular-net-backend
 
Last edited:
As you know the treasury is very diminised thanks to Dash Core group taking 60% of the treasury leaving an average of 850 Dash. At this moment, most of the remaining is fought very hashly by contending groups.

I think at this point a lot of MNO are very careful to see proof of the ROI for spending. I suggest to actually give more structure to your budget in a way compatible with the treasury model.

I will recommend to separate the development on stages and on budget per stage and ask for the reward per stage. Also not have it on one single payment, and even starting before that first payment since we really need to be sure you are capable to deliver.

Feel free to spend time on the Discord development and maybe having a core developer to co-sign your project.
 
Very interesting.

Couple questions:

1. Do you plan to have this development be performed in open manner? I mean, public github repo, so anyone can follow the progress?
2. How your work would be integrated with Dash Core wallet? Will you create PR to the Dash Core Wallet public repo and update it as you progress and the baseline (dash core wallet) changes?
3. Are there arrangements with Dash Core team to integrate your changes, so it will be used, not forgotten? Or, perhaps, you have different plans to integrate your changes into the network?
 
Very interesting indeed. I also would like more information on how this can be developed and integrated in our current software and how well this will work with Dash Evolution (v1.0)
I can definitely see the advantage that this project could bring to Dash.
 
I support this. Before I could vote yes on the proposal, I would need to see input from dcg devs indicating this is doable. I dont feel it should be rushed, however. At 37 dash per month we have room for it.
The concerns raised by this proposal are real, as I feel true adoption takes place in the worst-manages countries first, whose leaders are of the sort willing to block websites and protocols that may undermine their grip. It would be great to have an unblockable blockchain. Could any other cryptos make this claim?
 
As you know the treasury is very diminised thanks to Dash Core group taking 60% of the treasury leaving an average of 850 Dash. At this moment, most of the remaining is fought very hashly by contending groups.

I think at this point a lot of MNO are very careful to see proof of the ROI for spending. I suggest to actually give more structure to your budget in a way compatible with the treasury model.

I will recommend to separate the development on stages and on budget per stage and ask for the reward per stage. Also not have it on one single payment, and even starting before that first payment since we really need to be sure you are capable to deliver.

Feel free to spend time on the Discord development and maybe having a core developer to co-sign your project.

Thank you for your suggestions.
It's OK for me to split this proposal into 4 proposals, one per month, but my concern is that I'll burn 20 Dash instead of 5 as a result. I can include 5 Dash fee into each proposal, but it will cost 15 Dash extra for the whole Dash governance system.
 
This type of proposal is ideal for escrow. One proposal, with escrow, should be enough to ensure completion without burning extra dash.
 
Very interesting.
Thank you for your positive feedback.
1. Do you plan to have this development be performed in open manner? I mean, public github repo, so anyone can follow the progress?
Yes, of course. I'll be pushing my branch to Github on the regular basis. I've added a link to this branch to the main post.
2. How your work would be integrated with Dash Core wallet? Will you create PR to the Dash Core Wallet public repo and update it as you progress and the baseline (dash core wallet) changes?
Yes, I'm going to submit pull requests to develop branch of main Dash project at Github.
3. Are there arrangements with Dash Core team to integrate your changes, so it will be used, not forgotten? Or, perhaps, you have different plans to integrate your changes into the network?
I'll need cooperation from Dash Core team to review and merge my pull requests.
Also, my proposal needs one breaking change to Dash protocol to change serialisation of network addresses to include protocol label and allow addresses of different sizes for different protocols. For example, I2P uses 256-bit addresses that are SHA2-256 hashes. This change should be made before next stable release that introduces other breaking changes anyway.
 
Last edited:
Very interesting indeed.
Thank you for your positive feedback.
I also would like more information on how this can be developed and integrated in our current software
Networking backend modularisation and moving current networking code into a module has to be integrated into Dash Core software, and will be submitted as pull requests to the main Dash project at Github.
All further networking backends can be developed separately and loaded as plugins, but it would make sense to have most important modules (like I2P backend) to be included in main Dash repo as well.
and how well this will work with Dash Evolution (v1.0)
This work is related to inner workings of communication between full nodes and does not affect work on Dash Evolution.
However, modular networking backend can be used for accepting client connections by masternodes as well, allowing anonymous clients to use I2P.
 
Last edited:
I support this.
Thank you for your positive feedback.
Before I could vote yes on the proposal, I would need to see input from dcg devs indicating this is doable.
I absolutely agree with you. I'd like to hear feedback from Dash Core team on its willingness to accept changes like this.
I dont feel it should be rushed, however. At 37 dash per month we have room for it.
There is a reason to not delay this change much: it requires a breaking change to serialisation format of network address. There are other breaking changes planned before 1.0 (Evolution) release, so it makes sense to use this window of opportunity.
The concerns raised by this proposal are real, as I feel true adoption takes place in the worst-manages countries first, whose leaders are of the sort willing to block websites and protocols that may undermine their grip. It would be great to have an unblockable blockchain. Could any other cryptos make this claim?
Monero project is working on its own implementation of I2P node software called Kovri.
 
This type of proposal is ideal for escrow. One proposal, with escrow, should be enough to ensure completion without burning extra dash.
Thank you for this great idea!
This is my first pre-proposal, so could you please point me to more detailed information about how to use escrow?
 
I've updated the main post with a link to a branch at Github where I'm planning to work on this project. As you see, it already contains changes I was doing some time ago. Now it's time to continue this work.
 
Thank you for your suggestions.
It's OK for me to split this proposal into 4 proposals, one per month, but my concern is that I'll burn 20 Dash instead of 5 as a result. I can include 5 Dash fee into each proposal, but it will cost 15 Dash extra for the whole Dash governance system.
yes you can put the 5 dash back on your proposal, but remember you can also ask for multi-month proposal with only the 5 initial DASh, just make sure that you specify that in the proposal period.

Escrow is also a good advice, I will go with that as well.
 
Yes, of course. I'll be pushing my branch to Github on the regular basis. I've added a link to this branch to the main post.

Thanks, subscribed.

For example, I2P uses 256-bit addresses that are SHA2-256 hashes. This change should be made before next stable release that introduces other breaking changes anyway.

Can you also include a one-paragraph summary why you choose to use I2P network instead of Tor network. You will get such questions, because the Tor is more popular, so better be prepared.
 
Interesting proposal. I’m not very versed with I2p.

Would your proposal introduce the need to change the ip adress requirement of the deterministic masternode dip?

You mentioned having been a core dev before. Do you see any evolution functionality not being feasible after the changes you propose?
 
Hello, @ol, and thank you for your pre-proposal. This is a very interesting project, and quite ambitious for one person, but I can see the value in it, especially for the cost described. I played around with I2P a few years back, but at the time there just wasn't much happening with it, and I can't imagine it has grown in use or activity or capability since then. I suppose my primary concern is that the Dash code is changing immensely over the next few months, so I'm not sure right now would be the best time to begin an undertaking such as this. I'd love to see if one of the developers from DCG could comment on the feasibility and viability of this project. I echo the suggestion to visit one of the Dash Discord servers where you can more directly interact with one of our developers or the more prominent developers in the community to hash out the feasibility and viability of the project. If it can be determined that such a project is feasible and viable even with all the changes taking place, then I'd be happy to support a project like this.
 
Can you also include a one-paragraph summary why you choose to use I2P network instead of Tor network.
Added a summary of I2P benefits to the main post.
Tor and I2P have different purposes. Tor is designed as anonymising proxy to regular Internet, whereas I2P is true darknet, so nodes of I2P are supposed to communicate only to other nodes of I2P. It doesn't include exit nodes to access regular Internet (although, they are possible through third-party software).
The main problem with Tor is that it uses pre-configured set of directory servers. This means that Tor can be rendered inaccessible by blocking access to a small number of IP addresses of these servers. On the other hand, I2P is fully distributed, all nodes have enough information to connect to the rest of I2P network. I2P uses several transports, and recently introduced NTCP2 transport makes I2P even more difficult to detect and block.
 
Would your proposal introduce the need to change the ip adress requirement of the deterministic masternode dip?
My proposal requires inter-node communication protocol to be changed to allow more generic addresses in all places where an I2P address can be used instead of IP address.
Although the part of the protocol that deals with masternodes can be left intact, I would like it to be extended as well. Even if we keep requirement for a masternode to have a fixed IP address for now (most likely), this requirement can be lifted later if I2P masternodes prove to be valuable enough to reward them. A breaking change is required anyway, so it makes sense to switch to extended addresses in all places, so other breaking changes are not necessary in future.

Also, implementing this proposal can potentially open other interesting possibilities. For example, masternodes can be rewarded proportionally to number of networks they participate in (or other useful, but optional capabilities they have).
You mentioned having been a core dev before. Do you see any evolution functionality not being feasible after the changes you propose?
I don't see any functionality that can be lost as a result of this proposal's implementation.
In contrary, this proposal allows to extend Evolution functionality to allow anonymous clients connecting through I2P or any other future extended protocol.
 
Hello, @ol, and thank you for your pre-proposal. This is a very interesting project, and quite ambitious for one person, but I can see the value in it, especially for the cost described.
Thank you for your positive feedback.
I played around with I2P a few years back, but at the time there just wasn't much happening with it, and I can't imagine it has grown in use or activity or capability since then.
There are interesting developments in I2P world that I find important.
  1. i2pd, a fully-featured C++ implementation, was released few years ago. As a result, I2P is now available even on small devices (like Raspberry PI) without need to install Java runtime.
  2. NTCP2 transport was introduced very recently, making I2P detection much more difficult even with deep packet inspection.
  3. Monero project started its own I2P implementation called Kovri: https://getkovri.org/
If Dash nodes start using I2P, it will definitely cause significant growth of I2P network.
I suppose my primary concern is that the Dash code is changing immensely over the next few months, so I'm not sure right now would be the best time to begin an undertaking such as this.
In contrary, I think that if there are breaking changes, it's better to do as many of them as possible together to have one big mandatory network upgrade instead of many small ones.
I'd love to see if one of the developers from DCG could comment on the feasibility and viability of this project. I echo the suggestion to visit one of the Dash Discord servers where you can more directly interact with one of our developers or the more prominent developers in the community to hash out the feasibility and viability of the project. If it can be determined that such a project is feasible and viable even with all the changes taking place, then I'd be happy to support a project like this.
I'd like to hear feedback from Dash Core team members, not only on feasibility, but also on willingness to accept such changes.
 
Update.

I have bad news and good news.

You already know bad news: Dash price went down since my initial post. Hence, I had to increase amount in Dash to reflect that change. Now it's 90 Dash per month or 360 Dash total. I'm still targeting for €4500 per month, that will be about €3000 after I pay all taxes.

Good news is that I already started working on this project. My progress so far:
  • I've found places where Dash protocol has to be changed, and it appeared that changes are not so dramatic and can be implemented in a way that allows smooth transition.
  • I wrote a proposal to implement these changes in Dash forum.
  • I received positive feedback in Discord for my proposal to implement changes. There are some implementation details open for discussion, but overall attitude from Dash Core team is positive.
  • I've successfully rebased my already implemented changes on recent develop branch.
The time is running out for the next budget payment, so I'm going to submit my proposal to Dash budget system.
 
Back
Top