Proposal “modular-net-backend“ (Closed)Back

Title:Make Dash Network Censorship-Resistant: Modular Networking Backend for Dash Core
Monthly amount: 90 DASH (6740 USD)
Completed payments: no payments occurred yet (4 month remaining)
Payment start/end: 2018-12-17 / 2019-04-15 (added on 2018-12-14)
Final voting deadline: in passed
Votes: 61 Yes / 31 No / 0 Abstain

Proposal description


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

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

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

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.


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.
  • Email:
  • Matrix / Riot:
  • IRC: ol at Freenode network
You can follow development progress here:
But be careful if you check out this branch: I'm going to rebase it a lot before submitting pull requests.

Show full description ...

Discussion: Should we fund this proposal?

Submit comment
1 point,1 year ago
Voting yes. Question. Recently the Monero network endeavored and failed to develop a similar i2p-based concept, albeit much broader in scope. Their Kovri project was under development by one individual, anonimal, for about 2 years and it appears he bit off more than he could chew or they've decided that Kovri is the wrong path. What do you suppose your chances of success are as a one man team? Certainly your competence isn't in question here, as a former Core member. I guess, do you think the scope of the work you seek to do is within the reach of a one man team, would be my question?
0 points,1 year ago
I'm not going to do it Kovri way and write another I2P implementation. I'm going to write a module that is interoperable with already existing I2P implementations: Java I2P and C++ I2PD. They both implement I2CP, a protocol for client applications to access I2P service, and there are client libraries that implement I2CP (I'm not going to reinvent a wheel here as well).

This approach has a drawback that you have to install I2P service on your computer to have access to I2P network, but writing my own I2P implementation is not a realistic goal.
1 point,1 year ago
In the closing minutes of this treasury cycle, note that this prop still JUST fits. 119 Dash out of 119 Dash remaining. Let's shove it over and see if core is interested. Hey, why not?
1 point,1 year ago
0 points,1 year ago
First of I am not a github expert, so I am not 100% sure if am reading it correctly:
But what I can see is that the amount of work done compared to other team members seems a bit light:

If I am missing something here please do tell.
0 points,1 year ago
The main activity was in summer and autumn 2017 when I was massively backporting network related changes from Bitcoin.
This particular project is at its beginning, and nothing was accepted upstream yet.
2 points,1 year ago
The guy makes some valid points. Seems like a no-brainer. Can core weigh in here to let us know if they will be happy if this passes?
3 points,1 year ago
Should the western clown governments ever decide to mercilessly crackdown on Crypto,
we will all wish to have this approved.
3 points,1 year ago
why isn't this a core thing? 90% of the budget is going to core, why are they not doing this? this is core programming?
1 point,1 year ago
This is definitely a core thing, but I think that DCG is busy with Evolution and has no resources for other projects.
Of course, this is just my speculation, I have no insider info from DCG.
1 point,1 year ago
After reading all the opinions, and observing that the development is compatible with the future characteristics of the code. My vote is positive. You have my support. Thank you for you proposal.
1 point,1 year ago
It is a clear YES, don't understand the NO or ABSTAIN-voters. Hope this somehow passes.
0 points,1 year ago
Yes x13.
1 point,1 year ago
voting YES.
1 point,1 year ago
This sounds very interesting and brings up some questions:
1) This makes allot of sense to me, and I don't quit get why Dash core group never did this ?, these features in fact have been cause for pumps for certain coins
2) I am sorry if I am rude but I think its an important question, why are you no longer working for Dash ?
1 point,1 year ago
I'm not working for DCG for some time, so my replies to your questions are my own guesses and speculation.

1. I think, DCG is now focused on what they think is more important: Evolution. I presume, they now have no resources to hire people to work on other projects that they think can be postponed.

2. When I started working for DCG, I indicated my intention to modularise networking code from the beginning, and my work there was related to networking all that time. As Dash price was going down, at some point reorganisation has started in DCG, leading to termination of contracts of few team members; I was among them. What was common between us? We were working on something not directly related to Evolution. Coincidence? I don't think so.
1 point,1 year ago
Do you think you're work is also compatible with Dash evolution ?
4 points,1 year ago
It's not inly compatible, but also beneficial for Evolution.

It would make no sense to start working on something incompatible with Evolution because it won't be accepted upstream (and running incompatible node will make you banned by all other nodes).

