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

Ongoing DDoS attack on masternode network

Let me add on a little more...

tor exit nodes may be a contended point of observation, but tor's internal hidden service rendezvous mechanism is pretty damned cool.

I am very disappointed to see the electrum-dash .onion server was taken down for exactly this reason.

I believe DASH should be integrating tor directly into the infrastructure, not just having proxy settings in the client.

masternode.conf should look like this:

Code:
mn01 j2t1dn2aa7bc3kld.onion 93HaYBVUCYjEMeeH1Y4sBGLALQZE1Yc1K64xiqgX37tGBDQL8Xg 7603c20a05258c208b58b0a0d77603b9fc93d47cfa403035f87f3ce0af814566 0

But, you say... This would make the nodes unreachable to "normal" clients.

IPv4, IPv6, and Tor all need to be required on MNs so that clients can do as they please, or not.

There is no need to create DASH's own obfuscation network. tor already exists. All of the arguments against it relate to exit nodes.

As for acceptance into the iStore and other similar ramifications; tough cookies. Tor could/would simply be another supported protocol. No different from https. Modularity; make a no-tor version for China.

MNs can bridge. I've done it effectively on 12.0 via my IPv6 experiments. No, it doesn't result in fragmentation and islanding. You end up with contiguous layers that route through vertical bridge columns. Your single-protocol observation point makes it look like islands and fragmentation. But, if your observe from both sides it becomes clear that IPv4 looks fragmented from the IPv6 side, and the IPv6 looks fragmented from the IPv4 side, because the view is limited to the bridge points.

For a little more info on my research... I ran several dozen MNs. They were all bound to their IPv6, this is the key. I don't think the code was written intentionally to look this way, but it would prioritize IPv6, and still communicate by any other option available. 3 of the MNs were dual stacked, and they acted as a bridge to the remaining IPv6 nodes. In a small network, this seems isolated. But, they're not actually isolated because they were not the only IPv6 nodes out there. And those other IPv6 nodes were often dual-stacked bridges as well. So, what looks like islands from an IPv4 observer's perspective, was really just entry points to an entirely contiguous layer.

If DASH implemented a deliberate "tunnelling" layer... It could solve several incompatibility problems at the same time. There needs to be a network identifier that is not tied to the network address.

If a node finds that it has only IPv4 available, it still keeps track of all the IPv6 and .onion nodes that are shown to it, and it does not limit itself to same-protocol nodes. It tunnels by requesting through-nodes that support multiple protocols.

From a sterile perspective, one might conclude that that this creates bottlenecks and constricted points of failure. But, it's more organic than that. We're not looking at 200 nodes. We're looking at 4000. This DDos is a perfect example. How are you going to coordinate a 3-protocol DDos? I'm not saying it's impossible, but what's really happening here is a deliberate increase in attack surface. You're creating a thing that needs to be attacked in so many ways at once that you just can't. Instead of reduicing points of entry, give them so many requirements for an attack that it's too hard to do. If you can flood out the IPv6 nodes, the IPv4s are a perpetual backup. If you flood out the .onions, the IPv6 and IPv4 are still there... And most of them are multiple protocol. Instead of having only one way to spiderweb, have 2 or 3.

We shouldn't be looking at the "IPv6 fragmentation" as a problem because it's not really fragmentation. There was actually a complete functional ecosystem of IPv6 exactly like the IPv4. It simply communicated through limited IPv4 tunnels that looked like islands from the single-side perspective. If you required both and included a tunneling layer... Suddenly it's not just IP-layer routing. Instead of just distributing data shards on dashdrive, you can distribute the protocol itself across multiple transport layer types. Cloud protocol. Tor is not technically the same type of transport layer, but you could treat it as if it were by creating your own "superlayer."

This lesson teaches us that DASH needs to be multi-protocol, and the layer for accomplishing that could accommodate tor's hidden service rendezvous system just the same.

A token ring IPSEC hybrid.

Require MNs to run EVERYTHING, not restrict to IPv4.

Most ISPs that have a problem with tor, have a problem with exit nodes. Rarely do they care about hidden services, or even have a way to detect it. Most even have no problem with relays and bridges. And the best part: most of these tor-aware ISPs accept cryptocurrency for the same reasons they support tor.

This creates a MN network that naturally gravitates towards the most suited ISPs and the most capable MN Operators. The end-user network is transparent to the layer. Use whatever you can and the MNs bridge you to the whole thing.

Does eth0 have IPv4 and does it ping known addresses?
Yes: use it.
No: PoService penalty

