Crypto Help: { was ist bitcoin mining }

Dive Into Tendermint Consensus Protocol (I)

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

The semi-synchronous network model and Byzantine fault tolerance

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

The CAP theorem and Byzantine Generals Problem

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

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

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

Practical Byzantine Fault Tolerance, PBFT

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

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

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

Are we naive to think the elites were surprised by btc/blockchain? Some interesting points inside.

I'll start with saying the concept of blockchain was created by NSA with a bunch of cryptologists in 1994-1997 so they have known about it for a long time(even created it, actual paper below)
disclaimer: theres just a tiny bit of a conspiracy spin to it
With that as a starting point, it’s now becoming increasingly evident that Bitcoin MAY be a creation of the NSA and was rolled out as a “normalization” experiment to get the public familiar with digital currency. Once this is established, the world’s fiat currencies will be obliterated in an engineered debt collapse (), then replaced with a government approved cryptocurrency with tracking of all transactions and digital wallets by the world’s western governments.
.
What evidence supports this notion? First, take a look at this document entitled, “How to make a mint: The cryptography of anonymous electronic cash.” This document, released in 1997 — yes, twenty years ago — detailed the overall structure and function of Bitcoin cryptocurrency.
https://digitalcommons.wcl.american.edu/cgi/viewcontent.cgi?article=1389&context=aulr
.
[1997]With the onset of the Information Age, our nation is becoming increasingly dependent on network communications. Computer-based technology is impacting significantly our ability to access, store, and distribute information.
.
An electronic payment protocol involves a series of transactions, resulting in a payment being made using a token issued by a third party.
.
The most common example is the electronic approval process used to complete a credit card transaction; neither payer nor payee issues the token in an electronic payment.
.
The electronic payment scenario assumes three kinds of players:
" a payer or consumer ("Alice"),
" a payee, such as a merchant ("Bob"), and
" a financial network with whom both Alice and Bob have accounts(the "Bank")
Why would they want blockchain? Its even mentioned in the paper.
The untraceability property of electronic cash creates problems in detecting money laundering and tax evasion because there is no way to link the payer and payee. To counter this problem, it is possible to design a system that has an option to restore traceability using an escrow mechanism.
Theyre talking about blockchain and tracing money in fucken 1997.
So whilst btc is great and open source but do you think this is going to replace banks? That they didnt see this coming? Blockchain is great for goverment.
Btc is Robin Hood style money and its gonna get smashed.
.
"See Tony Eng & Tatsuaki Okamoto, Single-Term Divisib Electronic Coins, 1994 ADvANcES IN CRYPTOLOGY-EUROCRYPT '94, LECTURE NOTES IN COMPUTER SGI. 311, 313."
Three divisible off-line cash schemes have been proposed, but at the cost of longer transaction time and additional storage.
Eng/Okamoto's divisible scheme is based on the "cut and choose"
Okamoto's scheme is much more efficient and is based on Brands' scheme but also will work on Ferguson's scheme.'
Okamoto and Ohta's scheme is the most efficient of the three, but also the most complicated.
It relies on the difficulty of factoring and on the difficulty of computing discrete logarithms.
Eng/Tatsuaki Okamoto and Ohta's scheme
Tatsuaki Okamoto +eng+ohta
Satoshi Nakamoto
Did these 3 create this or?
??
.
It is evident that SHA-256, the algorithm Satoshi used to secure Bitcoin, was not available because it came about in 2001. However, SHA-1 would have been available to them, having been published in 1993.
.
On top of the fact that the NSA authored a technical paper on cryptocurrency long before the arrival of Bitcoin, the agency is also the creator of the SHA-256 hash upon which every Bitcoin transaction in the world depends. “The integrity of Bitcoin depends on a hash function called SHA-256, which was designed by the NSA and published by the National Institute for Standards and Technology (NIST).”
.
“If you assume that the NSA did something to SHA-256, which no outside researcher has detected, what you get is the ability, with credible and detectable action, they would be able to forge transactions. The really scary thing is somebody finds a way to find collisions in SHA-256 really fast without brute-forcing it or using lots of hardware and then they take control of the network.” Cryptography researcher Matthew D. Green of Johns Hopkins University said.
.
Chaum developed ecash way back in 1983, long before the large scale propagation of the world wide web. Chaum was a proponent of anonymity in transactions, with the express demand that banks and governments would have no way of knowing who had purchased what.
.
Although Bitcoin adds mining and a shared, peer-to-peer blockchain transaction authentication system to this structure, it’s clear that the NSA was researching cryptocurrencies long before everyday users had ever heard of the term.
.
‘I wouldn’t be surprised if he is actually an American working for the NSA specializing in cryptography. Then he got sick of the government’s monetary policies and decided to create Bitcoin.’ Vitalik Buterin account then replied: ‘Or the NSA itself decided to create Bitcoin.
Here you see a freedom of information act letter to the NSA asking about their involvement in BTC and they say its classified lol
Why the fuck would that be classified?
We're fucked guys.
submitted by pabbseven to CryptoCurrency [link] [comments]

Nebulas Technical White Paper Review January 20, 2018

Nebulas Technical White Paper Review January 20, 2018

Whitepaper version: 1.0 September, 2017.

Built on ground-breaking innovation, Nebulas brings blockchain technology into the 3rd generation.
Nebulas offers two different white papers; while the first is a basic overview, the second is technical.
The technical white paper describes the specifics of the project, and with each part broken down into details, it is not only quite long, it is also considered one of the most technical white paper of any blockchain technology to date. Although detailed information provides transparency and answers questions, many people are finding it difficult to comprehend.
No doubt, most investors are looking for the next hot coin that will provide a good pay day! While I believe that Nebulas can provide just that, I also feel that it is always important to understand what you are investing in. If you take the time to read everything carefully, Nebulas’ technical white paper shows the entire system in its final glory!
Therefore, the comments below compile my analysis of the technical white paper (in combination with other reliable sources). I will also do my best to include the page where you can find these facts in the technical white paper. Therefore, I suggest that rather than taking my word for it, read it for yourself.
Based on pros and cons, let’s break down the primary elements of Nebulas:

Nebulas Rank (NR)

Nebulas Rank (NR) will be the first to integrate search engine capability into blockchain. In other words, Nebulas Rank is the protocol responsible for making search engine a viable element in the blockchain. Right off the bat, let’s address an important question, "What good is a ranking system inside a blockchain?"
Currently, there is no way to search the blockchain for meaningful data (other than simple transactions), and, therefore, it’s impossible to find dApps or locate smart contracts. If this doesn’t sound like a big deal, imagine trying to search the internet without google or some other search engine – it would be impossible!
Just as the first internet search engine evolved the internet into what it is today, the first blockchain search engine will inevitably evolve blockchain. Not only a stepping stone for the future of blockchain, we’re talking about a new foundation for blockchain technology.
By providing a blockchain search engine, the Nebulas Ranking system will allow users to locate quality dApps (decentralized apps) and smart contracts. For example, let’s say that you are looking for a dApp like CryptoKitties. No doubt, there could be dozens of similar apps. So, based on multiple data resources, such as blockchain activity, github activity, and even google search history, the ranking algorithm (NR) orders similar apps, and then lists them in a manner that the user can evaluate and select.

Now, can you see why Nebulas is being compared to google?

But, this is only the beginning…. Nebulas Rank is also interwoven into the Developer Incentive Protocol (DIP) and the Proof of Devotion (PoD) Consensus Algorithm. Without Nebulas Rank, these other two elements could not operate as the white paper states.
Based on the current white paper, let’s spotlight some potential negatives about the Nebulas Rank(NR) protocol. However, also keep in mind that these potential issues could be completely eliminated as the project develops (thanks to Nebulas Force – more on this later).

Now the potential negative:

However, while the white paper describes the search engine being centralized, it also says "In current stage..." Thereby indicating that Nebulas developers have a better solution in the long run. Perhaps a sidechain just for searching? The white paper also states that "the complete code for searching backend is available to the community and third-party developers can create their own searching services on this basis." Hopefully, this will keep the ranking honest.
Since the Nebulas blockchain is based on the Nebulas Rank (NR) system, now that we have highlighted the most important aspects of Nebulas Rank (NR), we can dive deeper into specific functions.