The scope of my project is communication between nodes: to allow nodes to use a new anonimising protocol. But the existing protocol will remain the same. The only change needed is to allow nodes to announce peers from other networks. The immediate goal of this project is to prevent the network of Dash nodes (and masternodes) from being split into isolated islands by network filtering.

Evolution will allow thin clients to use masternodes as trusted servers, and current rules require a masternode to have a public IPv4 address. Once this policy decision is amended to allow masternodes to announce addresses from other networks, my project can be easily extended to allow thin clients to communicate to masternodes anonimously. Hence, you can consider this work to be a potential extension of Evolution.
3 points,1 year ago
When I created this proposal, Dash price was about €50 (€50.1 at lowest point so far, to be precise), and my target was €4500 per month to support my subsistence during the time of working on this project. Now Dash price went up, and I have no way to amend the proposal to lower amount of Dash.

Hence, if my proposal gets approved, and Dash does not fall to €50 back, I'll receive more money than I initially expected. This will allow to support my subsistence for longer period of time, so I'm thinking about stretch goals.

Both current TCP-based protocol and I2P-based one are stream-based (providing reliable stream of bytes with no explicit message boundaries), so the first obvious idea is to extend modular networking backend to support datagram-based protocols (unreliable stream of messages with explicit message boundaries) and implement a high-performance UCP-based protocol.

However, I'd like to hear other interesting ideas.

