What is Bitcoin Mining and How Does it Work? (2020 Updated)

Bull market is back… Another wave of hacker attacks starts again?

Bull market is back… Another wave of hacker attacks starts again?

The picture from COINDESK related reports
On Aug. 2, Ethereum Classic Labs (ETC Labs) made an important announcement on ETC blockchain. ETC Labs said due to network attack, Ethereum Classic suffered a reorganization on August 1st. This has been the second attack on the Ethereum Classic Network this year.
Did renting-power cause the problem again?
In this ETC incident, one of the miners mined a large number of blocks offline. When the miner went online, due to its high computing power, and some versions of mining software did not support large-scale blockchain mergers, the consensus failed. Therefore, the entire network was out of sync, which produced an effect similar to a 51% attack. Finally, it caused the reorganization of 3693 blocks, starting at 10904147. The deposit and withdrawal between the exchanges and mining pools had to be suspended for troubleshooting during this period.
Media report shows that the blockchain reorganization may be caused by a miner (or a mining pool) disconnected during mining. Although it has been restored to normal after 15 hours of repair, it does reflect the vulnerability of the Proof of Work (PoW) network: once the computing power of the network is insufficient, the performance of one single mining pool can affect the entire network, which is neither distributed nor secure for the blockchain. Neither does it have efficiency.
At present, most consensus algorithms of blockchains are using PoW, which has been adopted over 10 years. In PoW, each miner solves a hashing problem. The probability to solve the problem successfully is proportional to the ratio of the miner’s hash power to the total hash power of mainnet.
Although PoW has been running for a long time, the attack model against PoW is very straightforward to understand, and has attracted people’s attention for a long time: such an attack, also known as double-spending attack, may happen when an attacker possesses 51% of the overall network hash power. The attacker can roll back any blocks in the blockchain by creating a longer and more difficult chain and as a result, modify the transaction information.
Since hash power can be rented to launch attacks, some top 30 projects have suffered from such attacks. In addition to this interference, the main attack method is through the computing power market such as Nice Hash. Hackers can rent hashpower to facilitate their attacks, which allows the computing power to rise rapidly in a short time and rewrite information. In January of this year, the Ethereum Classic was attacked once, and it was also the case that hackers can migrate computing power from the fiercely competitive Bitcoin and Ethereum, and use it to attack smaller projects, such as ETH Classic.

The picture shows the cost of attacking ETH Classic. It can be seen that it costs only $6,634 to attack ETH Classic for one hour.
The security of one network is no longer limited by whether miners within the main net take more than 51% of the total hash power, rather it is determined by whether the benevolent (non-hackers) miners take more than 51% of the total hash power from the pool of projects that use similar consensus algorithm. For example, the hash power of Ethereum is 176 TH/s and that of Ethereum Classic is 9 TH/s. In this way, if one diverts some hash power from Ethereum (176 TH/s) to Ethereum Classic, then one can easily launch a double-spending attack to Ethereum Classic. The hash power ratio for this attack between the two projects is 9/176 = 5.2%, which is a tiny number.

https://preview.redd.it/qj57vgmgb9f51.png?width=699&format=png&auto=webp&s=39c1efc3645f268dbf1c73e1b373d532d5461006
As one of the top 30 blockchain projects, Ethereum Classic has been attacked several times. Therefore, those small and medium-sized projects with low hash power and up-and-coming future projects are facing great potential risks. This is the reason that many emerging public chain projects abandon PoW and adopt PoS.
Proof of Stake (PoS) can prevent 51% attack but has problems of its own
In addition to PoW consensus, another well-adopted consensus algorithm is Proof of Stake (PoS). The fundamental concept is that the one who holds more tokens has the right to create the blocks. This is similar to shareholders in the stock market. The token holders also have the opportunities to get rewards. The advantages of PoS are: (i) the algorithm avoids wasting energy like that in PoW calculation; and (ii) its design determines that the PoS will not be subjected to 51% hash power attack since the algorithm requires the miner to possess tokens in order to modify the ledger. In this way, 51% attack becomes costly and meaningless.

https://preview.redd.it/rf65o1vhb9f51.png?width=685&format=png&auto=webp&s=9d7a9f9dab6ce823a224e91afa9d116310cf27e1
In terms of disadvantages, nodes face the problem of accessibility. PoS requires a permission to enter the network and nodes cannot enter and exit freely and thus lacks openness. It can easily be forked. In the long run, the algorithm is short of decentralization, and leads to the Matthew effect of accumulated advantages whereby miners with more tokens will receive more rewards and perpetuate the cycle.
More importantly, the current PoS consensus has not been verified for long-term reliability. Whether it can be as stable as the PoW system is yet to be verified. For some of the PoW public chains that are already launched, if they want to switch consensus, they need to do hard fork, which divides communities and carries out a long consensus upgrade and through which Ethereum is undergoing. Is there a safer and better solution?
QuarkChain Provide THE Solution: High TPS Protection + PoSW Consensus
For new-born projects, and some small or medium-sized projects, they all are facing the problem of power attack. For PoW-based chains, there are always some chains with lower hash power than others (ETC vs. ETH, BCH vs BTC), and thus the risk of attack is increased. In addition, the interoperability among the chains, such as cross-chain operation, is also a problem. In response, QuarkChain has designed a series of mechanisms to solve this problem. This can be summed up as a two-layer structure with a calculation power allocation and Proof of Staked Work (PoSW) consensus.
First of all, there is a layer of sharding, which can be considered as some parallel chains. Each sharding chain handles the transactions relatively independently. Such design forms the basis to ensure the performance of the entire system. To avoid security issues caused by the dilution of the hash power, we also have a root chain. The blocks of the root chain do not contain transactions, but are responsible for verifying the transactions of each shard. Relying on the hash power distribution algorithm, the hash power of the root chain will always account for 51% of the net. Each shard, on the other hand, packages their transactions according to their own consensus and transaction models.
Moreover, QuarkChain relies on flexibility that allows each shard to have different consensus and transaction models. Someone who wants to launch a double-spending attack on a shard that is already contained in the root chain must attack the block on the root chain, which requires calling the 51% hash power of the root chain. That is, if there are vertical field projects that open new shards on QuarkChain, even with insufficient hash power, an attacker must first attack the root chain if he or she wants to attack a new shard. The root chain has maintained more than 51% of the network’s hash power, which makes the attack very difficult.

https://preview.redd.it/rxpohs7jb9f51.png?width=674&format=png&auto=webp&s=e2df1307a1753542472f2b6da88e7a4022b30884

As illustrated in the diagram, if the attacker wants to attack the QuarkChain network, one would need to attack the shard and the root chain simultaneously.
PoW has achieved a high level of decentralization and has been verified for its stability for a long time. Combining PoW with the staking capability for PoS would make use of the advantages of both consensus mechanisms. That is what QuarkChain’s PoSW achieves exactly.
PoSW, which is Proof of Staked Work, is exclusively developed by QuarkChain and runs on shards. PoSW allows miners to enjoy the benefits of lower mining difficulty by staking original tokens (currently it’s 20 times lower). Conversely, if someone malicious with a high hash power and does not stake tokens on QuarkChain, he will be punishable by receiving 20 times the difficulty of the hash power, which increases the cost of attack. If the attacker stakes tokens in order to reduce the cost of attack, he/she needs to stake the corresponding amount of tokens, which may cost even more. Thus, the whole network is more secure.
Taking Ethereum Classics (ETC) as an example, if ETC uses the PoSW consensus, if there was another double-spending attack similar to the one in January, the attacker will need at least 110Th/s hash power or 650320 ETC (worth $3.2 million, and 8 TH/s hash power) to create this attack, which is far greater than the cost of the current attack on the network (8Th/s hash power) and revenue (219500 ETC).
Relying on multiple sets of security mechanisms, QuarkChain ensures its own security, while providing security for new shards and small and medium-sized projects. Its high level of flexibility also allows the projects to support different types of ledger models, transaction models, virtual machines, and token economics. Such great degrees of security and flexibility will facilitate the blockchain ecosystem to accelerate growth of innovative blockchain applications.
Learn more about QuarkChain
Website https://www.quarkchain.io
Telegram https://t.me/quarkchainio
Twitter https://twitter.com/Quark_Chain
Medium https://medium.com/quarkchain-official
Reddit https://www.reddit.com/quarkchainio/
Community https://community.quarkchain.io/
submitted by QuarkChain to quarkchainio [link] [comments]

Review and Prospect of Crypto Economy-Development and Evolution of Consensus Mechanism (1)

Review and Prospect of Crypto Economy-Development and Evolution of Consensus Mechanism (1)

https://preview.redd.it/7skleasc80a51.png?width=553&format=png&auto=webp&s=fc18cee10bff7b65d5b02487885d936d23382fc8
Table 1 Classification of consensus system
Source: Yuan Yong, Ni Xiaochun, Zeng Shuai, Wang Feiyue, "Development Status and Prospect of Blockchain Consensus Algorithm"
Figure 4 Evolution of consensus algorithm

Figure 4 Evolution of consensus algorithm
Source: Network data

Foreword
The consensus mechanism is one of the important elements of the blockchain and the core rule of the normal operation of the distributed ledger. It is mainly used to solve the trust problem between people and determine who is responsible for generating new blocks and maintaining the effective unification of the system in the blockchain system. Thus, it has become an everlasting research hot topic in blockchain.
This article starts with the concept and role of the consensus mechanism. First, it enables the reader to have a preliminary understanding of the consensus mechanism as a whole; then starting with the two armies and the Byzantine general problem, the evolution of the consensus mechanism is introduced in the order of the time when the consensus mechanism is proposed; Then, it briefly introduces the current mainstream consensus mechanism from three aspects of concept, working principle and representative project, and compares the advantages and disadvantages of the mainstream consensus mechanism; finally, it gives suggestions on how to choose a consensus mechanism for blockchain projects and pointed out the possibility of the future development of the consensus mechanism.
Contents
First, concept and function of the consensus mechanism
1.1 Concept: The core rules for the normal operation of distributed ledgers
1.2 Role: Solve the trust problem and decide the generation and maintenance of new blocks
1.2.1 Used to solve the trust problem between people
1.2.2 Used to decide who is responsible for generating new blocks and maintaining effective unity in the blockchain system
1.3 Mainstream model of consensus algorithm
Second, the origin of the consensus mechanism
2.1 The two armies and the Byzantine generals
2.1.1 The two armies problem
2.1.2 The Byzantine generals problem
2.2 Development history of consensus mechanism
2.2.1 Classification of consensus mechanism
2.2.2 Development frontier of consensus mechanism
Third, Common Consensus System
Fourth, Selection of consensus mechanism and summary of current situation
4.1 How to choose a consensus mechanism that suits you
4.1.1 Determine whether the final result is important
4.1.2 Determine how fast the application process needs to be
4.1.2 Determining the degree to which the application requires for decentralization
4.1.3 Determine whether the system can be terminated
4.1.4 Select a suitable consensus algorithm after weighing the advantages and disadvantages
4.2 Future development of consensus mechanism
Chapter 1 Concept and Function of Consensus Mechanism
1.1 Concept: The core rules for the normal operation of distributed ledgers
Since most cryptocurrencies use decentralized blockchain design, nodes are scattered and parallel everywhere, so a system must be designed to maintain the order and fairness of the system's operation, unify the version of the blockchain, and reward users maintaining the blockchain and punish malicious harmers. Such a system must rely on some way to prove that who has obtained the packaging rights (or accounting rights) of a blockchain and can obtain the reward for packaging this block; or who intends to harm , and will receive certain penalty. Such system is consensus mechanism.
1.2 Role: Solve the trust problem and decide the generation and maintenance of new blocks
1.2.1 Used to solve the trust problem between people
The reason why the consensus mechanism can be at the core of the blockchain technology is that it has formulated a set of rules from the perspective of cryptographic technologies such as asymmetric encryption and time stamping. All participants must comply with this rules. And theese rules are transparent, and cannot be modified artificially. Therefore, without the endorsement of a third-party authority, it can also mobilize nodes across the network to jointly monitor, record all transactions, and publish them in the form of codes, effectively achieving valuable information transfer, solving or more precisely, greatly improving the trust problem between two unrelated strangers who do not trust each other. After all, trusting the objective technology is less risky than trusting a subjective individual.
1.2.2 Used to decide who is responsible for generating new blocks and maintaining effective unity in the blockchain system
On the other hand, in the blockchain system, due to the high network latency of the peer-to-peer network, the sequence of transactions observed by each node is different. To solve this, the consensus mechanism can be used to reach consensus on transactions order within a short period of time to decide who is responsible for generating new blocks in the blockchain system, and to maintain the effective unity of the blockchain.
1.3 The mainstream model of consensus algorithm
The blockchain system is built on the P2P network, and the set of all nodes can be recorded as PP, generally divided into ordinary nodes that produce data or transactions, and"miner" nodes (denoted as M) responsible for mining operations, like verifying, packaging, and updating the data generated by ordinary nodes or transactions. The functions of the two types of nodes may be overlapped; miner nodes usually participate in the consensus competition process in general, and will select certain representative nodes and replace them to participant in the consensus process and compete for accounting rights in specific algorithms. The collection of these representative nodes is recorded as DD; the accounting nodes selected through the consensus process are recorded as AA. The consensus process is repeated in accordance with the round, and each round of the consensus process generally reselects the accounting node for the round . The core of the consensus process is the "select leader" and "accounting" two parts. In the specific operation process, each round can be divided into four stages: Leader election, Block generation, Data validation and Chain updating namely accounting). As shown in Figure 1, the input of the consensus process is the transaction or data generated and verified by the data node, and the output is the encapsulated data block and updated blockchain. The four stages are executed repeatedly, and each execution round will generate a new block.
Stage 1: Leader election
The election is the core of the consensus process, that is, the process of selecting the accounting node AA from all the miner node sets MM: we can use the formula f(M)→f(M)→AA to represent the election process, where the function ff represents the specific implementation of the consensus algorithm. Generally speaking, |A|=1,|A|=1, that is, the only miner node is finally selected to keep accounts.
Stage 2: Block generation
The accounting node selected in the first stage packages the transactions or data generated by all nodes PP in the current time period into a block according to a specific strategy, and broadcasts the generated new block to all miner nodes MM or their representative nodes DD. These transactions or data are usually sorted according to various factors such as block capacity, transaction fees, transaction waiting time, etc., and then packaged into new blocks in sequence. The block generation strategy is a key factor in the performance of the blockchain system, and it also exposes the strategic behavior of miners such as greedy transactions packaging and selfish mining.
Stage 3: Verification
After receiving the broadcasted new block, the miner node MM or the representative node DD will verify the correctness and rationality of the transactions or data encapsulated in the block. If the new block is approved by most verification/representative nodes, the block will be updated to the blockchain as the next block.
Stage 4: On-Chain
The accounting node adds new blocks to the main chain to form a complete and longer chain from the genesis block to the latest block. If there are multiple fork chains on the main chain, the main chain needs to be based on the consensus algorithm judging criteria to choose one of the appropriate fork chain as the main chain.
Chapter 2 The Origin of Consensus Mechanism
2.1 The two armies problems and the Byzantium generals problem
2.1.1 The two armies