Proof of Devotion (PoD) Consensus Algorithm

In the cryptocurrency world, Proof of work (PoW) means mining. While damaging to the environment, few can argue that this is a terrible waste of natural resources. As an alternative, the cryptocurrency world also has Proof of Stake (PoS). Proof of Stake allows token/coin holders to stake (aka hold un-spendable tokens), and to be rewarded with more tokens when they create a new block. For example, if there are 100 people staking and there are 100 new blocks per hour, every stake will, on average, receive one block reward per hour.
While better for the environment, Proof of Stake creates an imbalance where major coin holders (aka whales) are rewarded with even more coins, and this allows "whales" to stake even more coins (this means that there could be a potential to monopolize the system).
Now, Nebulas brings us Proof of Devotion (PoD)[iii]. As far as I know, there is currently nothing like this in blockchain technology (nor ready to be released). Proof of Devotion essentially awards developers who make awesome things (such as dApps) on the Nebulas blockchain.
If you develop an dApp that’s performing well on the Nebulas network, you will have the option to be a validator (aka validate submitted transactions), and, in return, receive token rewards from the blockchain. To be a validator, you will need to stake (deposit) X amount of tokens. Then, multiple validators (per transaction) will have to agree on the result[iv], and, each will be rewarded 1.5x the amount staked.
The generation of new blocks[v] will be carried out by "highly important" accounts that Nebulas Rank (NR) calculates. As stated in the whitepaper, "PoD empowers the selected accounts to have the bookkeeping right with equal probability to participate in new block generation in order to prevent tilted probability that may bring about monopoly".
The bottom line... when it comes to Proof of Devotion, why use Ethereum to create a dApp when you can create the same dApp on Nebulas and make a profit? Needless to say, this is a huge incentive for developers to make dApps on the Nebulas network, and, consequently, it will increase the value of the network. Furthermore, since Nebulas will provide developer tools, it will be easier to create dApps.

Now the potential negative:

Because it inspires developers to create awesome dApps, and, at the same time, profit directly from blockchain, I personally love this idea! No longer will dApp creators require insane ICO’s nor will they need some other stream of revenue. However, participating in PoD does not stop developers from benefiting from other income streams. Truly groundbreaking!

Developer Incentive Protocol (DIP)

Not only can Proof of Devotion give incentive to developers, quality developers will also receive extra coins/tokens for their hard work. Based on Nebulas Rank(NR), Nebulas will use an algorithm for reward distribution[vii]. The rewards will be automatically distributed to the smart contract cash-out address every 7 days.
There is really nothing negative to add to this. It’s truly a powerful incentive!

Nebulas Force (NF)

Who needs hard forks? Nebulas Force will allow developers to introduce new features/protocols into the Nebulas blockchain without a fork. The Nebulas white paper calls it "Self-evolving blockchain technology" but I don’t believe this is quite correct. Rather than being self-evolving, it is actually community driven! Because this will build the blockchain community, in my opinion, this is even better!
With other blockchains for example, if a developer has an awesome idea for a dApp but it needs a new protocol that does not exist on any blockchain, the developer would have to centralize the dApp or chuck it altogether.
With Nebulas, new ideas can be developed, and if they provide positive contribution, the Nebulas community (Nebulas token holders) can vote on and approve changes to the network protocol. Once approved, Nebulas developers can add the new protocol into the Nebulas blockchain. Perhaps, further in the development, sub-chains will also support new protocols for full implementation.

Upgradable Smart Contracts

Revolutionary for blockchain, Nebulas Force will include upgradable smart contracts[viii]. Why is this important? Well, due to bugs in smart contracts, investors can lose funds in any blockchain network that uses smart contracts. Once submitted to the blockchain, nothing can be done to fix the bugs, and, as a result, tens of millions of dollars have already been lost.
Nebulas plans to overcome this problem through the implementation of upgradable smart contracts. In a nutshell, token holders will vote on proposed changes (to fix specific bugs), and when the overall vote is affirmative, bugs can be eliminated at any time. By saving investors millions, it will restore lost confidence!

Now the potential negative:

  • The Nebulas protocol is only modifiable by the Nebulas core developers. Although this is not really a negative, I would not call it "self-evolving". If you look at Bitcoin, there is a handful of developers responsible for source code, and, subsequently, the source code for all alt coins that use Bitcoin core in some capacity (such as LTC, BCC, BTG, DOGE, etc…)
  • The protocol updates will be applied via a hard coded signature into the genesis block[ix] and this means that there is a potential for network compromise.
  • Although there are some ethical issues with modifying smart contracts, overall, it is a great idea! Since token holders will have to vote on any changes, there could be an issue with whales (monopoly owners) controlling contracts.
Even with the negatives, this is a powerful feature.

The above includes Nebulas’ most innovative features, and although these features stand out, there is even more to Nebulas:

Anti-cheating algorithms[x]

To ensure fairness, the above protocols contain anti-cheating algorithms that are manipulation resistant, and, if someone is found trying to cheat, there are penalties.

Smart contracts almost anyone can write![xi]

Nebulas will support smart contracts written in Javascript, Python, Java and more! And this means that any coder can create a logical contract!

Full voting protocol[xii]

Since Nebulas includes a full voting protocol in the blockchain, you and I, as token holders, can help decide the direction of Nebulas. As an example, the coin "Decred[xiii]" also has a voting system; giving end-users a voice keeps them engaged.

Domain Name Service[xiv]

Although blockchain users are accustomed to "please send funds to: 0x488B2630CEdB5Bfd5e02c33A3653227170743357", it’s simply not logical. If you miss a letter, change a number, or simply enter an address incompletely, funds are sent into the abyss - forever. To correct this inherent problem, Nebulas will implement the use of "meaningful names." For instance, using a meaningful name, your Nebulas address could be "Rick_Sanchez.me." Users will have the opportunity to bid for requested names, and renew yearly - just like a web based domain name.

Lightning Network[xv]

As many of you probably already know, bitcoin can now use a Lightning Network. This will allow multiple small transactions to be signed without clogging up the blockchain and memory pool. It keeps an open ledger between two entities and can be closed at any time by either party, resulting in one transaction on the network instead of potentially dozens or hundreds.If the Bitcoin network started with the Lightning Network, it would currently be able to handle all transactions per second without any problems. Without the Lightening Network, Bitcoin can only handle 7~ transactions per second (and usually less). With the Lightening Network initially in place, the Nebulas network will be able to handle the required transactions and close the lightning ledgers when requested by users. It would also not cost $20.00++ to send $5.00 nor would it take an hour. I won’t get into the ludicrous prices of Bitcoin transactions fees and how we got here, but if you don’t know much about it, you should learn more. As an important feature of Nebulas, the Lightning Network will provide quick and cheap transactions.

High Strength Encryption

Nebulas uses SHA3-256 encryption. Although you won’t find this in the white paper, SHA3-256 is Highly Quantum Resistant[xvi] - research it yourself. Why is this so important? Well, as an inevitable evolution of quantum computing, previous generations of encryption will be rendered inadequate, and, consequently, susceptible to decryption of private keys. Basically, this means that once quantum computers are developed, you can lose your money in a non-quantum resistant blockchain. Since Quantum Resistance is a very important feature, many new coins (such as the QRL coin[xvii]) are being intentionally created for this purpose.

So, what role does the NAS token play in the network?

Directly from the white paper[xviii]; "The Nebulas network has its own built-in token, NAS. NAS plays two roles in the network. First, as the original money in the network, NAS provides asset liquidity among users, and functions as the incentive token for PoD bookkeepers and DIP. Second, NAS will be charged as the calculation fee for running smart contracts. The minimum unit of NAS is 10−18 NAS." If interested, the white paper goes into detail. If you question the purpose of NAS, simply ask yourself, "What role does ETHER play in the Ethereum network?" As of this writing, ETHER’s current price is $1098.00USD – and that’s not even it’s high. I believe that common sense indicates the potential value of the NAS coin!

