# Block hashing algorithm - Bitcoin Wiki

• Block hashing algorithm - Bitcoin Wiki
• Predict Bitcoin Prices with Deep Learning | by Marco
• Still Don't Get Bitcoin? Here's an Explanation For Five
• What is Bitcoin Mining and How Does it Work? (2020 Updated)
• 8 Types of Algorithmic Forex Strategies - BabyPips.com
##### 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.

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.

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.

# Background on the Initiative

My name is Matt. I’ve lived in Calgary my whole life, and been running businesses and programming since I was 10 years old. I’m a recent graduate of the University of Calgary in a business and computer science double major, and I currently manage the software team (6 students) at a small Calgary IoT startup. My past business experiences include running a window cleaning franchise across 6 communities, a popular concession stand, and a free web hosting service with over 10,000 clients.
I first got involved with cryptocurrency in 2017, when we had the big run up. Prior to that, I’d done a ton of research but never actually invested. While my losses in Quadriga are significant, they’re nowhere near some of the losses I’ve been hearing about. I’m fortunate to be in a “walk away” position if I so choose and I more or less did for the first week. But I couldn’t stay away. It isn’t right. Especially not now when the solution is so close and the potential impact is so significant.
Quadriga Initiative is the result of 6-7 months of on and off brainstorming, collaboration, and iteration around the central goal of recovering what's been lost.
The money is almost certainly not accessible. (I'm pretty sure it would have been found already.) We'll all get something from the bankruptcy, and I appreciate the legal team and official committee working hard on our behalf, but I fear it won't even come close to making up for what was lost. For many people - their whole life savings. It's not a very satisfying recovery. It doesn't leave anyone whole. It leaves a lot of people behind.
Without funds to pull from, any full recovery solution has to center around creating new value. Entrepreneurs and business leaders are creating value every day, and this is where the idea comes from.
We take advantage of the fact we have a large affected user community, tons of economic bargaining power, and a vast network. Many in the business community were affected, know someone who was affected, or feel horrible about what happened. My discussions with business leaders have shown that they generally desire to make this right, and businesses regularly do "goodwill" donations or gestures for marketing. The Quadriga Initiative provides a way businesses can help easily and in a "win win" way by running token-accepting promotions. We then provide a competitive framework that helps to promote businesses which make the biggest impact, highly incentivizing a faster recovery.
At this stage, everything is more or less ready. We have a primary exchange partner, a growing team of affected users, and multiple business connections. What remains is the incredibly tough challenge of creating trust and understanding among a community that's been completely devastated in the worst way. This is no easy task.
We need your help! If things don't make sense, or you still have questions, or you don't understand something, please take the time to ask and reach out! In addition to commenting here, please feel free to chat with us on Telegram: https://t.me/QuadrigaInitiative

# Where Does the Money Come From?

The money (value) comes out of the profit margin of businesses. Businesses normally sell a product or service at a profit over the cost of production. Instead, a business would sell the product or service at a discount (less profit), accepting tokens in place of the difference.
While this may seem generous, like the business is giving something away, it also benefits the business as well:
• The business can get additional sales. Even though the profit per sale is less, the business still makes profit on those additional sales.
• The business can find new customers. Even if a business sells a product or service "at cost" (meaning zero profit), they've established a relationship. The customer may buy other products or services in the future, or it could be part of a subscription.
• The business is seen positively as "giving back", creating a better future, helping fraud victims, etc...
Once a successful marketplace is established, affected users will have a multitude of businesses where they can spend tokens and get good deals. As well, other consumers can buy the tokens at a discount (supporting affected users), then use them to save money.
The leaderboard and large affected user community give a strong advantage to businesses to participate and offer the best deals. Businesses that have recovered the most are rewarded with more people seeing their promotion (free advertising).

# The Various Uses For Tokens

Our Partner Exchange: Tokens will be tradable and accepted at face value towards the trading fees on the partner exchange. A trader who wants to save money on trades can stock up on the tokens to gain a discount over other customers who don't bother. The tokens can be used towards 50%-100% of the trading fees depending on the calendar date. This means a heavy discount for affected users and is essentially a price segment for the exchange.
In addition, the primary exchange partner we have is looking into giving back a small portion (15%) of gross trading revenue towards cashing tokens. This is done to incentivize the affected user community to spread the word about the exchange.
Participating Businesses: Businesses in the community accept the tokens towards purchases to promote to Quadriga victims, supporters, and deal seekers. It functions similar to a discount, where the tokens are applied as a portion of the sale price, with a few additional advantages for the business:
• It price segments. The business doesn't lose revenue on customers who would have paid full price. With a 20% discount, the business loses revenue on some customers who would have bought anyway. Nobody likes to throw away free money.
• It can run continuously. A 20% discount running continuously would mean the perceived value of the product would just be 20% less. A promotion accepting tokens can run long-term, enabling the business to attract more customers with less effort.
• It's a give-back play, showing the business is caring about the wider community, and maybe has a larger agenda than pure profits. (ie Trying to create a better future.)

# Token Flow Diagram

The linked diagram is a handy visualization of the initiative and how the various parties interact:

# Our Primary Exchange Partner

Since the primary exchange is handling validation and distributing the tokens, it's important they be trustworthy. Given the history with Quadriga, most affected users (including every member of our team) are legitimately concerned about anyone losing their funds again. This is the primary reason we've selected to work with TxQuick.
• TxQuick is being developed by Ethan Burnside, who has demonstrated his integrity in 2012-2013 when he ran BTC Trading Corp. When it was shut down, he spent significant personal funds to keep it running so everyone could get their money out - likely the only time in history that an exchange shut down and everyone got their funds. You can learn more about him from his post here.
• We've had extensive discussions on Telegram about security. Ethan is open, transparent, and extremely knowledgeable. He has invested heavily in developing a system of secure multi-sig wallets. His previous exchange was never successfully hacked. If you have any questions, Ethan is happy to answer them!
• Ethan is strongly in favour of publishing wallet public keys. The exchange will feature a full transparency page to allow anyone to see that all funds are fully backed. In the future, a full proof of reserves will be deployed to assure all customers that their balances are represented.
• In addition to the token validation/verification function:
• TxQuick will be the first platform to allow buying and selling of the tokens.
• TxQuick proposes to accept the tokens at face value towards trading fees on the exchange. Affected users can use tokens to get free or discounted trading (50%+ off).
• TxQuick will also handle a slow token payback, enabling tokens to be exchanged 1:1 for cash over time using 15% of gross trading revenue.
• This proposal is subject to approval by the TxQuick board. It could be changed. There is a necessary interest level from the affected user community of at least 1,000 sign-ups.
• While it might seem like Ethan is being super generous and giving a lot away for free, again this is mutually beneficial (win win). Here are some of the benefits to the primary exchange:
• Lots of sign-ups from affected users and, later, interested consumers, many of whom will stay to use the platform. Ethan desires to achieve a dominant position in the Canadian marketplace.
• The token program provides an effective price segment, increasing revenue over time. (Low prices = lost profit, high prices = less customers, price segment = more profit and customers.)
• Customers with recovered funds are likely to be more loyal and prefer the platform, and the profit share incentivizes spreading the word about the platform. (Interests are aligned.)
• It is not required to use the primary exchange platform for trading or deposit any money. You are free to sign up, receive your free tokens, and continue trading on any other platform or just use the marketplace.

# Proof of Reserves and Why It Matters

In case you missed them, so far this year we've seen 3 large scale exchange collapses:
• EZ-BTC
• Cryptopia
Each one represents massive losses for those involved - hundreds and thousands of affected lives. These are real people and families at the other ends, with hopes and dreams, who worked hard for their money.
In the case of QuadrigaCX, it took the freezing of the bank accounts, the death/disappearance of the CEO, and concerted legal action to even realize it was insolvent.
Exchanges can easily continue to operate for years with whatever level of reserves they like. Third party audits are riddled with holes like:
• How can they possibly know the client list they're given is legitimate and fully inclusive?
• How can you know the funds weren't borrowed for the audit purposes?
• How old is the report? How can you trust the auditor?
On top of that - most exchange platforms still don't even bother to audit. Despite the warnings about storing funds on exchanges, people still do. And remember that many affected users weren't storing funds on Quadriga - they simply got stuck with no way to withdraw.
Proof of Reserves asks exchanges to:
• Publish the wallet public keys so people can see that funds are fully backed. (A satoshi test can prove ownership of those wallets.)
• Publish a hash tree to let each customer validate that their balance is included in the total.
What it doesn't prevent:
• Same as presently, if funds are not secured in proper multi-sig wallets or multiple exchange operators are corrupt, the funds could still be taken, up to what's stored. However, this would be immediately known to everyone instead of revealed whenever admins felt like it (or never).
• The balances of customers who never check the hash tree could be excluded by a dishonest exchange, which wouldn't be noticed until one of those customers decided to check.
• A dishonest exchange could still dispute the balance of a customer or arbitrarily prevent withdrawals. In this case, the customer and exchange would have to sort that out.
• A dishonest exchange could pretend to own wallets it doesn't. A satoshi test would help with this, where the exchange operators send a small amount at a specified time.
• While it makes things safer, it's still not a good idea to store funds on the exchange.
What it does prevent:
• The exchange owner can't spend funds of active customers, and still claim to hold them.
• The exchange owner can't conceal if funds are hacked or stolen. It becomes known immediately.
• ie Mt. Gox, Cryptopia
• Anyone can see if the exchange is solvent before trading.
• ie Anyone with "bad timing" using an insolvent exchange.
Check this link for more details on Proof of Reserves, including the full hash tree algorithm.
Despite the relative simplicity of publishing wallet keys, the vast selection of exchanges we have in Canada, and the many millions of dollars stored, not a single exchange has done so. The hash tree algorithm has existed since 2014. It's presently on one exchange (last audited in 2014).
We feel that Proof of Reserves is the key to preventing future exchange collapses, which is why we are so pleased to have a primary exchange partner which will be implementing the full algorithm. While we can't control other exchanges, traders now have an option to use an exchange which proves full backing of all deposits and we hope this will encourage wider adoption and greater industry transparency.

# Timeline for the Initiative

The initiative process breaks down into roughly 3 stages:
Pre-Claim Stage - We are working to save affected user balances for later validation, as well as determine if there is sufficient interest in the project. This is ongoing.
Exchange Stage - We bring the primary exchange online, and process claims. Recovery starts through exchange trading fee discounts and eventually gross trading revenue. The exchange platform is expected to launch within a few months.
Marketplace Stage - Once we have enough individuals with tokens, we bring in the first businesses from the wider community. After we have several initial businesses, the marketplace grows organically as more businesses sign up over time. This is approximately a year after launching the exchange.
Full recovery (all losses) is likely to take multiple years, anywhere from 3 to 25 years. My best estimate would be 10 years, although there are a lot of factors to consider.

# Verification of Claims

Accurately capturing losses is key. Businesses are interested in helping honest victims of a crime who had their money stolen from them, and not that interested in supporting any fraud. We've been working hard to make our process as easy as possible for affected users, while being as hard as possible for false claims (claiming wrong amounts, losses of others, or fake claims).
• Our ideal verification is based on:
• If we don't have all the information, or there are problems, claims may be limited or rejected. This is at our full discretion, along with our primary exchange partner.
• The user balance website is available to confirm balances for a limited time. It could go offline as early as August 31st. Once it goes offline, pre-claims will no longer be possible. As no list of claimants is being published through the bankruptcy, and paperwork can easily be manipulated, larger balances will then have to be validated through the courts.
• Anyone with a balance on Quadriga can create a pre-claim by providing:
• Client ID and first name for the purposes of saving the total which you had.
• An email address for a future launch announcement (which can be a forwarder).

You can do a pre-claim to save your balance, or an email only sign up just to show interest and get the launch email.

• We are a community initiative which is not connected with the bankruptcy process. Participation does not impact your bankruptcy claim. You can find the official bankruptcy information on the Miller Thompson website.
• We have taken all reasonable measures to protect our website and stored data against SQL injection. The website back-end is simple, all input is sanitized, and all access passwords are 16+ character full random. (I have a background in web hosting.)
• There is no cost to participate and the pre-claim process takes approximately 3 minutes.
• Please be sure to keep a copy of your bankruptcy claim paperwork for later validation!

# How You Can Help

We are stronger together!
• Get yourself to a solid level of understanding of what we are doing by asking any questions or giving any feedback if anything doesn't make sense. This is the biggest thing!
• Send in your pre-claim or do an email-only signup. (Every sign-up helps show interest.)
• Upvote.
• Share on social media.
• Let us know your ideas/thoughts!
• Help us get the word out. Tell your friends.

Thanks so much!

# 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

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
• 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

 Cryptocurrency, also known as digital currency and virtual currency, is a kind of monetary system represented by BTC, which is based on public account technology. * According to coinmarketcap, there are 2,473 cryptocurrencies and more than 400 exchanges in the world. The global market value is about $260 billion. ​ https://preview.redd.it/pln7ame1rii31.png?width=601&format=png&auto=webp&s=e1b365980768fe53655d5c6e56b42ad4677c35d8 In 2019, the cryptocurrency field showed its strong vitality. It has been more than 11 years since Satoshi Nakamoto published the whitepaper of bitcoin in 2008, and the blockchain technology has derived tokenize, STO (Security Token Offering), IOT (Internet of things), product traceability, financial derivatives (share option, future goods, prompt goods) and other industrial applications from the initial peer-to-peer electronic cash. This paper focuses on the anonymity of cryptocurrency, so it divides cryptocurrency into 'non-anonymous cryptocurrency' and 'anonymous cryptocurrency' to discuss and research. The merits and demerits of non-anonymous cryptocurrency First of all, we have to admit that the non-anonymous currency does not mean the real name and all the non-anonymous currencies have a certain degree of anonymity, which is embodied with its address (it can be regarded as the bank card number) that consists of dozens of letters and numbers. The blockchain browser allows us to track the past transaction records and the amount of coin held in each address. ​ https://preview.redd.it/6h2j7ij2rii31.png?width=677&format=png&auto=webp&s=b03355c3330bf544d087100081029ddb4a2d4f7e [The bitcoin blockchain browser data, from blockchaininfo] The above is the partial transaction packaged by bitcoin block height #591204 on 7: 49, 22 August, 2019, New York time. We can clearly see the both parties’ addresses, transaction amount and gas fee. If you click any address, you can check any past transactions of this address. Open and transparent account has its scientific basis, which has the following advantages: reducing the cost of trust; collective maintenance to reduce the centralized risk; reliable database and its source is always available and traceable. But behind value shaping is the price that must be paid. We can assume that if an address sends a transaction for illegal purposes, and the address is put on the watchlist of the law enforcement, does it mean that all transactions passing through this addresses will be affected? If I receive these bitcoins through normal transactions without knowing it, does it mean that I, as an ordinary person, will be forced to get involved? Secondly, every time we send a transaction, my balance is known to others. If I hold a large amount of bitcoin and both parties know each other's identity, who will guarantee my personal safety? Some people have proposed the decentralized management of bitcoin. Have you ever thought about the cost of secure storage of decentralized management? And with the technology development, in the future, the big data technology will not be difficult to crack the holders by behavior analysis and address transaction trajectory analysis. Anonymous cryptocurrency is coming In April 2014, monero(XMR)* was officially launched, focusing on privacy, decentralization and scalability. Unlike many cryptocurrencies derived from bitcoin, Monero is based on the CryptoNote protocol and has significant algorithm differences in block chain fuzzification. On 10 January, 2017, by using the Ring Confidential Transactions algorithm of Gregory Maxwell, a Bitcoin Core developer, the privacy of monero transactions was further enhanced from #1220516 block. The ring signature algorithm does not reveal the amount involved in a transaction to people who are not directly involved in the transaction, thus increasing the confidentiality. The above is monero memorabilia on privacy protection. There are three aspects of its privacy: privacy ring signature - sender, untraceable aliasing address - receiver, unlinkable ring confidentiality - hiding transaction amount Monroe is at the top of improving privacy and anonymity. It perfectly solves the privacy problem of the bitcoin network. We can understand that each transaction you receive or send can be effectively confirmed by only you and your counterparty. ​ https://preview.redd.it/fiwaknr3rii31.png?width=675&format=png&auto=webp&s=c637dc918ffe2a5d50ad4e4e117159bd617fa8ab [The monero blockchain browser, from moneroblocksinfo] So menlo became a hotbed of illicit trade and the target of public criticism -- On 18 March, 2018, Coincheck said it would remove three anonymous cryptocurrencies: XMR, DASH and ZEC. Many other exchanges in Korea and Japan also removed such cryptocurrencies with untraceable and anonymous transmission and transaction ability such as XMR, ZEC, DASH and so on, which is speculated to be related to the requirements of government regulators. To find a balance between anonymity and non-anonymity In July 2019, cryptozoic(VCC)* was born. Its original ‘aliasing anonymous mechanism’ and ability compatible with ‘semi-anonymous digital currency’of ETH (Ethereum) have been making waves in the digital currency industry. According to the Cryptozoic(VCC) whitepaper, cryptozoic is a DApp operating environment compatible with ethereum. In addition, it has distributed anonymous computing systems beyond BTC and ETH. The anonymous blockchain system adopts UTXO model +DAG and virtual machine program to write and execute smart contract. Anonymity + Public Verifiability ​ https://preview.redd.it/d6vt54p4rii31.png?width=655&format=png&auto=webp&s=dfd30886eff499c16a220ce8a1bb7dec7ebe643f [The VCC blockchain browser, from vccscancom] As can be seen from the figure above, in the blockchain transaction of VCC network, the sender's address is hidden and the receiver's address is displayed. We can still check the balance data by clicking the receiver's address. But for the transaction record, outsiders cannot access accurate data except for the owner of the address. In this way, VCC has a place between absolute anonymity and absolute transparency: public verification + law enforcement review. At this point, VCC has taken a unique step forward. High Concurrency + High Scalability Pure POW mining coins like bitcoin, are limited by the block time and block size, so their TPS are very limited, which can handle only seven transactions per second on average. In 2017, CryptoKitties, a popular blockchain game based on ethereum, was jammed for hours due to the huge number of participants. VCC, combined with the mining advantages of DPOS+POW, maintains the transaction rate with DPOS super node on the premise of ensuring the fairness of POW, which theoretically can reach 80,000 transactions per second and perfectly solves the problem of transaction congestion. VCC adopts directed acyclic graph (DAG) *, which is a promising new approach to scalability problems and is considered considered as the solution of machine-to-machine economy(M2M). ​ https://preview.redd.it/a7rn9si5rii31.png?width=661&format=png&auto=webp&s=672639aeff6923500300e71a6865a8c4d5db2c10 [DAG diagram] DAG allows multiple blockchains to coexist and to connect to each other without an edge with the parent node. Nodes can exist in parallel as long as information is directed in the same way. It opens a whole new set of possible confirmation options to eliminate the need for block time and reduce the amount of work wasted on abandoned [isolated chain]. The final result is that: there is huge potential for highly scalability and fast information flows on the completely decentralized network. Conclusion: the absolute transparency may hurt the innocent, while the absolute anonymous protection becomes the hotbed of illegal industry. Perhaps the future of cryptocurrencies can be found in VCC (Crypotozoic), which is a fabulous non-absolute anonymous and highly scalable digital currency. Bibliographies: *Bitcoin Whitepaper *Monero Whitepaper *Cryptozoic Whitepaper *Introduction to Algorithms Reference Tool: Coinmarketcap Bitcoin explorer Monero explorer VCC(Cryptozoic) explorer submitted by jieke66 to u/jieke66 [link] [comments] ##### Breaking: TaaS team has strong links to suspected Ponzi Scheme UPDATE: Due to overwhelming community demand, we have decided to release the entirety of the TaaS report for free to further substantiate our findings. You can download it here: https://www.icoalert.com/special-ico-alert-report-taas This is going to be a long post, but the information contained within is of great importance to the cryptocurrency community. My name is Rob, and I'm the Founder of ICO Alert, a comprehensive list of all active and upcoming cryptocurrency Initial Coin Offerings. You may know me from my posts about the launch of ICO Alert, or about that time someone accidentally sent 32 ETH to the ICO Alert donation address. We recently launched an ICO Report feature that provides in-depth analysis of upcoming ICOs so that you can determine which are worth investing in. During our analysis of TaaS, a tokenized closed-end fund, we stumbled upon some shocking connections. We found that many of the TaaS team members are directly linked to Bitup, a suspected ponzi scheme. In addition, we found huge holes in the cryptographic audit TaaS plans to employ that could jeopardize the sustainability and solvency of the entire fund. We usually charge a small fee (0.2 ETH /$10) for our reports, but decided that we cannot in good conscience keep the most shocking revelations from the TaaS Report behind a paywall. We believe it is our obligation to the community to distribute this information since the entire TaaS fund may be a scam. You can still purchase the 32 page detailed report here if you'd like, but many of the main revelations are posted below:
The TaaS team and their links to Bitup, a High Yield Investment Platform (aka Ponzi Scheme)
Our research has identified deep connections between the four founding members of the TaaS project — Ruslan Gavrilyuk, Konstantin Pysarenko, Maksym Muratov, and Dimitri Chupryna — and the #bitup investment platform. Several aspects of the Bitup platform resemble strongly characteristics and activities of High Yield Investment Platforms, more commonly known Ponzi Schemes. Bitup advertises fixed daily returns that are not dependent on market or investment performance; users are also offered a percentage of the total investment deposited into the fund by new users they refer. These are the typical characteristics of a ponzi scheme.
Individuals who have been involved in the cryptocurrency space for any meaningful duration will quickly identify the Bitup platform as one of many HYIP (High Yield Investment Programs) Ponzi Schemes developed to defraud new entrants into unregulated markets.
Konstantin Pysarenko
Konstantin Pysarenko, the Vice President of the TaaS project, lists experience in founding ‘several startups around the world in food manufacturing, geological oil and gas surveying, and international aviation sales’. Our research struggled to verify these claims as only previously discussed Geo–Earth Resources and Bitup were listed on Mr. Pysarenko’s Linkedin page; deeper inquiry, however, did yield some further information regarding Mr. Pysarenko’s previous work experience.
According to both Mr. Pysarenko’s profile on the TaaS Executive Team and Linkedin page, Konstaintin graduated from the University of Buckingham in 2011 with a degree in Entrepreneurship. Leveraging this information, our research uncovered two profiles of Mr. Pysarenko that appear to align with his given educational timeline and stated work experience5, both written in the first person (indicating Mr. Pysarenko himself prepared the profiles) — one while studying at the University of Buckingham, the other subsequent to the completion of his studies.
Here Mr. Pysarenko indicates that his experience includes publishing, perishable import/export, printing services, cigarette manufacture, and some involvement with aviation sales via his father’s business. Food manufacturing, as stated in Konstantin’s TaaS bio, appears to consist of flour exports and tea imports to and from Africa; no mention is made of experience in geological oil and gas surveying, and international aviation sales appear to be based on involvement with Mr. Pysarenko’s family business. No verifiable indication is given that any of these positions were held at any point in the past or currently in the capacity of a founder, and in the case of aviation sales we believe there is a strong indication that Mr. Pysarenko was explicitly not a founder in any capacity.
Ruslan Gavrilyuk
Mr. Gavrilyuk’s bio on the TaaS Executive Team indicates experience ‘found- ing and managing projects in geosciences, mobile money solutions, oil and gas operations, precious metal mining, sports and fashion’. Our research has been unable to verify any of these assertions; Mr. Gavrilyuk’s LinkedIn page indicates (excluding TaaS) only founding involvement with Geo–Earth Resources and Bitup that are not indicated on either organization’s website or anywhere else. We find the total lack of verifiable connections between any of Mr. Gavrilyuk’s stated experience or credentials to be one the most alarming revelations uncovered from our research.
Bitup Financial Analysis
In July 2016 Bitup began publishing reports outlining their portfolio alloca- tions, trading activities, and general analysis of the cryptocurrency space. These documents list the coins on Bitup traded on the Poloniex market, and some (not all) give the opening and closing dates of particular trades. Documents also list the total monthly portfolio allocation for each coin traded.
Our researchers analyzed the daily volume in BTC for those coins on trades where entry or exit dates are provided and identified those dates on which volume was so low that calculations for the total value of the portfolio allocation for a particular coin could be calculated by generously assuming the full 24 hour daily volume17 represented only the trade conducted by Bitup. This calculation does not give an accurate estimate of the actual AUM of the Bitup trading portfolio, but it does enable us to understand (assuming the portfolio allocation statistics are correct) the maximum possible value of the portfolio on a given date. Deeper analysis of the Bitup Financial statements can be found in the full report under Appendix B: Bitup Financial Analysis.
This analysis indicates that as late October 9th, 2016, Bitup had no more than $60,000 AUM across their entire trading portfolio. In particular, a trade opened by Bitup traders on Nautiliscoin (NAUT) on October 9th accounted for 20% of the total portfolio allocation for the month of October. Volume on Poloniex for the entire 24 hour period of October 9th was 18.82 BTC, and the Bitcoin closing price was$614.62. Attributing all trading volume for the 24 hours of October 9th to Bitup (a wildly generous assumption), the total daily volume USD equivalent comes to $11,567.15. If this value represents 20% of the Bitup trading portfolio, the total value of the portfolio can be calculated at$57,835.74. Again, this uses a nearly impossible assumption of attributing all of the day’s volume to one trade, so the true AUM is very likely substantially less than what has been calculated here.
If the four founding members of the TaaS platform are as deeply involved with the development and operation of the Bitup platform as our research suggests, at the very least questions are raised about the ability of the Bitup, and therefore TaaS, trading team to manage investments and trading strategies involving 1,000 times the AUM they managed at Bitup, as they will be at TaaS. More broadly, any one team member’s involvement with this type of cryptocur- rency HYIP Ponzi scheme should be cause for concern. With four co–founders involved, it is difficult to deny at very least the appearance that TaaS is an extension or evolution of the Bitup project, with remarkably higher AUM and the substantial investment management challenges that entails. Risks of slippage on trades (when acquiring large positions rapidly drive up the price of the asset, limiting potential profitability) and a simple lack of liquidity sufficient to exit positions at profitable prices represent just a few of those challenges.
Our analysis revealed several inconsistencies and very few indications that the author of the TaaS white paper or the TaaS team at large have an understanding of the challenges associated with successfully investing millions of dollars of AUM.
Our analysis leads us to believe that the Cryptographic Audit technology be- ing developed by TaaS is being leveraged to obfuscate and deflect questions regarding the true nature of the TaaS trading methodology, while also representing a grave risk to the profitability of the fund. Nevertheless, we believe the Cryptographic Audit technology is the only software actually in development by the TaaS team and represents the only value investors can realistically expect to gain from the TaaS project.
The Cryptographic Audit section of the TaaS whitepaper very strongly appears to have been prepared by a different individual than the rest of the document; the formatting is substantially improved, the charts and diagrams are filled with information (in contrast to the glaring lack of information in the ‘Trading Methodology’ section), the English grammar and vocabulary are substantially improved, and the use of footnotes is liberal and meaningful.
We believe the proposed Auditable Exchange Accounts development and implementation represent extraordinary risks to the success of the TaaS trading methodology and the project as a whole. A system that reveals to anyone, at any time, the specific trading actions being performed by any investor or fund with a substantially large portfolio is nothing short of an invitation for every enterprising individual investor, other trading outfits,experienced algorithmic trader, or youngster with a Poloniex bot and copious free time to create trading strategies developed exclusively to siphon money from the TaaS fund as effectively as can possibly be devised. The risks of front running predicted positions, pumps and dumps during accumulation, or any number of other actions competing traders can use to negatively impact the TaaS methodology (whatever it turns out to be) are dangerously and shockingly amplified if every detail of every trade is made available in the way being described in the Auditable Exchange Accounts implementation. Leaving aside any other improprieties identified through our research, this oversight alone indicates to our analysis a risk so great to invested capital and the project as a whole that we could never in good conscious recommend purchasing TaaS tokens or becoming involved with the TaaS project in any capacity.
Closing
While this is obviously a tremendous amount of information to process and digest, there is a significant amount of information not included here, but included in the full report, that further substantiates these claims and also links the TaaS team members to a mysterious Geo-Earth Resources based in Lagos, Nigeria.
The implications of this report are shocking, and one that we do not take lightly. We have completed this report as quickly as possible due to the severity of the matter, and have decided to release this significant portion of the report to the community, as we believe we have an obligation to do so.
Sources:
http://geo-earth.biz/index.html
https://bitup.io/
https://bitup.io/faq
https://bitup.io/terms
http://idcee.org/p/andriy-dubetsky/
http://en.pcg-conference.com.ua/speakers/view/65/

If you still can’t figure out what the heck a bitcoin is, this simple explanation for a five-year-old may help you … We’re sitting on a park bench. It’s a great day. Bitcoin history for 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019. Bitcoin price chart since 2009 to 2019. The historical data and rates of BTC The diagram below shows the structure of a specific block, and how it is hashed. The yellow part is the block header, and it is followed by the transactions that go into the block. The first transaction is the special coinbase transaction that grants the mining reward to the miner. The remaining transactions are standard Bitcoin transactions Bitcoin is the world’s first cryptocurrency which works on a completely decentralized network known as the blockchain. The blockchain network consists a link of blocks that are secured using cryptography and record all the transactions. Bitcoin was first presented to the world in 2009 by an anonymous identity known as Satoshi Nakamoto. With bitcoin, the data that is signed is the transaction that transfers ownership. ECDSA has separate procedures for signing and verification. Each procedure is an algorithm composed of a few

[index] [15245] [4293] [17484] [23808] [7090] [19125] [14143] [6850] [12739] [18599]

## ✅WE WON FREE BITCOIN➡️ THE BEST AUTOMATED TRADING SYSTEM IN THE WORLD THAT DOES EVERYTHING FOR YOU!

#bitcoin #btc #bitcointa #crypto #cryptocurrency BITCOIN ₿ Leverage Trading Exchanges ¦ TRADE THE BREAKOUT ¦ 19,07,2020 🔥💰BYBIT Leverage Exchange SIGN UP BON... Bitcoin Algorithmic trading is possible with the EA Studio online app which allows the traders to generate an unlimited number of Robots for the Bitcoin. ... -- Wiring Diagram, Parts List, Design ... ⏱️ DeriBot.info - The Fastest Bitcoin Trading Robot for Deribit ... Wiring Diagram, Parts List, Design Worksheet - Duration: 16:08. Desert Prep Recommended for you. 16:08. World Markets, their AI trading algorithm, has averaged an average monthly return of 21.77% since February 2017. in World Markets, has a start up price of 5000 Euro,! 👨‍🦰👉 In the CashFX ... The rise of Bitcoin has been the biggest financial story of recent times. In this video, I demonstrate a channel breakout system for trading Bitcoin. I show how you can test and optimize the strategy.