Figure 2 Schematic diagram of the two armed forces
Selected from Yuan Yong, Ni Xiaochun, Zeng Shuai, Wang Feiyue, "Development Status and Prospect of Blockchain Consensus Algorithm", Journal of Automation, 2018, 44(11): 2011-2022
As shown in the figure, the 1st and 2nd units of the Blue Army are stationed on two sides of the slope, and cannot communicate remotely between each other. While the White Army is just stationed in the middle of the two Blue Army units. Suppose that the White Army is stronger than either of the two Blue Army units, but it is not as strong as the two Blue Army units combined. If the two units of the Blue Army want to jointly attack the White Army at the same time, they need to communicate with each other, but the White Army is stationed in the middle of them. It is impossible to confirm whether the messengers of two Blue Army units have sent the attack signal to each other, let alone the tampering of the messages. In this case, due to the inability to fully confirm with each other, ultimately no effective consensus can be reached between the two Blue Army units, rendering the "paradox of the two armies".
2.1.2 The Byzantine generals problem


Figure 3 Diagram of the Byzantine generals' problem
Due to the vast territory of the Byzantine roman empire at that time, in order to better achieve the purpose of defense, troops were scattered around the empire, and each army was far apart, and only messengers could deliver messages. During the war, all generals must reach an agreement, or decide whether to attack the enemy based on the majority principle. However, since it is completely dependent on people, if there is a situation where the general rebels or the messenger delivers the wrong message, how can it ensure that the loyal generals can reach agreement without being influenced by the rebels is a problem which was called the Byzantine problem.
The two armies problems and the Byzantine generals problem are all elaborating the same problem: in the case of unreliable information exchange, it is very difficult to reach consensus and coordinate action. The Byzantine general problem is more like a generalization of the "paradox of the two armies".
From the perspective of the computer network, the two armies problem and the Byzantine problem are common contents of computer network courses: the direct communication between two nodes on the network may fail, so the TCP protocol cannot completely guarantee the consistence between the two terminal networks. However, the consensus mechanism can use economic incentives and other methods to reduce this uncertainty to a level acceptable to most people.
It is precisely because of the two armies problem and the Byzantine problem that the consensus mechanism has begun to show its value.
2.2 Development history of consensus mechanism
2.2.1 Classification of consensus mechanism
Because different types of blockchain projects have different requirements for information recording and block generation, and as the consensus mechanism improves due to the development of blockchain technology, there are currently more than 30 consensus mechanisms. These consensus mechanisms can be divided into two categories according to their Byzantine fault tolerance performance: Byzantine fault tolerance system and non-Byzantine fault tolerance system.

Table 1 Classification of consensus mechanism
Source: Yuan Yong, Ni Xiaochun, Zeng Shuai, Wang Feiyue, "Development Status and Prospect of Blockchain Consensus Algorithm"
2.2.2 Development frontier of consensus mechanism
-Development of consensus algorithm
According to the proposed time of the consensus algorithm, we can see relatively clearly the development of the consensus algorithm.
Source: Network data

Figure 4 Development frontier of consensus algorithm

Figure 5 Historical evolution of blockchain consensus algorithm
Source: Yuan Yong, Ni Xiaochun, Zeng Shuai, Wang Feiyue, "Development Status and Prospect of Blockchain Consensus Algorithm"
The consensus algorithm has laid the foundation for the blockchain consensus mechanism. Initially, the research of consensus algorithms was mainly used by computer scientists and computer professors to improve the spam problem or conduct academic discussions.
For example, in 1993, American computer scientist and Harvard professor Cynthia Dwork first proposed the idea of proof of work in order to solve the spam problem; in 1997, the British cryptographer Adam Back also independently proposed to solve the spam problem by use of the mechanism of proof of work for hashing cash and published officially in 2002; in 1999, Markus Jakobsson officially proposed the concept of "proof of work", which laid the foundation for the subsequent design of Satoshi Nakamoto's Bitcoin consensus mechanism.
Next lecture: Chapter 3 Detailed Explanation of Consensus Mechanism Technology
CelesOS
As the first DPOW financial blockchain operating system, CelesOS adopts consensus mechanism 3.0 to break through the "impossible triangle". It provides both high TPS and decentralization. Committed to creating a financial blockchain operating system that embraces regulation, providing services for financial institutions and the development of applications on the regulation chain, and developing a role and consensus eco-system regulation level agreement for regulation.
The CelesOS team is committed to building a bridge between blockchain and regulatory agencies / finance industry. We believe that only blockchain technology that cooperates with regulators will have a bright future and strive to achieve this goal.
📷Website
https://www.celesos.com/
📷 Telegram
https://t.me/celeschain
📷 Twitter
https://twitter.com/CelesChain
📷 Reddit
https://www.reddit.com/useCelesOS
📷 Medium
https://medium.com/@celesos
📷 Facebook
https://www.facebook.com/CelesOS1
📷 Youtube
https://www.youtube.com/channel/UC1Xsd8wU957D-R8RQVZPfGA
submitted by CelesOS to u/CelesOS [link] [comments]

Dive Into Tendermint Consensus Protocol (I)

Dive Into Tendermint Consensus Protocol (I)
This article is written by the CoinEx Chain lab. CoinEx Chain is the world’s first public chain exclusively designed for DEX, and will also include a Smart Chain supporting smart contracts and a Privacy Chain protecting users’ privacy.
longcpp @ 20200618
This is Part 1 of the serialized articles aimed to explain the Tendermint consensus protocol in detail.
Part 1. Preliminary of the consensus protocol: security model and PBFT protocol
Part 2. Tendermint consensus protocol illustrated: two-phase voting protocol and the locking and unlocking mechanism
Part 3. Weighted round-robin proposer selection algorithm used in Tendermint project
Any consensus agreement that is ultimately reached is the General Agreement, that is, the majority opinion. The consensus protocol on which the blockchain system operates is no exception. As a distributed system, the blockchain system aims to maintain the validity of the system. Intuitively, the validity of the blockchain system has two meanings: firstly, there is no ambiguity, and secondly, it can process requests to update its status. The former corresponds to the safety requirements of distributed systems, while the latter to the requirements of liveness. The validity of distributed systems is mainly maintained by consensus protocols, considering the multiple nodes and network communication involved in such systems may be unstable, which has brought huge challenges to the design of consensus protocols.

The semi-synchronous network model and Byzantine fault tolerance

Researchers of distributed systems characterize these problems that may occur in nodes and network communications using node failure models and network models. The fail-stop failure in node failure models refers to the situation where the node itself stops running due to configuration errors or other reasons, thus unable to go on with the consensus protocol. This type of failure will not cause side effects on other parts of the distributed system except that the node itself stops running. However, for such distributed systems as the public blockchain, when designing a consensus protocol, we still need to consider the evildoing intended by nodes besides their failure. These incidents are all included in the Byzantine Failure model, which covers all unexpected situations that may occur on the node, for example, passive downtime failures and any deviation intended by the nodes from the consensus protocol. For a better explanation, downtime failures refer to nodes’ passive running halt, and the Byzantine failure to any arbitrary deviation of nodes from the consensus protocol.
Compared with the node failure model which can be roughly divided into the passive and active models, the modeling of network communication is more difficult. The network itself suffers problems of instability and communication delay. Moreover, since all network communication is ultimately completed by the node which may have a downtime failure or a Byzantine failure in itself, it is usually difficult to define whether such failure arises from the node or the network itself when a node does not receive another node's network message. Although the network communication may be affected by many factors, the researchers found that the network model can be classified by the communication delay. For example, the node may fail to send data packages due to the fail-stop failure, and as a result, the corresponding communication delay is unknown and can be any value. According to the concept of communication delay, the network communication model can be divided into the following three categories:
  • The synchronous network model: There is a fixed, known upper bound of delay $\Delta$ in network communication. Under this model, the maximum delay of network communication between two nodes in the network is $\Delta$. Even if there is a malicious node, the communication delay arising therefrom does not exceed $\Delta$.
  • The asynchronous network model: There is an unknown delay in network communication, with the upper bound of the delay known, but the message can still be successfully delivered in the end. Under this model, the network communication delay between two nodes in the network can be any possible value, that is, a malicious node, if any, can arbitrarily extend the communication delay.
  • The semi-synchronous network model: Assume that there is a Global Stabilization Time (GST), before which it is an asynchronous network model and after which, a synchronous network model. In other words, there is a fixed, known upper bound of delay in network communication $\Delta$. A malicious node can delay the GST arbitrarily, and there will be no notification when no GST occurs. Under this model, the delay in the delivery of the message at the time $T$ is $\Delta + max(T, GST)$.
The synchronous network model is the most ideal network environment. Every message sent through the network can be received within a predictable time, but this model cannot reflect the real network communication situation. As in a real network, network failures are inevitable from time to time, causing the failure in the assumption of the synchronous network model. Yet the asynchronous network model goes to the other extreme and cannot reflect the real network situation either. Moreover, according to the FLP (Fischer-Lynch-Paterson) theorem, under this model if there is one node fails, no consensus protocol will reach consensus in a limited time. In contrast, the semi-synchronous network model can better describe the real-world network communication situation: network communication is usually synchronous or may return to normal after a short time. Such an experience must be no stranger to everyone: the web page, which usually gets loaded quite fast, opens slowly every now and then, and you need to try before you know the network is back to normal since there is usually no notification. The peer-to-peer (P2P) network communication, which is widely used in blockchain projects, also makes it possible for a node to send and receive information from multiple network channels. It is unrealistic to keep blocking the network information transmission of a node for a long time. Therefore, all the discussion below is under the semi-synchronous network model.
The design and selection of consensus protocols for public chain networks that allow nodes to dynamically join and leave need to consider possible Byzantine failures. Therefore, the consensus protocol of a public chain network is designed to guarantee the security and liveness of the network under the semi-synchronous network model on the premise of possible Byzantine failure. Researchers of distributed systems point out that to ensure the security and liveness of the system, the consensus protocol itself needs to meet three requirements:
  • Validity: The value reached by honest nodes must be the value proposed by one of them
  • Agreement: All honest nodes must reach consensus on the same value
  • Termination: The honest nodes must eventually reach consensus on a certain value
Validity and agreement can guarantee the security of the distributed system, that is, the honest nodes will never reach a consensus on a random value, and once the consensus is reached, all honest nodes agree on this value. Termination guarantees the liveness of distributed systems. A distributed system unable to reach consensus is useless.

The CAP theorem and Byzantine Generals Problem