Nebulas will have a maximum of 100,000,000 tokens

Many of the top 10 cryptocurrencies will distribute coins/tokens in the tens of billions, and, in fact, Ethereum will have an indefinite amount (albeit, they will taper off in time). However, when there are significantly less coins/tokens, the value of each increases. Treasure each NAS token!

A web-based playground for developer tools[xix]

To help developers create smart contracts easier and faster, Nebulas will offer developer tools. Nebulas will also support multiple IDE’s.
Although the list of features and functions goes on, this should give you an overview of what the Nebulas network can do, how it can evolve blockchain technology, and why it will be a very attractive option for future dApps. Having said all this, please be clear, it is not financial advice.
Also, keep in mind that the above statements are based on my analysis of the white paper (version: 1.0 September, 2017), but this is not to say that the developers don’t have a different perspective. With that being said, Nebulas staff and co-founder, Robin Zhong, actively responds to questions in their Slack channel. This leads us to a review of the Nebulas team.

The Nebulas Team

When looking at a new, and yet to be released, project, it’s not only important to understand the innovation, it’s also important to understand the team behind the innovation. Although not the largest team, the developers are highly educated with real blockchain experience. In fact, many have worked at Google, IBM, Alibaba, Alibaba financial, Airbnb, etc… Additionally, two Nebulas founders previously co-founded the NEO coin (formerly Antshares) which on January 20, 2018 trades at $140.00 (not even its high) per coin/token.
No doubt, the team is influential in past, current and future blockchain innovation. In fact, playing a huge part in bringing blockchain to China, Hitters Xu created Bitsclub, and many other team members started blockchain communities. If you have not yet learned about the team, I strongly suggest you do. Check out their LinkedIn pages and also look at the developers Githubs.

Full disclosure:

As a fellow investor and fan of blockchain technology, I got into the crypto world in 2012. Since then, I have mined, traded, and even created an arbitrary trading system. My portfolio includes dozens of different types of tokens/coins. My focus is on innovation rather than "rinse and repeat."
I first learned about Nebulas in the beginning of January 2018. After reading the technical white paper multiple times and fully understanding Nebulas (what it is and what it’s not), I confidentially purchased NAS (ERC-20) tokens.
As with any great blockchain, Nebulas will not be the last, but it is a crucial step to the next generation of blockchain innovation! Without doubt, I see the true potential of blockchain technology, and, if you ask me, Nebulas is an amazing short, medium and long term project, and I’m excited about the future!
To quote a Nebulas founder, "Ask not what blockchain can do for you, ask what you can do for blockchain..." - Hitters Xu

Quick Update (January 31, 2018)

For full transparency, I wanted to add that I have been asked by the Nebulas Team Reddit manager if I would be willing to be a moderator of the Nebulas subreddit. I told them that I would happy to continue helping the community and accepted. There is no extra benefit to me and does not change my opinion about Nebulas. I look forward to continuing helping the community!

References

i: Pg 41 – 6.2
ii: Pg 24 – Last bullet point
iii: Pg 34 - 5.3.1
iv: Pg 35 – 3.3.3
v: Pg 34 – 5.3.1
vi: Visit https://gifto.io/ for more info – Watch the video for an example of what Nebulas will do.
vii: Pg30 – 4.2
viii: Pg 27 – 3.3.2
ix: Pg 26 – Paragraph2
x: Many locations – There are many parts of the white paper that talk about anti-cheating in different capacities.
xi: Pg 26 – 3.3.1
xii: Many locations – There are many parts of the white paper that talk about voting in different capacities.
xiii: Visit https://decred.org/ for more information. For full disclosure, I do own DCR and stake them.
xiv: Pg 45 – 7.1
xv: Pg 45 – 7.2
xvi: Visit https://www.theregister.co.uk/2016/10/18/sha3256_good_for_beelions_of_years_say_boffins/ for more information.
xvii: Visit https://www.theqrl.org for more information. And yes, for full disclosure, I like this project as well, and have invested post ICO.
xviii: Pg 47 - 8
xix: Pg 46 – 7.3
submitted by satoshibytes to nebulas [link] [comments]

FAQ: What exactly is the fraud in Ethereum?

Most important above all else, Ethereum has never been decentralized since its distribution (i.e. premine) & thus value of incentives depend entirely on 1 trusted party, the exact opposite of decentralization or trust minimization [1,2,3,4,5,6]. Calling themselves decentralized is literally deception of others for profit, which is by the most standard definitions called fraud.
Below is an example of how this centralization manifests and the absolute lack of ethics & types of other fraud behind Ethereum:
Historic account of bailout, fraud, and centralization: how Ethereum Foundation demonstrated to have full control over the ethereum blockchain beyond reasonable doubt while advertising falsely for profit
Point by point summary (sources cited below):
  1. Ethereum Foundation (EF) sell centrally pre-mined/pre-made Eth coins in ICO for centralized funding/profit while advertising "unstoppable .. exactly as programmed" code (regular cryptocurrencies are 0% premined, EF had 72m coins premined on day 0 which is ~70% of current supply)
  2. Slock.it developers including eth co-founder create an app called DAO on it for the purposes of funding themselves even more with claims that their "code sets the terms and conditions" like no one has done before them for even more money.
  3. DAO code has a mistake and starts giving away money to a user, vocal fraction of community is divided whether to bailout DAO investors, many unofficial polls show conflicting results with extremely low participation making it unclear whether the super majority is even aware or cares about this 3rd party issue.
  4. EF members refuse to disclose if they are invested in the DAO after promoting it, and many are later found to have been invested in it.
  5. EF tells exchanges there will not be a minority chain surviving, ignoring the divided community, and making it impossible to sell no-bailout version
  6. EF makes the carbonvote the "official" vote 12 hours before the release of the client--after repeatedly claiming for weeks it had no official capacity, and after already having made support for the fork the default option in the codebase. The vote only shows 4% of possible consensus supporting bailout, 1/4 of it from one vote.
  7. Most automated nodes and miners that run "apt-get upgrade && apt-get update" switch over even if haven't seen the announcement 12 hours prior and fork is declared a success.
  8. No-bailout chain survives regardless despite Foundation's efforts, but Ethereum Foundation refuses to update it even if it increases in popularity or size.
  9. Ethereum projects are forced to choose between developed chain with ICO funding, bailout, roadmap and one with no funding, no clear devs, no roadmap. Most are forced to stay with Ethereum Foundation holding central ICO funding & updates hostage.
  10. EF sells the unsold premined coins they still own on the no-bailout chain (forked premine), thus damaging its value
  11. EF members participate in White Hat Group (WHG), use same method used to drain DAO to drain no-bailout chain DAO and then market sell no bail-out ether on the exchanges damaging no-bailout chain value further
  12. EF changed the properties of the security it sold and still falsely advertises "unstoppable .. exactly as written" code (despite proving it false) while profiting from all of it.
