Title Text

Digital Currencies & Blockchain

Lecture 8

 

  • Network Security, Anonymity & Scalability

Content

Attack Vectors I.

  • Short-range attack – attacker waits until merchant accepts payment as confirmed than double- spends it by bribing validators to reorganize the chain
  • Long-range attack – attacker with enough power can rebuild the chain as he chooses, with the ability to build a blockchain however he desires
  • Coin accumulation – protocols which rely on the age of coins, where an attacker could try to accumulate enough old coins to be able to reach a majority in voting
  • Denial of service – flooding nodes so that they can no longer relay transactions
  • Sybil attack – flooding the network with bad nodes that isolate good ones
  • Selfish mining – secretly building on a chain and publish it selectively in order to waste competitors resources

Attack Vectors II.

 

There are two major ways of controlling the network:

 

1. Controlling the information flow between peers

 

2. Controlling the computational power of the network – remember that decisions are based on consensus/majority.

 

An adversary that controls more than half of the network's computing power can effectively control the entire network.

 

While controlling the network, the attacker can:

  • Reverse transactions that s/he sends, thus double- spending own funds.
  • Prevent other miners from mining valid blocks.
  • Prevent valid transactions from gaining confirmations.

However, the attacker cannot:

  • Reverse other people's transactions or spend outputs belonging to others. Create new coins.
  • Prevent transactions from being sent across the network.

51% attack

 

A denial of service (DoS)  attack is an attempt to make an online service unavailable by overwhelming it with traffic.

 

---> overloading a network/computer with requests above the capacity that the network/computer can handle.

 

In Blockchain, this can be achieved by sending lots of junk data to a node. The nodes under attack will not be able to process normal  transactions.

 

 

Denial of Service

 

  • The maximum block size 
  • The maximum number of signature checks that a transaction or block may request
  • The maximum script size (currently 10Kb)
  • The maximum size of values pushed while executing a script (currently 520 bytes)
  • The maximum number of "expensive" operations in a script (up to 201 operations – anything but push operations).
  • The maximum number of keys in multi-sig transactions (currently 20 keys)
  • The maximum number of stack elements stored (currently 1,000 elements)

 

Protocol-based anti-DoS measures

a (bitcoin) node/peer:

  • does not store more than 10,000 orphan transactions;
  • does not forward orphan transactions/blocks;
  • does not forward double-spend transactions;
  • does not forward the same block or transaction to the same peer;
  • does not forward or process non-standard transactions;
  • bans IP addresses that misbehave;
  • keeps a DoS score for each peer;
  • penalizes peers that send duplicate/expired/invalid signature messages;
  • disconnects from peers that send messages that fail to comply with the rules;
  • stores only UTXO (unspent transaction output set) in memory
  • checks all inputs are unspent before fetching a transaction from disk to memory – thus preventing a type of DoS, known as continuous hard disk activity DoS

Node-based anti-DoS measures

--> a malicious user gains control over a node's access to information in the peer-to-peer network.


 Three prerequisites:

  • The adversary should possess a large number of IP addresses and machines (or botnets)
  • The victim should have a public IP address (for example not using TOR).
  • The adversary is able to make the victim restart its Bitcoin client, for example through a DDoS attack (or if the victim restarts the client due to power/network failure or software update).

Eclipse Attack

If the above criteria are met then:

  • The adversary can monopolize all of the victim's outgoing and incoming connections, effectively isolating the victim from the rest of the network.
  • Thus, the adversary can control the victim's view of the blockchain. Further to defrauding the victim, the adversary can use an eclipse attack to:
  • Split the mining power in the network.
  • Perform an 51% attack with less than 50% mining power.
  • Perform selfish mining more easily, by splitting the mining power of honest nodes.
  • Double-spend transactions.

Eclipse Attack II.

  • The Bitcoin network spans the globe --> nodes are in different time zones.
  • Time is extremely important --> determines the validity of new blocks.
  • When establishing new connections, the protocol forces nodes to exchange their system time.
     
  • Each node maintains a counter, which represents the median network time of its peers. The counter reverts to system time, if the median differs from it by more than 70 minutes.
     
  • By announcing inaccurate timestamps when connecting to a node, an attacker can alter a node's network time counter and deceive it into accepting an alternate blockchain.
  •  --> increase the chances of a successful double-spend.

Time Jacking

  • process of sending thousands of nano-value transactions, in order to fill the blocks to the maximum size.
     
  • This will create delays to other legitimate transactions, thus delaying the whole network and increasing confirmation time for all transactions.

     
  • A flood attack is performed very easily, with the attacker just sending thousands of transactions to himself.
     
  • However, it is expensive to sustain for a long time, due to transaction fees.

 

Flood Attack

  • can be used by large miners to increase their returns by not playing fair.
  • The selfish miner starts building a chain of blocks, but does not publish and distribute it to the rest of the network.
  • When the rest of the network is about to catch up with the selfish miner, the miner a releases a portion of the chain to the public.
  • Because the chain of the selfish miner will be longer and more difficult, the rest of the network will discard the blocks of other miners and will adopt the chain of the selfish miner.

