Proposal : Investigation into using Masternodes for anonymous web

@QuantumExplorer

We appreciate you haven't started the white paper yet, but surely you have some idea as to the features you are thinking off? Can at least give us a high level overview of what you are thinking at this stage?

Otherwise its too vague.
 
@halso Yes I can, so basically what I was thinking so far was the following.

From a user perspective the core client would have a button that would turn it into a VPN/autonomous gateway. When this happened it would choose a number N of masternodes deterministically based on the hash of the last block. It would then encrypt the outgoing message with N layers as is common with onion routing, laying out the route of the message and would encrypt the last layer in a PGP type style in order to ensure that the entry masternode does not know that it is an entry masternode, this would therefore make the entry anonymous to your system hiding your IP. Then after N hops the exit node will get your message, it will go request the content in clearnet. When it did it could either encrypt the data back or send it clearly (something to think about).

This is basic onion routing with some small extra stuff for us preventing government snooping in between you and the first node. What makes our system better is that the client will only select nodes that are verified to have 1000 DASH, hence it would be almost impossible to have N "malicious" nodes if N>8.

But there are some problems, the masternodes know who have 1000 DASH, and your client doesn't most likely hence the entry node would know your IP. You would therefore have to have 1000 DASH in your wallet to hide your IP from the original Masternode and prevent it from knowing you are the originator of a message. The problem here is if someone controlled the entry and exit nodes there could be a statistical analysis attack to break the system since with the entry node would know your IP, and the exit node would know the request. The 2 nodes of course do not know each other, but someone doing the attack and owning both nodes could maybe figure out with a certain degree of probability what you where doing. A problem to be researched in depth.

Now that was the easy part, here comes the hard part. How to get people to pay for the service without compromising the system? This is where there is no other system I can base myself off. Ideally we would need to find a solution where people pay for bandwidth and not by month/ day etc. My thoughts were to create a secondary currency on the masternode network, that is not divisible, let's call it ash (or gas, not yet sure on the name) . Each packet would then add some ash to each packet.

The system of course needs to be trustless and the ash can not be allowed to be traced back to the dash address who bought it or else there could be another weakness in the system. I'll be honest that the problems here are monumental to overcome and would require a completely novel type of blockchain system. Hence why I need to do months of research on it.

If we don't go the bandwidth route things can become simpler yet still very complicated. Here we wouldn't need ash, but just a verification by each node that the originator has paid for the day/week/month. How would you verify this without knowing the originator DASH address? You would have to go off an anonymous transaction. I haven't dived further than this yet.

Anyways these are my thoughts for anonymous web. VPN is a lot easier than this because VPN trusts the nodes. Hence you can just pay any N nodes for N hops. The nodes know what you are doing. A VPN system like this would work very well for china for example. The first HOP could be towards a node inside china, then the second hop would be again a peer outside of china. The great firewall people, knowing our system could be used for this could ban the IP addresses of all nodes outside of china as a response. Here we could come up with a system of having 2 network interfaces per masternode (with the second being IPV6 only). One that would cycle IP addresses (IP V6), one that wouldn't (main masternode IP). This would make systems like china GFW (great firewall) to have a really hard time blocking us, as I think their blacklist is manual. For them to block us they would need to integrate with our system. Further research would be needed to figure out ways to outsmart them if this became a problem.

These are the majority of my thoughts for now. I didn't want to post them before because I wanted to come up with very sturdy ideas before they were released to the public.
 
I am in complete disagreement of where you want to take your research, I don't like this second token idea, and I don't like us becoming building a TOR clone on top of the MN network, but I still voted yes. I voted yes because we need to build our culture around ongoing research and development to stay at the leading edge.

Hope the budget passes, and i wish you the best of luck,
Pablo.
 
@fible1 I really understand why you think the way you do. My goal here is basically to do as much research as possible and then have a community debate on whether we should implement some of the things I come up with.

I'm only leaning towards all of them being implemented. However doing this research could open up the door for other innovations that could benefit us even more.

Hidden apps on the network would be possible with onion routing, which could lead to darknet marketplaces. While this could be great for us it would also be a disaster. It's very debatable if we want this.

How we could be better though than tor is that we could maybe, through our governance system elect people represented by address that moderate such apps. Hence we would be decentralized yet allow moderation.

See there's a lot to think about.

I like the VPN idea the most as it would start earning the network a potentially serious amount of money and it would draw serious attention to our project from China.
 