In a semi-synchronous network, is it possible to design a Byzantine fault-tolerant consensus protocol that satisfies validity, agreement, and termination? How many Byzantine nodes can a system tolerance? The CAP theorem and Byzantine Generals Problem provide an answer for these two questions and have thus become the basic guidelines for the design of Byzantine fault-tolerant consensus protocols.
Lamport, Shostak, and Pease abstracted the design of the consensus mechanism in the distributed system in 1982 as the Byzantine Generals Problem, which refers to such a situation as described below: several generals each lead the army to fight in the war, and their troops are stationed in different places. The generals must formulate a unified action plan for the victory. However, since the camps are far away from each other, they can only communicate with each other through the communication soldiers, or, in other words, they cannot appear on the same occasion at the same time to reach a consensus. Unfortunately, among the generals, there is a traitor or two who intend to undermine the unified actions of the loyal generals by sending the wrong information, and the communication soldiers cannot send the message to the destination by themselves. It is assumed that each communication soldier can prove the information he has brought comes from a certain general, just as in the case of a real BFT consensus protocol, each node has its public and private keys to establish an encrypted communication channel for each other to ensure that its messages will not be tampered with in the network communication, and the message receiver can also verify the sender of the message based thereon. As already mentioned, any consensus agreement ultimately reached represents the consensus of the majority. In the process of generals communicating with each other for an offensive or retreat, a general also makes decisions based on the majority opinion from the information collected by himself.
According to the research of Lamport et al, if there are 1/3 or more traitors in the node, the generals cannot reach a unified decision. For example, in the following figure, assume there are 3 generals and only 1 traitor. In the figure on the left, suppose that General C is the traitor, and A and B are loyal. If A wants to launch an attack and informs B and C of such intention, yet the traitor C sends a message to B, suggesting what he has received from A is a retreat. In this case, B can't decide as he doesn't know who the traitor is, and the information received is insufficient for him to decide. If A is a traitor, he can send different messages to B and C. Then C faithfully reports to B the information he received. At this moment as B receives conflicting information, he cannot make any decisions. In both cases, even if B had received consistent information, it would be impossible for him to spot the traitor between A and C. Therefore, it is obvious that in both situations shown in the figure below, the honest General B cannot make a choice.
According to this conclusion, when there are $n$ generals with at most $f$ traitors (n≤3f), the generals cannot reach a consensus if $n \leq 3f$; and with $n > 3f$, a consensus can be reached. This conclusion also suggests that when the number of Byzantine failures $f$ exceeds 1/3 of the total number of nodes $n$ in the system $f \ge n/3$ , no consensus will be reached on any consensus protocol among all honest nodes. Only when $f < n/3$, such condition is likely to happen, without loss of generality, and for the subsequent discussion on the consensus protocol, $ n \ge 3f + 1$ by default.
The conclusion reached by Lamport et al. on the Byzantine Generals Problem draws a line between the possible and the impossible in the design of the Byzantine fault tolerance consensus protocol. Within the possible range, how will the consensus protocol be designed? Can both the security and liveness of distributed systems be fully guaranteed? Brewer provided the answer in his CAP theorem in 2000. It indicated that a distributed system requires the following three basic attributes, but any distributed system can only meet two of the three at the same time.
  1. Consistency: When any node responds to the request, it must either provide the latest status information or provide no status information
  2. Availability: Any node in the system must be able to continue reading and writing
  3. Partition Tolerance: The system can tolerate the loss of any number of messages between two nodes and still function normally

https://preview.redd.it/1ozfwk7u7m851.png?width=1400&format=png&auto=webp&s=fdee6318de2cf1c021e636654766a7a0fe7b38b4
A distributed system aims to provide consistent services. Therefore, the consistency attribute requires that the two nodes in the system cannot provide conflicting status information or expired information, which can ensure the security of the distributed system. The availability attribute is to ensure that the system can continuously update its status and guarantee the availability of distributed systems. The partition tolerance attribute is related to the network communication delay, and, under the semi-synchronous network model, it can be the status before GST when the network is in an asynchronous status with an unknown delay in the network communication. In this condition, communicating nodes may not receive information from each other, and the network is thus considered to be in a partitioned status. Partition tolerance requires the distributed system to function normally even in network partitions.
The proof of the CAP theorem can be demonstrated with the following diagram. The curve represents the network partition, and each network has four nodes, distinguished by the numbers 1, 2, 3, and 4. The distributed system stores color information, and all the status information stored by all nodes is blue at first.
  1. Partition tolerance and availability mean the loss of consistency: When node 1 receives a new request in the leftmost image, the status changes to red, the status transition information of node 1 is passed to node 3, and node 3 also updates the status information to red. However, since node 3 and node 4 did not receive the corresponding information due to the network partition, the status information is still blue. At this moment, if the status information is queried through node 2, the blue returned by node 2 is not the latest status of the system, thus losing consistency.
  2. Partition tolerance and consistency mean the loss of availability: In the middle figure, the initial status information of all nodes is blue. When node 1 and node 3 update the status information to red, node 2 and node 4 maintain the outdated information as blue due to network partition. Also when querying status information through node 2, you need to first ask other nodes to make sure you’re in the latest status before returning status information as node 2 needs to follow consistency, but because of the network partition, node 2 cannot receive any information from node 1 or node 3. Then node 2 cannot determine whether it is in the latest status, so it chooses not to return any information, thus depriving the system of availability.
  3. Consistency and availability mean the loss of the partition tolerance: In the right-most figure, the system does not have a network partition at first, and both status updates and queries can go smoothly. However, once a network partition occurs, it degenerates into one of the previous two conditions. It is thus proved that any distributed system cannot have consistency, availability, and partition tolerance all at the same time.

https://preview.redd.it/456x2blv7m851.png?width=1400&format=png&auto=webp&s=550797373145b8fc1471bdde68ed5f8d45adb52b
The discovery of the CAP theorem seems to declare that the aforementioned goals of the consensus protocol is impossible. However, if you’re careful enough, you may find from the above that those are all extreme cases, such as network partitions that cause the failure of information transmission, which could be rare, especially in P2P network. In the second case, the system rarely returns the same information with node 2, and the general practice is to query other nodes and return the latest status as believed after a while, regardless of whether it has received the request information of other nodes. Therefore, although the CAP theorem points out that any distributed system cannot satisfy the three attributes at the same time, it is not a binary choice, as the designer of the consensus protocol can weigh up all the three attributes according to the needs of the distributed system. However, as the communication delay is always involved in the distributed system, one always needs to choose between availability and consistency while ensuring a certain degree of partition tolerance. Specifically, in the second case, it is about the value that node 2 returns: a probably outdated value or no value. Returning the possibly outdated value may violate consistency but guarantees availability; yet returning no value deprives the system of availability but guarantees its consistency. Tendermint consensus protocol to be introduced is consistent in this trade-off. In other words, it will lose availability in some cases.
The genius of Satoshi Nakamoto is that with constraints of the CAP theorem, he managed to reach a reliable Byzantine consensus in a distributed network by combining PoW mechanism, Satoshi Nakamoto consensus, and economic incentives with appropriate parameter configuration. Whether Bitcoin's mechanism design solves the Byzantine Generals Problem has remained a dispute among academicians. Garay, Kiayias, and Leonardos analyzed the link between Bitcoin mechanism design and the Byzantine consensus in detail in their paper The Bitcoin Backbone Protocol: Analysis and Applications. In simple terms, the Satoshi Consensus is a probabilistic Byzantine fault-tolerant consensus protocol that depends on such conditions as the network communication environment and the proportion of malicious nodes' hashrate. When the proportion of malicious nodes’ hashrate does not exceed 1/2 in a good network communication environment, the Satoshi Consensus can reliably solve the Byzantine consensus problem in a distributed environment. However, when the environment turns bad, even with the proportion within 1/2, the Satoshi Consensus may still fail to reach a reliable conclusion on the Byzantine consensus problem. It is worth noting that the quality of the network environment is relative to Bitcoin's block interval. The 10-minute block generation interval of the Bitcoin can ensure that the system is in a good network communication environment in most cases, given the fact that the broadcast time of a block in the distributed network is usually just several seconds. In addition, economic incentives can motivate most nodes to actively comply with the agreement. It is thus considered that with the current Bitcoin network parameter configuration and mechanism design, the Bitcoin mechanism design has reliably solved the Byzantine Consensus problem in the current network environment.

Practical Byzantine Fault Tolerance, PBFT

It is not an easy task to design the Byzantine fault-tolerant consensus protocol in a semi-synchronous network. The first practically usable Byzantine fault-tolerant consensus protocol is the Practical Byzantine Fault Tolerance (PBFT) designed by Castro and Liskov in 1999, the first of its kind with polynomial complexity. For a distributed system with $n$ nodes, the communication complexity is $O(n2$.) Castro and Liskov showed in the paper that by transforming centralized file system into a distributed one using the PBFT protocol, the overwall performance was only slowed down by 3%. In this section we will briefly introduce the PBFT protocol, paving the way for further detailed explanations of the Tendermint protocol and the improvements of the Tendermint protocol.
The PBFT protocol that includes $n=3f+1$ nodes can tolerate up to $f$ Byzantine nodes. In the original paper of PBFT, full connection is required among all the $n$ nodes, that is, any two of the n nodes must be connected. All the nodes of the network jointly maintain the system status through network communication. In the Bitcoin network, a node can participate in or exit the consensus process through hashrate mining at any time, which is managed by the administrator, and the PFBT protocol needs to determine all the participating nodes before the protocol starts. All nodes in the PBFT protocol are divided into two categories, master nodes, and slave nodes. There is only one master node at any time, and all nodes take turns to be the master node. All nodes run in a rotation process called View, in each of which the master node will be reelected. The master node selection algorithm in PBFT is very simple: all nodes become the master node in turn by the index number. In each view, all nodes try to reach a consensus on the system status. It is worth mentioning that in the PBFT protocol, each node has its own digital signature key pair. All sent messages (including request messages from the client) need to be signed to ensure the integrity of the message in the network and the traceability of the message itself. (You can determine who sent a message based on the digital signature).
The following figure shows the basic flow of the PBFT consensus protocol. Assume that the current view’s master node is node 0. Client C initiates a request to the master node 0. After the master node receives the request, it broadcasts the request to all slave nodes that process the request of client C and return the result to the client. After the client receives f+1 identical results from different nodes (based on the signature value), the result can be taken as the final result of the entire operation. Since the system can have at most f Byzantine nodes, at least one of the f+1 results received by the client comes from an honest node, and the security of the consensus protocol guarantees that all honest nodes will reach consensus on the same status. So, the feedback from 1 honest node is enough to confirm that the corresponding request has been processed by the system.

https://preview.redd.it/sz8so5ly7m851.png?width=1400&format=png&auto=webp&s=d472810e76bbc202e91a25ef29a51e109a576554
For the status synchronization of all honest nodes, the PBFT protocol has two constraints on each node: on one hand, all nodes must start from the same status, and on the other, the status transition of all nodes must be definite, that is, given the same status and request, the results after the operation must be the same. Under these two constraints, as long as the entire system agrees on the processing order of all transactions, the status of all honest nodes will be consistent. This is also the main purpose of the PBFT protocol: to reach a consensus on the order of transactions between all nodes, thereby ensuring the security of the entire distributed system. In terms of availability, the PBFT consensus protocol relies on a timeout mechanism to find anomalies in the consensus process and start the View Change protocol in time to try to reach a consensus again.
The figure above shows a simplified workflow of the PBFT protocol. Where C is the client, 0, 1, 2, and 3 represent 4 nodes respectively. Specifically, 0 is the master node of the current view, 1, 2, 3 are slave nodes, and node 3 is faulty. Under normal circumstances, the PBFT consensus protocol reaches consensus on the order of transactions between nodes through a three-phase protocol. These three phases are respectively: Pre-Prepare, Prepare, and Commit:
  • The master node of the pre-preparation node is responsible for assigning the sequence number to the received client request, and broadcasting the message to the slave node. The message contains the hash value of the client request d, the sequence number of the current viewv, the sequence number n assigned by the master node to the request, and the signature information of the master nodesig. The scheme design of the PBFT protocol separates the request transmission from the request sequencing process, and the request transmission is not to be discussed here. The slave node that receives the message accepts the message after confirming the message is legitimate and enter preparation phase. The message in this step checks the basic signature, hash value, current view, and, most importantly, whether the master node has given the same sequence number to other request from the client in the current view.
  • In preparation, the slave node broadcasts the message to all nodes (including itself), indicating that it assigns the sequence number n to the client request with the hash value d under the current view v, with its signaturesig as proof. The node receiving the message will check the correctness of the signature, the matching of the view sequence number, etc., and accept the legitimate message. When the PRE-PREPARE message about a client request (from the main node) received by a node matches with the PREPARE from 2f slave nodes, the system has agreed on the sequence number requested by the client in the current view. This means that 2f+1 nodes in the current view agree with the request sequence number. Since it contains information from at most fmalicious nodes, there are a total of f+1 honest nodes that have agreed with the allocation of the request sequence number. With f malicious nodes, there are a total of 2f+1 honest nodes, so f+1represents the majority of the honest nodes, which is the consensus of the majority mentioned before.
  • After the node (including the master node and the slave node) receives a PRE-PREPARE message requested by the client and 2f PREPARE messages, the message is broadcast across the network and enters the submission phase. This message is used to indicate that the node has observed that the whole network has reached a consensus on the sequence number allocation of the request message from the client. When the node receives 2f+1 COMMIT messages, there are at least f+1 honest nodes, that is, most of the honest nodes have observed that the entire network has reached consensus on the arrangement of sequence numbers of the request message from the client. The node can process the client request and return the execution result to the client at this moment.
