5.1.0 Trusty Tyr Mandatory Upgrade

loki network coin wallet

Hey Everybody, 

Today marks the start of the mandatory upgrade period for the new Loki Core Trusty Tyr 5.1.0 release. Trusty Tyr adds a number of notable features to Loki Core, including: 

  • Fully enabled and enforced Service Node checkpointing 
  • Updated RPC Calls to reflect transaction checkpoint status
  • RandomXL stability updates
  • Extended Uptime credits to 48 hours from 24 hours 
  • Number of bug fixes for issues which caused Service Nodes to calculate incorrect winners for certain blocks
  • Increased uptime proof relaying robustness 
  • Fully Linear Staking requirement curve
  • “Export_transfers” is now available via RPC (see Lokidocs RPC documentation for more information).
  • Better integration with Loki Storage Server to enforce network reliability

We have set the hardfork height for block 385,824, ‬which is approximately 13 days away and should fall on  ~22nd of October 2019 UTC. 

If you’re running a Service Node, mining pool, or you’re full node operator, you will need to update to the new version of Loki Core to ensure that you stay on the correct chain. 

Non Service Node Operators 

For mining pools and (Non Service Node) full nodes, Loki binaries can be downloaded directly here: https://github.com/loki-project/loki/releases/tag/v5.1.0

Service Node Operators

Service Node operators running Loki Launcher should refer to this guide for updating: https://docs.loki.network/ServiceNodes/SNFullGuide/#updating-your-binaries

For those running Loki Service Nodes using the Debian releases, you can upgrade using this guide: https://docs.loki.network/ServiceNodes/DebianPackageGuide/#upgrading

As part of their update procedures, Service Node operators should also update their Loki Storage Server to the newly released Version 1.0.7. This should happen automatically if you follow the guides above. 

Thanks,  

Kee

Does Pulse Make the Rich Richer?

Loki Improvement Proposal: POS Scheme Pulse

Recently we released our fifth Loki Improvement Proposal in which we outlined a new Proof of Stake scheme, Pulse. If it’s to be implemented, Pulse would have Service Nodes produce blocks, order transactions, and secure the blockchain, rendering miners in the Loki ecosystem no longer necessary.

While we’re excited about the potential of Pulse, and the improvements it can bring to Loki’s suite of privacy tools, we’re aware it has raised some questions and concerns within the community. The main one being: “Won’t it Just Make the Rich Richer?”

Transitioning from Proof of Work to Proof of Stake

Let’s imagine Loki transitions from its current Proof of Work / Proof of Service hybrid consensus mechanism to Pulse (Proof of Stake). In this scenario, the Loki Network will be made up of two parties: Stakers and Non-Stakers. 

Stakers are those who are running a Service Node, either by themselves, or with others in a pool. They have enough $LOKI to do so.

Non-Stakers are those who aren’t running a Service Node, because they don’t have enough $LOKI to meet the staking threshold, or because they’re choosing to hold their $LOKI instead. 

Service Nodes

With Pulse, Service Nodes will create blocks in the Loki blockchain every two minutes, and receive a reward ($LOKI) for doing so. Ninety-five percent of that reward will go to the Service Node Staker (or Stakers, if it’s a pool), and the remaining five percent will go to the Loki Foundation.

In order to run a Service Node, Loki recommends you stake at least twenty-five percent of the full staking requirement. At the time of writing, that is roughly 5,200 $LOKI, which equates to about 1,400 USD. So Stakers – those that have enough (and choose) to stake the recommended amount of $LOKI – will increase their wealth through the accrual of rewards. 

Furthermore, each time a Service Node creates a block, the overall monetary supply of $LOKI increases. Just like in a traditional economy, assuming everything in the market stays constant, when the monetary supply increases, so does the inflation rate. And when the inflation rate goes up, the purchasing power of the currency goes down. This means everybody’s $LOKI buys a little less than it did before. This is an unfortunate (but not uncommon) side effect for those that hold (and don’t stake) currency. 

However, the inflation situation is the same with Proof of Work consensus mechanisms. When miners create blocks, they also receive rewards, which in turn increases the overall monetary supply and drives inflation up. 

One major difference between Proof of Work and Proof of Stake consensus mechanisms is the size of the barrier to entry. The initial investment (fixed cost) required to mine cryptocurrencies – specialised hardware, constant electricity, and a high-speed internet connection – is much higher than the cost of running a Service Node – which is essentially the cost of renting and maintaining a VPS. In essence, you need a lot more financial resources to be a miner, than to be a Staker. 