Last edited:
@fible Also the second token was just an idea. It would only live on the masternode network, and end users would not be able to interact with it. I just need a system to pay out masternode operators based on their bandwidth without overloading the DASH blockchain. These tokens would also not be mined and would no extra ones would ever be generated. They would never be able to leave the masternode network either. It was just an idea. I'm hoping to find a better one I must admit.
 
QuantumExplorer said:
Proposal

My proposal has two sides. The first is that I would work to figure out how to add various types of anonymity usages to our system. These would include VPNs, anonymous browsing, hidden apps and IP blinding among possibly other use cases I haven't even thought of yet.

The end result of this would be a white paper explaining how such systems could work, as well as a plan to implement each feature. Inside you can expect mathematical and cryptological proofs ensuring the security and robustness of the system as well as the pros and cons of the various choices we will need to make when implementing these solutions.
Click to expand...

So you have no proposition to offer, you will not write a single row of code, and you want to be paid for browsing the internet and copy paste it.
Is this a rational proposal?

QuantumExplorer said:
The second side to my proposal is that I would figure out how to monetize such systems and have them work well for us. There are millions upon millions of VPN users, Dash could potentially be amazing for these users since we have nodes all around the world. And same thing for Tor.
Click to expand...

So you want to transform the dash network into a TOR or VPN network that offers paid services. Will you write code for that? Or the VPN-TOR transformation of the dash network (and the monetization of these services) will be only in theory?


And my question-request on anonymity.
How can you turn the IP address of a masternode owner to a private one, so that all the rest masternode owners are not allowed to know that IP? Do you have something to propose on that?
 
Last edited:
@demo Well in a project research comes before implementation. If someone just starts writing code without actually doing the research that code will most likely fail or have security vulnerabilities. In many of the other proposals research has been included in the coding part of the proposal, but this is a far bigger challenge, which is why I broke it up.

My goal is to propose cryptographically secure solutions, have them be vetted, and then form a team where I would then be writing code along with my teammates. However such a project will take a long time. It would be ludicrous to ask for such funds now.

I'm sorry to say but if you think that figuring out how to make this system work is possible just by browsing the web and copy/pasting you really have no clue about the complexities involved. I'm not trying to remake tor, I'm trying to make something better than tor that works faster, more securely and incentivizes nodes. If you think this can be done by copy pasting from the internet then you really should join the project and show me your copy pasting skillset.

I just rewrote my proposal, maybe you saw the previous version. If after that you really think I'm trying to steal money from the system, there's nothing more I can do.

If this proposal fails because of the research aspect (it could fail for other reasons that make more sense), it might underline that we have a problem with research proposals in general. So far Evan has done all the research for DASH, and because of his status as well as the fact that he holds a great deal of DASH he is heavily incentivized to continue doing so. However it would be wise for us to figure out how to incentivize other people to bring in innovation.
 
My question-request on anonymity.
How can you turn the IP address of a masternode owner to a private one, so that all the rest masternode owners are not allowed to know that IP? Do you have something to propose on that?
 
I have changed my votes to yes. More research in the field can only be a good thing. Even to build capability in the ecosystem.

However, i must admit im not convinced to much about the VPN angle.

Although i do like the idea of side chains. How would we respond to a big corporate if they came along and said 'i love your incentivised network, can i run my own chain on it?'

Perhaps we could look at the best sidechain ideas in the crypto world and make them better. Then include into Dash.
 
@halso I think you heard side-chain and thought of side-chains in the sense of ethereum, that's not what I'm proposing here. Side chains are for another day. This would be a specialized side-chain that serves only one purpose and that is to deal with remunerating nodes that provide a service. Having it on a "side chain" would allow us to ultra specialize it and reduce network usage/blockchain bloat of the main DASH chain since the main DASH chain isn't meant for something like this.
 
@demo If you are talking in general outside of the anonymity system and just for direct communication, such a system seems to me the opposite of what we built. Masternodes are addresses (transactions actually) with 1000 DASH associated with an IP address.

What problem are you trying to solve here?

The only possible solution I can see is if we allowed people to set up masternode tunnels where the entry masternode "proxy" with a known public IP would route all it's traffic to the hidden masternode. It is notable to think of a system where you could run multiple servers for one masternode and have your proxy alleviate load among them. But this is for the way way future.
 