Selfish Mining

  • The computing power of honest miners is wasted.

    --> selfish miners increase the impact of their own mining power on the network and enjoy additional power and profits.


    Selfish mining increases transaction confirmation times, because transactions confirmed by the selfish miner in private, are not broadcast to the public immediately.


    Selfish mining also increases the threat of double spending, as both honest and selfish miners can add mutually exclusive transactions to the private and public chains.

      

    May be possible with 1/3 of network (33% attack).

Selfish Mining II.

  • Cutting edge, untested
     
  • 10 x more buggy code
     
  • Different logic than SW on centralized machines
     
  • Potentially unchangeable
     
  • Different platforms, limited interoperability
     
  • Ethereum seems to be so far the winner

Dapps security considerations

  • All transactions are public, traceable and permanently stored in the blockchain.
     
  • To protect your privacy, you must use a new address for every
    new transaction.
     
  • Protecting your IP is also a good idea.
     
  • Beware of mixing services: further to potential legality issues, they rely on trusting a third party and are, generally, not effective for large transactions.

Anonymity (Fungibility)

CoinJoin is a trustless method for combining multiple Bitcoin payments from multiple spenders into a single transaction to make it more difficult for outside parties to determine which spender paid which recipient or recipients.

 

Unlike many other privacy solutions, coinjoin transactions do not require a modification to the bitcoin protocol.

CoinJoin

  • A user withdraws bitcoin from his wallet and turns them into Zerocoins.
  • Zerocoins from multiple users are then "mixed up”.
     
  • The user can then redeem zerocoins and deposit bitcoins to a new wallet address. Nobody can then link the new bitcoins to the old ones.
     
  • The Zerocoin protocol can be seen as an inbuilt anonymizer where you don’t have to trust any third parties. You mint a coin by burning it up, and then at later time, redeem it for a new coin with no transaction history. The link between the old coin and its associated transaction history is broken.

Zerocoin

Zerocoin II.

 

  • Zcash is a new blockchain that also aims at true cryptographic anonymity.
     
  • The principle is similar to Zerocoin, but the cryptography used is the current state-of- the-art, an evolution of zero-knowledge proof constructions, called zk-SNARKs.
     
  • It offers both so-called transparent transactions (t-addresses) like Bitcoin, and true anonymous transactions (z-addresses).
     
  • Transactions using z-addresses are hiding the source, destination and amount involved in the transaction, but they are still verifiable.

Zcash

Zcash

  • Cryptonote is based on ring signatures, which allow users to sign messages on behalf of a group
     
  • A ring signature only proves the message was created by someone in the group, but all the possible signers are indistinguishable from each other.
     
  • So, the verifier may only identify that a message of the group was the signer, thus providing plausible deniability.
     
  • Cryptonote receivers have multiple one-time addresses, which are derived from a single public key. Funds sent to these one-time

    addresses cannot be linked to the receiver, who is using the public key.
  • Non-repeating one-time addresses and mixed keys in ring signatures make the whole blockchain resistant to analysis.

Anonymity IV.

Scalability

Scalability II.

Processing Power - the more processing power your computer has, the more transactions it can process.

- mostly for verifying transactions using:

  • hashing (sha256 and ripemd160) and
  • signature verifications (ECDSA)


In theory, Bitcoin is able to verify approximately 4,000 transactions per second on an average CPU.
In reality we cannot hope to scale beyond 200 transactions per second

 

Scalability III.

Storage - Maintaining a full bitcoin node means storing every single transaction ever recorded on the blockchain.

As of  November 2020, the Bitcoin blockchain takes around  303 GB and increases by cca 5GB per month.

 

If the network grows to the size of competing networks, storage requirements will skyrocket:

For 200 transactions per second (tps) – a reasonable target, given

PayPal's current rate of 100 tps –nodes would require an additional storage space of 3Tb per year.

 

Scalability IV.

Bandwidth - Assuming that a bandwidth of 10Mbits/s is available, the rate with which nodes can receive transactions is limited to approximately 2,000 transactions per second.

 

+ each node is informed about every transaction multiple times and that other non-transaction messages are broadcasted over the network

 

If bandwidth is not enough, peers won’t be able to receive and validate transactions in time, making them unable to synchronize with the rest of the network.

Scalability IV.

RSK

Lightning Network II.

1) Users run a Lightning Node.

2) Two users lock funds in a multisig on the blockchain. This opens a bi-directional payment channel between both of their Lightning Nodes.

3) Lightning transactions instantly update the balance of the payment channel without needing to involve the blockchain. The transaction data is stored locally on the Lightning Node.

4) As more Lightning Nodes come online, and more payment channels connect them, a peer-to-peer mesh network begins to form. This means that even if two nodes don't directly connect, they can still transact as payments are routed over the network of connected nodes.

5) To settle, a user closes their payment channel, with the net balance finally being broadcast to the blockchain.

Lightning Network

LN stats - www.1ml.com

Ethereum - Layer 2

Payment Channels

Sidechains & Plasma

Readings

UNI - L8 (Network Security & Scalability)

By David Stancel

UNI - L8 (Network Security & Scalability)

Security, Anonymity & Scalability of Cryptocurrencies

  • 698