Almost all the above actions are fraud.
Details and sources:
Top left of the banner shows marked up graphic [1] of ethereum.org claims including
"decentralized platform that runs smart contracts exactly as programmed without any possibility of downtime, censorship, fraud".
Additionally, the third party app "the DAO" also re-iterated in their contract the similar premise that their code IS the terms and conditions [1,2]. Both DAO and Eth were sold advertised as such in their initial phases.
However, the DAO was programmed in a poorly done manner [1] and allowed loss of the investments put into it [2]. It was no secret members of the Ethereum Foundation (EF) were connected to the DAO often promoting it. Many were found to be invested in the DAO as time passed [1,2,3] , yet refused to disclose it when asked directly [4,5,6]. Despite the loss due to DAO contract being an issue of only minority of users, virtually all mentioned advertised properties of ethereum and the DAO were changed by the Ethereum Foundation to manually reverse the operations the smart contract ran while profiting from it.
How did they do it? By exploiting and proving centralization
Several centralized aspects of Ethereum were used to achieve this result:
  1. EF controls the defaults settings in codebase to get what they want. Only 12 hours before before the release of the client they selected carbonvote the "official" vote out of many varying options (after repeatedly claiming for weeks it had no official capacity, and after already having made support for the fork the default option in the codebase). This selected poll had many issues discussed below including 96% of possible votes not showing support for EF/DAO bailout. However the 4% vote with quarter from single vote with only hours of official notice before were used as justification anyway for bailout as default setting [1,2,3,4,5,6,7]. By controlling the defaults, they easily took advantage of anyone not up to date on announcement hours earlier who automatically updated and/or the apathetic users to control the blockchain. By moving focus from what's best for majority via opt-in consensus (blockchain standard) to giving only a short window to opt-out, they can centrally manipulate the blockchain in almost any manner without enraging the majority into action [1,2]. As expected, the fork was quickly declared a success [1,2,3]. Control over codebase also allowed them to compromise those opting out by leaving them open to replay attacks, thus further damaging their value as can be seen celebrated by DAO and Eth cofounder Stephan Tual [1]. Effectively, this was equivalent to a successful 4% attack on a blockhain or even attack by a single centralized entity (EF). The approach is easily repeatable and exact opposite of expected censorship resistance against <50% attacks, thus proving it unsecure.
  2. EF has complete centralized ownership of the funds from 70% premine in form of eth and ICO BTC raised [1]. This made them the only well funded core developers and thus the only choice for rapid development and fully in control of what gets updated. By choosing to address this third party contract issue, by refusing to update the old chain, they effectively held their funding and updates hostage to make sure people can't opt out without significant costs [1,2]. Additionally, with such capital, it's trivial to affect the swing vote for under-represented polls with eth or hashpower making their polling governance methods unsecure. Furthermore, once the old chain did receive an exchange and thus possible value, the old chain coins from EF premine were used to damage the value of the old chain further [1].
  3. EF has name recognition as the founders, name ownership of "the real Eth" or ETH, with even a trademark [1]. Unlike volunteer based or anonymous core teams, EF is Swiss nonprofit operating as a single entity. When a high publicity issue appeared that threatened their money, they were able to stop trade on major exchanges with a simple message [1,2].
  4. Exchanges were deceived by the EF into belief there will be no one in dissent of the self-bailout fork (leaving the other fork without a market and 0 worth) and not prepared for people opting out of bailout [1,2,3], which was misleading due to highly uncertain polls (below). This deception allowed them to be the only chain with value following the fork, and allowed them to keep the name. Despite it all, dissent was also to exist by original chain surviving and prospering even under countless harmful actions of the EF (usually 1/3rd of Eth in number of transactions, 45-50% of marketcap at peak [3], and even longer chain on at least one occasion).
EF demonstrated ability and willingness to cease trade, fork, and affect entire network when a single app of their choosing fails while profiting from it [1]. The non-democratic nature of the decision was noted by many [1,2].
Changes in properties of the ether security - securities fraud
The "unstoppable" app was sending money to an unknown user. What followed was the controversial change of the advertised rules where EF stopped the app by censoring that transaction without consent and confiscated the transaction contents resulting in personal profit for EF devs and friends. The rule change that let EF and friends profit financially while harming someone else financially is very plausibly securities fraud [1,2,3,4]. Additionally, it was a clear conflict of interest in governance.
The change of the rules of the security associated platform to censor or run applications based on feelings of how it should run (e.g. liked/ok or disliked/exploit) by the Ethereum Foundation (a centralized entity) broke the EF and DAO earlier statements on decentralization, lack of censorship, and explicit execution of code. While the user followed all the known rules from statements of the platform and the app, the fork rule changes were applied not to fix a bug but to undo previous actions using new rules ex post facto. The changes were retroactive and arbitrary: stopping the app and censoring the user by reverting his money transfer back to where they could take it out, subjectively justified by calling it a theft. Blockchains gain value by decentralizing trust to numerous different parties thus creating censorship resistance against minority attacks and thus security. Ethereum Foundation supported ether asset changed from decentralized, trustless, secure, censorship-resistant platform asset to (proven based on EF actions) centralized, trust-requiring, unsecure, censorable platform asset hence damaging said value. However, to this day the advertisement of the properties of the ether security has not changed, long after EF actions proved virtually every statement in them false. No safeguards were put into place to prevent a repeat as well. This makes it a case of continuous securities fraud as well.
What choice did community have? Bad and worse.
No evidence of community support for bailout
The justifications of the self-bail out forks are often in the tone of it being a democratic decision or that there was agreement from the community. The survival of the original chain both in value and transactions despite being damaged in value by the EF and even when it had no market value is a demonstration it was not an insignificant disagreement. Additionally, often several voluntary polls are referred to with ~5% eth and 12% hash turnout and single digit 4% and 9% vote of all possible votes for self-bail out fork [1,2,3] - far from majority. Historic archives of the subreddit and simple online polls during the time show much stronger opposition to bailout [1,2,3,4,5].
Issues with official poll
  1. The low turnouts of a voluntary insignificant poll done on a little known subreddit instead of protocol level makes it statistically insignificant. EF made carbon vote the "official" vote 12 hours before the release of the client after claiming it had no official capacity and after making support for the EF-bailout fork default option in the code base [1,2,3,4,5,6]. Additionally, due to low turn out and polls could be easily manipulated for financial gain by buying eth or renting hash power momentarily just for the vote by third parties (thus breaking another earlier statement). About 1/4th of the 5% eth vote was from a single voter [1].
  2. Voluntary polls are extremely susceptible to biases. Voluntary response bias strongly favors those with stronger incentives to respond and thus results in sampling bias: the profit coming from self-bailout of a minor third party app investors is far stronger incentive than voting for standard operation of a blockchain. Uncast votes from apathy or not being up to date was prevalent accounting for 90%+ mentioned above. By setting the bailout as the default setting (unlike opt-in setting used typically elsewhere) with only 12 hour warning, anyone not paying attention was tricked into supporting the bailout. Nodes can simply automate "apt-get upgrade && apt-get update" so this setting took advantage of everyone who hasn't seen official announcement only hours earlier [1].
  3. Censorship resistance is often taken for granted in crypto projects as it is expected as the minimum requirement of something being called a blockchain. This expectation results in a bias from bystander effect [1] and diffusion of responsibility to ensure it: many assume vote for censorship resistance is a sure thing but will definitely happen by others voting. What can happen is a group expects someone else to vote and ends up in almost no one voting.
  4. By the EF labeling the unintended execution of a contract "an exploit" and the person doing it "the attacker" alleging "theft" (which was not a universal interpretation) and stating support for the bailout, they introduced leading question bias that increases tendency to vote in a way that favored bailout. Additionally, individuals and companies had to face a social desirability bias where they were more likely to vote in a way that would feel more socially acceptable.
In summary on 2 polls selected and referenced by the EF is that there is no conclusive evidence of majority support for the bailout fork. Similar conclusions were reached by others. [1]
Financial & value attacks
Ethereum Foundation refused to work on the older chain thus damaging the older security they sold [1,2]. Ethereum Foundation took the premine from the development of the original chain, which is possible theft. Ethereum Foundation took the money of a rule following user, which is possible theft [1]. Ethereum Foundation compromised security of the old chain by keeping it open to replay attacks hurting its value further[1]. Ethereum Foundation damaged the value of the competing asset of the original chain using the stolen premine by selling it on exchanges [1] and making fun of doing so [2]. Ethereum Foundation and closely related White Hat Group (WHG) not only took the remaining money from the DAO on their chain, but also on the original chain, and then used the funds to damage the price of the competing asset on the exchanges [1,2,3,4].
Every level of Ethereum proven to be unsecure and not trustworthy
Additionally, every level of ethereum after proven centralized requires trust. And it's easily shown how each level cannot be trusted thus lowering its value:
  1. Code: Ethereum Foundation (EF) via demonstration of centralized control stated and shown that they will decide how code should run instead of as written, so the code itself doesn't matter, and it can't be trusted to handle transactions, balances, apps.
  2. Apps: Ethereum foundation broke the promises of a third party app called DAO that very uniquely stated code sets the terms, so eth apps cannot be trusted.
  3. EF: Ethereum foundation also broke its own advertised statements about the platform when it censored users and stopped apps to take others money for subjective reasons. Additionally, their refusal to acknowledge conflict of interest, making a poll official only hours before pushing the update, and abusing power of defaults in the code shows so Ethereum Foundation cannot be trusted [1,2,3,4,5,6]. Additionally, centralization shown by EF makes it a weak spot for malicious actors to attack the entire platform using incentives (e.g. litigation, force, threat, pressure 1) to force them to exercise the control over the chain once again with existing precedent. There's no way to gain trust that this attack vector won't be used.