You mentioned that there are two sides to this proposal, one side that will study all possebilities and in the end comes up with a white paper and another side that will try to implement that white paper.
Reading all the comments there seems to be a clear interest in the white paper side (me included), which makes me wonder if we should perhaps have this proposal first
focus on the white paper at reduced costs, look into the results and then contemplate making another proposal for actually implementing that white paper. That other proposal will then have its own costs.
 
@qwizzie I think you miss read something. The two sides of this proposal are all research/white paper, the second side being monetization of the system.

I get that this is expensive and I won't feel bad if MNOs turn me down. I just estimate that it will take me 2 months or so to do this, and I personally am not willing to live at a loss while working so hard.

The truth is I'm doing this because I really want this work done and no one else has done it yet or is stepping up to do it.
 
Last edited:
QuantumExplorer said:
@qwizzie I think you miss read something. The two sides of this proposal are all research/white paper, the second side being monetization of the system.

I get that this is expensive and I won't feel bad if MNOs turn me down. I just estimate that it will take me 2 months or so to do this, and I personally am not willing to live at a loss while working so hard.

The truth is I'm doing this because I really want this work done and no one else has done it yet or is stepping up to do it.
Click to expand...

I just re-read it and your right, sorry about that.
Also i share fible1's opinion and think this is wearth investigating, so i decided to vote yes for this one-time proposal of yours.
 
Last edited:
It would be a big change turning the MN network that handles instant transactions and anonymization into a VPN service - as I said to Quantum I don't think this aligns strategically with Dash's goals and second I don't see how it could be economical. Each end-user streaming at 8MBPS is going to cost MN owners a lot in bandwidth, and they are individually competing with large VPN providers who wholesale that bandwidth.

Plus it would but a massive strain on the network which has limited capacity for transport / processing / storage - Evolution will require a lot more bandwidth and storage than the current system and if the same system is being used to download torrents from KickAss for end-users paying $5 per month or dark-net users I doubt the network will be functioning effectively or doing what it was designed to do.

Theres also a lot of cross over here - Evolution will provide a layer of services that users can interact with - it would be far better for Quantum to work on anonymization at that level rather than adding a seperate layer below Evolution that can potentially conflict with it. So i am hoping he will do that instead :)

EDIT: By the way...i've worked with Quantum and he is a great dev but his time is limited. What I would really love to see is this proposal but with Quantum fulltime on Evolution instead. Just a thought...:)
 
Last edited:
As a masternode owner we think like investors. Therefore, I only vote for something that can help Dash becoming more value, or at least it has high level of certainty to improve value.

But researching for feasibility doesn't guaranty for value improvement, then I vote No for this proposal.
 
@AndyDark I like comments like yours a lot more which focus on the ability of this system.

Lets start with it not aligning with our goals. And this applies to @bhkien 's comment too. If we are able to pull this off we will find a market where we are able to be used but no other coin can be. It's like an onboarding event. Even though Dash is vying to be digital cash, we need to find markets that will take us. This gives a way to have a lot of people use our coins. I really do believe that if we offer VPN through our network, because of the great firewall, we would generate a ton of interest and excitement within China, which would drive our usage up and of course our market price which would in turn would cause more interest.

Again this paper is to figure out how we can make system(s) like this work. Just because it's not apparent now doesn't mean it can't be done.

First about bandwidth, one of the aspects of this paper is that I will try to figure out how we can be economically viable, either by charging per packet, or by charging for bandwidth amount.

For the massive strain part I really disagree though. Computationally the system could work on threads with lower importance than core so processing is no longer a problem. As for storage there would be none. Bandwidth for autonomous VPN usage could be configurable and limited and therefore not hurt core's bandwidth necessities.

As for evolution, the services it will provide are very different as far as I know. Being an anonymous user on a payment system is completely different to this proposal. There's really no overlap I can see. Can you explain in more detail what overlap you mean? I also see no possible conflicts, can you think of any?

If this proposal fails this time around I'll guess that at least a few people voted no because of them seeing Evolution as the only goal we should be pursuing right now. And I'm completely fine with MNOs voting that way.

Even though I might be shooting myself in the foot here the truth is that there are a lot of valid reasons to vote no for this proposal. They are:
-That you don't think we should ever go down this path. Anonymity will just lead to PR problems.
-That you don't think this is the right time for this proposal. All efforts should be put in one basket and that basket is evolution.

In my opinion the not valid reasons are :
-That you don't believe in research.
-That you don't think I'm good enough.
-That you don't think the system can be made. (It most likely can and should at least be investigated).

Even if this doesn't end up passing I'm happy I brought it up for a discussion.
 