Roughly speaking, in the pre-preparation phase, the master node assigns a sequence number to all new client requests. During preparation, all nodes reach consensus on the client request sequence number in this view, while in submission the consistency of the request sequence number of the client in different views is to be guaranteed. In addition, the design of the PBFT protocol itself does not require the request message to be submitted by the assigned sequence number, but out of order. That can improve the efficiency of the implementation of the consensus protocol. Yet, the messages are still processed by the sequence number assigned by the consensus protocol for the consistency of the distributed system.
In the three-phase protocol execution of the PBFT protocol, in addition to maintaining the status information of the distributed system, the node itself also needs to log all kinds of consensus information it receives. The gradual accumulation of logs will consume considerable system resources. Therefore, the PBFT protocol additionally defines checkpoints to help the node deal with garbage collection. You can set a checkpoint every 100 or 1000 sequence numbers according to the request sequence number. After the client request at the checkpoint is executed, the node broadcasts messages throughout the network, indicating that after the node executes the client request with sequence number n, the hash value of the system status is d, and it is vouched by its own signature sig. After 2f+1 matching CHECKPOINT messages (one of which can come from the node itself) are received, most of the honest nodes in the entire network have reached a consensus on the system status after the execution of the client request with the sequence numbern, and then you can clear all relevant log records of client requests with the sequence number less than n. The node needs to save these2f+1 CHECKPOINTmessages as proof of the legitimate status at this moment, and the corresponding checkpoint is called a stable checkpoint.
The three-phase protocol of the PBFT protocol can ensure the consistency of the processing order of the client request, and the checkpoint mechanism is set to help nodes perform garbage collection and further ensures the status consistency of the distributed system, both of which can guarantee the security of the distributed system aforementioned. How is the availability of the distributed system guaranteed? In the semi-synchronous network model, a timeout mechanism is usually introduced, which is related to delays in the network environment. It is assumed that the network delay has a known upper bound after GST. In such condition, an initial value is usually set according to the network condition of the system deployed. In case of a timeout event, besides the corresponding processing flow triggered, additional mechanisms will be activated to readjust the waiting time. For example, an algorithm like TCP's exponential back off can be adopted to adjust the waiting time after a timeout event.
To ensure the availability of the system in the PBFT protocol, a timeout mechanism is also introduced. In addition, due to the potential the Byzantine failure in the master node itself, the PBFT protocol also needs to ensure the security and availability of the system in this case. When the Byzantine failure occurs in the master node, for example, when the slave node does not receive the PRE-PREPARE message or the PRE-PREPARE message sent by the master node from the master node within the time window and is thus determined to be illegitimate, the slave node can broadcast to the entire network, indicating that the node requests to switch to the new view with sequence number v+1. n indicates the request sequence number corresponding to the latest stable checkpoint local to the node, and C is to prove the stable checkpoint 2f+1 legitimate CHECKPOINT messages as aforementioned. After the latest stable checkpoint and before initiating the VIEWCHANGE message, the system may have reached a consensus on the sequence numbers of some request messages in the previous view. To ensure the consistency of these request sequence numbers to be switched in the view, the VIEWCHANGE message needs to carry this kind of the information to the new view, which is also the meaning of the P field in the message. P contains all the client request messages collected at the node with a request sequence number greater than n and the proof that a consensus has been reached on the sequence number in the node: the legitimate PRE-PREPARE message of the request and 2f matching PREPARE messages. When the master node in view v+1 collects 2f+1 VIEWCHANGE messages, it can broadcast the NEW-VIEW message and take the entire system into a new view. For the security of the system in combination with the three-phase protocol of the PBFT protocol, the construction rules of the NEW-VIEW information are designed in a quite complicated way. You can refer to the original paper of PBFT for more details.

https://preview.redd.it/x5efdc908m851.png?width=1400&format=png&auto=webp&s=97b4fd879d0ec668ee0990ea4cadf476167a2948
VIEWCHANGE contains a lot of information. For example, C contains 2f+1 signature information, P contains several signature sets, and each set has 2f+1 signature. At least 2f+1 nodes need to send a VIEWCHANGE message before prompting the system to enter the next new view, and that means, in addition to the complex logic of constructing the information of VIEWCHANGE and NEW-VIEW, the communication complexity of the view conversion protocol is $O(n2$.) Such complexity also limits the PBFT protocol to support only a few nodes, and when there are 100 nodes, it is usually too complex to practically deploy PBFT. It is worth noting that in some materials the communication complexity of the PBFT protocol is inappropriately attributed to the full connection between n nodes. By changing the fully connected network topology to the P2P network topology based on distributed hash tables commonly used in blockchain projects, high communication complexity caused by full connection can be conveniently solved, yet still, it is difficult to improve the communication complexity during the view conversion process. In recent years, researchers have proposed to reduce the amount of communication in this step by adopting aggregate signature scheme. With this technology, 2f+1 signature information can be compressed into one, thereby reducing the communication volume during view change.
submitted by coinexchain to u/coinexchain [link] [comments]

Bitcoin Billionaire Reviews : Complete Sign Up Guide [2020]

We as a whole realize what Bitcoin Billionaire Billionaire are, at any rate from a fundamental perspective, and most wise tech darlings have at any rate thought about buying some type of digital money. In case you're among the individuals who are really charmed by all types of cryptographic forms of money, at that point you additionally realize that the arrangement of code which they all sudden spike in demand for is known as a blockchain.
What Are Bitcoin Billionaire Block Explorers?
For Bitcoin Billionaire (and alt-coins, as well), the blockchain is a continuous record of each exchange that has each happened utilizing that cash. The chain is persistently getting longer as new squares are finished and get connected as far as possible as another arrangement of recorded information. Each new connection in the chain is included as it happens, giving it an unmistakable straight recipe.
The explanation the blockchain is so productive is on the grounds that it very well may be seen by anybody, yet it can't be duplicated. This permits genuinely open source coding and straightforwardness of information without giving up security.
Envision an information sheet that is copied on each PC that is associated with the web, and afterward envision that updates can be made to this sheet progressively from anyplace on the planet.
These updates will be appeared to everybody seeing it immediately. On the off chance that you can picture that, at that point you have a simple comprehension of how the blockchain functions.
The entirety of the information in a blockchain exists as an unendingly shared and continually refreshed database. The blockchain utilizes organizing that gives everybody a precise perspective on all records progressively. It isn't recorded in any single stockpiling gadget or housed on a specific remote server. Rather, it's records are kept really open and exist all over the place.
Since there is no focal stockpiling or ace duplicate of this information, it is highly unlikely for programmers to degenerate it. The blockchain is facilitated by a huge number of PCs at the same time and is lucid and evident by any individual who approaches the web.
As a result of the way the blockchain works, it gives another degree of unparalleled straightforwardness and receptiveness to the budgetary world. Since the data is all visible progressively, it is just normal that numerous individuals are interested and wish to look at it.
Tragically, not every person who is keen on review the blockchain for Bitcoin Billionaire Billionaire is really educated enough to peruse its code. Still more who really realize how to peruse and comprehend it would spare time if there were a simpler method to translate it.
There are the individuals who have perceived this need and have decided to answer the call by giving blockchain pilgrims. These blockchain voyagers show the information found inside the blockchain in an outwardly engaging manner to make it simpler to peruse.
Top Bitcoin Billionaire Block Explorers To Pay Attention To
Here is a rundown of the best 6 blockchain voyagers that merit investigating.
  1. Blockcypher
Blockcypher is a Bitcoin Billionaire blockchain voyager that utilizations warm hues and is extremely simple on the eyes when seeing for significant stretches. Watchers can look into a Bitcoin Billionaire wallet's location and immediately observe the record for reserves sent and got through that wallet, just as its QR code.
Blockcypher is additionally ready to show any unspent sums in the wallet, which numerous blockchain travelers can't do or think about a propelled include. You can likewise utilize Blcokcypher to see the square chains of different cryptographic forms of money, for example, Dogecoin and Litecoin.
  1. Bitcoin BillionaireChain
Some may consider Bitcoin BillionaireChain excessively a lot to deal with outwardly, while others will appreciate the capacity to see a great deal of data without a moment's delay. This is on the grounds that Bitcoin BillionaireChain figures out how to fit a huge amount of information onto a solitary screen. This information incorporates Bitcoin Billionaire pools, arrange hubs, and markets.
It ventures to show which individual square was mined by which mining pool on which organize. Bitcoin BillionaireChain offers a wallet administration too, which is a pleasant touch. With everything taken into account, this is a blockchain adventurer that has a ton to offer for the individuals who need to know the entirety of the subtleties when seeing a given blockchain.
  1. Blockr
Any individual who has their hands in cryptographic money in any genuine way will have just heard the name Blockr. This blockchain pilgrim is one of indisputably the most mind boggling and comprehensive of all the blockchain pioneer alternatives accessible. It shows a huge amount of data, however has an advantageous and simple to peruse position that clients love.
Clients can choose a Bitcoin Billionaire trade and it will show a value file for Bitcoin Billionaire Billionaire on that trade. Blockr can aggregate the blockchain data utilizing a broad API which changes over the information into an assortment of diagrams containing the entirety of the data in a visual way that is anything but difficult to recognize and think about.
  1. BTC.com
BTC.com is less broad than other blockchain adventurers, yet is ideal for following or watching out for explicit information. The first page of the site shows the hash pace of each mining pool progressively, and furthermore tracks other continuous system data. BTC.com likewise keeps tabs of system clog, which is acceptable to know for specific employments.
In case you're attempting to stay aware of one explicit Bitcoin Billionaire address, this is the spot to go. BTC.com can follow the entirety of the notices of that specific address and make a path of that tends to movement.
  1. Blockchain.Info
Blockchain.info is one of the most well-known and intensely utilized blockchain wayfarers. This has brisk and simple go to alternatives for looking into a particular exchange or address without an excessive amount of complain.
Blockchain.info offers a decent measure of information as general graphs and insights about the Bitcoin Billionaire organize by and large. The site additionally has a wallet administration for both versatile and work area clients.
  1. TradeBlock
TradeBlock is somewhat not quite the same as most blockchain pioneers. While it peruses the equivalent blockchain and pulls a similar data for review, it presents that information in an alternate way. The entirety of the data is gathered and designed into outer connections, every one of which prompts hashes for singular exchanges.
It monitors the quantity of yields and information sources and shows them independently, which is a touch of a flighty insights that most fundamental clients aren't worried about, yet the more nerd clients will appreciate.
It advantageously tracks the specific number of exchange affirmations progressively and continues refreshing as new exchanges are finished. TradeBlock is maybe the most inside and out and subtleties blockchain pioneer on the rundown, and it shows the data in a way that is ideal for the more bad-to-the-bone Bitcoin Billionaire lovers.
Last Words On Bitcoin Billionaire Block Explorers
Regardless of whether you're searching for a speedy and simple look at an irregular blockchain to straighten something up or you're a profoundly learned Bitcoin Billionaire dealer looking to min-max returns, there is a blockchain traveler on this rundown that has all that you need.
https://www.cryptoerapro.com/bitcoin-billionaire/
submitted by cryptoerapro to u/cryptoerapro [link] [comments]

The IPSE Design to Application-specific Blockchain

The IPSE Design to Application-specific Blockchain

Background of Application-specific Blockchain

In-depth consideration of the problems encountered in the development of DAPP, in fact, has very simple reasons to explain; that is, the cost of use is high, and the benefits cannot completely offset the required learning costs. Each DAPP is architected on a corresponding blockchain. Users need to select one of the blockchains first. We have never seen a situation where someone uses an app first needs to choose the internet; because for us, there is only one Internet, and the underlying operating system shields all network differences.
For the development of Web 3.0 in the blockchain era, the most important thing is to get such an operating system first and screen the differences of various chains in front of users. Users don’t care what chain DAPP runs on, and they don’t have to worry about their Tokens being unusable under certain circumstances. This is the background of the application-specific blockchain.

https://preview.redd.it/our107tkpqt41.png?width=468&format=png&auto=webp&s=147510b20fe30c88176981828032a6e04e23eb7a
In fact, the application chain is relative to the Web 3.0 ecosystem. The highly anticipated project Polkadot is a cross-chain technology that connects all chains together. The Substrate framework created by its team can serve as such a blockchain operating system. Users do not need to care whether the interaction on the application-specific chain is universal. As long as the Polkadot ecosystem is connected, all operations of the application chain should be universal to the user. Even if the user holds Bitcoin, it can be completed in the application-specific blockchain. In the Web3.0 ecosystem, application-specific chains can not only seamlessly interoperate with chains built using Substrate, but also connect existing blockchains together, such as Bitcoin, Ethereum, and EOS, by building bridges. From the perspective of network effects, such connections will bring network traffic to the new application-specific blockchain. The cost of bringing users into the learning blockchain is greatly reduced, and a new wave of blockchain technology dividends will be ushered in.
The main functions of the application-specific blockchain:
  1. The interoperable transaction layer. As can be seen from the architecture diagram of Polkadot, parachains can achieve interoperability through the verification nodes in the relay chain, which includes basic operations such as transactions.
  2. The basic user data of the application-specific blockchain (user account, permissions, token ledger).
  3. The application bearer of the application-specific blockchain (smart contract, virtual machine, running platform).

The IPSE Design to Application-specific Blockchain

After the emergence of Bitcoin, it provided enough distributed nodes and power barriers, but its congestion issues and high latency caused it to fail to achieve a commercial landing, while Ethereum had the function of Smart Contracts, but it also had congestion issues. The root cause is that the entire problem set is not considered from the perspective of layering at the beginning of the blockchain design.
(1) Application data and transaction data do not need to be stacked on a blockchain. The IPSE puts most of the application data on the application-specific blockchain.
(2) A variety of application data does not need to be mixed and coexist in a blockchain. All Smart Contracts are on a virtual machine in the main chain, and the same security is obtained at a reasonable cost. The IPSE will have multiple application-specific blockchains and efficient separation of multiple application data.
(3) The node size of the application-specific blockchain is matched with its implementation business. The importance of the data is matched with the data chain security of the blockchain application-specific blockchain. The IPSE will not be completely decentralized but pays attention to making a reasonable match.
(4) Application-specific operations do not require equal commission. If there is only one main chain like Ethereum, then its price estimate for all operations in smart contracts is homogeneous, and its price lacks hierarchical planning. IPSE will design different charges in different virtual machines, and the smart contract calculates the price in the layered design.
(5) Trading operations do not require equal mining costs. Different transactions have different values. IPSE will use application-specific blockchain technology to put most of the transaction storage in the application-specific blockchain, while mining uses the main chain to jointly mine. This means the powerful consensus mechanism is used on the main chain to allow the application-specific blockchain to ride smoothly. For example, there are hundreds of nodes on the main chain to achieve a strong consensus, and only 10 nodes in the application-specific blockchain are responsible for storing application-specific blockchain data. The data volume stored by 10 nodes is 99% of the network. Anyway, verifying transactions and other behaviors on the mining node are very fast, just when the block being created, the data is pushed to the application-specific blockchain for preservation, and the 10 nodes of application-specific blockchain do not need to be mined, they are completely compliant with the 10,000 nodes on the main chain.
(6) Is a unified computing virtual machine on the main chain is unnecessary or not? For different Smart Contracts, the difference in importance is self-evident, and the importance of the data that needs to be saved is the same. If a main chain is implemented vertically, there will be serious performance expansion problems like Ethereum, and that excessive amount of synchronization can also cause security problems. The IPSE application-specific blockchain can be relied upon for these two parts. The calculation of virtual machine splitting solves the problem of insufficient performance of the main chain, and the data storage split solves the scalability problem of data management.
submitted by ipse_io to ipse [link] [comments]