*
The self-bailout fork events demonstrated centralized Ethereum Foundation has complete centralized control over every level of this blockchain: every transaction and every app. It proved that EF has capability and the will to use it to overwrite operation of any smart contract even if it serves their self interest. In other words, Eth is a proven unsecure centralized censorable trust-requiring platform that can't be trusted on any level with any aspect of operation. There are zero safeguards currently in place to prevent EF from taking advantage of their control from occurring again. Additionally this is public information making it a well known centralized weakness and, thus, a known attack vector that could be used by interested third parties, which would be nothing new [1].
Nothing has been done to fix it and continues to be part of Ethereum's flawed premine controlled "economic forks"[1].
This subreddit is a curated collection of resources for education purposes only that would be difficult to find downvoted on biased ethereum subreddits to protect and warn people from being hurt by this fraud via investment or development on top of a nonsecure blockchain.
Other notable events about Ethereum to read about:
SUMMARY: Ethereum is an unsecure, trust-requiring, centralized, mutable platform that runs stoppable apps and censors people Ethereum Foundation (EF) dislikes - the opposite of what it advertises itself as. Ethereum Foundation misrepresents what Ethereum is to prospective investors for increasing the value of the traded asset ETH while profiting financially. This means, by definition, Ethereum Foundation is participating in fraud by continuously misleading investors. Furthermore, the act of suddenly changing the properties of the unregistered security after the sale of the security in the initial coin offering (ICO) and/or on exchanges while profiting personally constitutes securities fraud. Additionally, Ethereum Foundation is connected to damaging the value of sold assets, damaging the value of competing assets, theft from competition, and market manipulation of competing assets for profit.
Nothing has changed after historic actions proved centralization beyond reasonable doubt. Eth is still centralized, unsecure, and gains value only through fraud
submitted by newweeknewacct to ethereumfraud [link] [comments]

Nebulas (NAS) Technical White Paper Review

Nebulas Technical White Paper Review - January 20, 2018 by u/satoshibytes

Whitepaper version: 1.0 September, 2017.

Built on ground-breaking innovation, Nebulas brings blockchain technology into the 3rd generation.
Nebulas offers two different white papers; while the first is a basic overview, the second is technical.
The technical white paper describes the specifics of the project, and with each part broken down into details, it is not only quite long, it is also considered one of the most technical white paper of any blockchain technology to date. Although detailed information provides transparency and answers questions, many people are finding it difficult to comprehend.
No doubt, most investors are looking for the next hot coin that will provide a good pay day! While I believe that Nebulas can provide just that, I also feel that it is always important to understand what you are investing in. If you take the time to read everything carefully, Nebulas’ technical white paper shows the entire system in its final glory!
Therefore, the comments below compile my analysis of the technical white paper (in combination with other reliable sources). I will also do my best to include the page where you can find these facts in the technical white paper. Therefore, I suggest that rather than taking my word for it, read it for yourself.
Based on pros and cons, let’s break down the primary elements of Nebulas:

Nebulas Rank (NR)

Nebulas Rank (NR) will be the first to integrate search engine capability into blockchain. In other words, Nebulas Rank is the protocol responsible for making search engine a viable element in the blockchain. Right off the bat, let’s address an important question, "What good is a ranking system inside a blockchain?"
Currently, there is no way to search the blockchain for meaningful data (other than simple transactions), and, therefore, it’s impossible to find dApps or locate smart contracts. If this doesn’t sound like a big deal, imagine trying to search the internet without google or some other search engine – it would be impossible!
Just as the first internet search engine evolved the internet into what it is today, the first blockchain search engine will inevitably evolve blockchain. Not only a stepping stone for the future of blockchain, we’re talking about a new foundation for blockchain technology.
By providing a blockchain search engine, the Nebulas Ranking system will allow users to locate quality dApps (decentralized apps) and smart contracts. For example, let’s say that you are looking for a dApp like CryptoKitties. No doubt, there could be dozens of similar apps. So, based on multiple data resources, such as blockchain activity, github activity, and even google search history, the ranking algorithm (NR) orders similar apps, and then lists them in a manner that the user can evaluate and select.

Now, can you see why Nebulas is being compared to google?

But, this is only the beginning…. Nebulas Rank is also interwoven into the Developer Incentive Protocol (DIP) and the Proof of Devotion (PoD) Consensus Algorithm. Without Nebulas Rank, these other two elements could not operate as the white paper states.
Based on the current white paper, let’s spotlight some potential negatives about the Nebulas Rank(NR) protocol. However, also keep in mind that these potential issues could be completely eliminated as the project develops (thanks to Nebulas Force – more on this later).

Now the potential negative:

However, while the white paper describes the search engine being centralized, it also says "In current stage..." Thereby indicating that Nebulas developers have a better solution in the long run. Perhaps a sidechain just for searching? The white paper also states that "the complete code for searching backend is available to the community and third-party developers can create their own searching services on this basis." Hopefully, this will keep the ranking honest.
Since the Nebulas blockchain is based on the Nebulas Rank (NR) system, now that we have highlighted the most important aspects of Nebulas Rank (NR), we can dive deeper into specific functions.

Proof of Devotion (PoD) Consensus Algorithm

In the cryptocurrency world, Proof of work (PoW) means mining. While damaging to the environment, few can argue that this is a terrible waste of natural resources. As an alternative, the cryptocurrency world also has Proof of Stake (PoS). Proof of Stake allows token/coin holders to stake (aka hold un-spendable tokens), and to be rewarded with more tokens when they create a new block. For example, if there are 100 people staking and there are 100 new blocks per hour, every stake will, on average, receive one block reward per hour.
While better for the environment, Proof of Stake creates an imbalance where major coin holders (aka whales) are rewarded with even more coins, and this allows "whales" to stake even more coins (this means that there could be a potential to monopolize the system).
Now, Nebulas brings us Proof of Devotion (PoD)[iii]. As far as I know, there is currently nothing like this in blockchain technology (nor ready to be released). Proof of Devotion essentially awards developers who make awesome things (such as dApps) on the Nebulas blockchain.
If you develop an dApp that’s performing well on the Nebulas network, you will have the option to be a validator (aka validate submitted transactions), and, in return, receive token rewards from the blockchain. To be a validator, you will need to stake (deposit) X amount of tokens. Then, multiple validators (per transaction) will have to agree on the result[iv], and, each will be rewarded 1.5x the amount staked.
The generation of new blocks[v] will be carried out by "highly important" accounts that Nebulas Rank (NR) calculates. As stated in the whitepaper, "PoD empowers the selected accounts to have the bookkeeping right with equal probability to participate in new block generation in order to prevent tilted probability that may bring about monopoly".
The bottom line... when it comes to Proof of Devotion, why use Ethereum to create a dApp when you can create the same dApp on Nebulas and make a profit? Needless to say, this is a huge incentive for developers to make dApps on the Nebulas network, and, consequently, it will increase the value of the network. Furthermore, since Nebulas will provide developer tools, it will be easier to create dApps.

Now the potential negative:

Because it inspires developers to create awesome dApps, and, at the same time, profit directly from blockchain, I personally love this idea! No longer will dApp creators require insane ICO’s nor will they need some other stream of revenue. However, participating in PoD does not stop developers from benefiting from other income streams. Truly groundbreaking!

Developer Incentive Protocol (DIP)

Not only can Proof of Devotion give incentive to developers, quality developers will also receive extra coins/tokens for their hard work. Based on Nebulas Rank(NR), Nebulas will use an algorithm for reward distribution[vii]. The rewards will be automatically distributed to the smart contract cash-out address every 7 days.
There is really nothing negative to add to this. It’s truly a powerful incentive!

