Proposal “modular-net-backend“ (Closed)Back
| Title: | Make Dash Network Censorship-Resistant: Modular Networking Backend for Dash Core |
| Owner: | ol |
| Monthly amount: | 90 DASH (2631 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
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.
As a result of this project, Dash will be improved in the following ways.
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:
The Timeline
The estimated work timeline is following.
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.
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.
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.
- Design and implement a framework for modular networking backends.
- Refactor code implementing current networking protocol into a module within this framework.
- 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. - Write documentation on implementing other networking backend modules.
- 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.
As a result of this project, Dash will be improved in the following ways.
- Ability to circumvent restrictive network filters and prevent blockchain forks caused by them.
- 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.
- 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.
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.
- Writing an abstract base for modular networking backends — done already.
- 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. - Abstracting away addressing (making CNetAddr class and all classes inheriting it universal and not specific to TCP) — almost done, 3 weeks more needed.
- Implementing changes to network address serialisation — 3 weeks.
- Completely moving current networking protocol implementation to modular networking backend — 3 weeks.
- Writing networking backend for I2P — 4 weeks.
- Writing documentation on writing other networking backends — 2 weeks.
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.
- Email: ol@infoserver.lv
- Matrix / Riot: @ol:infoserver.lv
- IRC: ol at Freenode network
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.
Show full description ...
Discussion: Should we fund this proposal?
Submit comment
|
No comments so far?
Be the first to start the discussion! |
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.
solarguy
But what I can see is that the amount of work done compared to other team members seems a bit light:
https://github.com/OlegGirko
If I am missing something here please do tell.
This particular project is at its beginning, and nothing was accepted upstream yet.
we will all wish to have this approved.
Of course, this is just my speculation, I have no insider info from DCG.
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. 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.
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.
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. 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?
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.
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.
Voting yes until I hear from DCG that this conflicts with what they are doing or that this is a bad idea.
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.
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:
https://www.dash.org/forum/threads/breaking-changes-to-extend-support-for-other-networks-and-address-formats.42529/
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.
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.
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.
Thank you to the proposal owner for keeping his progress updated on the forums. It's great that DCG is supportive of your proposal.