MasterNode Scaling...

[Plateglassarmour]

From what I have been able to determine, Hashgraph is not resistant to adversarial nodes, or to Sybil attacks. There's a reason it's only been implemented in closed applications so far, and there is no discussion of having an open or public version of it yet (or at all.)

If you are curious if masternodes can scale to data-center proportions, while still being supported by income from transactions, the answer is yes, even assuming we are stuck at today's hardware and we never get price or performance improvements while needing to cover the whole world's transnational capacity.

This was proven (with supporting evidence) by one of the folks in the BCH community.

http://blog.vermorel.com/journal/2017/12/17/terabyte-blocks-for-bitcoin-cash.html

 

[bhkien]

Forget about blockchain.
What about this?
http://www.swirlds.com/downloads/SWIRLDS-TR-2016-02.pdf
Can this scale?

Very interesting. I think hashgraph can be used with masternode consensus mechanism.

 

[Arthyron]

The primary function of mining is NOT to slow down the blockchain but to ensure SCARCITY and decentralized coin distribution. Speed is worthless if we get the economics wrong.

...and how does it "get the economics right" and control the coin supply? By delaying the confirmation of blocks to the speed of a fraction of the total computing power and potential of the chain so that you don't have massive forking everywhere:

"as of October 2016 the Bitcoin network was running 1,900,000,000,000,000,000 — 1.9×1018, or 1.9 quintillion — hashes per second, or 1.14 x 1021 — 1.14 sextillion — per ten minutes. The difficulty is adjusted every two weeks — 2016 blocks — to keep the rate of solved blocks around one every ten minutes. The 1.14 sextillion calculations are thrown away,"

That's of course BTC rather than Dash, but that's generally how blockchains work. That's not how hashgraphs work, no wasted calculation, the network's speed and power is not reduced to make up for lossy algorithms.

From what I have been able to determine, Hashgraph is not resistant to adversarial nodes, or to Sybil attacks. There's a reason it's only been implemented in closed applications so far, and there is no discussion of having an open or public version of it yet (or at all.)

If you are curious if masternodes can scale to data-center proportions, while still being supported by income from transactions, the answer is yes, even assuming we are stuck at today's hardware and we never get price or performance improvements while needing to cover the whole world's transnational capacity.

This was proven (with supporting evidence) by one of the folks in the BCH community.

http://blog.vermorel.com/journal/2017/12/17/terabyte-blocks-for-bitcoin-cash.html

Hashgraph is just a consensus/trust algorithm. Sybil attacks aren't really relevant to the Hashgraph in particular but to *all* ledger systems. Baird does describe various ways a ledger implementing the Hashgraph could foil Sybil attacks, though: http://www.swirlds.com/downloads/Swirlds-and-Sybil-Attacks.pdf

As for masternode hardware scaling...yeesh...even if it's plausible that's still such an absurd and unnecessary expenditure of energy and wasted computational power. Why not just implement a better algorithm and avoid all of that entirely? It makes no sense to continue that way other than "people are already invested in it."

 

[Plateglassarmour]

As for masternode hardware scaling...yeesh...even if it's plausible that's still such an absurd and unnecessary expenditure of energy and wasted computational power. Why not just implement a better algorithm and avoid all of that entirely? It makes no sense to continue that way other than "people are already invested in it."

I don't actually have a problem with changing the algorithm; but I won't hold my breath for Hashgraph specifically until I see them with a public release.

There are always trade-offs, and I don't see how you can make the barrier to entry for changing a ledger so much lower (i.e. more efficient) without simultaneously lowering it's resistance to having the ledger changed by an attacking party.

If it can be done, and it truly is a revolutionary new way of getting around the byzantine general's problem, then by all means research it; but like I said, I won't hold my breath.

 

[Arthyron]

I don't actually have a problem with changing the algorithm; but I won't hold my breath for Hashgraph specifically until I see them with a public release.

There are always trade-offs, and I don't see how you can make the barrier to entry for changing a ledger so much lower (i.e. more efficient) without simultaneously lowering it's resistance to having the ledger changed by an attacking party.

If it can be done, and it truly is a revolutionary new way of getting around the byzantine general's problem, then by all means research it; but like I said, I won't hold my breath.

