camosoul
Well-known member
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:
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.
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 0But, 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:
