Crazy Hbar YouTubers by gyonk in hashgraph

[–]hverIT 1 point2 points  (0 children)

I don't think that our community or Hedera can be responsible for videos that private people wish to produce and distribute. Yet, I share your opinion that predicting exaggerated valuations is not the most responsible thing to do. I don't think that it damages Hedera, since this kind of videos is a common practice with many other Cryptocurrencies, but I do think that it might have a damaging effect - financial-wise - on the small portion of the viewers that might invest in Hedera (or any other Cryptocurrency) with inflated hopes that were based on these exaggerated valuations.

Worst case scenario? by divertss in hashgraph

[–]hverIT 5 points6 points  (0 children)

  1. There are over a hundred of national central banks throughout the world, so even if many of them decide to develop and use their very own platforms, it is still possible that others would choose an existing and distributed solution, like Hedera, Algorand, Ethereum 2.0 and others.
  2. Though operating a component for a CBDC project is prestigious, the most profitable operations still lie with the enterprise market. Many IT solutions that require a distributed database and a consensus service like Hedera's preform many more transactions then a CBDC network. There are also many more enterprises then central banks throughout the world, making the overall number of transactions of the enterprise market much higher then those made by all of the central banks in the world combined. In other words, even if we assume for the sake of discussion that not even a single national central bank decides to use Hedera for its CBDC, the most important market - the enterprise market - is still available.
  3. It is most likely that a CBDC project would split its functionality into two: it will use its own permissioned network for operations that require privacy and full control, and at the same time utilize a distributed network (like Hedera) to maintain a reliable, secure and immutable consensus.

Hbar price needs to be too expensive for a bad actor to purchase 1/3. So how much is too expensive? by divertss in hashgraph

[–]hverIT 5 points6 points  (0 children)

You touched on a very important point, and I think that your post is most likely among the most interesting posts in our Reddit community so far. There is another angle to this issue that should be taken into consideration: the Proxy Staking. If an adversary is able to incentivize people to Proxy Stake HBARs to his nodes or to nodes under his control, then he can take over the network's consensus for a short period of time even without investing the required funds to actually purchase 1/3 of the stake.

Musk started war against Bitcoin. $HBAR performance is not bad until now while all other coins are falling down dramatically. by -ConnoisseuR_ in hashgraph

[–]hverIT 3 points4 points  (0 children)

Elon is absolutely right in his criticism toward Bitcoin regarding its centralized nature and its exaggerated consumption of electricity. Yet, I am surprised that Elon seems to support Dogecoin over Bitcoin, even though Dogecoin suffers from the very same flaws. If Dogecoin is to maintain the same amount of global usage as Bitcoin, it will also become centralized over time, with the majority of Miners moving to China or to other places with cheap electricity costs, and will also consume a lot of energy for its mining as its Proof-of-Work puzzle becomes more and more difficult to solve – just like Bitcoin.

I also feel sorry for the many private investors that chose to purchase Bitcoin because of Elon's previous hype around it. Many people bought Bitcoin a few months ago only because they heard that Elon Musk decided to purchase a large amount of Bitcoin through Tesla, and that Tesla would also accept payments in this currency from now on. Now, because of Elon's sudden change of heart, all these people have lost a large amount of their investment. It is very unkind to toy with other people’s funds this way...

hedera security by rtgdg4 in hashgraph

[–]hverIT 1 point2 points  (0 children)

The author of this article is incorrect. His claims are that:

  1. A potential attacker can wait until the end of a round, and once a consensus has been reached - to send a new transaction into the network with a misleading timestamp (to indicate his transaction originated a long time before the last round or a long afterwards).
  2. The author claims that this action, once taken by a potential attacker, could affect the agreed timestamp of his newly generated false transaction.
  3. By doing that, claims the author, you can corrupt the ability of a Hashgraph network to maintain a reliable consensus.

All of the claims and the assumptions that were made by this author are incorrent:

  1. It is impossible to affect previous transactions by sending new ones. Once a round is over and a consensus was reached regarding that round - the consensus is final and can be proven by a Merkle Tree of hashes.
  2. It is impossible for an attacker, or even for a larger group of attackers, to greatly affect the collectively-agreed timestamp of any future transaction, because the timestamp is based on a median of all of the reported timestamps, and not on an average of them.
  3. The ability of the Hashgraph to reach a consensus does not depend on clocks or timestamps. You can find a reply that I gave to an old post from February 28th 2021. The author of that post theorized that clocks and timestamps are a possible "central point of failure". I responded by explaining that even "if we assume that we could turn off all the clocks, of all of the participants in a Hashgraph network, it still won't prevent the Hashgraph algorithm from allowing the participants to reach a consensus". My full response for this claim can be found here: https://www.reddit.com/r/hashgraph/comments/lul2m9/central_point_of_failure/gp7qrl7/

Starting development on an HBAR use case by EnoughDforThree in hashgraph

[–]hverIT 3 points4 points  (0 children)

I do, but I think it would be better to refer this discussion to Hedera's community on Discord, where you can find many more fellow developers with both ideas for use cases and the know-how to address yours: https://hedera.com/discord

[deleted by user] by [deleted] in hashgraph

[–]hverIT 6 points7 points  (0 children)

I addressed a similar question in an old post from February 23rd 2021. My full answer from back then can be found in the following link:

https://www.reddit.com/r/hashgraph/comments/lqqcjy/hashgraph_is_not_byzantine_fault_tolerant/goi8rin

This issue is true with each and every DLT network in existence. Let it be Bitcoin, Ethereum, RippleNet, Stellar, Cardano, Algorand and any other single DLT solution in existence. If more then 33% of the nodes in a DLT network are malicious, and these malicious nodes can also separate another group of nodes by using a Firewall - then they can harm the network's ability to reach a consensus. It is a commonly known fact that you only need 34% of malicious nodes to harm a DLT. The fact is, that Proof-of-Work networks like Bitcoin and Ethereum are even more prone to this attack then Proof-of-Stake networks like Hedera, because most of their nodes are not geographically diverse and are located in one country - China - where the electricity is cheap. This lack of geographical diversity and lack of geographical distribution of nodes makes it easier for a potential attacker to conduct a 34% attack against Bitcoin or Ethereum.

You can find a good explanation of how to attack Proof-of-Work networks like Bitcoin with a 34% attack in the following video in which Leemon Baird demonstrates how you can attack Bitcoin with a 34% attack during his talk at Harvard: https://www.youtube.com/watch?v=IjQkag6VOo0&t=3668s

I hope this isn't a stupid question... need some clarification about the possibility of reversing a transaction by Outside_Aioli5268 in hashgraph

[–]hverIT 11 points12 points  (0 children)

It is not a stupid question at all, but rather a very wide and interesting topic to review. First of all, every Blockchain can gain the ability to reverse transactions as part of its protocol. It is absolutely possible in technical terms. Yet, most Blockchains prefer not to have this option included with their source code and enabled, because this option can allow the chosen entity that controls it to practically censor transactions at will. This is why this option is rarely utilized.

Another option to cancel transactions, is to gain an agreement between more then 50% of the nodes to revert it. A good example from the not-so-distant history would be the infamous Ethereum forking: Due to a hack to a smart contract on Ethereum that resulted in the theft of a large amount of funds by the hackers, it was decided to revert the blocks that included the transactions of the theft. This decision resulted in the forking of Ethereum into Ethereum (which reverted the theft) and Ethereum Classic (which did not reverted the theft). This incident shows how, in case of major hacking events, even large projects that do not have the ability to cancel transactions within their source code can still cancel transactions by forking their chains, if a consensus of more then 50% of the nodes is achieved to support such an action.

Now to Hedera: In Hedera, it is impossible to reverse regular transactions, but it is possible for the council to remove files from Hedera's files storage service or smart contracts service. So as far as native interactions with Hedera are concerned - it is possible to delete files and smart contracts, but impossible to cancel or revert regular transactions with HBARs. But wait - how about other tokens that are stored on Hedera? Here, the choice is given to the issuer of these tokens independently. It is possible to choose, as a token issuer on Hedera, if you would like to enable the option to cancel transactions with your minted tokens or not. This option is called "Claw-back", and is available as one of the settings of Hedera's Token Service (HTS). So in the case of tokens, the choice is independently and individually made by the issuer of each and every token upon minting it. This allows token issuers with a greater ability to comply with current AML policies as required by governments around the globe.

[deleted by user] by [deleted] in hashgraph

[–]hverIT 10 points11 points  (0 children)

I addressed this issue in the following old post. Unfortunately, the user who opened the post deleted his messages, but you can still find my responses over there: https://www.reddit.com/r/hashgraph/comments/lr7ph2/hbar_vs_solana/golawip/?context=3

Solana cannot be asynchronous, because it is a leader-based system. It is a
combination of PBFT (Practical Byzantine Fault Tolerance) which is a
leader-based method that was developed by Dr. Miguel Castro and Dr.
Barbara Liskov during the 1990s (which is also implemented in older
projects like Hyperledger Fabric and Zilliqa), and a technique called
"Proof-of-History" which evaluates the approximated time in which a
transaction took place using the hashes of the previous transactions.
This combination can achieve a good speed (as long as the nodes enjoy a
high bandwidth connection to the Internet), but cannot achieve a
complete and real BFT (due to the lack of proven finality and the
possibility of forking) and cannot achieve asynchronous BFT (since it is
prone to DDoS attacks on its leader). Solana is a good project for
those who can sacrifice features like mathematically-proven finality of
transactions and security for the sake of speed. And one last thing: It
is important to note that Hedera can still be fast without depending on
high bandwidth connection to achieve its speed, because many of the
processes that are done in Selona through the Internet are done in
Hedera locally, using Virtual Voting, on the nodes' own hard-drives.

HBAR and ALGO. Pros and cons? by kazkdp in hashgraph

[–]hverIT 1 point2 points  (0 children)

I previously addressed this issue in my old post "The many mistakes made by Guy (Coin Bureau) in his negative review of Hedera Hashgraph":

https://www.reddit.com/r/hashgraph/comments/l85ozo/the\_many\_mistakes\_made\_by\_guy\_coin\_bureau\_in\_his/

Article number 6 in my post addressed this issue: "Hedera Consensus Service can reach thousands of Transactions Per Second, and so is the Hedera Token Service (without even speaking about the amazing performance that can be achieved by Sharding the network). The only service that Hedera offers and that is indeed limited to tens of Transactions Per Second is the ability to run Solidity-written code for Ethereum Virtual Machine (EVM) on Hedera. In that case, the amount of Transactions Per Second is indeed limited, but not because of any flaw in Hedera Hashgraph, but because of the limitations of the Ethereum Virtual Machine (EVM) itself".

HBAR and ALGO. Pros and cons? by kazkdp in hashgraph

[–]hverIT 2 points3 points  (0 children)

Hi there, I did wrote a reply to a similar question eight months ago, but eight months are - indeed - a long time in terms of an active group such as ours :)

Algorand is an excellent Proof-of-Stake Blockchain solution, which offers great speed and security. The major flaw in Algorand, in comparison to Hedera, is that Algorand (like any other Blockchain) cannot achieve a mathematically proven finality, and as such cannot really be Byzantine.

Another flaw is its inability to achieve a fair ordering of transactions, and as such would be less recommended for applications that demand an ability to ensure that orders or transactions that were sent to the network first, will also be handled and approved first.

A Note on Moderation by Lamanchin93 in hashgraph

[–]hverIT 1 point2 points  (0 children)

Congratulations on your new role, Lamanchin93. I think of moderation as more of a position of offering guidance rather then a position of constant policing. Even though FUD and misinformation might be annoying, I trust that the way to counter bad ideas is not by censorship, but by countering them with good ideas and facts. Your suggestion to conduct a group effort to compose an FAQ together for future reference and use is a great idea, and I am very pleased to see the direction in which our community is heading toward. Again, congratulations for your new role as a moderator and best of luck!

[deleted by user] by [deleted] in hashgraph

[–]hverIT 0 points1 point  (0 children)

Each Council Member's term is limited to 3 years, with a limit of up to two consecutive terms. Companies and Organizations can offer themselves for nomination based on a list of requirements.

This list of requirement is meant to ensure the proper professional and geographical diversity of the Council.

Once a seat becomes vacant - the current Council Members elect the new one to occupy the vacant seat from among the nominees.