Of course, in reality everything in the market does not stay constant. The real-world market cap of $LOKI fluctuates, and if it increases, everyone’s purchasing power increases. Same goes the other way. Regardless, there still exists an inequality caused by the barriers to entry for mining or staking. However, a barrier to entry is necessary* in order to keep the Loki Network protected from malicious activities like Sybil Attacks. 

Low barrier of entry allows more people to benefit from POS

The lower barrier to entry for Service Node operators is why Pulse is an attractive prospect for Loki. It means more people have the opportunity to participate in the rewards-based ecosystem (especially when compared to Proof of Work). Ideally, it also means more Service Nodes are in operation on the Loki Network, making our privacy products better for all. So we think it’s a win-win.

We love that our community is engaged, and challenges us to be better, which is why we’ve endeavoured to answer this question. If you have more, please keep them coming on our various social media channels.

Testing Bounties

Service Node checkpointing is now being enforced on testnet v5.0.0. We really want to make sure everything is running smoothly, so are inviting you to do your best to break checkpointing on the testnet! 

As a reward for the hard-working testers out there who manage to find bugs in v5.0.0, we have put a bounty system together: https://github.com/loki-project/loki/releases

The total reward pool is 4000 $LOKI.

Bounty Guidelines:

  • Attacks should be performed on the Loki testnet, where the most recent checkpointing code has been activated. 
  • The goal of an attack should be to invalidate Service Node checkpointing. Functionally, this means you should be able to get an unmodified lokid node to sync or switch to any alternate chain that competes with a mainchain with more than 2 consecutive checkpoints.

Some attacks you might try to execute are:

  • Targeted attacks that prevent Service Nodes communicating during consensus. 
  • 51% attacks on the mining network. 
  • Joining a dishonest minority of Service Nodes – please remove these nodes from the network once you finish testing as others may be trying to use similar methods.
  • Constructing special transactions/blocks. 

The following attacks are out of the scope of this bounty program and will not be rewarded: 

  • Gaining more than 51% of the Service Nodes on the Service Node network (this would be prohibitively difficult on the mainnet). Note: The 20 Service Nodes operated by the Loki team on the Loki testnet represent the “Honest Majority”.
  • Blanket DDOS attacks are not considered in scope as they would be prohibitively difficult on the mainnet given the size of the Service Node network.

Bug Severity will be decided arbitrarily by the Loki team. High severity bugs will earn 50% of the total prize pool at the time your claim is approved. Medium severity bugs will earn 20%, and low severity bugs will earn 5%.

Happy Testing!

Weekly Dev Update #62

Hey Y’all, 

A small update this week as many of the Loki devs are attending conferences (I’m at Blockchain Week Berlin) or on holiday. Most of our work went into Loki Core and Lokinet releases, where we are successfully improving stability on both fronts. 

Loki Core


Lokinet

If you’re on our Discord you can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What’s going on this week with Lokinet:

We continued to focus on testing and fixing up various issues. Some major PRs have been added which have noticeably increased Lokinet connection and stability, however these changes have introduced a regression in network speed that we’re investigating. Next week we are focusing on solving the aforementioned issues, plus other general testing and fixes for an upcoming 0.5 release. The changelog for this past week is lighter than normal as Jeff was away for most of the week, but he’s back and at it now!

Changelog:

New/updated/pending PRs:


Loki Messenger for Mobile (iOS and Android)

What’s going on this week with Loki Messenger: 

We released the APK for Loki Messenger for Android which means Loki Messenger is now available on all major platforms! We will be working hard to iron out bugs and improve the user experience over the coming months.


Thanks,  

Kee 

Weekly Dev Update #61

Hey Y’all, 

This week we continued work on some key areas in Loki Messenger, including adding chat channel support for Android and iOS, and starting work on support for Loki Messenger across multiple devices. We also released an update to the Loki Storage Server which allows for the measuring of additional statistics, so we can continue to monitor the network and the success of the switch from testnet to mainnet for Loki Messenger. 

Loki Core

There’ll be a point release to Loki Core this week with a number of bug fixes that should increase Service Node stability. This is not a mandatory upgrade but is recommended for those running Service Nodes. 


Lokinet

If you’re on our Discord you can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What’s going on this week with Lokinet: 

Testing continues. We’ve identified a couple of issues related to existing sessions closing prematurely: we have a good idea where they are happening and are focusing on solving them.

Changelog:

New/updated/pending PRs:


Loki Messenger for Desktop 

Storage Server


Loki Messenger for Mobile (iOS and Android)

