In general, OruMesh works in the following way. Instead of the global blockchain, there is a DAG ( A directed graph with no path that starts and ends at the same vertex. Also known as DAG,acyclic directed graph, oriented acyclic graph. … directed graph, acyclic graph. See also cycle, feedback edge set, feedback vertex set.) that we call The mesh. The transactions issued by nodes constitute the site set of the mesh (i.e., the mesh graph is the ledger for storing transactions). Its edge set is obtained in the following way: when a new transaction arrives, it must approve two previous transactions; these approvals are represented by directed edges, If there is no directed edge between transaction A and transaction B but there is a directed path of length at least two from A to B, we say that A indirectly approves B. There is also the “genesis” transaction, which is approved (directly or indirectly) by all other transactions.The genesis is described in the following way. In the beginning there was an address with balance containing all the tokens. Then the genesis transaction sent these tokens to several other “founder” addresses. Let us stress that all the tokens were created in the genesis (no other tokens will be created), and there no mining in the sense “miners receive monetary rewards”.
A quick note on the terminology: sites are transactions represented on the tangle graph. The network is composed by nodes; that is, nodes are entities that issue transactions. Now, the main idea is the following: to issue a transaction, users must work to approve other transactions, therefore contributing to the network’s security. It is assumed that the nodes check if the approved transactions are not conflicting and do not approve (directly or indirectly) conflicting transactions. As a transaction gets more and more (direct or indirect) approvals, it becomes more accepted by the system; in other words, it will be more difficult (or even practically impossible) to make the system accept a double-spending transaction. It is important to observe that we do not impose any rule for choosing the transactions to approve; rather, we argue that if a large number of other nodes follow some “reference” rule (which seems to be a reasonable assumption, especially in the context of different devices, where nodes are specialized chips with pre-installed firmware), then for any fixed node it is better to stick to a rule of the same kind More specifically, to issue a transaction, a node does the following:
• First, it chooses two other transactions to approve (in general, these two transactions may coincide), according to some algorithm. • It checks if the two transactions are not conflicting and do not approve conflicting transactions. • For the transaction to be valid, the node must solve a cryptographic puzzle (which may be computationally demanding) similar to those in the Bitcoin mining (e.g., it needs to find a nonce such that the hash of that nonce together with some data from the approved transactions has a particular form, for instance, has at least some fixed number of zeros in front).
It is important to observe that, in general, we have an asynchronous network, so that nodes do not necessarily see the same set of transactions. It should be noted also that the tangle may contain conflicting transactions. The nodes do not have to achieve consensus on which valid transactions have the right to be in the ledger (all of them can be there); but, in case there are conflicting transactions, they need to decide which transactions will become orphaned (that is, eventually not indirectly approved by incoming transactions anymore). The main rule that the nodes use for deciding between two conflicting transactions is the following: a node runs the tip selection algorithm many times, and see which transaction of the two is more likely to be (indirectly) approved by the selected tip. For example, if, after 100 runs of the tip selection algorithm, a transaction was selected 97 times, we say that it is confirmed with 97% confidence.Let us also comment on the following question:
what motivates the nodes to propagate transactions? In fact, in our setup the nodes do not have motivation not to propagate. Every node calculates some statistics, one of which is how many new transactions are received from a neighbor. If one particular node is “too lazy”, it will be dropped by its neighbors. So, even if a node does not issue transactions (and hence has no direct incentive to share new transactions that approve its own one), it still has incentive to work hard.
It should be noted that the ideas about usage of DAGs in the crypto currency context were around for some time. Specifically, the work introduces the so-called GHOST protocol, which proposes a modification of the Bitcoin protocol by making the main ledger a tree instead of the blockchain; it is shown that such a modification permits to reduce the confirmation times and improve the overall security of the network.
We offer one of the lowest fees for money transfers in the world. It costs as little as 0% (Global average 7.72% )
You can send payments directly to bank accounts in almost 40 countries powered by Block Chain.
Send money conveniently and frequently from wherever you are using OruWallet Apps (Web, Window, IOS or Android).
You’re safe with us. Your privacy and information security is our top priority.
What is OruMesh
A blockchain whitout blocks & mining
we are always ready
To Become Partner
Consectetur adipisicing elit sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.