Does eth0 have IPv6 and does it ping known addresses?
Yes: use it.
No: PoService penalty

Can we torify and reach known .onions?
Yes: use it.
No: PoService penalty

I'd even go so far as to suggest at 40/40/20 structure... No IPv4? You forfeit 40% of your MN payment. No IPv6? You forfeit 40% of your MN payment. No tor? You forfeit 20% of your MN payment.

This penalty structure also incentivizes LEARNING; hte most important part, and the reason this DDoS did anything at all... MNOs need to become better admins. Right now, MNOs are mostly ex-miners who treat it like a bare-minimum effort fire-and-forget money hose. They make no effort to do the job properly.

The costs to a middle-man service are going to increase to the point that they'll be taking 50% or more of your MN payments. Time to use your brain to get your money back; grow up and take care of it yourself, like a responsible adult. Node babysitting services may even outright refuse to support tor due to their bulk nature preventing them from being flexible, forfeiting 20% up front. Those node services also have the power to downvote such a change without even submitting a proposal... Greed and Power.

MNs are reaching a point that they need to carry these burdens to give the client more options. This is how the privacy concepts of tor and cryptocurrency finally become a unified theory. If you're running a hidden service anyway, may as well be a relay node, too. there's your white noise for both sides. Tor would finally have incentivized pipes, and true science and analysis could be done on a meaningful scale that benefits both. Take safenet and distributed markets as an example. these are closed ecosystems that came about as a result of echo chambers. Couldn't reach the outside market, so they created their own internal market to make it look like a thing that matters when it still doesn't. Crypto projects always seem to turn in on themselves because they fail to do what is needed to include the outside world.

I do not disagree with DASH's facebook-of-crypto features. I'm saying that you're building the roof before the foundation. You have to start at the bottom and work up, or you end up with re-engineering that is prohibitive, and you're stuck with limitations of a poorly-conceived legacy foundation. Wasn't the whole point of Evolution to re-engineer the mess? You're making the same mistake, again.

I'm not saying it would be easy. I realize some of the hurdles needing be overcome are quite large. Did you get this far by doing the easy thing? This is why I respect the coding side of DASH, but not the "business" side. The coders are busting their ass while the "biz devs" fiddle fuck around looking busy with fluff and pork, laughing all the way to the bank... The irony.

The worry of maintaining BTC backwards compatibility is holding you back in many areas. There's no reason to keep treating it as mandatory. If you want to do something better than BTC, you're going to have to break from it. The supposed advantage only exists inside the cryptosphere bubble. But that's the very problem. The whole point is to go outside of that bubble. Outside of the cryptosphere bubble, there is no BTC infrastructure to be compatible with. There's no need to be backwards compatible with something that functionally does not exist on the road you are traveling.

If you are a leader, act like it. Stop deferring to something else that can't get traction for very good reasons. Stop holding on to those reasons. Bitclones have an ecosystem of support systems around them due to lack of feature set. An infection growing in an open wound is not a good thing no matter how well you word it... "Organic ecosystem" is just another way of saying "even more middle-man scum fixing all the it's-a-feature-not-a-bug problems; for a price." It's worse than Visa out there... Bitclones' arrogant refusal to adapt have made crypto into the worst option. Don't imitate it by deferring to it. If you want to lead, act like it.
 
Last edited:
I'd even go so far as to suggest at 40/40/20 structure... No IPv4? You forfeit 40% of your MN payment. No IPv6? You forfeit 40% of your MN payment. No tor? You forfeit 20% of your MN payment.

Not again the same mistake! Magic numbers again?
Why 40/40/20 and not 39/41/20?
Is there a theory behind your proposed magic numbers?
If not, then you are simply wrong.

The 40/40/20 is not a solution, the solution is this.

I have already told you the truth for the very beginning, but you refuse to accept it.
It is very crucial to select randomly the IPbased and the anonymous new masternodes (according to the result of the appropriate poll that is always active, so that we can change the percentage of anonymous and IPbased new masternodes , according to the extend of the attack beeing made at the public dash network) because this randomness makes much more difficult the task of prohibiting the public dash network. The randomness can be calcutated using appropriate cryptographic protocols, among masternode owners.

The old mastenodes, as long as they are baptized and randomly toοκ their anonymous state, they can remain (or even they are forced to remain) anonymous for ever.

The solution is to vote the number.
 
Last edited:
If you were able to understand the content of the post, then the question answered itself.
Is there a theory behind your proposed magic numbers?
Yes.

But, the post was long enough already, and anyone who can understand the post can understand why.