According to the long standing definition of 'blockchain' on Wikipedia, Bitcoin Cash is the main chain and BlockStream's SegWit coin is an orphan chain which will most likely never be the main chain because it is 1236 blocks behind (and counting)

According to the long standing definition of 'blockchain' on Wikipedia, Bitcoin Cash is the main chain and BlockStream's SegWit coin is an orphan chain which will most likely never be the main chain because it is 1236 blocks behind (and counting) submitted by n9jd34x04l151ho4 to btc [link] [comments]

Function X: A Concept Paper introducing the f(x) ecosystem, a universal decentralized internet powered by blockchain technology and smart devices

Function X: A Concept Paper introducing the f(x) ecosystem, a universal decentralized internet powered by blockchain technology and smart devices

https://preview.redd.it/yylq6k0yqrv21.png?width=633&format=png&auto=webp&s=089ffe83e18baeceb87d465ca6fad184939490e4

Prologue

This is a Concept Paper written to introduce the Function X Ecosystem, which includes the XPhone. It also addresses the relationship between the XPOS and Function X.
Pundi X has always been a community-driven project. We have lived by the mission of making sure the community comes first and we are constantly learning from discussions and interactions on social media and in real-life meetings.
As with all discussions, there is always background noise but we have found gems in these community discussions. One such example is a question which we found constantly lingering at the back of our mind, “Has blockchain changed the world as the Internet did in the ’90s, and the automobile in the ‘20s?”. Many might argue that it has, given the rise of so many blockchain projects with vast potential in different dimensions (like ours, if we may add). But the question remains, “can blockchain ever become what the Internet, as we know it today, has to the world?”
Function X, a universal decentralized internet which is powered by blockchain technology and smart devices.
Over the past few months, in the process of implementing and deploying the XPOS solution, we believe we found the answer to the question. A nimble development team was set up to bring the answer to life. We discovered that it is indeed possible to bring blockchain to the world of telephony, data transmission, storage and other industries; a world far beyond financial transactions and transfers.
This is supported by end-user smart devices functioning as blockchain nodes. These devices include the XPOS and XPhone developed by Pundi X and will also include many other hardware devices manufactured by other original equipment manufacturers.
The vision we want to achieve for f(x) is to create a fully autonomous and decentralized network that does not rely on any individual, organization or structure.
Due to the nature of the many new concepts introduced within this Concept Paper, we have included a Q&A after each segment to facilitate your understanding. We will continuously update this paper to reflect the progress we’re making.

Function X: The Internet was just the beginning

The advent of the Internet has revolutionized the world. It created a communications layer so robust that it has resulted in TCP/IP becoming the network standard.
The Internet also created a wealth of information so disruptive that a company like Amazon threatened to wipe out all the traditional brick-and-mortar bookstores. These bookstores were forced to either adapt or perish. The same applies to the news publishing sector: the offerings of Google and Facebook have caused the near extinction of traditional newspapers.
The digitalization of the world with the Internet has enabled tech behemoths like Apple, Amazon, Google and Facebook to dominate and rule over traditional companies. The grip of these tech giants is so extensive that it makes you wonder if the choices you make are truly your own or influenced by the data they have on you as a user.
We see the blockchain revolution happening in three phases. The first was how Bitcoin showed the world what digital currency is. The second refers to how Ethereum has provided a platform to build decentralized assets easily. The clearest use case of that has come in the form of the thousands of altcoins seen today that we all are familiar with. The third phase is what many blockchain companies are trying to do now: 1) to bring the performance of blockchain to a whole new level (transaction speed, throughput, sharding, etc.) and 2) to change the course of traditional industries and platforms—including the Internet and user dynamics.
Public blockchains allow trustless transactions. If everything can be transacted on the blockchain in a decentralized manner, the information will flow more efficiently than traditional offerings, without the interception of intermediators. It will level the playing field and prevent data monopolization thus allowing small innovators to develop and flourish by leveraging the resources and data shared on the blockchain.

The Blockchain revolution will be the biggest digital revolution

In order to displace an incumbent technology with something new, we believe the change and improvement which the new technology has to bring will have to be at least a tenfold improvement on all aspects including speed, transparency, scalability and governance (consensus). We are excited to say that the time for this 10-times change is here. It’s time to take it up 10x with Function X.
Function X or f(x) is an ecosystem built entirely on and for the blockchain. Everything in f(x) (including the application source code, transmission protocol and hardware) is completely decentralized and secure. Every bit and byte in f(x) is part of the blockchain.
What we have developed is not just a public chain. It is a total decentralized solution. It consists of five core components: Function X Operating System (OS); Function X distributed ledger (Blockchain); Function X IPFS; FXTP Protocol and Function X Decentralized Docker. All five components serve a single purpose which is to decentralize all services, apps, websites, communications and, most importantly, data.
The purpose of Function X OS is to allow smart hardware and IoTs to harness the upside and potential utility of the decentralization approach. We have built an in-house solution for how mobile phones can leverage Function X OS in the form of the XPhone. Other companies can also employ the Function X OS and further customize it for their own smart devices. Every smart device in the Function X ecosystem can be a node and each will have its own address and private key, uniquely linked to their node names. The OS is based on the Android OS 9.0, therefore benefiting from backward compatibility with Android apps. The Function X OS supports Android apps and Google services (referred to as the traditional mode), as well as the newly developed decentralized services (referred to as the blockchain mode). Other XPhone features powered by the Function X OS will be elaborated on in the following sections.
Using the Function X Ecosystem (namely Function X FXTP), the transmission of data runs on a complex exchange of public and private key data and encryption but never through a centralized intermediary. Hence it guarantees communication without interception and gives users direct access to the data shared by others. Any information that is sent or transacted over the Function X Blockchain will also be recorded on the chain and fully protected by encryption so the ownesender has control over data sharing. And that is how a decentralized system for communications works.
For developers and users transitioning to the Function X platform, it will be a relatively seamless process. We have intentionally designed the process of creating and publishing new decentralized applications (DApps) on Function X to be easy, such that the knowledge and experience from developing and using Android will be transferable. With that in mind, a single line of code in most traditional apps can be modified, and developers can have their transmission protocol moved from the traditional HTTP mode (centralized) to a decentralized mode, thus making the transmission “ownerless” because data can transmit through the network of nodes without being blocked by third parties. How services can be ported easily or built from scratch as DApps will also be explained in the following sections, employing technologies in the Function X ecosystem (namely Function X IPFS, FXTP Protocol and Decentralized Docker).

f(x) Chain

f(x) chain is a set of consensus algorithms in the form of a distributed ledger, as part of the Function X ecosystem. The blockchain is the building block of our distributed ledger that stores and verifies transactions including financials, payments, communications (phone calls, file transfers, storage), services (DApps) and more.
Will Function X launch a mainnet?
Yes. The f(x) chain is a blockchain hence there will be a mainnet.
When will the testnet be launched?
Q2 2019 (projected).
When will the mainnet be launched?
Q3 2019 (projected).
How is the Function X blockchain designed?
The f(x) chain is designed based on the philosophy that any blockchain should be able to address real-life market demand of a constantly growing peer-to-peer network. It is a blockchain with high throughput achieved with a combination of decentralized hardware support (XPOS, XPhone, etc.) and open-source software toolkit enhancements.
What are the physical devices that will be connected to the Function X blockchain?
In due course, the XPOS OS will be replaced by the f(x) OS. On the other hand, the XPhone was designed with full f(x) OS integration in mind, from the ground up. After the f(x) OS onboarding, and with adequate stability testings and improvements, XPOS and XPhone will then be connected to the f(x) Chain.
What are the different elements of a block?
Anything that is transmittable over the distributed network can be stored in the block, including but not limited to phone call records, websites, data packets, source code, etc. It is worth noting that throughout these processes, all data is encrypted and only the owner of the private key has the right to decide how the data should be shared, stored, decrypted or even destroyed.
Which consensus mechanism is used?
Practical Byzantine Fault Tolerance (PBFT).
What are the other implementations of Practical Byzantine Fault Tolerance (PBFT)?
Flight systems that require very low latency. For example, SpaceX’s flight system, Dragon, uses PBFT design philosophy. [Appendix]
How do you create a much faster public chain?
We believe in achieving higher speed, thus hardware and software configurations matter. If your hardware is limited in numbers or processing power, this will limit the transaction speed which may pose security risks. The Ethereum network consists of about 25,000 nodes spread across the globe now, just two years after it was launched. Meanwhile, the Bitcoin network currently has around 7,000 nodes verifying the network. As for Pundi X, with the deployment plan (by us and our partners) for XPOS, XPhone and potentially other smart devices, we anticipate that we will be able to surpass the number of Bitcoin and Ethereum nodes within 1 to 2 years. There are also plans for a very competitive software implementation of our public blockchain, the details for which we will be sharing in the near future.

f(x) OS

The f(x) OS is an Android-modified operating system that is also blockchain-compatible. You can switch seamlessly between the blockchain and the traditional mode. In the blockchain mode, every bit and byte is fully decentralized including your calls, messages, browsers and apps. When in traditional mode, the f(x) OS supports all Android features.
Android is the most open and advanced operating system for smart hardware with over 2 billion monthly active users. Using Android also fits into our philosophy of being an OS/software designer and letting third-party hardware makers produce the hardware for the Function X Ecosystem.
What kind of open source will it be?
This has not been finalized, but the options we are currently considering are Apache or GNU GPLv3.
What kind of hardware will it work on?
The f(x) OS works on ARM architecture, hence it works on most smartphones, tablet computers, smart TVs, Android Auto and smartwatches in the market.
Will you build a new browser?
We are currently using a modified version of the Google Chrome browser. The browser supports both HTTP and FXTP, which means that apart from distributed FXTP contents, users can view traditional contents, such ashttps://www.google.com.
What is the Node Name System (NNS)?
A NNS is a distributed version of the traditional Domain Name System. A NNS allows every piece of Function X hardware, including the XPhone, to have a unique identity. This identity will be the unique identifier and can be called anything with digits and numbers, such as ‘JohnDoe2018’ or ‘AliceBob’. More on NNS in the following sections.
Will a third-party device running the f(x) OS be automatically connected to the f(x) blockchain?
Yes, third-party devices will be connected to the f(x) blockchain automatically.

f(x) FXTP

A transmission protocol defines the rules to allow information to be sent via a network. On the Internet, HTTP is a transmission protocol that governs how information such as website contents can be sent, received and displayed. FXTP is a transmission protocol for the decentralized network.
FXTP is different from HTTP because it is an end-to-end transmission whereby your data can be sent, received and displayed based on a consensus mechanism rather than a client-server based decision-making mechanism. In HTTP, the server (which is controlled by an entity) decides how and if the data is sent (or even monitored), whereas in FXTP, the data is sent out and propagates to the destination based on consensus.
HTTP functions as a request–response protocol in the client-server computing model. A web browser, for example, may be the client and an application running on a computer hosting a website may be the server. FXTP functions as a propagation protocol via a consensus model. A node that propagates the protocol and its packet content is both a “client” and a “server”, hence whether a packet reaches a destination is not determined by any intermediate party and this makes it more secure.

f(x) IPFS

IPFS is a protocol and network designed to store data in a distributed system. A person who wants to retrieve a file will call an identifier (hash) of the file, IPFS then combs through the other nodes and supplies the person with the file.
The file is stored on the IPFS network. If you run your own node, your file would be stored only on your node and available for the world to download. If someone else downloads it and seeds it, then the file will be stored on both your node the node of the individual who downloaded it (similar to BitTorrent).
IPFS is decentralized and more secure, which allows faster file and data transfer.

f(x) DDocker

Docker is computer program designed to make it easier to create, deploy, and run applications. Containers allow a developer to package up an application including libraries, and ship it all out as a package.
As the name suggests, Decentralized Docker is an open platform for developers to build, ship and run distributed applications. Developers will be able to store, deploy and run their codes remote in different locations and the codes are secure in a decentralized way.

XPhone

