Here at Lisk, we take security of our users and of the whole network very seriously. With the recent increase in the LSK token price and greater exposure for our project, it is more important than ever for our community members to stay educated about best security practices within the blockchain industry. Along with two minor patch releases, we’d like to take this blog post to remind you about how to best secure your account and stay safe ahead of the upcoming holiday season.

Basics about Lisk addresses

Every Lisk account consists of a private and a public key, commonly known as Public Key Infrastructure (PKI). The private key is being derived from the passphrase generated during the account creation process. The public key is then generated from the private key, which in turn is used to create a Lisk address.

This is what the process looks like:

Passphrase > Private key > Public key > Lisk address

Below you will find format examples of these different strings.

A passphrase looks like:

File name
Copy
1person nothing test smoke hundred entry 
2flush capital episode rent budget october

A private key looks like:

File name
Copy
12cb689a302890ae3b135fc68b533e32c3c1f5fdee8bc1431db98f688d85ab4b37ad97456a355280d6e447fa3f4bd7e73895a9461f1764443708af37b91535e40

A public key looks like:

File name
Copy
17ad97456a355280d6e447fa3f4bd7e73895a9461f1764443708af37b91535e40

A Lisk address looks like:

File name
Copy
11710406280801763244L

Every Lisk address always has a corresponding public key infrastructure. For user convenience, Lisk addresses have a much smaller entropy than a private key. In fact, there are 264 possible addresses and 2256 possible private keys. To put the magnitude of this number in perspective, 2256 is approximately 1077, which is close to the estimated number of atoms in the observable universe, 1078, and much bigger than atoms of Earth, approximately 1050.

This results in multiple private keys leading to the same address, but different public keys. In the blockchain world, this event is called an ‘address collision’ and in theory could enable someone with a different private key to send funds from an existing address. This is an extremely rare event — even active mining of address collisions on average takes at least several months.

If the network is aware of the public key of an address this issue is solved because there are 2256 possible public keys, so theoretically the same amount as private keys. Address collisions in this scenario don’t matter anymore.

What does this mean for our users? In the case of zero outgoing transactions from a Lisk account, the network only knows the Lisk address of an account, not its public key. This way in extremely rare instances, address collision is possible.

Best practices

Therefore, it’s important to broadcast the correct public key to the network for any given Lisk address. This can be done by simply sending at least one transaction from a Lisk account.

The reason is; during the process of conducting one transaction from your account you have to use the passphrase, from which the private key and then the public key are derived. During that process the public key is also permanently cemented into the Lisk blockchain and associated with your Lisk address. This way even if a collision happens the network detects non-matching public keys, because a different private key will also lead to a different public key, and will refuse any outgoing transactions.

In order to ensure extra safety for all of our users, we have used this month’s patch releases to implement additional, in-software security notifications and measures. We also urge our community to familiarize themselves with our Security FAQ which includes all relevant information. Alternatively, please contact our Customer Support Team at support@lisk.io with any further questions you may have.

Lisk Nano 1.3.1

In an effort to further raise awareness of this basic blockchain procedure, we have added the Lisk account initialization feature to Lisk Nano 1.3.1. From this version onwards, account holders with no public key cemented in our blockchain will be reminded to activate a transaction to add this additional layer of security. Please download the latest Lisk Nano version and check if this applies to you.

Lisk Core 0.9.11

Another step towards better security is the release of Lisk Core 0.9.11 which is aimed at improving user safety, code quality and network reliability.

Our team has decided to fully discontinue Lisk UI, our user-interface submodule of the Lisk client, as a method of accessing your wallet or performing other network actions. This move comes as a safety measure in order to decrease the probability of our users stumbling on phishing sites claiming to be official Lisk portals. Another reason is that Lisk UI is not using Lisk-JS which adds an extra layer of security by signing transactions offline.

Our test suite is now being used in a more intuitive way, namely by using the NPM run command system. This shift will allow developers to choose the demanded test set to run by simply providing their directory, type or tag.

The test suite itself has greatly improved as well. The parts of code responsible for block verification and peers management are now strengthened. This will help to keep the network secure by ensuring code quality, functionality and product assurance.

In a push for smarter coding practices, we have also improved the quality of documentation for various modules. Improving the quality of documentation positively affects the code readability overall. This in turn streamlines team code writing by improving in-code team interaction and communication.

In our continued push to ensure network quality and interoperability, we have addressed the issue of unsigned multi-signature transactions propagation. Now, they will be broadcasted through the network and validated by the remaining nodes. This will help to streamline network efficiency, by boosting node interaction. As well as this, we have optimised the maintenance of unconfirmed state during sync operation, which helps to improve the overall performance of transactions processing.

Lastly, we have improved the fork recovery mechanism by introducing the element of time verification allowing nodes to reject blocks with unreasonable timestamp. This is another step towards greater stability of the network and shorter fork occurrences.

Fake websites/wallets disclaimer

Given the rise in popularity of Lisk, we are seeing an increased amount of fake websites and web wallets. Please be extremely careful where you type in your passphrase. We ask everyone to only use our official Lisk Nano wallet downloaded from our official website. Don’t trust any third party wallet providers and be careful not to accidentally visit phishing websites.

Please note: Given the decentralized nature of our blockchain, LiskHQ is not able to verify individual accounts, freeze wallets, retrieve passphrases, or issue refunds for victims of phishing websites.

Stay warm and secure out there! Happy holidays. :)

- The Lisk Foundation