1) Tor is not a true transport layer. It's just being treated like one by the proposed "superlayer" concept. Lack of tor should be punished less severely than lack of true TCP.
2) Exact numbers are not that important. The point is to punish lack of protocol support proportionally. Lack of IPv4/IPv6 is much worse than lack of Tor. It's also a lot easier, so there is no excuse NOT to do it. Thus, harsher punishment for being an obnoxiously lazy/stupid MNO. The desired outcome is boolean, so it doesn't have to have precision proportionality. "Whip them hard enough that they set it up properly." If 10% gets the job done, then so will 20%. Tor is a bit tougher. 20% is more of a "penalty I pay for not figuring it out yet, but I will because I want my 20% back!" 20% is more of a tax on being stupid. 40% is a true punitive measure for outright unacceptable behavior. Since 100% is the biggest number I have to work with... 40 + 40 + 20 = 100. It works out as intended. Lacking IPv4/IPv6 is outright unacceptable. Lack of Tor can be tolerated, but harshly discouraged.

If I had my way, a lack of any of those 3 would result in removal from the MN list; no more payments at all. But snowflakes can't handle something that harsh. Lets whip them only hard enough...

If you were looking for the understanding, instead of looking for a thing to troll about and post back to your silly vote with numbers crap, you would have understood and not asked such a stupid question.

The beatings will continue until morale improves! This is the law of nature. Your situation will not improve until you do.
 
Last edited:
Let me add on a little more...
Require MNs to run EVERYTHING, not restrict to IPv4.
That's brilliant! Not only we will be reachable by whatever protocol the user wants, we will have a much stronger, sturdier network.
Also, should any jurisdiction try to ban the use of Dash, it will be immediately circumventable. That option alone will serve as a deterring factor...
 
2) Exact numbers are not that important.
Are you kidding me? Exact numbers is very very important!
Unless you think that 98/1/1 is the same as 1/1/98.
The point is to punish lack of protocol support proportionally. Lack of IPv4/IPv6 is much worse than lack of Tor. It's also a lot easier, so there is no excuse NOT to do it. Thus, harsher punishment for being an obnoxiously lazy/stupid MNO. The desired outcome is boolean, so it doesn't have to have precision proportionality. "Whip them hard enough that they set it up properly." If 10% gets the job done, then so will 20%. Tor is a bit tougher. 20% is more of a "penalty I pay for not figuring it out yet, but I will because I want my 20% back!" 20% is more of a tax on being stupid. 40% is a true punitive measure for outright unacceptable behavior. Since 100% is the biggest number I have to work with... 40 + 40 + 20 = 100. It works out as intended. Lacking IPv4/IPv6 is outright unacceptable. Lack of Tor can be tolerated, but harshly discouraged.
Not again the same mistake! Magic numbers again?
Why 40/40/20 and not 39/41/20?
As you can see in the above quote, I understood that 40+40+20 equals 100 as long as my new numbers 39+41+20 were also equal to 100.
And you may believe that the correct is 40/40/20 but @UdjinM6 believes that only IP4 is suitable and he votes 100/0/0.
Why are you right, and why he is wrong? Exact numbers matter and are very very important.

My point is that each masternode should SPECIALIZE in a network type and you should not expect for EVERY masternode to have both IP4 and IP6 and tor and whatever else network type will be available. And you should have some nodes that will behave as gateways.
 
Last edited:
You quotes are usefull, but you are usally wrong.
But the below quote is right.
1) Tor is not a true transport layer. It's just being treated like one by the proposed "superlayer" concept. Lack of tor should be punished less severely than lack of true TCP.

Additionaly (and exactly because Tor is not a true transport layer which is a disadvantage) the Dash community should invest in bandwidth coins that are produced in independant wireless (wifi or optical) networks. At these networks there is a total control up to the physical transport layer and these networks cannot be easily controled by the state (especially the wireless optical networks are hard to discover).
 
Last edited:
That's brilliant! Not only we will be reachable by whatever protocol the user wants, we will have a much stronger, sturdier network.
Also, should any jurisdiction try to ban the use of Dash, it will be immediately circumventable. That option alone will serve as a deterring factor...
Thats not brilliant, that is stupid.

Every masternode should speciallize in a network type, and you should not expect every masternode to have all the network types. This will turn masternodes very heavy, and very hard to maintain. Kiss (keep it simple, stupid!)

I had proposed that every new masternode should be randomly baptized by the protocol to serve a specific network type, and that some masternodes should be randomly baptized to behave as the gateways between two (or more) different network types. And I insist that this is the correct solution.
 