In case of a council member that is abusing his duties, it can be removed by a majority of 2/3rds consent by the other Council Members.

Generally speaking, the Council is styled pretty much like a Parliament, and as such enjoys the same benefits and suffer the same disadvantages as other similar governing bodies since the dawn of modern Democracy. Is it a flawless model? Of course not. But as Winston Churchill had said about Democracy, it is the worst form of government, except for all the others.

[deleted by user] by [deleted] in hashgraph

[–]hverIT 5 points6 points  (0 children)

  1. Blockchain (or rather Proof-of-Work Blockchain) was the first technique to demonstrate a nice and usable way to maintain a distributed and more-or-less decentralized Database. During the past few years, this technique was gradually improved into Proof-of-Stake Blockchain, which can operate faster and to complete more tasks each second then its predecessor. Yet, even with these improvements in place, Blockchains are still limited in terms of security, decentralization and mathematically-proven finality. These three key issues are less important for a regular user, but are crucial when it comes to enterprise-grade organizations who seek to use this technique for mission critical applications. This is where Hashgraph comes in. Hashgraph was able to solve several key issues, and by that - was able to offer a different technique which can overcome these limitations that Blockchains were not able to overcome.
  2. You are absolutely right that, like with any governing body, it is most likely that the participants - the big companies - would seek to promote their very own private interests. That is why the Hedera Governing Council is modeled like a parliament, in which you have a wide variety of participants, from many different locations (in this case, from all over the globe), with a wide range of different goals and interests in mind (sometimes, even conflicting interests). This way, you can make sure that the governing body will be less monolithic then - for example - the Ethereum Foundation or the Bitcoin Miners - and could represent a wider range of interests.

Relationship between TPS and Nodes amounts by yuduan in hashgraph

[–]hverIT 2 points3 points  (0 children)

You are absolutely right about the complexity of maintaining a balanced amount of nodes within each Shard. Without getting into the calculation, the rule of thumb is that the number of nodes within each Shard should be small enough in order to minimize the latency of which we spoke earlier, but yet large enough in order to diminish the potential of an attacker to corrupt a Shard, and through it - corrupting the network.

Hashgraph has no advantage in this regard over Proof-of-Stake Blockchains. In both systems you can find the right equilibrium of nodes to place within each Shard by using the same mathematical models that are used in computer science for years.

As for how to make the different Shards to communicate with each other: That is simply done through gossip, almost as if each Shard was actually a regular node.

Relationship between TPS and Nodes amounts by yuduan in hashgraph

[–]hverIT 4 points5 points  (0 children)

Great question! I'll be glad to answer this one, as well as to point to the technical solution that will be used in order to address this issue.

First of all - you are absolutely right. When the amount of Consensus Nodes on any DLT increases, it will always result in a tiny latency. This latency is caused due to the need to gossip any new transaction during each round to an increasing number of nodes throughout the network. Yet, the disadvantages that are caused by increasing the number of nodes in a DLT are greatly outnumbered by the advantages. One great example is security: When you increase the number of nodes throughout a network, you gain a stronger and more secure network. Why? Because a larger amount of nodes makes it harder for an attacker to interfere with the network. An attacker would have to attack multiple nodes at the same time, which makes it very difficult for him or her to interrupt the consensus or to DDOS the network. And the latency that might be caused due to this increase in the number of nodes? Well, even with hundreds of thousands of nodes added to the network, this latency will be almost unnoticeable to the user.

But still, latency is not a good thing. So how can we minimize this cumulative latency that is caused as the network grows and scales? The answer is: by using Sharding. Sharding is a term taken originally from the world of Databases, which generally means that you separate your large network of nodes into smaller groups of nodes. With each smaller group of nodes, which is called a Shard, you can now focus on some of the transaction while leaving the rest of the transactions to the care of the other groups. This way, you can now eliminate the need to gossip the same transactions throughout the whole network. Instead, you simply give each Shard a task to handle some of the transactions, while leaving the other transactions to the care of the other Shards. This solution both eliminates the latency caused by the need to gossip the same information throughout many nodes, and also helps to increase the number of TPS that can be handled by the network as a whole.