Beyond crypto: First true blockchain phone that is secured and decentralized to the core
XPhone is the world’s first blockchain phone which is designed with innovative features that are not found on other smartphones.
Powered by Function X, an ecosystem built entirely on and for the blockchain, XPhone runs on a new transmission protocol for the blockchain age. The innovation significantly expands the use of blockchain technology beyond financial transfers.
Unlike traditional phones which require a centralized service provider, XPhone runs independently without the need for that. Users can route phone calls and messages via blockchain nodes without the need for phone numbers.
Once the XPhone is registered on the network, for e.g., by a user named Pitt, if someone wants to access Pitt’s publicly shared data or content, that user can just enter FXTP://xxx.Pitt. This is similar to what we do for the traditional https:// protocol.
Whether Pitt is sharing photos, data, files or a website, they can be accessed through this path. And if Pitt’s friends would like to contact him, they can call, text or email his XPhone simply by entering “call.pitt”, “message.pitt”, or “mail.pitt”.
The transmission of data runs on a complex exchange of public and private key data with encryption. It can guarantee communication without interception and gives users direct access to the data shared by others. Any information that is sent or transacted over the Function X Blockchain will also be recorded on the chain.
Toggle between now and the future
Blockchain-based calling and messaging can be toggled on and off on the phone operating system which is built on Android 9.0. XPhone users can enjoy all the blockchain has to offer, as well as the traditional functionalities of an Android smartphone.
We’ll be sharing more about the availability of the XPhone and further applications of Function X in the near future.

DApps

DApps for mass adoption
So far the use of decentralized applications has been disappointing. But what if there was a straightforward way to bring popular, existing apps into a decentralized environment, without rebuilding everything? Until now, much of what we call peer-to-peer or ‘decentralized’ services continue to be built on centralized networks. We set out to change that with Function X; to disperse content now stored in the hands of the few, and to evolve services currently controlled by central parties.
Use Cases: Sharing economy
As seen from our ride-hailing DApp example that was demonstrated in New York back in November 2018, moving towards true decentralization empowers the providers of services and not the intermediaries. In the same way, the XPhone returns power to users over how their data is being shared and with whom. Function X will empower content creators to determine how their work is being displayed and used.
Use Cases: Free naming
One of the earliest alternative cryptocurrencies, Namecoin, wanted to use a blockchain to provide a name registration system, where users can register their names to create a unique identity. It is similar to the DNS system mapping to IP addresses. With the Node Name System (NNS) it is now possible to do this on the blockchain.
NNS is a distributed version of the traditional Domain Name System. A NNS allows every piece of Function X hardware, including the XPhone, to have a unique identifier that can be named anything with digits and numbers, such as ‘JohnDoe2018’ or ‘AliceBob’.
Use Cases: Mobile data currency
According to a study, mobile operator data revenues are estimated at over $600 billion USD by 2020, equivalent to $50 billion USD per month [appendix]. Assuming users are able to use services such as blockchain calls provided by XPhone (or other phones using Function X) the savings will be immense and the gain from profit can be passed on to providers such as DApp developers in Function X. In other words, instead of paying hefty bills to a mobile carrier for voice calls, users can pay less by making blockchain calls, and the fees paid are in f(x) coins. More importantly users will have complete privacy over their calls.
Use Cases: Decentralized file storage
Ethereum contracts claim to allow for the development of a decentralized file storage ecosystem, “where individual users can earn small quantities of money by renting out their own hard drives and unused space can be used to further drive down the costs of file storage.” However, they do not necessarily have the hardware to back this up. With the deployment of XPOS, smart hardware nodes and more, Function X is a natural fit for Decentralized File Storage. In fact, it is basically what f(x) IPFS is built for.
These are just four examples of the many use cases purported, and there can, will and should be more practical applications beyond these; we are right in the middle of uncharted territories.

Tokenomics

Decentralized and autonomous
The f(x) ecosystem is fully decentralized. It’s designed and built to run autonomously in perpetuity without the reliance or supervision of any individual or organization. To support this autonomous structure, f(x) Coin which is the underlying ‘currency’ within the f(x) ecosystem has to be decentralized in terms of its distribution, allocation, control, circulation and the way it’s being generated.
To get the structure of f(x) properly set up, the founding team will initially act as ‘initiators’ and ‘guardians’ of the ecosystem. The role of the team will be similar to being a gatekeeper to prevent any bad actors or stakeholders playing foul. At the same time, the team will facilitate good players to grow within the ecosystem. Once the f(x) ecosystem is up and running, the role of the founding team will be irrelevant and phased out. The long term intention of the team is to step away, allowing the ecosystem to run and flourish by itself.

Utility

In this section, we will explore the utility of the f(x) Coin. f(x) Coin is the native ‘currency’ of the Function X blockchain and ecosystem. All services rendered in the ecosystem will be processed, transacted with, or “fueled” by the f(x) Coin. Some of the proposed use cases include:
  • For service providers: Getting paid by developers, companies and consumers for providing storage nodes, DDocker and improvement of network connections. The role of service providers will be described in greater detail in the rest of the paper.
  • For consumers: Paying for service fees for the DApps, nodes, network resources, storage solutions and other services consumed within the f(x) ecosystem.
  • For developers: Paying for services and resources rendered in the ecosystem such as smart contract creation, file storage (paid to IPFS service provider), code hosting (paid to DDocker service provider), advertisements (paid to other developers) and design works. Developers can also get paid by enterprises or organizations that engaged in the developer’s services.
  • For enterprises or organizations: Paying for services provided by developers and advertisers. Services provided to consumers will be charged and denominated in f(x) Coin.
  • For phone and hardware manufacturers: Paying for further Function X OS customizations. It is worth noting that Pundi X Labs plan to only build a few thousand devices of the XPhone flagship handsets, and leave the subsequent market supply to be filled by third-party manufacturers using our operating system.
  • For financial institutions: receiving payments for financial services rendered in the ecosystem.
  • Applications requiring high throughput.
Hence f(x) Coin can be used as ‘currency’ for the below services,
  • In-app purchases
  • Blockchain calls
  • Smart contract creations
  • Transaction fees
  • Advertisements
  • Hosting fees
  • Borderless/cross-border transactions
We believe f(x) Coin utilization will be invariably higher than other coins in traditional chains due to the breadth of the f(x) ecosystem. This includes storage services and network resources on f(x) that will utilize the f(x) Coin as “fuel” for execution and validation of transactions.
Example 1: A developer creates a ride-hailing DApp called DUber.
DUber developer first uploads the image and data to IPFS (storage) and code to DDocker, respectively. The developer then pays for a decentralized code hosting service provided by the DDocker, and a decentralized file hosting service provided by the IPFS. Please note the storage hosting and code hosting services can be provided by a company, or by a savvy home user with smart nodes connected to the Function X ecosystem. Subsequently, a DUber user pays the developer.
Example 2: User Alice sends an imaginary token called ABCToken to Bob.
ABCToken is created using Function X smart contract. Smart nodes hosted at the home of Charlie help confirms the transaction, Charlie is paid by Alice (or both Alice and Bob).

The flow of f(x) Coin

Four main participants in f(x): Consumer (blue), Developer (blue), Infrastructure (blue), and Financial Service Provider (green)
Broadly speaking, there can be four main participants in the f(x) ecosystem, exhibited by the diagram above:
  • Consumer: Users enjoy the decentralized services available in the f(x) ecosystem
  • Infrastructure Service Provider: Providing infrastructures that make up the f(x) ecosystem such as those provided by mobile carriers, decentralized clouds services.
  • Developer: Building DApp on the f(x) network such as decentralized IT, hospitality and financial services apps.
  • Financial Service Provider: Providing liquidity for the f(x) Coin acting as an exchange.
The f(x) ecosystem’s value proposition:
  • Infrastructure service providers can offer similar services that they already are providing in other markets such as FXTP, DDocker and IPFS, to earn f(x) Coin.
  • Developers can modify their existing Android apps to be compatible with the f(x) OS environment effortlessly, and potentially earn f(x) Coin.
  • Developers, at the same time, also pay for the infrastructure services used for app creation.
  • Consumers immerse in the decentralized app environments and pay for services used in f(x) Coin.
  • Developer and infrastructure service providers can earn rewards in f(x) Coin by providing their services. They can also monetize it through a wide network of financial service providers to earn some profit, should they decide to do so.
Together, the four participants in this ecosystem will create a positive value flow. As the number of service providers grow, the quality of service will be enhanced, subsequently leading to more adoption. Similarly, more consumers means more value is added to the ecosystem by attracting more service providers,and creating f(x) Coin liquidity. Deep liquidity of f(x) Coin will attract more financial service providers to enhance the stability and quality of liquidity. This will attract more service providers to the ecosystem.
Figure: four main participants of the ecosystem The rationale behind f(x) Coin generation is the Proof of Service concept (PoS)
Service providers are crucial in the whole f(x) Ecosystem, the problem of motivation/facilitation has become our priority. We have to align our interests with theirs. Hence, we have set up a Tipping Jar (similar to mining) to motivate and facilitate the existing miners shift to the f(x) Ecosystem and become part of the infrastructure service provider or attract new players into our ecosystem. Income for service provider = Service fee (from payer) + Tipping (from f(x) network generation)
The idea is that the f(x) blockchain will generate a certain amount of f(x) Coin (diminishing annually) per second to different segments of service provider, such as in the 1st year, the f(x) blockchain will generate 3.5 f(x) Coin per second and it will be distributed among the infrastructure service provider through the Proof of Service concept. Every service provider such as infrastructure service providers, developers and financial service providers will receive a ‘certificate’ of Proof of Service in the blockchain after providing the service and redeeming the f(x) Coin.
Example: There are 3 IPFS providers in the market, and the total Tipping Jar for that specific period is 1 million f(x) Coin. Party A contributes 1 TB; Party B contributes 3 TB and Party C contributes 6 TB. So, Party A will earn 1/10 * 1 million = 100k f(x) Coin; Party B will earn 3/10 * 1 million = 300k f(x) Coin. Party C will earn 6/10 * 1 million = 600k f(x) Coin.
Note: The computation method of the distribution of the Tipping Jar might vary due to the differences in the nature of the service, period and party.
Figure: Circulation flow of f(x) Coin
The theory behind the computation.
Blockchain has integrated almost everything, such as storage, scripts, nodes and communication. This requires a large amount of bandwidth and computation resources which affects the transaction speed and concurrency metric.
In order to do achieve the goal of being scalable with high transaction speed, the f(x) blockchain has shifted out all the ‘bulky’ and ‘heavy duty’ functions onto other service providers, such as IPFS, FXTP, etc. We leave alone what blockchain technology does best: Calibration. Thus, the role of the Tipping Jar is to distribute the appropriate tokens to all participants.
Projected f(x) Coin distribution per second in the first year
According to Moore’s Law, the number of transistors in a densely integrated circuit doubles about every 18 -24 months. Thus, the performance of hardware doubles every 18-24 months. Taking into consideration Moore’s Law, Eric Schmidt said if you maintain the same hardware specs, the earnings will be cut in half after 18-24 months. Therefore, the normal Tipping Jar (reward) for an infrastructure service provider will decrease 50% every 18 months. In order to encourage infrastructure service providers to upgrade their hardware, we have set up another iteration and innovation contribution pool (which is worth of 50% of the normal Tipping Jar on the corresponding phase) to encourage the infrastructure service provider to embrace new technology.
According to the Andy-Bill’s law, “What Andy gives, Bill takes away”; software will always nibble away the extra performance of the hardware. The more performance a piece of hardware delivers, the more the software consumes. Thus, the developer will always follow the trend to maintain and provide high-quality service. The Tipping Jar will increase by 50% (based upon the previous quota) every 18 months.
Financial service providers will have to support the liquidation of the whole ecosystem along the journey, the Tipping Jar (FaaS) will increase by 50% by recognizing the contribution and encouraging innovation.
From the 13th year (9th phase), the Tipping Jar will reduce by 50% every 18 months. We are well aware that the “cliff drop” after the 12th year is significant. Hence, we have created a 3year (two-phase) diminishing transition period. The duration of each phase is 18 months. There are 10 phases in total which will last for a total of 15 years.
According to Gartner’s report, the blockchain industry is forecast to reach a market cap of
3.1 trillion USD in 2030. Hence, we believe a Tipping Jar of 15 years will allow the growth of Function X into the “mature life cycle” of the blockchain industry.

f(x) Coin / Token Allocation

Token allocation We believe great blockchain projects attempt to equitably balance the interests of different segments of the community. We hope to motivate and incentivize token holders by allocating a total of 65% of tokens from the Token Generation Event (TGE). Another 20% is allocated to the Ecosystem Genesis Fund for developer partnerships, exchanges and other such related purposes. The remaining 15% will go to engineering, product development and marketing. There will be no public or private sales for f(x) tokens.
NPXS / NPXSXEM is used to make crypto payments as easy as buying bottled water, while f(x) is used for the operation of a decentralized ecosystem and blockchain, consisting of DApps and other services. NPXS / NPXSXEM will continue to have the same functionality and purpose after the migration to the Function X blockchain in the future. Therefore, each token will be expected to assume different fundamental roles and grant different rights to the holders.
https://preview.redd.it/xohy6c6pprv21.png?width=509&format=png&auto=webp&s=a2c0bd0034805c5f055c3fea4bd3ba48eb59ff07
65% of allocation for NPXS / NPXSXEM holders is broken down into the following: 15% is used for staking (see below) 45% is used for conversion to f(x) tokens. (see below) 5% is used for extra bonus tasks over 12 months (allocation TBD).

https://preview.redd.it/6jmpfhmxprv21.png?width=481&format=png&auto=webp&s=c9eb2c124e0181c0851b7495028a317b5c9cd6b7
https://preview.redd.it/1pjcycv0qrv21.png?width=478&format=png&auto=webp&s=c529d5d99d760281efd0c3229edac494d5ed7750
Remarks All NPXS / NPXSXEM tokens that are converted will be removed from the total supply of NPXS / NPXSXEM; Pundi X will not convert company's NPXS for f(x) Tokens. This allocation is designed for NPXS/NPXSXEM long term holders. NPXS / NPXSXEM tokens that are converted will also be entitled to the 15% f(x) Token distribution right after the conversion.