This week we released the APK for Loki Messenger for Android which means Loki Messenger is now available on all major platforms! We will be working hard to iron out bugs and improve the user experience of over the coming months.


Thanks,  

Kee 

Weekly Dev Update #59

Hey Y’all, 

This week we’ve mostly worked on bugs that were affecting Service Node operators as they transitioned from lokid 3.0.X to the 4.0.3 suite of Loki Service Node tools. We published a new release for the Loki Storage Server and Launcher, and we have also made good progress on transitioning Loki Messenger to the mainnet so it can take advantage of the ~550 Loki Storage Servers.

Loki Core


Lokinet

If you’re on our Discord you can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What’s going on this week with Lokinet: 

All of the pull requests for the next version are either merged, or reviewed and to be merged in the next day or so. We are spinning up a distributed “toy” network to test the stability and functionality of the codebase in anticipation of a public release sometime in the next week or two (testing dependent). We also have internally-working debian packages for various recent Debian and Ubuntu versions to allow easy installation of Lokinet on those systems, and plan to release these with the public release.

Changelog:

New/updated Pull Requests:


Loki Messenger Desktop 

Storage Server


Loki Launcher

What’s going on this week with Loki Launcher:

With the launch of the Hefty Heimdall hardfork, the Loki Storage Server is now active. This week, after tracking down a number of bug reports submitted in Telegram and Discord about unexpected crashes, we found the suspect behaviour and put in a work around into the 1.0.0 release of the launcher. We also added a couple of fixes as a few new eyes were on the code, and improved its accuracy of status and startup.

Changelog:

  • Fix Storage Server pipe that would lock up Storage Server
  • Fix Storage Server stderr handler typo
  • SIGHUP guard fix
  • Double check running pid
  • Use SIGTERM instead of SIGINT to stop processes
  • Handle socket write errors better
  • Test socket for connectivity in status
  • Clear stale pid and socket files
  • Move uncaught exception log into var_path
  • Make sure Storage Server is running before startup is successful
  • Change version for git checkouts to be the last committed revision

Loki Blocks Onion Explorer 

The Loki Block Explorer has been expanded to show a number of new things including checkpoints and their votes, and decommissioned or inactive nodes. 

Loki Messenger on Mobile (iOS and Android)

We are very close to an Android release of Loki Messenger, and are now testing it internally in the office.


Thanks,  

Kee 

Weekly Dev Update #58

Loki Network Development Update 58

Hey Y’all, 

The Loki 4.0.0 hardfork is fast approaching! It’s happening in approximately 24 hours, so if you haven’t upgraded your Service Node, Miner or Mining Pool, now is your chance. If you don’t update in time, you will be left on an alternate chain and won’t be able to talk to the majority of the network.

A full guide on how to update can be found here: https://loki.network/2019/07/12/hefty-heimdall-mandatory-upgrade-period/

Loki Core


Lokinet

If you’re on our Discord you might catch Jeff, the lead developer of LLARP, live streaming as he codes: https://www.twitch.tv/uguu25519.  He typically streams on Tuesday mornings, 9am-12pm Eastern (US) time.

What’s going on this week with Lokinet:

Lokinet is entering a feature freeze for an upcoming release to the public, and is undergoing heavy internal testing to see how the network performs under various types of load.  We don’t have a fixed release date yet — it will depend on how testing goes this week, but look for one soon. The last several weeks of development have fixed a myriad of issues, big and small, and we think Lokinet will be ready for public testing soon.  Hence, we have internally frozen the codebase* to not add anything new (just important fixes!) between now and the 0.5.0 release.

* There is one exception; see below.

Changelog:

New Pull Requests:


Loki Messenger Desktop 

Storage Server


Loki Blocks Onion Explorer 

The Loki block explorer has been expanded to show a number of new things including checkpoints and their votes, and decommissioned or inactive nodes. 


Messenger Mobile (iOS and Android)


Thanks,  

Kee 

Hefty Heimdall Changes for Service Node Operators

There are a number of new and changing rules being implemented in the Loki Hefty Heimdall hardfork, and Service Node operators should make sure they’re aware of the new requirements.

The following changes will be implemented on July 24 at block height 321,467.

Changing Rules:

  • We have relaxed the Service Node deregistration rules in order to be more lenient on Service Nodes, particularly those that have previously demonstrated quality performance. 

New Rules

  • All Service Nodes must now run the Loki Storage Server to receive rewards.
  • All Service Nodes must now have an accessible Public IP address and must open ports for the Loki Storage Server.
  • There is now a penalty for Service Nodes that send their uptime proofs from different IP addresses.

More Detail:

Relaxed Deregistration: 

After reviewing feedback from Service Node operators on Discord and Github over the past 6 months, the Loki team proposed a number of relaxations (included in Hefty Heimdall) with regard to how Service Nodes are deregistered when they fail to meet the expected requirements. 

A few basic changes were made to implement the new system, including the introduction of a credit scheme and decommission/recommission transactions. The basic scheme is detailed below:

  • Each Service Node starts with 2 hours of credit.
  • Each Service Node earns 0.8 hours of credit per day of uninterrupted operation up to a maximum of 24 hours.
  • If a Service Node has been assessed to be no longer meeting the standards of the network (for example, not submitting uptime proofs) the quorum looks to see if they have any credit.
  • If the Service Node has 2 hours or more in credit, it will be decommissioned (instead of deregistered) for the amount of time it has in credit.
  • When a Service Node is decommissioned, its funds are not locked for 30 days but it is removed from the rewards pool and cannot participate in normal network functions.
  • If the Service Node starts sending uptime proofs again during the decommission period, the current quorum will detect this and submit a recommission transaction which will reset the Service Node’s credit balance to zero, and insert the decommissioned Service Node back to the bottom of the rewards list.
  • If, during the decommission period, the Service Node’s credit runs out before it can successfully submit an uptime proof, it will be deregistered.

TL;DR Service Nodes now have a longer grace period which grows the longer your Service Node is up and performing well. Service Nodes that have been running without interruption for 30 days will now have 24 hours where they can be offline before they are deregistered and your funds are locked for 30 days.

Read the full details of the relaxed deregistration rules here: https://lokidocs.com/ServiceNodes/DeregistrationRules/


Loki Storage Server:

The Loki Storage Server is an application that exposes a public endpoint for Loki Messenger users to be able to store and retrieve messages on your Service Node. It is a necessary requirement for Loki Messenger.

Hefty Heimdall versions of lokid running in Service Node mode will look for a running Loki Storage Server on your machine. If lokid does not find a running Storage Server, it will refuse to start. Lokid will also periodically check to see if the Loki Storage Server is still running – if it isn’t, lokid will stop broadcasting uptime proofs.  

You can easily manage lokid and the Loki Storage Server with the Loki Launcher, which sets up the required utilities. If you are an experienced system administrator, you can manage these utilities yourself – though we recommend you test your setup on testnet.

TL;DR You need to run the Loki Storage Server alongside lokid. Loki Launcher will do this automatically, otherwise binaries can be found here: https://github.com/loki-project/loki-storage-server


Public IP address and Open Ports:

All Service Nodes must now have a public IP address and open ports for lokid P2P and the Loki Storage Server. The default port for mainnet lokid P2P is 22022, and for the Loki Storage Server the default port is 23023.

If you are currently running your Service Node without any open ports or behind NAT, you will need to look into creating port forwarding rules in your router, and/or opening these ports in your firewall. If you are running a custom setup, you can change your default ports for Loki Storage Server and lokid P2P communications.

TL;DR You need to open ports in your firewall or router and have a public IP address.


IP Address Change Penalty: 

We understand that many Service Node operators in the community are running backup servers which submit uptime proofs for their Service Node. Most operators have set up these backup servers by running another lokid with the –service-node flags on a seperate IP, but with the same Service Node key as their primary Service Node.

This setup creates a race between the two Service Nodes, which compete to send out the first uptime proof. Depending on the precise timing of when the separate lokids submit their uptime proofs, the relationship between the two Service Nodes can change. You may find one is master for a while, and then it switches. You may find the two Services Nodes swap on every announcement. 

This race condition will be a problem in Hefty Heimdall because of the inclusion of the Service Node IP address in each uptime proof. Every time the server sending the uptime proof “wins”, it changes the IP on which the network tries to reach the Service Node’s Storage Server, and of course, the backup won’t have the same messages stored as the primary server.

Without modifying the Storage Server code to create a syncing channel between a master and backup Service Node, this problem is difficult to solve. Instead, the Loki team has implemented a punishment for Service Nodes that submit uptime proofs from different IP addresses. Each time your IP address changes, you will be dropped to the bottom of the rewards list losing your previous position. 

From talking to Service Node operators, we found that one of the most common reasons they ran Service Node backups was because they didn’t have enough time to respond to outages on their Service Nodes. By addressing the core issue – which was the lack of forgiveness in the deregistration rules – we think there will be far fewer people wanting to run backup Service Nodes. 