Last edited:
@demo
No, your "solution" is the one that is needlessly complex.

All nodes must do it all, and all wallets and backend services must support all connection types. That way we have a real bulletproof fail-safe for, well, anything short of turning the internet off.
 
@demo
No, your "solution" is the one that is needlessly complex.

All nodes must do it all, and all wallets and backend services must support all connection types. That way we have a real bulletproof fail-safe for, well, anything short of turning the internet off.

@camosoul votes IPv4/IPv6/Tor = 40/40/20
@UdjinM6 votes IPv4/IPv6/Tor = 100/0/0

What is your vote? Is this "All nodes must do it all" translated to 33/33/33 ?
 
My vote would be every node must support IPv4, IPv6 and Tor, or not get paid at all.

So you consider IPv4, IPv6 and Tor as equal. So your vote is 33/33/33 although you are afraid to admit it.
 
My vote would be every node must support IPv4, IPv6 and Tor, or not get paid at all. And voting with numbers is bullshit.

Of course voting with numbers is bullshit, in your case.
Your vote is not a simple number vote. It is a conditional number vote.

IF the node supports all protocols, THEN pay it 33/33/33 ELSE pay nothing
 
So you consider IPv4, IPv6 and Tor as equal. So your vote is 33/33/33 although you are afraid to admit it.
No, it's not. I consider every one of them a REQUIREMENT.
Of course voting with numbers is bullshit, in your case.
Your vote is not a simple number vote. It is a conditional number vote.

IF the node supports all protocols, THEN pay it 33/33/33 ELSE pay nothing
No. IF the node supports all protocols, THEN pay it 100 ELSE pay nothing.
 
No, it's not. I consider every one of them a REQUIREMENT.

No. IF the node supports all protocols, THEN pay it 100 ELSE pay nothing.

You have just voted with numbers! 100 is a number, remember?

You should also take into account how the others express their number vote, in order to be able to extract a result. Thats why this 100 should be translated to the way the others are voting, which is in @camosoul's system the 33/33/33

So we have 3 votes until now:
@camosoul votes IPv4/IPv6/Tor = 40/40/20
@UdjinM6 votes IPv4/IPv6/Tor = 100/0/0
@lynx IF the node supports all protocols, THEN pay it 100 ELSE pay nothing

How can we extract a result from this vote? Do you want to decide something as a community, or you will fork to three pieces? This is were governance stands.
 
Last edited:
You have just voted with numbers! 100 is a number, remember?
9b3.png


You should also take into account how the others express their number vote, in order to be able to extract a result. Thats why this 100 should be translated to the way the others are voting, which is in @camosoul's system the 33/33/33
No, because it makes no sense. It could just as easily be translated to 0/0/100. Because the node will either get paid, or it won't.
 
No, because it makes no sense. It could just as easily be translated to 0/0/100. Because the node will either get paid, or it won't.

0/0/100 in @camosoul's system means that you support only the Tor network. This is not the case. You didnt understand his system.

  1. Camosoul pays 20 if someone supports only tor.
  2. Camosoul pays 40 if someone supports only IPv4.
  3. Camosoul pays 40 if someone supports only IPv6.
  4. Udjinm6 pays 100 if someone supports only IPv4
You pay nothing in the above four cases.

  1. Udjinm6 pays 0 if someone does not support IPv4.
You do the same in that case. So you have something in common with Udjinm6.

And the question is: Do you want to decide something as a community, or you will fork to three pieces? This is where governance stands. This is where vote with numbers, and conditional votes stands.
 
Last edited:
0/0/100 in @camosoul's system means that you support only the Tor network. This is not the case. You didnt understnad his system.
I understood his system. But my vote doesn't translate into that system, so I'm not using it.

So we have 3 votes until now:
@camosoul votes IPv4/IPv6/Tor = 40/40/20
@UdjinM6 votes IPv4/IPv6/Tor = 100/0/0
@lynx IF the node supports all protocols, THEN pay it 100 ELSE pay nothing

How can we extract a result from this vote? Do you want to decide something as a community, or you will fork to three pieces? This is were governance stands.
If we vote "Should masternodes be required to support all protocols? (yes/no)" there will be a clear decision one way or the other.
 
I understood his system. But my vote doesn't translate into that system, so I'm not using it.


If we vote "Should masternodes be required to support all protocols? (yes/no)" there will be a clear decision one way or the other.

Yes of course, you can use interdependent polls.
But even in that case, you have to decide the selection process.
 
Back
Top