Economics of stealing uninitialized Lisk accounts – Simon Warta – Medium

0
406

The primary identifier of an account on the Lisk blockchain is an address. The format of a Lisk address is “<unsigned 64 bit integer>L”. An account is called uninitialized when there is a record in the Lisk database but no outgoing transaction was sent from this account. This happens when an account only received tokens but never sent anything.

As long as an account is uninitialized, no public key for that account is known to the blockchain. Thus any public key that leads to the account’s address can be used to spend the funds. A public key is 256 bit long but the address in Lisk is only 64 bit long, i.e. 2²⁵⁶/2⁶⁴ (a very big number) different pubkeys exist for every single address. However, those pubkeys are not so easy to find.

In January 2018, JP Aumasson posted the article Blockchains: How to Steal Millions in 2⁶⁴ Operations about this exact problem and I recommend you to read his excellent analysis to develop a deep understanding of the problem. While the qualitative findings back then remain unchanged, I will go into detail about the quantitative aspects. Since I was not convinced by the numbers of the original author and Lisk HQ, I did a lot of my own research. I contrast to the original arguments, I will not try to answer the question How long does an attack take? but the question How much does an attack cost?, or rephrased Is the attack profitable?.

To find out how quickly Lisk addresses can be generated, I created the tool lisk-vanity, which is yet another short address generator. The difference to other tools is that it utilizes GPUs, which do very well in brute forcing addresses due to their highly parallel processing capacity.

Cost

The following table shows the computational performance and renting cost for different GPUs I had access to. I’m leaving out the source of those offers to avoid unnecessary advertisement. Feel free to choose a GPU hoster of your choice and re-do the calculation.

Benchmarks and cost for Ed25519 keypair brute forcing

Given the GPUs are rented from big cloud providers, I’m going to assume it is possible to rent as much computational power as you want for about 1.9 * 10^-11 EUR per keypair.

Revenue

To make this an interesting business, we need to attack multiple accounts at once, i.e. every address that was generated is looked up in a list of target addresses. My analysis show that about 80 % of that expected revenue is already reached when targeting the top 500 addresses at once. Adding more target addresses does not help very much. Since this is a game of orders of magnitude, we consider attacking the top 500 all we need. This can easily be implemented, as 500 addresses consume only 4 kilobytes of memory and searching in an ordered list of 500 elements is super fast.

Given the current balances of the top 500 uninitialized accounts, generating a single keypair and testing the resulting address gives us an average revenue of 2.3*10^-13 LSK.

Summing up

Per keypair we brute force we gain 2.3*10^-13 LSK at a cost of 1.9*10^-11 EUR. This means we are break even at a rate of 83 EUR per LSK.

So as soon as the market price of LSK reaches 83 EUR, this is a profitable business. If you can alternatively reduce brute-forcing cost by a factor of ~ 83, this can be profitable at the current market price around 1 EUR.

Small safety margin

A factor of 80 might sound good at first glance but you need to consider that this factor can be composed by different smaller factors. If you for example

  • find GPU that is twice as fast, and
  • find a provider that only costs half the money, and
  • improve the implementation of the key generation by 100 %, and
  • expect a Lisk price of 10 EUR,

you get an improvement by the factor 2*2*2*10 = 80.

What’s next

As a user you need to make sure your accounts are initialized. This protects you and has the additional side effect that you contribute to keep stealing other uninitialized accounts unprofitable.

Additionally the size of Lisk addresses must increase, better sooner than later.

Source