Nebulas Force (NF)

Who needs hard forks? Nebulas Force will allow developers to introduce new features/protocols into the Nebulas blockchain without a fork. The Nebulas white paper calls it "Self-evolving blockchain technology" but I don’t believe this is quite correct. Rather than being self-evolving, it is actually community driven! Because this will build the blockchain community, in my opinion, this is even better!
With other blockchains for example, if a developer has an awesome idea for a dApp but it needs a new protocol that does not exist on any blockchain, the developer would have to centralize the dApp or chuck it altogether.
With Nebulas, new ideas can be developed, and if they provide positive contribution, the Nebulas community (Nebulas token holders) can vote on and approve changes to the network protocol. Once approved, Nebulas developers can add the new protocol into the Nebulas blockchain. Perhaps, further in the development, sub-chains will also support new protocols for full implementation.

Upgradable Smart Contracts

Revolutionary for blockchain, Nebulas Force will include upgradable smart contracts[viii]. Why is this important? Well, due to bugs in smart contracts, investors can lose funds in any blockchain network that uses smart contracts. Once submitted to the blockchain, nothing can be done to fix the bugs, and, as a result, tens of millions of dollars have already been lost.
Nebulas plans to overcome this problem through the implementation of upgradable smart contracts. In a nutshell, token holders will vote on proposed changes (to fix specific bugs), and when the overall vote is affirmative, bugs can be eliminated at any time. By saving investors millions, it will restore lost confidence!

Now the potential negative:

  • The Nebulas protocol is only modifiable by the Nebulas core developers. Although this is not really a negative, I would not call it "self-evolving". If you look at Bitcoin, there is a handful of developers responsible for source code, and, subsequently, the source code for all alt coins that use Bitcoin core in some capacity (such as LTC, BCC, BTG, DOGE, etc…)
  • The protocol updates will be applied via a hard coded signature into the genesis block[ix] and this means that there is a potential for network compromise.
  • Although there are some ethical issues with modifying smart contracts, overall, it is a great idea! Since token holders will have to vote on any changes, there could be an issue with whales (monopoly owners) controlling contracts.
Even with the negatives, this is a powerful feature.

The above includes Nebulas’ most innovative features, and although these features stand out, there is even more to Nebulas:

Anti-cheating algorithms[x]

To ensure fairness, the above protocols contain anti-cheating algorithms that are manipulation resistant, and, if someone is found trying to cheat, there are penalties.

Smart contracts almost anyone can write![xi]

Nebulas will support smart contracts written in Javascript, Python, Java and more! And this means that any coder can create a logical contract!

Full voting protocol[xii]

Since Nebulas includes a full voting protocol in the blockchain, you and I, as token holders, can help decide the direction of Nebulas. As an example, the coin "Decred[xiii]" also has a voting system; giving end-users a voice keeps them engaged.

Domain Name Service[xiv]

Although blockchain users are accustomed to "please send funds to: 0x488B2630CEdB5Bfd5e02c33A3653227170743357", it’s simply not logical. If you miss a letter, change a number, or simply enter an address incompletely, funds are sent into the abyss - forever. To correct this inherent problem, Nebulas will implement the use of "meaningful names." For instance, using a meaningful name, your Nebulas address could be "Rick_Sanchez.me." Users will have the opportunity to bid for requested names, and renew yearly - just like a web based domain name.

Lightning Network[xv]

As many of you probably already know, bitcoin can now use a Lightning Network. This will allow multiple small transactions to be signed without clogging up the blockchain and memory pool. It keeps an open ledger between two entities and can be closed at any time by either party, resulting in one transaction on the network instead of potentially dozens or hundreds.If the Bitcoin network started with the Lightning Network, it would currently be able to handle all transactions per second without any problems. Without the Lightening Network, Bitcoin can only handle 7~ transactions per second (and usually less). With the Lightening Network initially in place, the Nebulas network will be able to handle the required transactions and close the lightning ledgers when requested by users. It would also not cost $20.00++ to send $5.00 nor would it take an hour. I won’t get into the ludicrous prices of Bitcoin transactions fees and how we got here, but if you don’t know much about it, you should learn more. As an important feature of Nebulas, the Lightning Network will provide quick and cheap transactions.

High Strength Encryption

Nebulas uses SHA3-256 encryption. Although you won’t find this in the white paper, SHA3-256 is Highly Quantum Resistant[xvi] - research it yourself. Why is this so important? Well, as an inevitable evolution of quantum computing, previous generations of encryption will be rendered inadequate, and, consequently, susceptible to decryption of private keys. Basically, this means that once quantum computers are developed, you can lose your money in a non-quantum resistant blockchain. Since Quantum Resistance is a very important feature, many new coins (such as the QRL coin[xvii]) are being intentionally created for this purpose.

So, what role does the NAS token play in the network?

Directly from the white paper[xviii]; "The Nebulas network has its own built-in token, NAS. NAS plays two roles in the network. First, as the original money in the network, NAS provides asset liquidity among users, and functions as the incentive token for PoD bookkeepers and DIP. Second, NAS will be charged as the calculation fee for running smart contracts. The minimum unit of NAS is 10−18 NAS." If interested, the white paper goes into detail. If you question the purpose of NAS, simply ask yourself, "What role does ETHER play in the Ethereum network?" As of this writing, ETHER’s current price is $1098.00USD – and that’s not even it’s high. I believe that common sense indicates the potential value of the NAS coin!

Nebulas will have a maximum of 100,000,000 tokens

Many of the top 10 cryptocurrencies will distribute coins/tokens in the tens of billions, and, in fact, Ethereum will have an indefinite amount (albeit, they will taper off in time). However, when there are significantly less coins/tokens, the value of each increases. Treasure each NAS token!

A web-based playground for developer tools[xix]

To help developers create smart contracts easier and faster, Nebulas will offer developer tools. Nebulas will also support multiple IDE’s.
Although the list of features and functions goes on, this should give you an overview of what the Nebulas network can do, how it can evolve blockchain technology, and why it will be a very attractive option for future dApps. Having said all this, please be clear, it is not financial advice.
Also, keep in mind that the above statements are based on my analysis of the white paper (version: 1.0 September, 2017), but this is not to say that the developers don’t have a different perspective. With that being said, Nebulas staff and co-founder, Robin Zhong, actively responds to questions in their Slack channel. This leads us to a review of the Nebulas team.

The Nebulas Team

When looking at a new, and yet to be released, project, it’s not only important to understand the innovation, it’s also important to understand the team behind the innovation. Although not the largest team, the developers are highly educated with real blockchain experience. In fact, many have worked at Google, IBM, Alibaba, Alibaba financial, Airbnb, etc… Additionally, two Nebulas founders previously co-founded the NEO coin (formerly Antshares) which on January 20, 2018 trades at $140.00 (not even its high) per coin/token.
No doubt, the team is influential in past, current and future blockchain innovation. In fact, playing a huge part in bringing blockchain to China, Hitters Xu created Bitsclub, and many other team members started blockchain communities. If you have not yet learned about the team, I strongly suggest you do. Check out their LinkedIn pages and also look at the developers Githubs.

Full disclosure:

As a fellow investor and fan of blockchain technology, I got into the crypto world in 2012. Since then, I have mined, traded, and even created an arbitrary trading system. My portfolio includes dozens of different types of tokens/coins. My focus is on innovation rather than "rinse and repeat."
I first learned about Nebulas in the beginning of January 2018. After reading the technical white paper multiple times and fully understanding Nebulas (what it is and what it’s not), I confidentially purchased NAS (ERC-20) tokens.
As with any great blockchain, Nebulas will not be the last, but it is a crucial step to the next generation of blockchain innovation! Without doubt, I see the true potential of blockchain technology, and, if you ask me, Nebulas is an amazing short, medium and long term project, and I’m excited about the future!
To quote a Nebulas founder, "Ask not what blockchain can do for you, ask what you can do for blockchain..." - Hitters Xu

References