If this proposal gets approved, I'm going to start a thread at Dash Forums to discuss ideas for further extension of modular networking backend, and use extra time of my work that extra money from my proposal can support to implement most interesting ideas from that discussion.
1 point,1 year ago
In you're post you just said you'll focus on smaller one man scope, I think this should be you're main goal, other stuff should come later.
1 point,1 year ago
Of course, I'm going to do everything in sequence. Modular networking backend first, I2P backend second, then everything else.
3 points,1 year ago
Can any of the no voters chime in why they're voting no? All the comments are tentatively in favour of voting yes, subject to DCG objections, and I can't really figure out why anyone would vote down what sounds like major improvements to the resiliency of the network.
1 point,1 year ago
I have some questions regarding this:
1. Would this slow down propagation, thus would miners use it, would everyone need to use i2p to keep the anonymity?
2. would we run our own nodes? (i2p nodes are voluntary, thus probably slow and underpowered. Could we run our own nodes as part of our MN responsibilities?
3. I've always felt it would be a natural fit for our network nodes to run a high throughput "tor-like" service, for a tiny fee, so that there would be no speed and volume limits. Might this be something we could do?

Anyway, I fear it would slow down propagation and possibly interfere with instant send due to the low quality nodes. Are you certain that's not the case?
0 points,1 year ago
Sorry for my late reply. This is a weekend before Christmas in Europe, so I was away from my computer most of the time during these days.

1. It should not slow down propagation because using I2P does not preclude using existing TCP-based protocol. A block is propagated using the fastest way between nodes anyway. I2P will not slow down existing communication. It will make communication possible when it's impossible using regular TCP-based protocol.

2a. The goal of modular networking backend is to be able for a node to be a part of different networks *simultaneously*. Normally, there should not be TCP-only and I2P-only nodes. The only reason for a node to be I2P-only is when it has no way to communicate using existing TCP-based protocol (filtered by provider, for example), but it still shold announce nodes from other networks, to make more lucky nodes that have access to these networks be able to connect to these nodes.

2b. Speaking about masternodes, the current situation is different. They are still full nodes and will be able to communicate with other full nodes using different network backends, but current rules require masternodes to have IPv4 address to provide masternode functionality. This is not a technical limitation, but rather policy decision. I would like this policy decision to be amended to either allow a masternode to announce secondary addresses than can be used to access this masternode, or just to have multiple addresses without distinction between primary and secondary ones. But this is a separate topic for discussion with Dash Core Group.

3. Although most visible goal of my project is providing communication using anonymising I2P network, this is actually a secondary goal (not by importance, but by the timeline of goals). The primary goal is making networking implementation modular to allow writing implementations of other network protocols much easier. This will allow to experiment with different network protocols, not only for better privacy and anonimity, but also for better performance.
0 points,1 year ago
Over 4 months the price is going to change a lot from $50. Wouldn't it make more sense to ask for the money after the work is done and release upon payment of the US dollar amount you want.
1 point,1 year ago
The dev cost even with the 60% gain from the bottom is still below the average salaries big companies pay for blockchain devs fyi. Good blockchain devs earn 130k+ / year.
0 points,1 year ago
130k/year = 10,800 per month. He should submit a proposal at the end for 3x10,800= 32,400. I think there is little risk he won't receive the approval. Plus there is less risk for both parties of dramatic price swings. I'm open to being wrong here but it makes sense to me at least.
0 points,1 year ago
This is my first proposal, so I'm not experienced much in making proposals.
When creating this proposal, I was not intending to receive money comparable to salary of blockchain developer. I just wanted to have income for the duration of this work to be able to pay my bills and support my subsistence at reasonable level to not worry about doing other jobs.
At the time when I created this proposal, Dash price went down to about €50 for 1 dash (please note that prices where I live is in EUR, not USD), so my target was €4500 per month. Now Dash price went up, so if this trend is not reversed, this will allow me to live on this money longer. If this is the case, we can think about stretch goals.
0 points,1 year ago
I think this is a tough proposal for MNOs to understand. If it doesn't pass this time around, is it possible to partner up with DCG to get it funded? It's tough getting funding these days. Sounds like an excellent improvement if it doesn't affect the functionality of regular communications between nodes. Gotta admit TCPIP freaking never made sense to me, so this is going to go over my head as well :P
2 points,1 year ago
I believe this is a great way to attract talent to improve the dash codebase: have experts take on improving parts that are already open-source.

Voting yes until I hear from DCG that this conflicts with what they are doing or that this is a bad idea.
1 point,1 year ago
Yes from me, but i also would like an opinion on this matter by a Dash Core Team member.
0 points,1 year ago
Voting yes. improving anonymity as a MNO is one of the biggest and growing concerns I have for the long term viability of this decentralised network. Although the scope of this work is only for anonymising regular nodes it sounds like this is a step in the right direction towards realising that.
0 points,1 year ago
Once Evolution is released and client-server protocol stabilised, modular networking backend framework can be easily used for client-server communication as well.
5 points,1 year ago
I just wanted to bring to everyone's attention that a member of DCG has confirmed on DN Discord that Ol has worked with DCG in the past and has done "a very good job at backporting network related refactorings from Bitcoin." Whether or not you ultimately support this proposal, I believe this is both relevant and important to factor in to your decision.
0 points,1 year ago
I'm all for this but wouldn't you need the Evo code to be open sourced before diving in?
2 points,1 year ago
Development of Dash Core (software that runs full nodes and masternodes) is already opensourced. You can follow this development in develop brahch on GitHub.
I base my changes on this branch as well, and rebase it quite often to keep my development in sync and prevent change conflicts.
Other parts of Evolution project are separate from Dash Core software, and my changes do not affect them at all.
0 points,1 year ago
How can we be certain that this would be compatible with all the new features that will be released by Core team in the coming months and years?
0 points,1 year ago
Because doing otherwise makes no sense.
The most important part of my changes is refactoring code of Dash Core (the software that runs all full nodes and masternodes) to make networking modular. This is internal code change that does not affect functioning of the software, but allows to extend it with additional modules.
Then a change in inter-node communication protocol is needed to allow announcing known peers from different networks, and I've described this change in this Dash Forum post:
So far, the reaction from Dash Core team was positive, so it means that they have no intention to accept this change once it's implemented.
Evolution features will be implemented mostly in other software outside of Dash Core. There are changes in Dash Core implemented already (like special transactions), and support for Evolution will be implemented on top of them. My changes do not affect special transactions, and I rebase my changes on latest develop branch quite often.
0 points,1 year ago
Sorry, I made a typo, and I don't know how to edit comments.
Instead of "they have no intention to accept this change" I mean "they have no intention to oppose accepting this change", so everything is OK.
1 point,1 year ago
I think I would need someone from DCG to give this their blessing before voting. It is important that all efforts are moving forward in concert.
0 points,1 year ago
Well, I wouldn't say a blessing is necessary but they would need to confirm that this doesn't conflict with their plans.

I'll be voting yes, for now, to give this some visibility and because I think it's a good idea to do. But if there is no comment from Core i will change my vote back again.
0 points,1 year ago
Just wanted to reiterate that this confirmation was provided, see my comment above.
0 points,1 year ago
I agree, and will do the same.
1 point,1 year ago
Yes from me. The implications of having an unblockable blockchain will grow as we get bigger. When governments and their banker friends decide we are becoming a serious threat we will wish we had done this.
Thank you to the proposal owner for keeping his progress updated on the forums. It's great that DCG is supportive of your proposal.