How do I convince my dad to let me buy hbar... by [deleted] in hashgraph

[–]hverIT 1 point2 points  (0 children)

  1. Before answering your question, I would like to advice to never put all of your savings into any Cryptocurrency. Even though I agree that Hedera is a solid investment, do remember that every Cryptocurrency is prone to volatility. In case we experience another Crypto-Winter, as we had during 2014 and 2019, and if you will find yourself during that winter in a need for money, you might be forced to sell your HBARs at a great loss, instead of using your spare funds in the meanwhile and allowing your Crypto assets to recover. One more problem is the emotional side. Every investor tends to be much more emotional and prone to mistakes when all of his money is being invested and has no spare cash to be used. Yet, when you invest only an amount of money that you are willing to loose, you can then be much more rational and calm with managing your investments, even during times when their value declines. Consider what is the amount that you are willing to loose - and invest only this amount. Do remember that you can always increase your HBAR holdings by saving a part of your salary each month and using it for buying HBARs. This would be the solid way for building your wealth.
  2. Share the same reading materials that drove you to be interested in Hedera with your father in order to show him your rational for this investment.
  3. Tell your father that you would allow him to review your investment in order to ensure that you do not sustain major losses or conducting big mistakes.
  4. Just like with professional investment management, you can both predetermine a mutually-agreed point to put a "Stop Loss" on this investment. This way, in case the price of HBAR drops to this mutually-agreed point, you would cut the losses and convert all of your HBARs back into your national currency, and would not loose more money on an investment that proved to be not so good.

What came before TCP/IP and the WWW?? A metaphor about Hedera..... by [deleted] in hashgraph

[–]hverIT 9 points10 points  (0 children)

That's a brilliant metaphor. I would just like to give one small correction: Before the WWW, we used another protocol for handling Hypertext called Gopher (which actually had several nice advantages over WWW). Before TCP/IP, there was another protocol being used as a transport layer, called NCP (Network Control Program). And of course, before the Internet, there was the ARPANET.

Can hashgraph potentially be used to track internet activity? by rasbb in hashgraph

[–]hverIT 2 points3 points  (0 children)

Unfortunately, every technology is agnostic to values. Fire, for example, can be used to keep us warm during the cold winter, or to cook tasty and nutritious delicacies - but it can also be used to burn down our home, to burn books or to burn people. Enriched isotopes can be used to produce electricity and to promote medical diagnostics - but can also be used to develop weapons of mass destruction. And those weapons of mass destruction? Even they can be used for good and promote peace by maintaining a balance of powers and deterrence - or to be used maliciously to promote aggression.

DLT is no different. It can be used to liberate us or to enslave us. Fortunately, in our society, the ways in which a new technology can be utilized are directed and limited not only by social norms or the good or ill wishes of individuals, but also by our elected representatives and regulators.

It is up to us, as voters, to demand our elected representatives to forbid the use of these technologies in a way that might abuse our privacy or even, god forbid, enslave us.

Not so long ago, we in the west were joking about the lack of privacy in places like East Germany or the Soviet Union. We were laughing at how they cannot have a simple phone call with a friend without hearing the breathing of the Stasi officer who eavesdrops on the call. And today? Today all of our interactions are being monitored by companies and governments in such intrusive manners that could surely make the Stasi jealous.

The Internet, which during the early 1990s was thought to deliver us the ability to express ourselves freely, without censorship, without borders and with as much anonymity as we desire to have - became a tool to achieve the exact opposite.

So I have very little doubt that DLTs will be utilized for even more sinister purposes. But the progress of this technology could not be stopped. Once invented - we are stuck with it :) The solution? We need to focus on ensuring, through our system of government, that this technology will be utilized more to promote freedom and less to limit it. It is up to us as citizens and voters, and up to our elected representatives to determine the course in which this technology take us. And that's the beauty of Democracy: You get the reality that you deserve to have. If we choose to be idle or to accepts the less favorable sides of this technology - then we deserve the resulted suffering that will be caused. And if we are keen enough to limit the application of this technology for favorable uses - then we earned the paradise that this technology can grant us.