Although this change does not explicitly prevent the running of backup Service Nodes, Service Node operators who choose to run backup servers should ensure that they only send uptime proofs from the backup Service Node when it’s clear that the master server is actually down, rather than just setting up two Service Nodes and having both submit proofs at competing times.

TL;DR Running two Loki Service Nodes with the same SN key on two machines with different IP addresses will likely lead to your Service Node being dropped to the bottom of the rewards list regularly.


We are really excited to see these changes go live on mainnet on July 24. The Loki team and Loki community are always looking for ways to improve the stability and usefulness of the Service Node network, while maintaining a simple user experience so the Service Node network can continue to grow.  

Hefty Heimdall Mandatory Upgrade Period

Hey Everyone!

It’s hardfork time again! The Hefty Heimdall upgrade period has begun, and that means everyone has approximately 12 days to upgrade to the latest versions of the Loki software before the hardfork on July 24. 

Below is a guide on how to prepare for the hardfork for each type of user in the Loki ecosystem: 

Wallet users

You guys don’t need to do anything yet. Over the course of the next two weeks we will be pushing updates to the Loki Desktop, iOS and Android wallets to upgrade them to the latest versions of the Loki software. 

Once these updates are released we encourage everyone to upgrade their wallet to the latest version, otherwise you will no longer be able to send transactions on the correct chain. 

Service Node Operators 

If you are using the Loki Launcher you can update to the latest binaries by using these commands: https://lokidocs.com/ServiceNodes/SNFullGuide/#updating-your-binaries.

For those more experienced with system administration and who aren’t using the Loki Launcher, you can upgrade your lokid binaries manually. Please note that you will also need to update to the latest Loki Storage Server. We have compiled a guide here: https://lokidocs.com/ServiceNodes/SNFullGuideLegacy/.

Pools

Pools do not need to enable RandomXL support until the hardfork on July 24 or at block 321467, however they should make sure they are ready to switch when the fork happens, and can look at these two reference implementations for changes they may need to introduce to their software.

A cryptonote-node-JS reference implementation pool which supports the new RandomXL Loki hashing algorithm can be found here: https://github.com/jagerman/cryptonote-nodejs-pool/tree/randomx.

A reference implementation for node-cryptonight-hashing can be found here: https://github.com/jagerman/node-cryptonight-hashing/commits/master.

A list of the full Loki changes to RandomX can be found here: https://github.com/loki-project/loki-randomXL.

Miners 

Miners can continue to mine Loki using CN-Turtle, however on the July 24 at block height 321467 they will need to switch to using RandomXL which is supported in a mining software called Xmrig on their “evo” branch: https://github.com/xmrig/xmrig/tree/evo. Xmrig have not yet published release binaries with RandomXL support, and if they haven’t published release binaries by the hardfork, we willl build and distribute mining binaries from a fork of their repository. 

Exchanges 

Exchanges will need to update their lokid and wallet with the latest CLI binaries found here: https://github.com/loki-project/loki/releases/latest. We will reach out to exchanges individually with any additional instructions if required.

Happy Forking!

Loki Launcher

The Loki Launcher has just been released, and we STRONGLY RECOMMEND that all Service Nodes update.

The Loki Launcher has a number of components which will improve the user experience for Service Node operators and reduce the chance of being deregistered. These include managing the Loki Storage Server, lokid, and in the future, Lokinet – which will startup and restart these applications if they crash.

User Experience Improvements

Easy access to the lokid console from Loki Launcher

Lokid is now handled by the Loki Launcher. Running the command ‘loki-launcher client’ will allow you to run commands compatible with the Loki daemon, such as ‘prepare_registration’, ‘print_sn_key’, e.t.c.

Unified config file for Loki Storage Server, lokid and Lokinet.

You can now use one unified config file to manage all aspects of the Loki Service Node software!

The Loki Launcher uses the newly unified config file to manage the Loki Storage Server, lokid and Lokinet properties! It also includes validation on startup to alert you to any errors in the config file.

Easier Updates

It’s now much easier to update your Service Node!

We’ve added commands to the Loki Launcher to make downloading the latest Loki binaries as simple as running, ‘loki-launcher download-binaries’.

Service Node Bench Utility

Running the SNbench utility will test your node and advise you on whether your setup meets the requirements for each release.

How to add Loki Launcher to your Service Node:

To update your Service Node to use the Loki Launcher, please run through the following guide:

https://lokidocs.com/ServiceNodes/UpdateGuide/

How to set up a new Service Node with the Loki Launcher:

To set up a new Service Node using the Loki Launcher, please run through the following guide:

https://lokidocs.com/ServiceNodes/SNFullGuide/