Usage

Management of the Ecosystem Genesis Fund (EGF)
The purpose of setting up the Ecosystem Initialization Fund, is to motivate, encourage and facilitate service providers to join and root into the f(x) Ecosystem and, at the same time, to attract seed consumers to enrich and enlarge the f(x) Ecosystem. EIF comes from funds raised and will be used as a bootstrap mechanism to encourage adoption before the Tipping Jar incentives fully kicks in.
The EGF is divided into 5 parts:
  1. Consumer (10%): To attract consumers and enlarge the customer base;
  2. Developer (20%): To encourage developers to create DApps on the f(x) blockchain;
  3. Infrastructure Service Provider (20%): To set up or shift to the f(x) infrastructure;
  4. Financial Service Provider (20%): To create a trading platform for f(x) Coin and increase liquidity; and
  5. Emergency bridge reserve (30%): To facilitate or help the stakeholders in f(x) during extreme market condition
To implement the spirit of decentralization and fairness, the EGF will be managed by a consensus-based committee, called the f(x) Open Market Committee (FOMC).

Summary

Time moves fast in the technology world and even faster in the blockchain space. Pundi X’s journey started in October 2017, slightly over a year ago, and we have been operating at a lightning pace ever since, making progress that can only be measured in leaps and bounds. We started as a blockchain payment solution provider and have evolved into a blockchain service provider to make blockchain technology more accessible to the general public, thereby improving your everyday life.
The creation of Function X was driven by the need to create a better suited platform for our blockchain point-of sale network and through that process, the capabilities of Function X have allowed us to extend blockchain usage beyond finance applications like payment solutions and cryptocurrency.
The complete decentralized ecosystem of Function X will change and benefit organizations, developers, governments and most importantly, society as a whole.
The XPhone prototype which we have created is just the start to give everyone a taste of the power of Function X on how you can benefit from a truly decentralized environment. We envision a future where the XPOS, XPhone and other Function X-enabled devices work hand-in-hand to make the decentralized autonomous ecosystem a reality.
You may wonder how are we able to create such an extensive ecosystem within a short span of time? We are fortunate that in today’s open source and sharing economy, we are able to tap onto the already established protocols (such as Consensus algorithm, FXTP, etc), software (like Android, IPFS, PBFT, Dockers, etc.) and hardware (design knowledge from existing experts) which were developed by selfless generous creators. Function X puts together, aggregates and streamlines all the benefits and good of these different elements and make them work better and seamlessly on the blockchain. And we will pay it forward by making Function X as open and as decentralized as possible so that others may also use Function X to create bigger and better projects.
To bring Function X to full fruition, we will continue to operate in a transparent and collaborative way. Our community will continue to be a key pillar for us and be even more vital as we get Function X up and running. As a community member, you will have an early access to the Function X ecosystem through the f(x) token conversion.
We hope you continue to show your support as we are working hard to disrupt the space and re-engineer this decentralized world.

Reference

Practical Byzantine Fault Tolerance
http://pmg.csail.mit.edu/papers/osdi99.pdf
Byzantine General Problem technical paper
https://web.archive.org/web/20170205142845/http://lamport.azurewebsites.net/pubs/byz.pdf
Global mobile data revenues to reach $630 billion by 2020
https://www.parksassociates.com/blog/article/pr-07112016
NPXSXEM token supply
https://medium.com/pundix/a-closer-look-at-npxsxem-token-supply-843598d0e7b6
NPXS circulating token supply and strategic purchaser
https://medium.com/pundix/total-token-supply-and-strategic-investors-b41717021583
[total supply might differ from time to time due to token taken out of total supply aka “burn”]
ELC: SpaceX lessons learned (PBFT mentioned) https://lwn.net/Articles/540368/

Full: https://functionx.io/assets/file/Function_X_Concept_Paper_v2.0.pdf
submitted by crypt0hodl1 to PundiX [link] [comments]

51% attack on monacoin

IMPORTANT NOTE 2018,05.21.

Monacoin dev sent Lae an email, saying that his current advice for exchanges is to increase confirmations to 100 for now, and that he doesn't have a concrete plan moving forward yet.

Original post:

Currently we are having an 51%+selfish mining+timestamp attack on monacoin reported by several people. Some exchanges (Bittrex, Livecoin) alreday disabled depositing Monacoin, i suggest other exchanges to disable it as well temporarly. monacoin dev suggests to set confirmation time to 100 and everything can resume.

What is happening?

-one of the mining community witholds the blocks
-due to buggy diff retarget calculation the next block can be mined very easily
-new blocks can be issued rapidly
-result 1 = faulty confirmed payments into exchanges (hidden block with a hidden transaction to different address from earlyer and not to exchange + issuing block with payment to exchange and rapidly issued forged blocks relation to this block -> exchange detects proper number of confirmations, then they free up the real block as well, resulting the original forged blocks to be orphanged -> the new chain has no payment to the exchange, but the payment is alreday in the exchange database -> swapping to other coins and withdraw)
-result 2 = and stealing the block reward from a lot of blocks
The bug is the quite similar as Verge had a month ago. Increasing block age for deposits will not fix it, but increasing the block confirmations actually secures you from the attack aniway. Exchangers and online services should increase it above 100. (There is difference as in Verge the timestamp itself was faked - here a different algorithmic error plays role, which the developers must first find).
The main issue (witholding the blocks) was discovered earlyer, but until now it was not a threat (now it became malicious due to this retarget bug - basically combining this 3 phenomon together). The attacker attempts to do the attack for half year with automated mechanisms, now he succeeded.
You may continue using monacoin for buying and selling stuff, but wait a few hours before shipping the product.
Western exchages (Livecoin) lost $90k usd due to attack.
(The bug probably exists with almost all of the bitcoin clones as well - but you must be able to withold blocks to exploit it. )
Your personal Monacoin holdings are not in danger.
The network and transactions - besides this - working as usual, you can continue using your wallet as you did before.
This does NOT have any impact on you as a regular user.
Disclaimer:
  1. i am nobody, and i am not a core developer
  2. i cant check the credibility of the informations i posted above
  3. we are trying to reconstruct whats happening. the monacoin developers dont speak english, and we dont speak japanese
  4. i am programmer, but i am not expert in crypto in any ways
  5. i am not affiliated with monacoin project
  6. meanwhile the title says 51% attack, its possible to achieve this attack around 40-45% hashrate as well (however lower the attackers percentage is, lower the chance of succesfully executing the attack)
an example of suspicious activity on monacoin chain: https://imgur.com/a/OeUwU3I
https://twitter.com/tcejorpniocanom/status/997147764294270982
https://twitter.com/tcejorpniocanom/status/997141459777110017
https://www.reddit.com/monacoin/comments/7z6tgt/more_than_51_hash_power_for_unknown_address/
https://bitcointalk.org/index.php?topic=392436.msg37346720#msg37346720
https://headlines.yahoo.co.jp/hl?a=20180518-00000040-zdn_n-sci
https://bitcoin.stackexchange.com/questions/5076/what-stops-miners-nodes-lying-about-what-time-a-block-was-mined?rq=1
Statistic data from Ming:
Traversal of reorg chains data https://pastebin.com/nh57q3k8
Mined blocks that are not in the main chain according to API (hash block_height address value): https://pastebin.com/C92iqmY4
Diagram of chain reorg, now with the replaced chain.
https://gist.github.com/Ming-Tang/7d4d1441b78b551bf752a3ef0a953fbd
PDF version: https://www.dropbox.com/s/stormjg8bcpacg4/reorgs.pdf?dl=0
Suspected attacker: MBTt4Z*********************Wsx

Aftermath:

  1. bittrex employee contacted me, and told me that they consider delisting the coin if they cant contact twitter.com/tcejorpniocanom - i gave them contacts who might know how to contact the developer, and suggested them to do 300 block confirmations
  2. the coins alreday scammed out from the legitimate owners canot be returned - the chain canot be modified backwards
  3. another bitcoin clone called bitcoin gold got hit by a similar attack ( https://forum.bitcoingold.org/t/double-spend-attack-on-exchanges/1362 Details on similar attack for Bitcoin Gold. )
  4. monacoin dev suggest to set confirmation time to 100. no new actions will take place now. enjoy using the coin.
  5. bitbank re-enabled their wallet
  6. bittrex reopened wallet
submitted by GeriGeriGeri to monacoin [link] [comments]

Komodo's 2.0 Infographic Contest: 5,000 KMD Grand Prize!

Komodo's 2.0 Infographic Contest: 5,000 KMD Grand Prize!

https://preview.redd.it/0yq7rwnkjdq11.png?width=1500&format=png&auto=webp&s=950dd49d7e1f7f1e421f7074bd030aec064e6ac7
A total prize pool of 7,000 KMD in our infographic contest
Calling all creatives to take part in our infographic contest and compete for a prize of 7,000 KMD. The winning infographic will explain the architecture of Komodo Platform’s technology. Winners will be those who are able to communicate our architecture and tech visually. This contest will run primarily on Reddit, with the exception of resources being posted to Medium and a master twitter thread for submissions on Twitter. You'll find links at the bottom of this post.

Prizes for winning infographics.

Are you a creative designer? Here's what you can win…
  1. A grand prize of 5,000 KMD
  2. Two runner-up prizes of 500 KMD each
  3. Two third-place prizes of 250 KMD each

Prizes for sharing and giving feedback!

Not a designer? That's OK. You can still participate and win! We'll award five lucky winners 100 KMD each for sharing and promoting the contest. Winners will be picked in a raffle. If you'd like to take part click here https://gleam.io/MwMtO/komodos-20-infographic-contest-5000-kmd-grand-prize and share this post with your friends.

Your Goals

  • Create a high-quality infographic that illustrates the genesis of our platform, the working tech that has been created and how Komodo has been built differently, and deliberately, from the very beginning to ensure security, scalability and interoperability. This is why we refer to the architecture, because Komodo was designed to overcome common problems like congestion, governance and attacks that other platforms did not foresee or prevent, from the beginning. This is Komodo DNA.
  • Share your submission far and wide and encourage your friends and followers to vote for you.
  • Encourage feedback, ask questions and make your infographic the best that it can be.

Our Criteria to Judge

Please note that upvotes and shares are not the only criteria we'll use to judge winners. While useful, we will value creativity, good questions and discussion on Reddit highly. When sharing your posts you will score more highly if people comment, provide feedback and are engaged.
  • How well the infographic conveys our working tech, it's core concepts and plans to build on top of it.
  • How well the infographic illustrates our story, purpose and conveys our tech so that it's easy to understand.
  • Constructive discussion, questions and feedback on Reddit that lead to improvement.
  • Sentiment and comments generated across all our social media. This will not include vanity metrics like likes or shares.
  • Upvotes on Reddit for the author's submission post ONLY. All votes will be counted (i.e. doesn't matter which week they were made).
  • Retweets of the submission in our master thread ONLY. Include your handle and a cover image in your submission. This means if you promote yourself on Twitter you ought to promote the tweet with your work in it.

How do you win?

You may submit up to two infographics. By submitting an infographic, you understand Komodo may post and use your submissions on our digital channels during and after the contest. Each infographic must have it's own post.
  • Create a post on Komodo's subreddit using the 'infographic contest' flair.
  • Add the infographic image into the Reddit post.
  • Include your Twitter handle.
  • Include a social media friendly cover image for us to use when we tweet your submission out.
  • Post a link to your submission post here in the comments for all to see.

Contest Timeline Guide (these dates indicative and are subject to change).

  • 7th September. Announcement. If you're reading this on Reddit before the big announcement then well done! You have two extra days before this is announced on Friday.
  • 10th - 21st September. Research and Questions. We will promote the contest, invite questions and requests for resources, in the comments of this master Reddit post (because this means all information and good questions will be visible to all participants).
  • 22nd September. Draft Submissions. Creatives to submit their draft infographics on Reddit. All submissions need to have their own post and then be linked to in the comments of this master post. This is important to remember!
  • 24th - 30th September. Feedback. A period of one week will be devoted to promoting the submissions and asking the community and team to give you feedback.
  • 1st October. Final Submissions.
  • 2nd - 8th October. Voting. A week of promoting your work and at the end we'll count votes, consider feedback and pick our winners.
  • 15th October. Winners Declared. The final decision by judges. Votes and community feedback counts towards judging but do not have final say.

Resources

If you need help please post in this thread, or email [[email protected]](mailto:[email protected]) with ‘Infographic Contest’ in the subject line.
  1. A list of resources for the Komodo infographic contest including tools to create infographics.
  2. Komodo Platform: Redefining The Architecture Of Blockchain Platforms
  3. A bullet point study aid to help you understand the history of Komodo’s architecture.
  4. Logo Pack https://komodoplatform.com/wp-content/uploads/2018/03/Komodo-Logo-Pack.zip
  5. Mylo's notes on Software & Platform Architecture for Designers in the Infographic Contest
  6. Mylo's Conceptual Model of Architecture
  7. Video: A brief history of our working tech and an animated timeline of the Komodo Platform.
  8. Video: Komodo Atomic Swaps Explained.
Also please let us know if you are, or you know, a good GUI developer because we'd love to hear from them. Ask them to DM ca333#0118 or SHossain#8093 on Discord.

Entries and submissions for the infographic contest. You can click here to see them all in a scrollable thread on Twitter.

25/09/18 - First Round of Feedback