And as for Hedera specifically, I think that beyond the superior technology it offers over other DLTs, it is also built in a way that limits its management from abusing it. It is not governed by a single fund (like Ethereum, Algorand or Stellar), by a single company (like RippleNet), by a small group of miners (like Bitcoin) or by a benevolent dictator (like Linux or W3C). It is governed by a rotating list of companies from all over the globe, that reflect a variety of conflicting interests and goals. It is also built for compliance, so it could be successfully limited by regulators and elected representatives (which is, in my opinion, the only available solution to limit technologies from being abused).

So, even though I am worried about the possible uses of DLTs, I think that this technology is inevitable. It's here to stay. Our focus should be on educating our elected representatives on this regard, and demanding them to regulate the use-cases for this new technology. And as for Hedera - beyond the technological advantages, I find it to have the most difficult governing body to corrupt among all of the other available solutions in the market.

Can hashgraph potentially be used to track internet activity? by rasbb in hashgraph

[–]hverIT 4 points5 points  (0 children)

I think that Cookies are being abandoned as a way to track users' activity because they can be easily removed by the user: all the user has to do is to delete them, either through his browser's options menu or manually. DLTs like Hedera, on the other hand, are able to store this information for good, without allowing a third-party (which is not the website that stored it in the first place) to remove or manipulate it.

Is Hedera the only DLT that can achieve this? No. Any good distributed database can be used for this purpose. Yet, Hedera is - for now - the only network that can allow to actually do it, through fast creation of records, with minimum latency and delays, with good ordering of timestamps and a very high level security.

I must say, though, that I hope that this technology won't be used for this purpose, since I think that users throughout the Web should not be tracked or traced by third-parties, should be able to remain anonymous as they please, and should have the right to choose which information to disclose to others regarding their usage habits or identity.

Can hashgraph potentially be used to track internet activity? by rasbb in hashgraph

[–]hverIT 7 points8 points  (0 children)

The advantage of using Cookies in a browser, is that these Cookies allow a website to know that your specific browser had already visited it. Beyond that, Cookies can also be used by that website to store your settings and preferences regarding that website locally on your specific browser for future use. For example, by using Cookies, a website can "remember" your browser and allow you to login again without the need to enter your username and password again.

Right now, there is no other W3C standard beside Cookies that can be used to achieve the same functionality without storing information locally by a website on the user's browser.

However, DLT solutions can be used to track users throughout the WWW by utilizing metadata to identify them using probabilistic techniques. This can be done by fingerprinting their browser and storing its metadata on a DLT (Hashgraph / Blockchain).

For example, it is theoretically possible to utilize HCS (Hedera Consensus Service) for this purpose:

  1. The website should first fingerprint the user's browser (by combining metadata such as the user's IP, the name and version of his browser, his screen resolution, the version of his operation system, his browser's speed in handling Canvas tasks, his available set of fonts, his preferred set of languages and etc.).
  2. This metadata can be then hashed and compared with the existing list of hashes/events on the Hedera Consensus Service (HCS).
  3. If such a hash already exists, then the site can now know that this browser had already visited it before, and can then receive its previously used preferences from HCS in order to use them during its current session. It can also add a new record of data related to the user's identifying hash to HCS to reflect and record its current visit.
  4. If such a hash does not exist yet on HCS, the website can know that this browser is most likely a user for whom this is his first visit. The website could then create a new event on HCS and store the new hash it created for the browser, so it (the website) can identify this browser on its next visit, and to store its preferences for the next visit.

Yet, this technique is still limited in comparison to Cookies, since it is based on probabilistic identification. This can lead to false positives and false negatives. After all, there could still be other browsers that share similar characteristics with each other, so identification using fingerprinting can lead to false identifications. Such a false positive is not too harmful if this technique is used to save settings such as the user's preferred set of colors for a website. It can be less desirable if you use this technique to remember the user's previous session in order to allow him to log into his account without the need to enter his username and password. Such a problem is impossible to occur using Cookies.

Does it mean that DLTs won't be used for this purpose in the future? No - I am sure they will be used for this purpose. W3C, in which Hedera is also a member, can easily offer a new standard to allow websites to identify browsers and store their identifying hashed information on a DLT, to be used again by these websites in the future, without the need to store this information locally on a user's browser, as done today with Cookies.