In part 4 we explore the various types of attacks the block lattice might be faced with and how it will overcome each of them (if needed).

Index

• Part 1: Introduction
  (https://steemit.com/blockchain/@iwan.spillebeen/bockchain-decrypted-the-block-lattice-introduction)
• Part 2: In depth
  (https://steemit.com/blockchain/@iwan.spillebeen/blockchain-decrypted-the-block-lattice-in-depth)
• Part 3: Adaptability / Scalability
  (https://steemit.com/blockchain/@iwan.spillebeen/blockchain-decrypted-the-block-lattice-adaptability)
• Part 4: Attack Potential
  (https://steemit.com/blockchain/@iwan.spillebeen/blockchain-decrypted-the-block-lattice-attack-potential)
• Part 5: Block Lattice Visualisation
  (https://steemit.com/blockchain/@iwan.spillebeen/blockchain-decrypted-the-block-lattice-visualisation)
• Part 6: Network Flooding
• Part 7: Resolving Forks

Attack Potential

In order to further asses long term viability of this system we need to evaluate how they can be attacked; how likely these attacks are and what the severity of these attacks would be.

The block lattice doesn’t have the concept of a coordinator (centralisation), and auto-peering has been a standard feature of full nodes and the wallet since it was released; which is a benefit.

Aside from this the system is quite new and hasn't been fully put through the paces yet, we did see a huge surge in usage and general awareness about Nano / the block lattice in recent months, with as a result the coin rising from rank 200 on 24 November 2017 to rank 40 by 14 December 2017 and up to rank 19-24 to-date (30/03/18); which will put the technology through its paces.

The block lattice has a number of mechanisms built in to protect from a range of possible attacks on the system; below an overview of attacks and safeguards in place:

Block Gap Synchronisation

• Risk level: Low
• Impact: Network amplify / Denial of service

Description

Each block has a link to its previous block. If a new block arrives where we can't find the previous block, this leaves the node deciding whether it's out of sync or if someone is sending junk data.

If a node is out of sync, synchronizing involves a TCP connection to a node that offers bootstrapping which is much more traffic than sending a single UDP packet containing a block; this is a network amplification attack.

Defense

For blocks with no previous link, nodes will wait until a certain threshold of votes have been observed before initiating a connection to a bootstrap node to synchronize. If a block doesn't receive enough votes it can be assumed to be junk data.

Transaction flooding

• Risk level: Moderate
• Impact: High i/o

Description

Transaction flooding is simply sending as many valid transactions as possible in order to saturate the network. Usually an attacker will send transactions to other accounts they control so it can be continued indefinitely.

Defense

Each block has a small amount of work associated with it, around 5 seconds to generate and 1 microsecond to validate. This work difference causes an attacker to dedicate a large amount to sustain an attack while wasting a small amount of resources by everyone else. Nodes that are not full historical nodes are able to prune old transactions from their chain, this clamps the storage usage from this type of attack for almost all users.

Sybil

• Risk level: No risk
• Impact: Completely destructive

Description

Certainly one of the better known attacks in the crypto space, a Sybil attack is a person creating a lot of nodes on the network, possibly thousands on a single machine, and using these in order to get a disproportionate vote on networks; where each node gets an equal vote in order to control the voting power of the network and as such the network itself.

Defense

The block lattice voting system is weighted based on account balance. Adding extra nodes in to the network will not gain an attacker extra votes.

Penny-spend

• Risk level: Moderate
• Impact: Large Ledger

Description

A penny-spend attack is where an attacker spends infinitesimal quantities to a large number of accounts in order to waste the storage resources of nodes.

Defense

Blocks publishing is rate-limited by work so this limits accounts to a certain extent. Nodes that are not full historical nodes can prune accounts below a statistical metric where the account is probably not a valid account. Finally, the block lattice is tuned to use minimal permanent storage space, so space required to store one additional account is proportional to the size of an open block + indexing ~ 96b + 32b ~ 128b.

This equates to 1GB being able to store 8 million penny-spend accounts.

If nodes want to be aggressive, they can calculate a distribution based on access frequency and delegate infrequently used accounts to slower storage.

51% Attack

• Risk level: Low to impossible
• Impact: Completely destructive

Description

The metric of consensus for the block lattice is a balance weighted voting system.

If an attacker is able to gain over 50% of the voting strength, they can cause the network to oscillate their decisions rendering the system useless. An attacker must have at least some value tied up in the network as a balance which they're willing to forfeit as an expense to performing this type of attack since this attack ruins the integrity of the system.
An attacker is able to lower the amount of balance they must forfeit by preventing good nodes from voting through a network DDoS.

Defense

• The primary defense against this type of attack is voting weight being tied to investment in the system; attempting to flip the ledger would be destructive to the system as a whole which would destroy their investment.
• The second defense against this attack is the cost of this attack is proportional to the market cap of all of Nano. In proof of work systems, technology can be invented that gives disproportionate control compared to monetary investment and if the attack is successful, this technology could be repurposed after the attack is complete. With Nano the cost of attacking the system scales with the system and if an attack were to be successful the cost of the attack can't be recovered.
• In order to maintain the maximum quorum of voters, the next line of defense is representative voting. Account holders who are unable to reliably participate in voting for connectivity reasons can name a representative who can vote with the weight of their balance.
• Forks in Nano are never accidental so nodes can make policy decisions on how to interact with forked blocks. The only time non-attacker accounts are vulnerable to block forks is if they receive a balance from an attacking account. Accounts wanting to be secure from block forks can wait a little or a lot longer before receiving from an account who generated forks or opt to never receive at all. Receivers could also generate separate accounts for receiving from dubious accounts in order to protect the rest of their balance.
• A final line of defense that has not yet been implemented is block cementing. The block lattice goes to great efforts to get block forks to settle quickly via voting. Nodes could be configured to cement blocks after a certain period of time, possibly a few minutes, which would prevent them from being rolled back. More research has to be done to figure out of this policy would be beneficial and what type of parameters would be the best. More than likely the network is sufficiently secured through focusing on fast settling time.

Bootstrap poisoning

• Risk level: Low
• Impact: Denial of Service for New Users

Description

The longer an attacker is able to hold an old private key with a balance, the higher the probability of balances that existed at that time no longer having representatives that are participating in voting because their balances or representatives have transferred to new people. This means if a node is bootstrapped to an old representation of the network where the attacker has a quorum of voting stake compare to representatives at that point in time, they would be able to oscillate voting decisions to that node.
If this new user wanted to interact with anyone besides the attacking node all of their transactions would be denied since they have different head blocks. The net result is nodes can waste the time of new nodes in the network by feeding them bad information.

Defense

Nodes can be paired with an initial database of accounts and known-good block heads; this is a replacement for downloading the database all the way back to the genesis block.
The closer the download is to be current, the higher the probability of accurately defending against this attack.
In the end this attack is probably no worse than feeding junk data to nodes while bootstrapping since they wouldn't be able to transact with anyone who has a contemporary database.

Conclusion

Based on the information provided by the Nano team as well as independent stress tests performed against the live network, and taking the above into considering I believe that Nano has a low susceptibility to the attacks outlined above.

That doesn't mean it will not be attacked and it doesn't mean an attack ultimately won't be successful but thus far they appear to have created a very safe and sound product. All they need is to gain much more traction so that attack potentials can really be put to the test.

Acknowledgements / References

Artwork:

• Title page “Intelligent Solutions” courtesy of http://www.hloom.com/cover-pages/
• Page header / footer “Abstract blue lights” created by Kotkoa - Freepik.com

Other references:

• https://medium.com/@yourcryptomarketing/Nano-the-future-of-bockchain-architecture-no-fees-and-unlimited-scalability-for-all-b2c51a0d80a7
• https://www.reddit.com/user/meor
• https://www.forbes.com/sites/louiscolumbus/2016/11/27/roundup-of-internet-of-things-forecasts-and-market-estimates-2016/#54bb8ea9292d
• https://github.com/clemahieu/Nano/wiki/Double-spending-and-confirmation
• https://github.com/clemahieu/Nano/wiki/Representatives-and-decentralization
• https://Nano.net/page/resources.php#devtools
• https://en.wikipedia.org/wiki/Steganography
• https://hackernoon.com/iota-vs-Nano-413679bb4c3e
• https://github.com/clemahieu/Nano/wiki/Distribution,-Mining-and-Units
• https://github.com/clemahieu/Nano/wiki/Roadmap
• https://github.com/clemahieu/Nano/wiki/Attacks
• https://hackernoon.com/visualizing-how-Nano-works-8c70678ef082

Contact me

You can contact me here with any questions, suggestions and / or to discuss the topic of this document:

LinkedIn: https://www.linkedin.com/in/iwanspillebeen/
Email: [email protected]
CryptoPub/ToshiTimes: https://forum.toshitimes.com/u/iwan.spillebeen

Sponsoring

I write these papers to - hopefully - help make blockchain more accessible to people new to the technology, I don't get paid, nor sponsored to write these papers. If you absolutely feel inclined to donate something to the writing of this document, you can do so at the following address:

• Ethereum / Ether: 0x6E2a1f9baD495B894A2c6F8240918620F899f4E2
• Nano / XRB: xrb_1xxzi1o9ywinusod35dcun6ku385i33bohhh8hpap76fh67fgnxg1m3qm9mb

Disclaimer

Blockchain – Decrypted is written as a series of chapters, aimed at demystifying the various workings of blockchain technology. Where appropriate I use examples from existing or to-be cryptocurrencies, these examples are just that, examples, and do not aim at promoting or otherwise endorsing any given cryptocurrency.

This document does not constitute legal or financial advice and I do not make any guarantees or promises as to any results that may be obtained from using my content. No one should make any investment decisions without first consulting his or her own financial advisor and conducting his or her own research and due diligence. I disclaim any and all liability in the event any information, commentary, analysis, opinions, advice and/or recommendations prove to be inaccurate, incomplete or unreliable, or result in any investment or other losses.