i: Pg 41 – 6.2
ii: Pg 24 – Last bullet point
iii: Pg 34 - 5.3.1
iv: Pg 35 – 3.3.3
v: Pg 34 – 5.3.1
vi: Visit https://gifto.io/ for more info – Watch the video for an example of what Nebulas will do.
vii: Pg30 – 4.2
viii: Pg 27 – 3.3.2
ix: Pg 26 – Paragraph2
x: Many locations – There are many parts of the white paper that talk about anti-cheating in different capacities.
xi: Pg 26 – 3.3.1
xii: Many locations – There are many parts of the white paper that talk about voting in different capacities.
xiii: Visit https://decred.org/ for more information. For full disclosure, I do own DCR and stake them.
xiv: Pg 45 – 7.1
xv: Pg 45 – 7.2
xvi: Visit https://www.theregister.co.uk/2016/10/18/sha3256_good_for_beelions_of_years_say_boffins/ for more information.
xvii: Visit https://www.theqrl.org for more information. And yes, for full disclosure, I like this project as well, and have invested post ICO.
xviii: Pg 47 - 8
xix: Pg 46 – 7.3
submitted by zigzagzig to CryptoCurrency [link] [comments]

Coinbase just revealed their new listing checklist, let's check how Nimiq does

https://listing.coinbase.com/policy#coinbase-mission-values
Open Financial System
Open financial system is defined as being available to everyone and not controlled by a single entity.
✔︎ Pretty easy
Innovation or Efficiency Gains
New or improved technology which helps solve a problem, creates a new market, addresses an unmet market need, or creates value for network participants.
✔︎ Again, pretty easy, Nimiq is bringing a huge leap forward in terms of accessibility and integration of cryptocurrencies.
Economic Freedom
A measure of how easy it is for members of a society to participate in the economy. The technology enables individuals to have more control over their own wealth and property, or the freedom to consume, produce, invest, or work as they choose.
✔︎ Basic requirement of any real cryptocurrency, easily fulfilled by Nimiq.
Equality of Opportunity
This technology is accessible to use by anyone with a smartphone or access to the internet. It contributes to the broader mission of building the on-ramps to Finance 2.0.
✔︎ Nimiq is the most accessible crypto on the market right now, you don't even have to install something to begin using it or mining it.
Decentralization
The network is public, decentralized, and enables trustless consensus.
〜 The architecture of Nimiq is decentralized however the hashrate is clearly not right now.
Security & Code
Assessment of engineering and product quality.
✔︎ Nimiq team has done everything it could to ensure the quality control of the code.
Source Code
Open-source code, well-documented peer-review, and testing by contributors separate from the initial development team on GitHub, etc.
〜 Of course Nimiq is open-source but the documentation is still weak, the good thing is that it's being redone.
Prototype
There is a working alpha or beta product on a testnet or mainnet.
✔︎ Well, the Nimiq Network is live.
Security & Code
Demonstrable record of responding to and improving the code after a disclosure of vulnerability, and a robust bug bounty program or third party security audit.
✔︎ Nimiq team has set a bug bounty program and has been very transparent on the issue of the 25th.
Team
Assessment of short-term operating expectations and decision making.
✔︎ You can even see them on video hehe.
Founders and Leadership
Able to articulate vision, strategy, use cases or drive developmental progress. Has a track record of demonstrable success or experience. If information is available, Coinbase will apply "know your client" standards to publicly visible founders or leaders.
✔︎ The profiles of the team are all known and easily checked.
Engineering
Assessment of the engineering team and their track record of setting and achieving deadlines.
✔︎ They released the product which is a damn good track record in a sector full of vaporwares.
Business & Operations
History of interacting with the community, setting a reasonable budget and managing funds, and achieving project milestones. Thoughtful cash management is a key driver of the project's long term viability.
✔︎ There has been some "lean" periods in terms of communication but overall the team has never stopped interacting with us. When it comes to cash management the dev team should be a model for everyone else with its last transparency report.
Specialized Knowledge and Key People
The project leadership is not highly centralized or dependent on a small number of key persons. Specialized knowledge in this field is not limited to a small group of people.
〜 Let's be honest: it is right now, that said the project protocol isn't even 6 months old.
Governance
Assessment of long-term operating expectations and decision making.
✔︎ Nimiq has a foundation.
Consensus Process
There is a structured process to propose and implement major updates to the code, or there is a system or voting process for conflict resolution.
✔︎ Well it's like Bitcoin, node operators decide whether they want or not to follow an update.
Future Development Funding
There is a plan or built-in mechanism for raising, rewarding, or allocating funds to future development, beyond the funds raised from the ICO or traditional investors.
✔︎ Yes, see the intended use of fund.
White Paper
Justifies the use case for a decentralized network and outlines project goals from a business and technology perspective. While a white paper is important for understanding the project, it is not a requirement.
〜 There is the "high level" whitepaper of the ICO however it doesn't really explain in detail how Nimiq works.
Scalability
Assessment of a network's potential barriers to scaling and ability to grow and handle user adoption.
✔︎ Like pretty much every project, that's what Robin is currently working on by the way.
Roadmap
Clear timeline with stages of development, reasonable project milestones, or built-in development incentives.
✔︎ We should have the roadmap soon™️.
Network Operating Costs
The barriers to scaling the network have been identified, or solutions have been proposed or discussed. The resource consumption costs for validators and miners are not the main deterrents to participation.
✔︎ Yes, the team has been considering second layer solutions like Lightning Network or Liquidity Network.
Practical Applications
There are examples of real-world implementation or future practical applications.
✔︎ The new Nimiq shop is a great example of it.
Type of Blockchain
The asset is a separate blockchain with a new architecture system and network, or it leverages an existing blockchain for synergies and network effects
✔︎ Both in fact, Nimiq is a whole new blockchain built from scratch in Javascript and Rust + it's using HTLC/atomic swap to interact with Ethereum.
Regulation
Can Coinbase legally offer this asset?
✔︎ I'm not a lawyer but I guess it can
US Securities Law
The asset is not classified as a security using Coinbase's Securities Law Framework.
〜 Hard to say, they have this checklist and the fact that some NIM were given against NET which were distributed through an ICO makes it kind of blurry
Compliance Obligations
The asset would not affect Coinbase or Coinbase's ability to meet compliance obligations, which include Compliance Obligations, Anti-Money Laundering (AML) program and obligations under government licenses in any jurisdiction (e.g. Money Transmitter Licenses).
✔︎ Conversion from NET to NIM went through a KYC specifically for that.
Integrity & Reputational Risk
Would listing the asset be inconsistent with Coinbase policy?
✔︎ I don't see why.
User Agreement
The asset, network, application or fundamental nature of the project does not constitute a Prohibited Business under Appendix 1 of the user Agreement.
✔︎ I read it and it's doesn't.
Liquidity Standards
How liquid is this asset?
〜 Weak liquidity right now.
Global Market Capitalization
How does the market capitalization compare to the total market capitalizations of other assets?
〜 Weak capitalization.
Asset Velocity
Trade velocity, or turnover, is a significant part of market capitalization. This is a measure of how easily the asset can be converted to another asset.
〜 Again, weak velocity.
Circulation
For service or work tokens, new supply is created through consensus protocols. If the supply is capped, then a material amount of the total tokens should be available to the public.
✔︎ It's available.
Global Distribution
Where is this asset available to trade?
✔︎ HitBTC/Tradesatoshi/LAtoken/BTC-alpha/Nimex.
Total # of Exchanges
The number of exchanges that support the asset.
✔︎ 5.
Geographic Distribution
The asset is not limited to a single geographic region and is available to trade on decentralized exchanges.
✔︎ It's tradable everywhere and I guess you can count Agoras as a DEX.
Fiat and Crypto Pairs
Fiat and crypto trading pairs exist.
〜 Fiat pairs don't.
Exchange Volume Distribution
If secondary markets exist, then volume should be relatively distributed across exchanges.
✔︎ It is.
Demand
What is driving demand for this asset and does it lead to stronger network effects?
✔︎ The Nimiq community I guess and of course it does.
Consumer Demand
Customer demand is carefully considered, however, any asset which is created from a fork, airdrop, or automated token distribution is subject to a separate set of criteria.
〜 It would be presumptuous to say there is a customer demand for Nimiq right now.
Developers and Contributors
Growing developer base and measured progress as defined by the number of repositories, commits, and contributors.
✔︎ Nimiq has already a flourishing developper base.
Community Activity
Dedicated forums are available where developers, supporters, users, and founders can interact and build a community and offer transparency into the project. The team provides regular updates or is responsive to feedback.
✔︎ Yes it has.
External Stakeholders
There are investments from venture firms or hedge funds which have experience working with crypto companies or projects. The project has corporate partnerships, joint ventures, or dedicated consortiums.
〜 It doesn't as far as I know.
Change in Market Capitalization
The market capitalization has grown after the network has activated, demonstrating increased demand for the asset after the project's launch.
〜 Sadly not.
Nodes
Growing # of nodes on the underlying blockchain. The project has a globally distributed node network, meaning operating nodes are not contained in a single country or geographic region.
✔︎ You can even check them on a map on https://miner.nimiq.com/
Transactions, Fees & Addresses
Growing # of transactions and fees paid over time. Growing # of asset or token holders, which is an indicator of asset distribution.
✔︎ Check the stats
Economic Incentives
Are the economic structures designed to incentivize all parties to act in the best interest of the network?
✔︎ It's a PoW coin so yes.
Type of Token
It is a service, work, or hybrid token. Tokens backed by fiat or other physical assets are categorized as US securities and will not be considered at this time.
✔︎ It's not backed by anything but the work done to generate them.
Token Utility
There is utility from obtaining, holding, participating, or spending the token. The team identifies a clear and compelling reason for the native digital asset to exist (i.e. the main purpose is not fundraising).
✔︎ Nimiq is a general payment protocol.
Inflation (Money Supply)
There is an algorithmically programmed inflation rate which incentivizes security and network effects. Or, if the total supply is capped, then a majority of the tokens should be available for trade when the network launches.
✔︎ You can check the inflation curve here.
Rewards and Penalties
There are mechanisms (such as transaction fees) which incentivize miners, validators, and other participants to exhibit 'good' behavior. Conversely, there are mechanisms which deter 'bad' behavior.
✔︎ Yes
Security
There is a focus on stringent security protocols and best practices to limit scams, hacks, and theft of funds.
✔︎ The smart-contract of the ICO was audited and they didn't lose the fund yet so I guess it's secure haha.
Participation Equality
Best efforts by the team to allow a fair distribution of tokens (i.e. setting initial individual purchase caps to limit the risk of small number of investors from taking a majority of the supply).
✔︎ The number of NIM distributed through NET is only 7% in any case.
Team Ownership
The ownership stake retained by the team is a minority stake. There should be a lock-up period and reasonable vesting schedule to ensure the team is economically incentivized to improve the network into the future.
✔︎ See the vesting schedule
Transparency
The team should be available and responsive to questions or feedback about the product, token sale, or use of funds across multiple forums.
✔︎ See the transparency report.
Total Supply The team should sell a fixed percentage of the total supply, and participants should know the percentage of total supply that their purchase represents, or have a clear understanding of the inflation rate.
✔︎ All informations are available freely online.
Ethics or Code of Conduct
White paper or project website should have an ethical or professional code of conduct.
✔︎ Check it here
Conclusion: 44 ✔︎ and 12 〜.
submitted by --Talleyrand-- to Nimiq [link] [comments]