Certainly it can be said that it's untested in a public ledger setting, but from a theoretical perspective, it's no *more* vulnerable than extant systems. The "barrier for entry" for changing the ledger is not lower, it's just tabulated differently, and there isn't wasted, unnecessary computation.

 

[Arthyron]

@Plateglassarmour -- They finally released their public ledger/cryptocurrency system: http://www.hederahashgraph.com They've got quite a lot of great features, technology, partners, integrations, and use cases already. Thankfully they're not gunning for the payment sector exclusively (the payment/currency aspect is moreso to secure the network and fuel Dapp operations), but it's pretty impressive.

 

[billyjoeallen]

Masternode Hosting benefits from economies of scale. That's why services such as Splawik's host two thirds of the MNs already. This is a dangerous situation perilously close to being a single point of failure. With drastically greater hardware requirements, this problem will only get worse as the network grows.

 

[solarguy]

Masternode Hosting benefits from economies of scale. That's why services such as Splawik's host two thirds of the MNs already. This is a dangerous situation perilously close to being a single point of failure. With drastically greater hardware requirements, this problem will only get worse as the network grows.

I would like to see where that data comes from.

thanks

 

[billyjoeallen]

https://chainz.cryptoid.info/dash/masternodes.dws

 

[solarguy]

https://chainz.cryptoid.info/dash/masternodes.dws

I don't quite see how that data suggests that masternode sharing services host 2/3 of the Masternodes. Illuminate me.

thanks,

 

[billyjoeallen]

http://178.254.23.111/~pub/Dash/masternode_ISPs.html

 

[Macrochip]

@splawik21 does not host "2/3 of all Masternodes" and to suggest so is nothing short of crazy. None of the links you've provided even remotely hint at that claim.

 

[billyjoeallen]

You're gonna quibble over details? The data shows clear centralization. I never said Splawik by himself hosts 2/3 of MNs. I said hosting services LIKE Splawik's. Stop fixating on a goddamn fraction and pay attention. How the hell does running even TWO masternodes in the same datacenter help the network? It doesn't. The whole concept was that we could be our own banks.

 

[Macrochip]

The data shows clear centralization.

The data shows clear decentralization. No single provider hosts a significant portion of the network alone. The largest one owns a mere 17%. How is that "centralized"? That's not even enough to feasibly trace a 4-round PrivateSend (chance: 0.09%).

I said hosting services LIKE Splawik

Splawik offers shared nodes. You're saying 2/3 of all Masternodes are shared nodes. That's how everyone including solarguy understood your statement. If you wanted to say 2/3 of all Masternodes are with commercial hosting providers like Choopa, AWS, OVH etc. which are very distinct from what Splawik and MooCow are offering, then say that instead of confusing people by conflating two entirely different business models.

How the hell does running even TWO masternodes in the same datacenter help the network?

Easy: Two nodes are twice as powerful as one. That's why it helps the network. "Same datacenter" is completely irrelevant as long as the nodes are distributed among many other providers as well. And they are as the data shows.

The whole concept was that we could be our own banks.

Economic reality is this: Masternode owners want to pay as little as possible for hosting. Users of the network expect the best performance possible. Commercial VPS providers offer high bandwidth, high-speed connections for cheap prices. The incentives are clearly laid out and the success of Dash speaks for itself. Nothing about that goes against being your own bank. Or do you keep your 1000 Dash collateral with the VPS provider?

 

[billyjoeallen]

It's not a shared masternode if you expose your private key. You are basically renting out your Dash to someone who uses them as MN collateral. Whoever has the keys owns the node.

Splawik offers TWO services: 1. MN hosting where the fee is lower but you can keep your private keys, provided you have 1K dash and 2. what you are calling "shared masternodes" where you give him your key meaning you become a dash lender and get a tiny rate of interest in exchange for risking your entire stack. so half the business model is the same.

 

[solarguy]

It's not a shared masternode if you expose your private key. You are basically renting out your Dash to someone who uses them as MN collateral. Whoever has the keys owns the node.

Splawik offers TWO services: 1. MN hosting where the fee is lower but you can keep your private keys, provided you have 1K dash and 2. what you are calling "shared masternodes" where you give him your key meaning you become a dash lender and get a tiny rate of interest in exchange for risking your entire stack. so half the business model is the same.

And, so far as I can tell, the data you give us still provides no evidence that anything like a majority of MasterNodes fall under either of Splawik's services.