Byteball - Smart payment cryptocurrency

yandot (67)in #byteball • 6 years ago (edited)

What is Byteball

Byteball is a decentralized system that allows tamper proof storage of arbitrary data, including data that represents transferrable value such as currencies, property titles, debt, shares, etc. The set of links among units forms a DAG (directed acyclic graph).There is no single central entity that manages or coordinates admission of new units into the database, everyone is allowed to add a new unit provided that he signs it and pays a fee equal to the size of added data in bytes.

Image

Byteball is a simple smart payment with risk-free terms. with a decentralized system that provides tamper-proof data storage. The terms will automatically ensure against the payment that is fulfilled. If conditions are not met, all money will only be returned to the sender. Byteball has gained a great deal of trust from people who are associated with crypto and others.
Byteball enables trust where trust couldn’t exist before.

When a contract is created on Byteball platform, it can be trusted to work exactly as agreed upon. Why? Because it is validated by multiple nodes on the decentralized network, which all follow the same immutable rules. The counterparty, even if it is a total stranger, has to behave honestly because only the rules have authority. Such a contract is called a smart contract.

Byteball data is stored and ordered using directed acyclic graph (DAG) rather than blockchain. This allows all users to secure each other's data by referencing earlier data units created by other users, and also removes scalability limits common for blockchains, such as blocksize issue.

What is DAG ?

DAG is Byteball's backbone where maximum crypto currencies use blockchain. For this Byteball has block size issue, because it has no blocks actually. Instead of blocks on blockchain, every new transaction references one or more earlier ones (parents) by including and signing their hashes. The links among transactions form a DAG. By including its parents, each new transaction also indirectly includes and confirms all parents of the parents, parents of the parents of the parents, and so on. As more transactions are added after your transaction, the number of confirmations you receive grows like snowball, that’s why the name Byteball (our snowflakes are bytes of data). more information check here

Database structure

When a user wants to add data to the database, he creates a new storage unit and broadcasts it to his peers. The storage unit includes (among other things):

The data to be stored. A unit may include more than one data package called a message. There are many different types of messages, each with its own structure. One of the message types is payment, which is used to send bytes or other assets to peers.
Signature(s) of one or more users who created the unit. Users are identified by their addresses. Individual users may (and are encouraged to) have
multiple addresses, like in Bitcoin. In the simplest case, the address is derived from a public key, again similar to Bitcoin.
References to one or more previous units (parents) identified by their hashes.
References

Image

References to parents is what establishes the order (only partial order so far) of units and generalizes the blockchain structure. Since we are not confined to one-parent–one-child relationships between consecutive blocks, we do not have to strive for near-synchrony and can safely tolerate large latencies and high throughputs: we’ll just have more parents per unit and more children per unit.

Double-spends

If a user tries to spend the same output twice, there are two possible situations:

There is partial order between the two units that try to spend the same output, i.e. one of the units (directly or indirectly) includes the other unit, and therefore comes after it. In this case, it is obvious that we can safely reject the later unit.
There is no partial order between them. In this case, we accept both. We establish total order between the units later on, when they are buried
deep enough under newer units (see below how we do it). The one that appears earlier on the total order is deemed valid, while the other is deemed invalid.

Image

There is one more protocol rule that simplifies the definition of total order.
We require, that if the same address posts more than one unit, it should include (directly or indirectly) all its previous units in every subsequent unit, i.e. there should be partial order between consecutive units from the same address. In other words, all units from the same author should be serial. If someone breaks this rule and posts two units such that there is no partial order between them (nonserial units), the two units are treated like double-spends even if they don’t try to spend the same output. Such nonserials are handled as described in situation 2 above.

The main chain

Our DAG is a special DAG. In normal use, people mostly link their new units to slightly less recent units, meaning that the DAG grows only in one direction. One can picture it as a thick cord with many interlaced wires inside. This property suggests that we could choose a single chain along child-parent links within the DAG, and then relate all units to this chain. All the units will either lie directly on this chain, which we’ll call the main chain, or be reachable from it by a relatively small number of hops along the edges of the graph. It’s like a highway with connecting side roads.

Image

If we start from another tip, we’ll build nother main chain. Of note here is that if those two main chains ever intersect while they go back in history, they will both go along the same path after the insersection point. In the worst case, the main chains will intersect only in genesis. Given that the process of unit production is not coordinated among users, however, one might expect to find a class of main chains that do converge not too far from the tips.

Mining, Fees & Money Supply

There is no PoW (Proof Of Work), no PoS (Proof of Stake), and no mining. All coins are issued to a genesis address from which every full moon we get free bytes. The fees paid for storing one’s transactions (or any other data) in the Byteball database are equal to the size of the data being stored. If the size of your transaction data is 500 bytes, you pay exactly 500 bytes (the native currency of Byteball) in fees. There are only 10^15 bytes (1 Million GBYTE) existed. All bytes will be issued in the genesis transaction. Since the fees paid are returned into the circulation, the money supply will remain the same.

BYTEBALL - telegram https://t.me/byteball