You don't have permission to do that.
Information about the author: https://www.linkedin.com/in/nikolaos-siafakas-71771953
Hash-hash.info is a financial audit platform --built using the latest HH-SDK -- that offers insights into wallet activity and keeps records of current account balances along with historical wallet snapshots.
How did we get involved with HH?
A few months back my colleague (Chris) pointed me to Hashgraph because he knew that it would interest me, due to Hashgraph's scientific angle, and he signed us up to take part in London's Hedera18 hackathon. We didn't know much about Hedera and I was reluctant to attend, but a few days before the Hackathon we had news of a successfully completed formal proof using the Coq proof assistant. I've been using Coq extensively a few years back and know how hard it is to get a formal proof, so these HH guys had to be taken seriously.
The theme of the Hackathon was micropayments and we entered with a deal-discovery dApp where users got rewarded for discovering and sharing great deals online. We got a working hack through, had a tremendous time at the event, made many great friends, but had to go back to our deal-dApp supporters and sponsors empty-handed because the prize-cow wasn't as easy of a target as we initially anticipated. The competition was fierce and the best entry -- payper -- went on to win the global H18 hackathon.
The deal-dApp went into the freezer and as Christmas approached my HH activity went into hibernation too. When checking back on HH in the last week of January, I noticed that a reward system was put up for reading articles on dailytimestamp.com. Once past the KYC, I saw my wallet balance slowly going up and was wondering how well other users are doing compared to my own repetitive compulsive clicking testing.
Beginning of hash-hash
A leader-board log is a straightforward thing to do with the SDK; a lot of effort has been put by the HH team to make HH coding as simple as possible. After a few exchanges with @GregScullard, who has a crystal ball with all HH coding answers written on it, we started printing leader-board scores into our system-log. Hash-hash.info was the next natural step where we shared that very same log with the rest of the community.
The initial response was quite encouraging and soon we started taking daily snapshots for over 5000 wallets; we're now monitoring and keeping a daily balance history for each wallet under our monitor. The community soon discovered that there are now enough data to start digging the dataset for more interesting answers.
What started as a leader board evolved into an audit tool just within a matter of days, which proves the power and ease of use of the SDK. The support of the community is impressive; we had numerous private messages that requested our account-id to transfer funds into it in order to keep the service running. It costs us a fee to monitor the accounts indeed, however that won't be an issue when mirror nodes become available. Nevertheless, we did have a 500 hBar donation, which allowed us increasing the frequency of our snapshots.
While donations do certainly help, the true HH way of doing things would be accepting micropayments using the native wallet for using the service. It' not just micropayments between end-users and the service that comes into play here but also micropayments among diverse services. We understand that as HH grows, it will be quite difficult and expensive for us to keep a record of each and every wallet and eventually we would have to buy and share data with similar services, like hbarscan.com, which aims to become a blockchain style scanner for HH.
The true value of payper, and this is why it's such an important contribution, is that it eventually could allow such collaborations to become frictionless and work towards building one coherent ecosystem. We still have a long way to go and we don't know yet what the future will bring, but we'll keep monitoring the progress of HH and will keep listening to the community.
And remember (miss-quoting Danny DeVito) you heard it here first, off the record, on the QT, and very... hash-hash.info.
You could give a demo to daily new papers association in India.
So that you attract right people for future customers
Gaming theory with Dr. Leemon Baird! Does the value that DLT brings to the world also apply in a simulated world of gaming? Dr. Leemon Baird, inventor of hashgraph joins our hosts to discuss ways that DLT can fit in the gaming stack. This podcast provides a fascinating perspective on the future of gaming, protecting the value of game assets, grinding tactics, ownership and trust. Watch more from Dr. Leemon Baird in this Hedera hashgraph masterclass: https://www.youtube.com/watch?v=MzWiiOLv96I.
The blog post Dr. Baird mentioned in the podcast "Hedera Technical Insights: A hybrid DLT architecture for gaming" by Paul Madsen can be found here: https://medium.com/hashgraph/hedera-technical-insights-a-hybrid-dlt-architecture-for-gaming-e77d27b11901
In this presentation, Hedera Hashgraph Technical Lead Paul Madsen presents the ten most common myths about distributed ledger technologies (DLTs). Demystifying these widespread, false beliefs, he reveals the truth about DLT security, the nuanced differences between DLT implementations, and the unique benefits of Hedera Hashgraph.
Paul Madsen | Technical Lead | Hedera Hashgraph
Myth #1: Distributed Ledger Technologies Create/Destroy Trust
Definitions of distributed ledger technologies often claim that DLTs guarantee, or create, trusted transactions. Meanwhile, DLTs are sometimes called “trustless systems,” or networks which destroy the very need for trust. These descriptions seemingly contradict each other, generating confusion around the relationship between DLTs and trust.
When we talk about trust and DLTs, we must be sure to include the context: trust only makes sense in terms of whom we trust and what we trust them to do.
Before DLTs were available, we had to trust third-party intermediaries to handle our transactions; we had to trust banks, government agencies, and centralized servers to validate exchanges and maintain central ledgers.
With DLTs, instead of having to trust a single, centralized authority, we can now trust the decentralized network to ensure the rules do not change. In Hedera Hashgraph’s case, we have to trust that less than one third of the network will be malicious.
When someone says that DLTs create or destroy trust, they don’t mean that DLTs don’t require any trust at all. Instead, they mean that DLTs generate a trustworthy network in which no single member needs to trust any other single member. The trust required in a DLT is placed in the network as a whole.
Myth #2: All Directed Acyclic Graphs (DAGs) Are the Same
Many DLTs on the market, Hedera Hashgraph included, use a data structure called a Directed Acyclic Graph (DAG). A DAG consists of two parts: nodes which store or represent information, and arrows which denote the directional flow or the order of those nodes. Notably, in a DAG, these nodes cannot form a cycle; there can be no path which leads from a node back to itself.
On the surface, DAGs have very little variation. Any two DAGs will have similar diagrams, consisting of nodes and arrows. Because these depictions all look the same, it is tempting to believe that all DLTs built on DAGs are the same.
DAGs are simply a data structure. While the data structure is always essentially the same, the information it represents can differ dramatically. For instance, Hedera’s DAG represents a history of messages. Through gossip-about-gossip, the DAG enables the network to recreate a shared, consistent record from which consensus can be derived. Other DAGs capture different types of information, such as transaction confirmations. While DAGs are all structured in the same way, DLTs can use the data structure in a variety of different contexts.
Myth #3: Proof-of-Work is Byzantine Fault Tolerant
Proof-of-Work (PoW) is a protocol used by many blockchain DLTs to deter malicious activity. The protocol requires nodes to solve a difficult, computationally-exhaustive puzzle in order to validate their transactions. By increasing the resource cost of issuing transactions, PoW disincentivizes malicious nodes from flooding the network with a high volume of bogus transactions, an attack known as distributed denial-of-service (DDoS). In this way, PoW is tolerant of malicious nodes.
Sometimes, people mistake PoW’s deterrence of malicious nodes for a tolerance of Byzantine nodes, and therefore believe PoW to be Byzantine Fault Tolerant (BFT).
Byzantine Fault Tolerance has a very precise definition. For a DLT to be BFT, nodes must reach consensus at a definite time, and they must know with certainty that other nodes will reach the same consensus as well, assuming that less than a third of all nodes are malicious.
Proof-of-Work cannot ensure definite consensus in this way. Rather, PoW is probabilistic; as more and more blocks are added to the blockchain, the probability that consensus will be reached continually grows. While confidence increases over time, it is not definite, as Byzantine Fault Tolerance would imply. Therefore, PoW is not Byzantine Fault Tolerant.
Myth #4: Larger Networks Are Always More Secure
The primary security feature of a DLT is its namesake, the distributed ledger. Unlike traditional systems with a central ledger, DLTs grant no individual node the power to add or alter records. Instead, the network must come to consensus on every update to the ledger, creating a significantly more transparent and tamper-resistant system.
Because the distribution of the ledger provides a significant boost to security, it is easy to see why many people believe that larger networks are more secure. After all, if distributing the ledger provides security, distributing it across an even greater group of nodes should be more secure. However, this is not always the case.
Larger networks are not necessarily more secure. A DLT’s network composition, consensus algorithm, and governance all factor into security alongside network size. If any of other these factors differ, a network with 10,000 nodes may be less secure than a network with 1,000 nodes. Larger networks only equate to greater security when all other factors are held constant.
Myth #5: You Don’t Need Particularly High Throughput
Some groups and companies assert that DLTs do not need high throughput. Their primary argument centers around practicality. Visa, for example, peaks at 50,000 transactions per second (tps). They believe, therefore, that any throughput significantly above 50,000 tps is unnecessary.
Many DLTs are designed to be platforms for hundreds or thousands of future decentralized apps. Visa is only one application. If a DLT aspires to host hundreds of Visa-like apps on its platform, it will need significantly higher throughput than 50,000 tps to support all of those applications. While high throughput may not be useful today, it is essential for any forward-thinking DLT.
Myth #6: Immutability Is an Unqualified Good
Many DLT’s, like Bitcoin, maintain an immutable ledger. On these networks, no node, nor group of nodes, can alter transactions that have already been recorded on the ledger.
There is no question that immutability provides additional security. Because nobody can change the immutable ledger, hackers cannot either; an immutable DLT provides no possible pathway for malicious agents to alter records. These security benefits lead many to believe that immutability is an unqualified good, a feature which provides no downsides along with its benefit.
While immutability does increase a DLT’s security, it also reduces the DLT’s efficiency and adaptability. When the ledger cannot be mutated, no prior records can be deleted or changed. Therefore, all records must be stored continuously. The buildup of records bloats the immutable network, requiring increasing amounts of resources for the storage of an ever-expanding ledger. Truly immutable DLTs will get more inefficient as time goes on.
Additionally, as accounting regulations change over time, DLTs may be required to change the formatting of the ledger. Immutable DLTs will not have the ability to update records to fit changing standards.
Myth #7: DLT Networks Can and Should Be Free
For a user, much of the internet appears free. While we must pay for internet access, many websites, applications, and services do not require payment. Because of this cultural mentality, some people believe that DLTs can and should be free to use.
There is no such thing as a free lunch. DLTs require resources to process transactions, come to consensus, store records and files, and provide other services. In order for the network to survive, the nodes and users who contribute to the network need to be compensated for their work. Any free DLT will not be sustainable.
Instead of levying hidden fees or taxes, Hedera Hashgraph aims to make all transactions transparent. Users pay for only the resources they use, and nodes and proxy-staking users are compensated based on the resources they provide.
Myth #8: Bitcoin Has a 51% Attack, and No Smaller
Like other platforms on the blockchain, Bitcoin is vulnerable to a 51% attack. If a hacker controls 51% of the network’s computation speed, or hashrate, then that hacker can control which transactions are added to the ledger. In this position, the hacker can alter transactions, prevent exchanges, and spend their cryptocurrency multiple times.
The 51% attack is often the focus of discussions around DLT security, especially when it comes to the blockchain. While this type of attack certainly warrants concern, its place in the spotlight gives rise to the popular myth that a hacker can only attack the DLT if they control over half of the network.
In addition to the intuitive 51% attack, all networks, including Bitcoin and Hedera Hashgraph, have 34% attacks. These attacks require the hacker to control over a third of the network, as well as a firewall. Using the firewall to split the moral 66% of the network into two groups of 33%, the malicious 34% of nodes can then tackle each of these two smaller groups separately. While this type of attack is far less intuitive than the 51% attack, it is possible on all decentralized networks.
While a DLT can safeguard against 34% attacks, it is impossible to prevent the possibility of them entirely. Therefore, the highest security possible for a DLT, called Byzantine Fault Tolerance (BFT), ensures that the network will always come to consensus when less than a third of the nodes are malicious.
Networks like Hedera Hashgraph, which have proven they are BFT, have no smaller attacks than the 34% attack. However, networks which are not BFT are susceptible to attacks by hackers who control less than a third of the network.
Myth #9: Proof-of-Stake Systems Are All the Same
Proof-of-Stake (PoS) is often described as the next logical step away from Proof-of-Work. Rather than require nodes to spend additional resources for security, PoS systems weight the legitimacy of nodes based on the number of tokens they have. By trusting nodes based on their investment into the system (their stake), PoS ensures that a malicious agent could only attack the system if they own over a third of the network’s total cryptocurrency, an incredibly large sum. In this way, PoS economically disincentivizes malicious attacks without increasing the network’s resource usage.
Because proof-of-stake is often described in opposition to proof-of-work, there is a tendency for people to believe that all proof-of-stake systems are the same.
Though all PoS systems trust nodes based on their stake, there are many nuanced differences between implementations. One such variation is delegated proof-of-stake. In a delegated proof-of-stake system, users who do not run their own node can use their stake to elect nodes to create blocks. Hedera’s proxy-staking model also allows non-nodes to stake their tokens. However, in the proxy-staking system, a user’s proxy-stake directly contributes to consensus rather than electing a node to do so.
Another difference between PoS systems is their treatment of the stake. On some platforms, a node’s stake may be taxed, bonded, or slashed. On Hedera, a user’s stake can be spent or unstaked at any time. While these differences may seem subtle, they significantly impact the functionality of proof-of-stake systems.
Myth #10: All Internet of Things Devices Will Be Nodes
In the near future, many of our electronic devices will be connected to the internet. Everything from our cars to our kitchen appliances will be able to upload data to the cloud, communicate with other devices, and be activated remotely.
This Internet-of-Things (IoT) revolution provides an interesting use case for distributed ledger technologies. If everyday electronics participate in distributed ledgers, the increased network size of our DLTs will raise security. As an added benefit, IoT technologies could then communicate with each other and issue transactions without the need for a middleman or central server. This functionality could provide direct, efficient, and secure transactions between vehicles, smart devices, and household appliances.
Upon seeing the benefits of pairing IoT technologies with DLTs, many wishful thinkers assume that all IoT electronics will become network nodes in the near future.
While there are benefits to having all IoT electronics serve as nodes, this future is infeasible. In order to maintain efficient networks, DLTs must set a minimum computational requirement for their nodes. Each node must have enough computing power, bandwidth, and storage to assist the network. Realistically, not all IoT devices will meet these requirements.
In addition to the many devices which will serve as DLT nodes, there will be many devices which cannot. Of course, these smaller devices may still be able to use decentralized networks, though not as fully participating nodes.