Cryptocurrencies turn largely red as cryptocurrency mining chip manufacturer TSMC forecasts weaker demand in 4Q2018

Crypto News

Sources:
https://bitcoinist.com/cryptocurrency-exchanges-lost-882-million-to-hackers-in-two-years-report-finds/ https://cointelegraph.com/news/report-blockchain-and-crypto-industries-see-growing-demand-for-talent https://cointelegraph.com/news/bermuda-government-approves-first-ico-under-new-regulatory-regime https://www.coindesk.com/chip-maker-tsmc-forecasts-weaker-crypto-mining-demand-in-q4/ https://cointelegraph.com/news/bitcoin-hedge-fund-and-ceo-slapped-with-25-million-penalty-for-ponzi-scheme https://www.cftc.gov/PressRoom/PressReleases/7831-18 https://www.coindesk.com/judge-orders-trading-firm-ceo-to-pay-2-5-million-in-bitcoin-ponzi-case/ https://www.coindesk.com/crypto-exchange-huobi-now-lets-users-swap-between-4-different-stablecoins/ https://cointelegraph.com/news/gates-foundation-to-partner-with-ripple-and-coil-to-support-pro-poor-payment-systems https://www.ccn.com/gates-foundation-partners-ripple-and-coil-in-financial-inclusion-initiative/ https://cointelegraph.com/news/tether-didnt-do-a-great-job-on-transparency-claims-investor-mike-novogratz
submitted by QuantalyticsResearch to CryptoCurrency [link] [comments]

How Bitcoin Works ? Bitcoin Mining Explained In Detail ... What is Bitcoin - Bitcoin Mining - How bitcoin works - Explained - In Hindi Cryptocurrency Mining Cost Breakdown Bitcoin Mining with an ANTMINER S9 in September 2017 - (OUDATED - Check Desc.) Bitcoin Mining Explained in Detail: Nonce, Merkle Root, SPV,...  Part 15 Cryptography Crashcourse

Bitcoin Champion is yet another automatic cryptocurrency trading platform that promises stellar earnings.. It is completely equal to other platforms already seen, such as Bitcoin Bank or Bitcoin Compass.. Website analysis. Bitcoin Champion features on the homepage of the website the usual video about the Bitcoin revolution, with a CNN journalist, Bill Gates, the Winklevoss twins and others. --- SOLO MINING BFGMiner supports solo mining with any GBT-compatible bitcoin node (such as bitcoind). To use this mode, you need to specify the URL of your bitcoind node using the usual pool options (--url, --userpass, etc), and the --generate-to option to specify the Bitcoin address you wish to receive the block rewards mined. When you run Bitcoin Core on the same computer as your miner, the ... Unter dem Namen Robin präsentiert die Deutsche Bank ihren hauseigenen Robo-Advisor als Teil der digitalen Vermögensverwaltung auf der Investment-Plattform maxblue.de. Den Robo-Advisor gibt es seit November 2017. Die Investition ist möglich ab einer Mindestanlage von 5.000 Euro bei Kosten von 0,80 % bis 1,00 % pro Jahr zuzüglich der Fondskosten. ture, such as Intel’s SGX processors, or by mining them starting from an initial fair distribution. For leader selection we use a deter-ministic approach. On each round, we select a set of the previously created identities as consensus leader candidates in round robin manner. Because simple round-robin alone is vulnerable to attacks Further, the round-robin format for selecting the leader node was not compatible with many of the goals of Bitcoin’s structural design. Satoshi built Bitcoin’s PoW consensus algorithm on the block leader selection method of a lottery-like system where miners compete to solve a computationally intensive puzzle. The winner of that round (~10 ...

[index] [5272] [37525] [15485] [25346] [39896] [37769] [8601] [12517] [50101] [24640]

How Bitcoin Works ? Bitcoin Mining Explained In Detail ...

Earn while you sleep, no expensive bitcoin mining involved. More details: ... bitcoin mining algorithm how to start bitcoin mining, btc mining, asic bitcoin miners bitcoin mining program, bitcoin ... What is Bitcoin, what is bitcoin mining, how bitcoin works I am going to explain you in Hindi Bitcoin was created by the "Satoshi Nakamoto". Bitcoin is a form of digital currency, created and ... This video is to give you insight on the cost elements associated to fixed/variable agnostic to the volatile price of crypto. i.e. back in the day in early mining of bitcoin, it was far from ... This video of Cryptocurrency Mining Algorithms gives an idea of algorithms requires for mining cryptocurrencies. It helps you to learn about mining algorithms. The video shows topics like: 1. What ... Since the scrapping of banking ban on cryptocurrency, crypto mining in India has been a growing industry. It is the process of processing transactions and adding them to the blockchain. Verifying ...

#