Byteball : Misunderstood fundamental aspects

First above all, I'm a Byteball fan, a Byteball holder and an IT guy. Each word in this article is based on my own understanding and interpretation of the Byteball whitepaper. So, the Byteball team could not be considered as responsible for my inaccurate understanding or potential wrong assertions. Furthermore, if it wasn't clear enough, this article is not an investment advice but an attempt, maybe poor, to explain some misunderstood fundamental aspects of the Byteball technology. Obviously, there are many technical aspects I don't mention but you can read the whitepaper if you're interested.

What is the Byteball common perception ?

Classical understanding will explain to you that Byteball is a cryptocurrency and a smartcontract platform published officially in 2016, December 25th by Anton Churyumov. At difference of the so-called blockchain cryptocurrencies, Byteball uses a directed acyclic graph (DAG) model to link every transaction in a chain. As there is no blocks, there is no miner to process users transactions. The transactions are validated by 12 witnesses (almost pure bullshit) and the total bytes amount has been generated in the genesis unit. So, the Byteball proposal could be qualified as environmental-friendly and self sustainable comparatively to the common blockchain models.

What is really Byteball ?

Byteball is a permissionless decentralized tamper-proofed database that allows all users to write/post arbitrary data almost instantly. There is no single or central entity that manage the admission of new transactions. Each transaction (or posted unit) is doubly multi-linked to the closest past and future transactions of other users and to the emitter past, and then future, transactions. So, each unit has a chain of referenced ancestors, transactional hashes and a witnesses list to track and validate each movement since the genesis unit.

It means that users help each other to validate and certify their posted units. And it's the user exclusive responsibility to keep the integrity of its own transactional chain until the genesis unit.

Once a transaction broadcasted, no one can revoke or rewrite it without risking to break its own chain integrity, and potentially other people linked-descendant chains, because a unit hash depends on its ancestors signatures, hashes and witnesses. In conclusion, any attempt to edit a transaction will have cascad-effects which grow exponentially in time and will require an impossible and massive users coordination.

How the Byteball transactions are validated ?

In the Byteball DAG model, posted units are vertices and parents-children links are edges of the graph. All units have to be posted serially. By consequence, parallel units are forbidden, detected and rejected, by default, as a double-spend attempt even if they could be legit. Each time a user post a new unit in the Byteball database, the posted unit will confirm automatically its parents and all its ancestors until the genesis unit by adding their references in its structure.

The posted unit will also include references of non-redundant past transactions of other users. This specificity will help the other users to have their transaction deemed as valid faster. Each new posted unit will then look for the best path until the genesis unit. This path has some recommended milestones represented by the user witnesses list and its ancestors witnesses lists which can differ by one permutation at each hop in history.

The best path is called partial order of the posted unit but the chain will stay unstable and the transaction unspendable until the total order confirmed by later transactions. Total order of the posted unit will be identified later by the partial order of children units which, in plus, confirm the posted unit transaction if valid obviously. This delay between partial order and total order is useful to detect parallel double-spend attacks and renegade witnesses behaviors. Eventually, the posted unit will be confirmed and its main chain until the genesis unit becomes stable and irrevocable.

Why Byteball witnesses are required ?

Byteball witnesses will be known people or entities reputed as trustable. The only mission of witnesses will be to post, serially, new units frequently enough. And if it's reasonable to expect them to behave honestly due to incentives, it's also unreasonable to totally trust any single witness. Byteball witnesses have a double role.

First, they are milestones or navigational aids (lighthouses) to help users to find the best path until the genesis unit. Once the majority of witnesses (6+1) crossed by successive hops to establish the partial order, the last one will be considered as a shortcut until the genesis unit. The shortcut function is pretty obvious because each unit includes as reference its ancestor list. And it's smart because the path until the genesis unit could be insanely long and, by consequence, could freeze your machine for a long time.

The second role of witnesses is, in my opinion, purely anecdotal because they help users to get their transactions validated as all other users when they post units. But this validation feature helps clearly the network in its young age.

Eventually, due to the possibility of one witness permutation, everyone can potentially act as a non-official witness for itself but without the financial incentives because the chance to have your witness set as a milestone of the main chain will be close to zero. Except if you become the permuted witness of many obviously. Anyway, it will help you to get your units validated faster.

What kind of attacks are possible against Byteball ?

As there is no miner, Byteball is immunized against the classical 51% attacks but variants could exist.

Magic coins creation isn't possible because the total amount is a constant and because every unit has a list of hashes that allow to track every movement since the genesis unit.

Revoke or rewrite a transaction is almost impossible because a massive coordination between all users is required due to the doubly multi-linked ancestors-descendants references of each unit. And, the attack complexity increases exponentially in time as mentionned in the whitepaper with the snowball term.

Due to the Byteball network rules, most of double-spend attacks are impossible. First rule, all the units have to be posted serially. Any attempt, even legit, to post in parallel will be detected and will be rejected, by default, as a double-spend attack. Partial order is the second anti-double-spend rule which will detect and reject automatically all attempts of double-spend due to the paradox of a child being its own parent. So, only the first transaction will be deemed as valid. The total order is the third rule that immunizes the network against a double-spend attack. For instance, if it's impossible to establish a unit partial order, the total order will delay the transaction until newer units establish their partial order. These newer units will exclude the double-spend chain as possible partial order and select an older unit, so the double-spend will be rejected. In case of a shadow chain (very long and parallel chain) with the complicity of renegade witnesses, the total order will reject the double-spend when the shadow chain will converge with the main chain.

The only true possibility of double-spend attack requires the complicity of the witnesses majority (6+1) with the attacker. Unfortunately for them, the double spend can still be detected by users, honest witnesses and permuted non-official witnesses.

An other kind of 51% attack, with the witnesses majority, would aim to censor some user. Unfortunately for the attackers, the doubly multi-linked ancestors-descendants references will inevitably isolate wide branches of the DAG. Once again, it will be detected by users, honest witnesses and permuted non-official witnesses.

Eventually, the last attack with the majority of witnesses would aim to resist against a witness change by the community to keep their financial privileges as a cartel. This will be obviously detected by users, honest witnesses and permuted non-official witnesses. In reaction, the Byteball community can cooperate to define some reputable permuted non-official witnesses as new witnesses to exclude cartelized witnesses of the game. In the worst case scenario, if a cooperation isn't possible between the Byteball community members, the whitepaper recommends a "Revolution" by the intermediary of a fork via a specific Byteball flag until the conflict stops.

Conclusion

To conclude this article, I insist on the decentralized aspects of Byteball and how important are the permuted witnesses to warranty that the Byteball network will stay healthy, even in case of collusion between witnesses and attackers or in case of a cartel creation, and to help yourself and other people to get your transactions confirmed as fast as possible. By the way, if you can't trust yourself, who can you trust ?

Byteball whitepaper : https://byteball.org/Byteball.pdf