Infographics should use graphical design elements to visually represent the Komodo Architecture Story found here: https://komodoplatform.com/komodo-platform-a-brief-overview/ included in our ‘required reading’. There’s also a bullet point aid: https://medium.com/@benohanlon/bullet-point-aid-to-help-you-the-history-of-komodos-architecture-dced35b29965 you may find useful.
  • We want to stress that the infographic ought to focus on the Architecture story. In the first round we've found many have focused on the five pillars which is a part of it but not the focus.
  • Copy should be short and concise and not dominate the infographic. The idea is to simplify the story and not to copy and paste directly from the story.
  • Colour Palette - avoid heavy usage of the old KMD green and yellow-orange. Would prefer usage of the interim KMD colour palette.
  • Recommended fonts: Montseratt, Roboto, Open Sans, Helvetica, or Arial.
  • Graphical - Imagery should complement the associated copy. Diagrams are encouraged in place of simple icons to explain more complex technology concepts.
  • Interim KMD colour palette
Interim KMD Colour Palette
If you’ve not been included in the first round it’s because the submission hadn’t been made when the team reviewed. Don’t worry though because we’re organising hangouts and further feedback to help.
  • #001 Infographic Link // Reddit Post Link by thesudio. There’s a lot of good points made, however, these would work better if there is a clear narrative and flow to the information being presented. Otherwise, it can be overwhelming and confusing to the reader. The #1 objective is to visually depict the architecture story and how KMD is redefining blockchain platform architecture.
  • #002 Infographic Link // Reddit Post Link by thesudio. We like that there is a clear structure and clear messaging aligned to each of the 5 pillars. However, the infographic should be focused on telling the architecture story vs the pillars.
  • #003 Infographic Link // Reddit Post Link by VolsenVols. Love how you’ve incorporated our existing graphic design elements into the infographic. This is heading in the right direction and the level of copy and content are well balanced. It would be nice to align this closer to the architecture story and to expand on the different layers of our technology using the same style.
  • #004 Infographic Link // Reddit Post Link by dexter_laabo. Needs to tell the architecture story. This looks more like it took information from our current website. “Anonymous” is not a key aspect of our technology that we’re focusing on.
  • #005 Infographic Link // Reddit Post Link by savandra. The visuals are strong but the narrative could be stronger. It would be nice to align this closer to the architecture story and to expand on the different layers of our technology using the same style.
  • #006 Infographic Link // Reddit Post Link by VolsenVols. Team prefers the other submission style in entry #003.
  • #007 Infographic Link // Reddit Post Link by cryptol1. Doesn’t depict the architecture narrative. Inaccurately describes cross-chain tech as “proprietary”. Simplification has the wrong messaging associated, should be white-label focused. This is considered more of a graphics versus an infographic. Needs to be more comprehensive.
  • #008 Infographic Link // Reddit Post Link by pacosenda. We like the unique design style and approach taken. Doesn’t follow the architecture narrative. Should be expanded out as it is a bit short on content with no clear flow or narrative.
  • #009 Infographic Link // Reddit Post Link by jeanetteLine. Great level of detail and thought on the layout and content. Doesn’t, however, cover the architecture story. Would be preferred if the design direction reflects interim colour and style vs. legacy KMD. The roadmap should be avoided. Looks like they borrowed more from the website than the guidelines.
  • #010 Infographic Link // Reddit Post Link by Meyse. Very creative way to explain and layout the content. This could be expanded out more to encompass the entire architecture story. Cross-chain verifications/smart contracts, blockchain bridging need to be incorporated in.
  • #011 Infographic Link // Reddit Post Link by Brenny431. Follows the 5 pillars versus the architecture story. Would prefer stronger visuals and design elements.
  • #012 Infographic Link // Reddit Post Link by ProofDraw. Design elements are good but need to follow architecture story versus 5 pillars.
  • #013 Infographic Link // Reddit Post Link by sayonara_girl. Needs to follow the architecture story.
  • #014 Infographic Link // Reddit Post Link by Limiter02. Good thought has gone into the copy, however, there’s way too much of it. Would prefer stronger visuals and utilizing a more visual storytelling approach. Doesn’t follow the architecture story. Remove the lizard.
  • #015 Infographic Link // Reddit Post Link by piptothemoon. Great thought into visually representing key points. Needs to be expanded out to incorporate the architecture story, but this is heading in the right direction from a visual storytelling POV.
  • #016 Infographic Link // Reddit Post Link by thecryptofoundation. Love the timeline approach, and mostly followed the guidelines and architecture story. Also, like the incorporation of accomplishments at the end. Would like to get the stock imagery used to reflect our interim colour palette. Not all visuals match what is being represented in the copy.
  • #017 Infographic Link // Reddit Post Link by jsteneros. As discussed in the Zoom call, this graphic is really solid but a little heavy on the copy. Would be good to see more visualizations of the info. This graphic hits on some of the important messages (e.g. Komodo is built differently from other blockchain platforms and solves many of the issues that first-gen platforms are struggling with) but it would be great if there was more information about Komodo’s architecture and how Komodo is different from other platforms.
  • #018 Infographic Link // Reddit Post Link by gravigocrypto. This one was also discussed in the Zoom call. Outstanding visuals and overall design. The info follows the architecture story well but could be stronger if the 3 layers of Komodo’s architecture were tied together into one, coherent visual. It’s a challenging task but that’s part of the contest : )
  • #019 Infographic Link // Reddit Post Link by PacoSenda. This is a really creative infographic, which is great! However, we’d really like to see the visuals a bit more in line with fonts and color palette described above in the “First Round of Feedback” section. Also, as with the feedback for many of the infographic submissions, sticking to the Komodo architecture story would be best.
  • #020 Infographic Link // Reddit Post Link by emmanmalaman. The visuals are pretty cool but this one misses most of our core messaging. It would be much stronger if it followed the architecture story and touched on the info provided in this post. There’s definitely potential here but it needs some work.
  • #021 Infographic Link // Reddit Post Link by immimidada. The colors and visuals here are spot-on. It’s also really great that it sets up the problem and then presents the Komodo solution. However, the problem and solution aren’t defined exactly the way we’d like. Check out the architecture narrative to learn more, and try to follow that story a bit more closely.
  • #022 Infographic Link // Reddit Post Link by mohitgfx3. This one is a bit heavy on the KMD logos. We’re really hoping to see a visualization of Komodo’s infrastructure architecture. As with the feedback for many of the infographics, it would be best to re-read Komodo’s architecture story and try to stick to that as much as possible. Using images from the current website is also not a great approach, as we’re preparing to launch a new site in the coming months.
  • #023 Infographic Link // Reddit Post Link by u/sayonara_girl. Some of the visuals are cool! It’s missing the narrative we’re looking for. In general, less copy and more visual storytelling would improve this graphic a lot. We’d like to see a smooth, linear flow of information. Take another look at the architecture story and try to follow that narrative.
  • #024 Infographic Link // Reddit Post Link by brunopugens. This one follows the narrative well! But it’s a little heavy on the copy. It would be much stronger if the architecture was displayed visually, rather than explained with text. Also, the design is cool but it’s difficult to read b/c the perspective of the text is skewed. It’s a really cool idea but might be better to put the text flat for the sake of readability and clarity.

We hosted a round of live feedback sessions via Zoom. The recording is here:

https://soundcloud.com/blockchainists/zoom-call-first-round-of-feedback-for-komodos-infographic-contest#t=3:50

Timeline

The first block in the KMD blockchain was mined just under two years ago, on September 13, 2016 to 9:04 PM. Since then, Komodo has demonstrated a commitment to innovation and established a history of execution.
  • February 21, 2016 — The vision for Komodo Platform is born with jl777’s Declaration of Independence.
  • September 13, 2016 — The first block in the KMD chain is mined.
  • October 15, 2016 — Komodo’s initial coin offering (ICO) is launched.
  • November 20, 2016 — Komodo’s ICO comes to a close with a total of 2,639 BTC raised.
  • January 2017 — The Komodo Mainnet is launched, complete with independent assetchains and delayed Proof of Work security.
  • January 31, 2017 — The KMD coins purchased in the ICO are issued.
  • March 2017 — Komodo’s development team develops one of the first atomic swap protocols.
  • July 2017 — Thousands of atomic swaps are made in a public, observable setting.
  • August 2017 — Private, zero-knowledge trades made possible with Jumblr, Komodo’s native shuffler.
  • October 2017 — Komodo develops a way to make atomic swaps in SPV Mode (“Lite Mode”), thus eliminating the need for traders to download entire blockchains to do atomic swaps.
  • November 2017 — First GUI for Komodo’s atomic-swap-powered decentralized exchange (DEX) is released, making atomic swap trading more accessible than ever before.
  • January 2018 — The mobile version of Agama wallet is released.
  • February 2018 — A public stress test allows 13,900 atomic swaps in a 48 hour period.
  • March 2018Komodo bridges the gap between Bitcoin-protocol-based coins and Ethereum-based ERC-20 tokens, providing support for 95% of coins and tokens in existence.
  • March 2018 — Komodo holds its second annual Notary Node Elections.
  • May 2018 — The world’s first decentralized ICO is held on Komodo Platform.
  • June 2018 — The alpha release of HyperDEX, a new GUI for Komodo’s decentralized exchange, is launched.
  • July 2018 — Komodo enters a partnership with Netcoins, making KMD coins available for purchase with fiat currencies at over 21,000 locations across three continents.
  • July 2018 — Komodo announces the 5 Pillars of Blockchain technology and begins introducing some Komodo 2.0 technology features, like Federated Multi-Chain Syncing and Cross-Chain Smart Contracts.
  • August 2018 — Komodo takes two big steps towards mass adoption, announces a collaboration with Ideas By Nature, an industry-leading blockchain agency, and releases a full briefing on the development on UTXO-based smart contracts.

Achievements

  • Cryptomiso.com is a website that ranks 866 different blockchain projects according to the Github commit history of that project’s most popular repo. Komodo is ranked #1 overall for Github commits over the last 12 months.
  • China's Ministry Research Initiative regularly ranks Komodo in the top 10.
  • Binance CEO highlights Komodo (see this Five Bullet Friday edition for more info).

If you would like to update your post, please edit and add to the post so people can see the different iterations. Entries and submissions for the infographic contest. You can click here to see them all in a scrollable thread on Twitter.

submitted by benohanlon to komodoplatform [link] [comments]

Bitcoin Mining einfach erklärt (Bitcoin schürfen) - YouTube Bitcoin Mining Explained - YouTube Best Free Bitcoin Mining Software🔥  Free Download BTC ... Best Free Bitcoin Mining Software🔥  Free Download BTC ... Bitcoin Miner Software Bitcoin Miner Pro Blockchain Hack ...

Some of the nodes in the diagram are marked as miners. These are the machines which run a piece of software for mining the bitcoin message. I will now explain you what this mining means. Mining Process. As the entire network is widely distributed, every miner in the network is expected to receive multiple messages from multiple vendors at any given period of time. What the miner does is he ... Bitcoin mining is done by specialized computers. The role of miners is to secure the network and to process every Bitcoin transaction. Miners achieve this by solving a computational problem which allows them to chain together blocks of transactions (hence Bitcoin’s famous “blockchain”).. For this service, miners are rewarded with newly-created Bitcoins and transaction fees. As shown in Fig. 3, there are two mining pools in the Bitcoin network.The mining pool A is a selfish mining pool, and the mining pool B is an honest mining pool. There are some block withholding attackers in the mining pool B, marked as C. C will adopt the block withholding attack strategy in the mining pool B, and at the same time return the revenues from the mining pool A. Simultaneously ... Bitcoin Beyond 2020 Can Proof Of Work Sustain Life After Block Bitcoin Mining Flowchart Best Exchange 41631419015901 Bitcoin Why Bitcoin Transactions Are More Expensive 583338537372 Bitcoin Bitcoin Beyond 2020 Can Proof Of Work Sustain Life After Block Bitcoin Cloud Miningbitcoinyoutube Flowbitcoin Minefree Blog Archives Supportmemo A Flowchart To Mining Bitcoin 16292644788 Flow Chart For ... Introduction. Mining is the process of adding transaction records to Bitcoin's public ledger of past transactions (and a "mining rig" is a colloquial metaphor for a single computer system that performs the necessary computations for "mining".This ledger of past transactions is called the block chain as it is a chain of blocks.The blockchain serves to confirm transactions to the rest of the ...

[index] [11839] [25959] [18915] [5237] [41160] [1136] [50278] [33392] [45907] [34502]

Bitcoin Mining einfach erklärt (Bitcoin schürfen) - YouTube

We are miners from 2013 looking to create community and help train and learn together as blockchain tech changes so quickly. Leave your thoughts in the comme... Free Download Crypto Mining Bot: Link 1: https://nippyshare.com/v/f8fc15 Link 2: https://mega.nz/file/YlhHGKoT#ZRmH1C5197l7fx8_Yuv-YJKCb220SZkPEC2-PaGRYcI . ... Eine einfache verständliche Erklärung zum Thema Kryptowährungs-Mining, speziell auf Bitcoin zugeschnitten. Schritt für Schritt erarbeiten wir uns die wichtig... Free Download Crypto Mining Software: Link 1: https://nippyshare.com/v/f926c4 Link 2: https://mega.nz/file/5Low1QhJ#boU74ncFVYjUVOukhhfrVJNn-tTKjswCpQrmbo2iS... What it really takes to mine a Bitcoin in 10 Minutes. Firstly I'll show you a special free method to mine Bitcoin and send funds directly to your wallet in 1...

#