Personally, I think this particular proposal deserves more credit than simply looking at the profit line:
  • consider it a punt
  • every advanced project needs some R&D (SpaceX etc), what other proposals do we have in this space?
  • a chance for some MNOs to provide additional services (earn more)
  • social benefit; returning to dash's roots regarding anonymization
  • to help protect the dash network in the long term because right now MNOs are the fall guy for end users actions
Sometimes you got to take a leap of faith and it's not super-expensive compared to other projects we've voted for.
 
QuantumExplorer said:
@AndyDark I like comments like yours a lot more which focus on the ability of this system.

Lets start with it not aligning with our goals. And this applies to @bhkien 's comment too. If we are able to pull this off we will find a market where we are able to be used but no other coin can be. It's like an onboarding event. Even though Dash is vying to be digital cash, we need to find markets that will take us. This gives a way to have a lot of people use our coins. I really do believe that if we offer VPN through our network, because of the great firewall, we would generate a ton of interest and excitement within China, which would drive our usage up and of course our market price which would in turn would cause more interest.

Again this paper is to figure out how we can make system(s) like this work. Just because it's not apparent now doesn't mean it can't be done.

First about bandwidth, one of the aspects of this paper is that I will try to figure out how we can be economically viable, either by charging per packet, or by charging for bandwidth amount.

For the massive strain part I really disagree though. Computationally the system could work on threads with lower importance than core so processing is no longer a problem. As for storage there would be none. Bandwidth for autonomous VPN usage could be configurable and limited and therefore not hurt core's bandwidth necessities.

As for evolution, the services it will provide are very different as far as I know. Being an anonymous user on a payment system is completely different to this proposal. There's really no overlap I can see. Can you explain in more detail what overlap you mean? I also see no possible conflicts, can you think of any?

If this proposal fails this time around I'll guess that at least a few people voted no because of them seeing Evolution as the only goal we should be pursuing right now. And I'm completely fine with MNOs voting that way.

Even though I might be shooting myself in the foot here the truth is that there are a lot of valid reasons to vote no for this proposal. They are:
-That you don't think we should ever go down this path. Anonymity will just lead to PR problems.
-That you don't think this is the right time for this proposal. All efforts should be put in one basket and that basket is evolution.

In my opinion the not valid reasons are :
-That you don't believe in research.
-That you don't think I'm good enough.
-That you don't think the system can be made. (It most likely can and should at least be investigated).

Even if this doesn't end up passing I'm happy I brought it up for a discussion.
Click to expand...

I think the best strategy is to keep the protocol in the core-business of decentralized/trustless payments. that's T1 basic (Bitcoin) transactions, T2 tx locking, anonymization, governance, T3 decentralized last-mile payment services (everything from digital cash payments, to paypal, online banking, openbazaar, or any services users want to build on the platform). Anon content delivery is a vertical application that's not payments related so trying to level that into the architecture is tying our fate to the success of that vertical application. It's also a different profile economically and technically, masternodes would need high-speed switching hw/NICs/fast pipes and access to cheap bandwidth to be profitable for MN operators and therefore viable as a long term feature. Dash is more suited to providing the decentralized infrastructure to power vertical applications as such, not to try to deliver those within the network tiers (anything not payments related i mean).

About the conflicting work, this was the main one:

"Hidden apps on the network would be possible with onion routing, which could lead to darknet marketplaces...How we could be better though than tor is that we could maybe, through our governance system elect people represented by address that moderate such apps. Hence we would be decentralized yet allow moderation."

this is basically a part of what Evolution is doing, without the onion routing, might be better to try to offer onion routing as a service option to Evolution apps they could build on that could be metered, rated, bought/sold within the T3 network, perhaps with the transport off-network, rather than a new core-network service i think. (maybe not onion routing either).
Just my thoughts though, propose what you like Quantum, it's a decentralized system and no one knows which way it's going to go, it's one of the great things about Dash :) I hope you get more involved in the Evo team though as you know, will send you these docs later or tomorrow :D
 
Quantum - I really like AndyDarks comments above about using this proposal and funds to get you onboard with Evolution fulltime - do you think this could be a possibility?

My opinion is that we should focus efforts on getting Evo complete then once we have a baseline, look at researching and developing additional services/options to extend the network even further. I agree that this research is important, and should be done, but with no clear picture as to what Evolution's capabilities will bring and or how they can be harnessed this may not allow your research to be as focused and effective as possible.

Thanks!
 
You must log in or register to reply here.
Back
Top