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.  

How To Vote For Loki on Binance DEX

Hey Loki Gang!

You’ve probably heard the awesome news! We have successfully issued B-Loki token on Binance Chain and have submitted our listing proposal to Binance DEX! 

The next step is a voting process involving the Binance Chain validators. 

We need your help!  Aside from the Loki tech, the validators will also be looking at our community activity and engagement on the Binance proposal post — specifically, the number of upvotes, replies, and views. Show your support and enthusiasm for the Loki Project by engaging in the Binance community!

Help us out by following these steps:

Step 1: Go to https://community.binance.org/

Step 2: Log in or register if you do not have an account.

Step 3: Go to https://community.binance.org/topic/380/proposal-to-list-loki-loki-on-binance-dex

Step 4: Scroll down to the bottom of the post and click the upvote button. 

Step 5: Reply to the thread to post a comment.

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/

Your Service Node and Hefty Heimdall

Hefty Heimdall will be a big release for Service Nodes and will see them start to perform meaningful work in storing messages. We want to be clear about the level of service the Loki Service Node network will be enforcing, and we hope that by outlining these changes, we can prevent Service Nodes from deregistering when we hardfork to Hefty Heimdall on July 24.

Here are some guidelines for Service Node operators on what to expect in the coming months.

Recommended Changes

We will be releasing the next version of the Loki Launcher before the hardfork – and we STRONGLY RECOMMEND that all Service Nodes update.

The Loki Launcher will have a number of components which will improve the user experience for Service Node operators and reduce the chances of being deregistered, including:

  • Managing the Loki storage server, lokid, and in the future Lokinet – which will startup and restart these applications if they crash.
  • Easy access to the lokid console for preparing Service Node registrations and running other commands.
  • One unified config file to manage all parts of the Loki Service Node software suite, which includes validation on startup to make sure everything makes sense.
  • Adding an installer which will grab the latest versions of Loki binaries for new Service Nodes.
  • Adding the SNbench utility which will test your node and give you a recommendation on whether your setup meets the requirements for each release.

New Requirements

The Hefty Heimdall release corresponds with the first version of the Loki Messenger. This means that all Service Nodes will be required to have the following software/hardware:

  • Running lokid with downloaded blockchain
  • Loki storage server
  • 15 GB of available space for blockchain storage (including any blockchain you have synced)
  • 3.5 GB available for message storage for Loki Messenger storage server
  • A public IP address and specified open ports

Two client side checks have been enabled: a test which prevents the startup of lokid if a specified Public IP address and open port number are uncontactable, and an ongoing client side test that prevents the broadcast of uptime proofs if at any point during operation the local Loki message storage server fails/shuts down.

Decentralised Testing

Hefty Heimdall will also enable a number of decentralised tests which will be run on Service Nodes by other Service Nodes. We will be enabling both blockchain storage and message storage tests. This means your node will be tested at random intervals by other Service Nodes to ensure it’s holding both a full copy of the blockchain, and storing all of the messages required by its swarm.

Initially, these tests will not be enforced through deregistration. But after collecting data on the effectiveness of the system, we will enable deregistration so that malicious nodes can be removed from the network.

Infinite Staking Overview

Outline For Existing Service Node Participants and Operators

Infinite Staking is an incremental upgrade on the existing staking process that is currently available on the Loki network (currently active in Hardfork 10: Bulletproofs, introduced in Hardfork 9: Service Nodes). With Infinite Staking, Service Nodes do not expire and funds remain locked until a contributor or operator explicitly requests the Service Node to unlock the funds.

Since Infinite Staking is an incremental upgrade, most of the steps necessary to register and participate in a Service Node remain the same. A quick overview for the new staking process is summarised for quick grokking. (Yes, grokking is a word. Google it.)

Updated Staking Process and Commands

Operators

Operators will still use the following commands when setting up a Service Node. The commands are as follows:

  • prepare_registration in the daemon that is running in --service-node mode.
  • register_service_node with the command returned by the daemon. Auto staking is no longer an option.

Contributors

Two new commands have been added to stop your Service Node from staking, and both the contributor and operator can execute these commands:

  • stake <service node key> to contribute to the node. Auto staking is no longer an option.

Operators & Contributors (When Service Node Active)

Two new commands have been added to stop your Service Node from staking, both the contributor and operator can execute these commands:

  • (Optional) print_locked_stakes to preview all the current wallet’s transactions that are locked in a Service Node or blacklisted on the network.
  • request_stake_unlock <service node key> to request to unlock the stake in 15 days (10800 blocks).

Unlocking Stakes & Deregistration

Service Nodes will continually receive block rewards indefinitely until a stake is unlocked or the Service Node becomes deregistered. Unlocking is available via the request_stake_unlock <service node key> in the command line wallet. Once the unlock is requested and the request is included in a block in the blockchain, the Service Node will then expire in 15 days (10800 blocks) and the funds will become unlocked after expiry.

In pooled nodes, any contributor that requests the stake to unlock will schedule the Service Node for expiration. All locked stakes in that Service Node will be unlocked in 15 days (10800 blocks). Once the unlock is requested, this process can not be undone or prolonged. Service Node participants will continue receiving rewards until expiration.

Under the new system, deregistrations can be issued at any point during the active lifecycle of the Service Node. This is inclusive of the time period during which the Service Node is scheduled for expiry. Getting deregistered removes your Service Node from the network and your stakes are placed into a list of blacklisted transactions. Blacklisted transactions are locked and unspendable for 30 days (21600 blocks) from the block in which the Service Node was deregistered.

Receiving a deregistration after participants have already requested the stake to unlock overrides the 15 day (10800 blocks) unlock time, and resets the unlock time to 30 days (21600 blocks).

Minimum Contribution Rules

Infinite Staking introduces new limitations on the number of transactions that can be contributed to a Service Node, changing the minimum contribution rules for participating in the Service Node.

Service Nodes accept at most 4 contributions, meaning the minimum contribution to a Service Node becomes:

Contribution

In a pooled Service Node with reserved spots, the Minimum Contribution must be either the Reserved Amount or the Contribution determined by the above equation, whichever is larger.

Min Contribution

A simplistic example being, if the staking requirement is 24,000 Loki then if,

  • Operator contributes 50% of the requirement (12,000 Loki)
  • The next contributor must contribute at least (⅓ * 12,000) Loki i.e. 4000 Loki to become a participant.
  • If this contributor had reserved a spot for more than 4000 Loki, their Minimum Contribution would be that amount.

There are rules in the client software in place to stop users from irreversibly funding a Service Node into an invalid state.

Staking Changes

Users are no longer allowed to stake on behalf of another participant in the Service Node. All contributions for a participant must come from the same wallet address as the one specified in the Service Node.

Developer API Changes

get_service_nodes

Updated/newly added fields:

  • requested_unlock_height – The height at which the stakes will unlock and the Service Node will expire.
  • contributors
    • locked_contributions – An array of each contribution from the contributor that is locked.
      • key_image – A string representation of the locked key image (stake).
      • key_image_pub_key – A string representation of the public key component of a key image.
      • amount – The amount of Loki locked in this contribution.

get_service_node_blacklisted_key_images

Retrieve a list of blacklisted transactions from deregistered Service Nodes on the network.

  • blacklist – An array of each blacklisted transaction from deregistered Service Nodes
    • key_image – A string representation of the blacklisted key image (stake).
    • unlock_height – The height at which the stake can be spent again.

What Are SNApps?

We wanted to write an article that provides a clearer explanation of what Loki SNApps are, how they work, and how you can get involved.

So what are SNApps? The simplest way to describe it would be – SNApps are private websites or web services. That might not sound very impressive, but let’s consider what usually happens when you visit a website.

Imagine you want to view a page on Wikipedia. Traditionally you would type “wikipedia.com” into your internet browser, the browser then connects to a DNS server and resolves the name of the website “wikipedia.com” into an IP address (103.102.166.224). This IP address is your point of contact when you request information from Wikipedia.

If that’s the traditional way the internet works, what’s wrong with it? Why are SNApps better?

The real issue here is that everything on the internet has an IP address, and these addresses are unique identifiers (similar to your street address) which can give away a lot about someone’s identity. As we said before, when you connect to a website you need to know the IP address of that website. Usually you never actually see the IP address of a website because the internet uses a system called DNS which matches the name you type, “wikipedia.com” for example, to its IP address. Suffice to say, most of the internet is just a collection of IP addresses communicating with other IP addresses.

Internet Service Providers and Hosting providers have lists which assign real-world identities to every website IP address. This means that every website you visit has an owner and an associated real-world identity. Recently we have started to see a spate of censorship at the ISP and host level. An ISP might be pressured by an activist group or legally compelled by a government to alter or block their DNS records or revoke hosting services. We have seen this happen extensively over the last few years with a number of services like Wikileaks, [1] Gab, [2] Lifesite, [3] and The Pirate Bay. [4]

How do SNApps fix these issues?
  1. SNApps never expose the IP address of the Server that hosts the website, and additionally, all traffic between the user and the website is encrypted. All the hosting provider can see is encrypted traffic moving to and from the Server. State level actors and activists cannot pressure the hosting providers, because they don’t know what the IP address of the Server is either, which means that nobody except the operator can know where SNApp is hosted.
  2. SNApps do not use traditional DNS servers, making the censorship of naming servers impossible. Instead, Loki uses public private keypairs which create addresses like http://i4irznec3pkdh7gay6xsmkyyqag4q8643kut739by17cuiwdnxqo.loki. We are also considering integrating a naming service on the blockchain to create an immutable human readable DNS records. This will be called the Loki Naming System (LNS).
Why are SNApps better than Dapps?
  1. They are free;

Unlike many Dapps or Dapp platforms, SNApps are completely free to use. This greatly reduces the barrier to entry for users who lack the ability, or who want to use the system without needing to engage in the cryptocurrency aspect of the project. It also makes Lokinet a much more realistic competitor to already established and free mixnets like Tor and I2P.

  1. SNApps are easy to code and launch;

SNApps are not written in a special programming language that developers need to learn before they can launch their own SNApp. SNApps can be written in any programming language- as long as you can serve content to the internet, Lokinet can serve it too. This means existing applications don’t need to be modified to work in special ways to work with Lokinet. We will be releasing a guide soon with instructions on how to get your first SNApp up and running.

  1. SNApps don’t interact with the blockchain;

Dapps usually require their state execution to happen consistently over all of the nodes that process the blockchain, which means in order to alter a Dapp you usually need to engage in an onchain transaction. This can be slow, inconvenient and costly depending on a number of factors outside of the Dapp’s control. SNApps never interact with the blockchain directly and do not require any onchain transactions in order to provide services to their users.

  1. SNApps are not decentralised.

Because most Dapps make use of the blockchain when making meaningful state changes, they lack a single point of failure. SNApps do not have this same protection. Although SNApps are hosted inside a decentralised network of Service Nodes, they are centralised servers run by an operator and are designed to protect against external censorship pressure rather than internal failures.

The TL;DR

SNApps are like private websites where no one can work out the IP address of the operator. They don’t require any special programming languages, and anyone can set up a SNApp. It’s just like hosting a website on the internet, except all data traffic flows through Lokinet first.


References:

[1] “WikiLeaks website pulled by Amazon after US political … – The Guardian.” 1 Dec. 2010, https://www.theguardian.com/media/2010/dec/01/wikileaks-website-cables-servers-amazon. Accessed 5 Nov. 2018.

[2] “Gab loses hosting provider following Pittsburgh mass … – Engadget.” 28 Oct. 2018, https://www.engadget.com/2018/10/28/gab-loses-hosting-provider/. Accessed 5 Nov. 2018.

[3] “LISTEN: Todd Starnes interviews Steve Jalsevac on LifeSite web ….” 3 Nov. 2018, https://www.lifesitenews.com/news/listen-todd-starnes-interviews-steve-jalsevac-on-lifesite-web-hosting-. Accessed 5 Nov. 2018.

[4] “The Pirate Bay shutdown: the whole story (so far) – Engadget.” 16 Dec. 2014, https://www.engadget.com/2014/12/16/pirate-bay-shutdown-explainer/. Accessed 5 Nov. 2018.

The State of Private Messaging Applications

Over the course of this article I will analyse three key elements which all messenger applications must consider.  

  • Metadata: Any information, aside from the actual message, which is transmitted and can be exposed to third parties.
  • Encryption: How your messages are encoded to obfuscate their content.
  • Scalability and Attacks: How well the messenger responds to increases in usage and if there are any known attack vectors or exploits to the specific system.

I will also explore how centralisation/decentralisation can affect the privacy and security of each element. Centralisation, in this context, refers to whether the messenger architecture has a group of permissioned non federated servers, which are the sole servers and can hold or relay messages.

Through these lenses, I will examine the most popular messaging services which claim to be encrypted, or private, along with Loki messenger.

  • Centralised server models, like Telegram, Facebook Messenger, Signal, Whatsapp or XMPP (Federated)
  • Decentralised messengers like Tox and Bitmessage
  • Mixnet based messengers like Loki Messenger

Metadata

Think about it like this: if I send a letter by post to my friend, I will put their full name and address on the front, and my full name and address on the back so that I can receive a reply. Although no one can see inside my letter and read its contents, the postal service now has a good idea of who I am, who I sent my letter to, and what time I sent my letter. This information is typically referred to as metadata.  

Here’s a great quote from Kurt Opsahl from the EFF, writing on the topic of government metadata collection:

“They know you rang a phone sex service at 2:24 am and spoke for 18 minutes. But they don’t know what you talked about.
They know you called the suicide prevention hotline from the Golden Gate Bridge. But the topic of the call remains a secret.
They know you spoke with a HIV testing service, then your doctor, then your health insurance company in the same hour. But they don’t know what was discussed.” [1]

And Michael Hayden (former Director of the NSA)

We kill people based on metadata” [2]

Now how does this relate to private messaging?

CENTRALISED SERVICES

When you use a service like Whatsapp, Telegram or Signal, you connect directly to a server owned by one of these companies. When you send a message, you must somehow tell that centralised server who you are and who the recipient of your message is. You will also typically give up your IP address and your phone number, depending on the client you use. 
These centralised services have the capacity to collect metadata. Some providers, like Whatsapp and Facebook Messenger, openly admit to collecting and storing their user’s metadata. [3][4] Some services, like Signal and Telegram, have policies against storage of user metadata. [5][6] These policies require a significant amount of trust, however it has been shown countless times that as soon as trust is involved in user privacy, companies and governments will violate that trust. Look no further than popular ‘private’ email service, Hushmail, which was compelled legally to hand over users’ private information to governments. [7]The only solution to this problem is for these centralised, privacy centric services to never have the ability to collect sensitive user data.
(A note on XMPP)
Messengers based on XMPP are slightly different in their construction since they operate on a federated model. [8] This means that only a protocol is provided, users/providers can operate their own servers (which means that metadata is held by individual servers), and users have more choice in the parties they trust to store their data. This is a step in the right direction, though XMPP servers can still collect this data and have the ability to transmit it to third parties.

DECENTRALISED SERVICES

So how do the decentralised models deal with metadata? Well, there’s a few out there and they each approach metadata in a different way. 
Services like Tox, and other P2P messengers, by their very nature do not require metadata to be stored on any centralised server, since messages are routed directly to their participants rather than traveling through servers or hopping through a mixing network. On the surface this can sound great, but really it gives more power to ISPs. Although the packets of data may be encrypted, ISPs can see the IP address of the person you are messaging, and if they can resolve the IP address of the recipient then they are able to very accurately ascertain information on who you messaged and at what time. This is something centralised services (Telegram, Signal, and WhatsApp) prevent. If encrypted properly, your ISP only knows you are communicating with a messaging service server, and never knows the actual IP address of your recipient.
Bitmessage is one of the other fully decentralised messaging models and might be the next best for hiding message metadata. Bitmessage operates a floodfill network, meaning that messages aren’t directed towards specific participants like they are in most other networks. In Bitmessage, every user is distributed a copy of every encrypted message. Once a user receives a message, they must attempt to decrypt the payload. This means when I want to send a message, I “flood” the message to the peers I know, who then flood the message to the peers they know. This technique makes it difficult to ascertain whether a user is merely relaying a message, or if they are the source of the message. It is also imposible to ascertain whom the true recipient is, as all clients receive all messages and attempt to decrypt them. However, there are significant downsides to operating floodfill networks, such as the high bandwidth consumption and computational overhead of attempting to decrypt each message you receive.

LOKI MESSENGER  

Loki Messenger uses a number of different techniques for obfuscating metadata. In the context of the above, it is close to a mashup of Bitmessage and the Tor network. Like Bitmessage, Loki Messenger uses a decentralised set of nodes (Service Nodes) to relay messages to other users. Service Nodes are incentivised by the Loki blockchain and undertake the job of relaying messages to receive a small reward in cryptocurrency. 
To avoid metadata collection in both offline and online communications, a method called onion routing is employed. Onion routing in Loki positions a set of randomly selected (simplified) Service Nodes between the user and the destination of their message. As the message hops through each Service Node toward the final recipient, a layer of encryption is removed. This onion routing provides a number of protections:

  1. In a typical connection it is not possible for a single Service Node to gather enough metadata to form a connection between the sender and receiver of a message.
  2. Service Nodes are run by the community, and are globally distributed, which makes targeted legal action difficult.
  3. Service Nodes require a large amount of the Loki cryptocurrency, meaning they are staked into the system. Any actions which reduce the usefulness of the Loki Messenger will likely also reduce the value of the Loki cryptocurrency. This financially incentivises good behaviour.  

When a direct link between users cannot be established (the recipient is offline), Loki can also enable metadata protection for offline messages. This is done through a process called Swarm messaging. Each Loki Messenger user resides in a swarm of 10 Service Nodes. To contact another user, I can use their public key to figure out their swarm identity. My message is then sent to one of the ten nodes in their swarm, which will flood the message to the 9 others. When the user comes online, they will randomly query a node in their swarm. If that Service Node is holding a message for them, the user will download it directly from the Service Node.

Alice sends a message to Bob, Bob’s assigned Swarm is B, When Bob comes online, he queries a random node in his swarm and receives Alice’s message.


Encryption

Encryption refers to the methods each messenger uses to obfuscate the actual data inside a message. It’s easy to think of encryption as an on/off switch, but in actuality encryption is more like a volume knob – there are various features and implementation details which can marginally increase or decrease the security of the encryption in an app.

CENTRALISED SERVICES

There is significant variance when it comes to how Telegram, Whatsapp, Signal and Facebook Messenger deal with encryption – with some services providing strong, mandatory and auditable encryption, and others providing much weaker protections.

Signal
Signal is widely considered to be the best private messaging app when it comes to encryption standards as all Signal conversions are end to end encrypted by default. Signal uses the aptly named Signal protocol, which is developed as an open source project by Open Whisper Systems. [9][10] The Signal protocol has also undergone a security audit, and the results were generally positive finding only minor vulnerabilities. [11]
When correctly implemented, the Signal protocol maintains both Perfect Forward Secrecy (PFS) and Deniable Authentication (DA) in both synchronous (online) and asynchronous (offline) messages. Signal also applies encryption automatically to group chats. PFS is the ability for a protocol to tolerate the loss of a private key, without compromising the privacy of other encrypted messages that are not part of the exposed session key. DA is the ability for each party to prove to themselves that a message was signed by the other participant, but can also deny this fact to a third party. The combination of both properties allows for a messenger where messages are end to end encrypted, selective key loss is tolerable, and the origin of sent messages can never be proven to any party other than the desired recipient. These are very strong guarantees, which in essence emulate the properties of a real world conversation. Hence, a messenger with both these properties is typically referred to as an Off The Record (OTR) messenger.

WhatsApp
WhatsApp provides end to end encryption on all messages by default (including group chats), and it uses the Signal protocol for its encryption. WhatsApp also maintains a public partnership with Open Whisper Systems, who assisted them in their implementation of the Signal protocol. [12] However, WhatsApp is not open source, which means there must be a degree of trust that WhatsApp’s implementation of the Signal protocol doesn’t expose vulnerabilities.  

Telegram
Telegram provides end to end encryption, but only does so for ‘secret chats.’ These chats are opt in, which means usage is low. Telegram does not yet support encrypted group chats.
For the encryption of its secret chats, Telegram currently uses the MTProto 2.0 protocol, which provides both PFS and DA. The MTProto protocol is a unique protocol, and like Signal, MTProto 1.0 has undergone formal security audits. Though in the case of MTProto 1.0, it was found that MTProto:

“is not IND-CCA secure, since it is possible to turn any ciphertext into a different ciphertext that decrypts to the same message.” [13]

With researchers also mentioning that

“The take-home message (once again) is that well-studied, provably secure encryption schemes that achieve strong definitions of security (e.g., authenticated-encryption) are to be preferred to home-brewed encryption schemes.” [14]

Since this audit, Telegram has overhauled its MTProto protocol and released version 2.0, which addresses many of the concerns that were raised in the independent security audits. [15] However many have lost trust in MTProto’s security guarantees based on the aforementioned attacks.

Facebook Messenger
Facebook Messenger provides two person end to end encrypted chats, but like Telegram, this encryption is only offered in ‘secret conversations’ and are opt in, meaning that the majority of users are left unprotected. For encryption, Facebook uses the Signal protocol, similar to WhatsApp (owned by Facebook), and is not open source meaning it is difficult for users to verify Facebook’s claims beyond assurances from Open Whisper Systems that the “integration was done appropriately.” [16]

DECENTRALISED SERVICES

Tox 
Tox provides end to end encryption by default on all chats (including group chats). Tox clients all implement the Tox protocol, which uses libsodiums crypto_box implementation. Tox provides PFS and DA for all messages (other than friend requests), however Tox does not support the sending of offline messages. [17]Tox has not undergone a security audit and has come under less cryptographic scrutiny, compared to centralised messengers, due to its smaller user base.

Bitmessage 
Bitmessage’s encryption is the most basic of the available decentralised messengers. This is mainly due to its asynchronous (offline) operation. Bitmessage encrypts only for longterm public key/private key pairs, meaning that it does not maintain PFS or DA. Bitmessage has not undergone a formal security audit, though community members expressed concern around some of the design decisions, which led to updated designs being released. [18]
XMPP 
Since XMPP is simply a protocol, it does not enforce any type of message encryption. Though there are a number of plugins for XMPP servers and clients to enable OTR messaging, like Pidgin’s OTR, and OMEMO extensions. [19]

LOKI MESSENGER

Loki Messenger is a fork of the Signal messenger, which means Loki Messenger fully implements the Signal protocol and maintains all the properties of OTR. All Loki Messenger code is open source, allowing users and auditors to ensure the viability of our implementation. [20] There are a number of differences between Loki Messenger and Signal messenger, though encryption wise the only major difference is the storage of pre keys, which in the case of Loki Messenger does not occur on a set of centralised servers, but as the result of prekeys being passed as extra data in message payloads.


Scalability and Attacks

Although there are effective methods for relaying messages across infrastructure that is being passively surveilled, these methods often present a clear trade-off to the end user or relay operators; an increase in bandwidth, or processing power for a increase in privacy. In addition, we should consider specific attacks that can be effective against both centralised and decentralised architectures.

CENTRALISED SERVICES

Established centralised messaging services like Signal, Telegram, and WhatsApp all have frameworks which enable them to scale with their users. Because they make no overt attempt to obfuscate metadata on a protocol level, their servers can simply relay messages from the source directly to the destination – this level of activity has low overheads. Centralised server models also have an easier time dealing with spam, since they can (and do) impose identity thresholds. These thresholds commonly require a user to sign up to their service using a valid mobile phone number. This limits the number of fake accounts a malicious actor can create.  
However, this type of centralisation can also present significant problems. Primarily, these services become centralised points of data collection, meaning they can expose themselves to requests from law enforcement or face legal action for activity that is occurring on their platforms. It also creates a honeypot for hackers seeking to obtain sensitive information. Additionally, most of these messengers are free to use, which means they need alternative means to pay for the infrastructure costs and staff. In order to create a viable business model, these businesses often attempt to montiese their user base by selling user data to advertisers.

DECENTRALISED SERVICES

Decentralised services primarily suffer attacks related to their inability to associate a physical identity with each one of their virtual users. This makes many decentralised models vulnerable to Sybil attacks, which can manifest as denial of service attacks or attacks that are used to passively surveil the network. 
In particular services, like Bitmessage, which maintain no concept of a trusted authority, an attacker can generally operate a large portion of the client architecture and pretend to be many legitimate users. In this instance, the attacker could attempt to flood a large number of messages into the system inundating its network. Bitmessage has provided a solution to this through a small proof of work which is generated for each message sent, making it prohibitively costly for an attacker to spam thousands of messages using numerous fake identities.
A separate kind of Sybil attack can target network routing architecture. As there is a relatively low cost to running this architecture, operating a majority of the routers in the network can enable passive temporal analysis. In Tox, this can lead to flooding the DHT (a distributed table which holds the state of the network) with malicious nodes which can then segment users, cause denial of service to the ‘real’ Tox network, or even errode the effectiveness of the onion routing that Tox uses to update its DHT. [21][22]  

LOKI MESSENGER

Loki introduces proof-of-work (PoW) on messages that are stored offline. Depending on the Time To Live (TTL) on the message, the difficulty of the PoW is adujsted to be easier or more difficult. For messages that do not require storage, there is no PoW needed as the overhead of processing these messages on Service Nodes is relatively low. 
Loki Messenger is able to reduce the impact of Sybil attacks on the routing architecture by requiring that each Service Node lock a large amount of Loki in a special time-locked transaction. This creates an inherent market-based Sybil resistance, making it prohibitively expensive for any single actor to own a large enough number of nodes to perform effective temporal analysis. [23]
Additionally, requiring that each Service Node stake an amount of Loki makes enforcement of good behaviour much easier. If a Service Node is acting poorly, then their stake will remain frozen and they will not receive any rewards for their staking period. This negative consequence (loss of opportunity cost) constitutes a programmatically self-policed punishment system which is run by the Service Nodes themselves in a system called ‘swarm flagging.’ [24]


Summary

The messenger landscape is full of emerging and established projects. It is important for consumers to critically analyse each messenger against key metadata, encryption, and scalability/attack resistant criteria. Although some messengers may provide strong encryption, they may not protect users’ metadata. As data breaches on centralised services continue, consumers are calling for more privacy centric applications. As the decentralised ecosystem grows, centralised services like WhatsApp, Signal and Telegram will have to compete against decentralised or federated alternatives. Ultimately, the service which maintains the highest privacy and best user experience is likely to be the winner of this battle.


REFERENCES

[1] “Why Metadata Matters | Electronic Frontier Foundation.” 7 Jun. 2013, https://www.eff.org/deeplinks/2013/06/why-metadata-matters. Accessed 10 Sep. 2018.
[2] “Former NSA boss: “We kill people based on metadata”” https://youtu.be/UdQiz0Vavmc?t=27s  Accessed 10 Sep. 2018.
[3] “WhatsApp security and role of metadata in preserving privacy, https://arxiv.org/ftp/arxiv/papers/1701/1701.06817.pdf. Accessed 5 Jul. 2018.
[4] “Facebook scraped call, text message data for years … – Ars Technica.” 24 Mar. 2018, https://arstechnica.com/information-technology/2018/03/facebook-scraped-call-text-message-data-for-years-from-android-phones/. Accessed 5 Jul. 2018.
[5] “Battle of the Secure Messaging Apps: How Signal Beats WhatsApp.” https://theintercept.com/2016/06/22/battle-of-the-secure-messaging-apps-how-signal-beats-whatsapp/. Accessed 10 Sep. 2018.
[6] “Telegram Privacy Policy – Telegram Messenger.” https://telegram.org/privacy. Accessed 10 Sep. 2018.
[7] “Hushmail warns users over law enforcement backdoor • The Register.” 20 Nov. 2007, https://www.theregister.co.uk/2007/11/20/hushmail_update/. Accessed 10 Sep. 2018.
[8] “XMPP | XMPP Main.” https://xmpp.org/. Accessed 11 Sep. 2018.
[9] “GitHub – signalapp/libsignal-protocol-c: Signal Protocol C Library.” https://github.com/signalapp/libsignal-protocol-c. Accessed 11 Sep. 2018.
[10] “Open Whisper Systems – Wikipedia.” https://en.wikipedia.org/wiki/Open_Whisper_Systems. Accessed 11 Sep. 2018.
[11] “A Formal Security Analysis of the Signal Messaging Protocol.” 27 Oct. 2016, https://eprint.iacr.org/2016/1013.pdf. Accessed 11 Sep. 2018.
[12] “Signal >> Blog >> Open Whisper Systems partners with WhatsApp to ….” 18 Nov. 2014, https://signal.org/blog/whatsapp/. Accessed 12 Sep. 2018.
[13] “On the CCA (in)security of MTProto – Cryptology ePrint Archive.” https://eprint.iacr.org/2015/1177.pdf. Accessed 12 Sep. 2018.
[14] “On the CCA (in)security of MTProto – Cryptology ePrint Archive.” https://eprint.iacr.org/2015/1177.pdf. Accessed 12 Sep. 2018.
[15] “MTProto Mobile Protocol – Telegram APIs.” https://core.telegram.org/mtproto. Accessed 12 Sep. 2018.
[16] “Signal >> Blog >> Facebook Messenger deploys Signal Protocol for ….” 8 Jul. 2016, https://signal.org/blog/facebook-messenger/. Accessed 12 Sep. 2018.
[17] “otr-like offline messages · Issue #1432 · irungentoo/toxcore · GitHub.” https://github.com/irungentoo/toxcore/issues/1432. Accessed 13 Sep. 2018.
[18] “My Security Analysis of Bitmessage.” 20 May. 2013, https://bitmessage.org/forum/index.php?topic=1666.0. Accessed 13 Sep. 2018.
[19] “#16801 (Add OMEMO Encryption support to XMPP) – Pidgin.” 10 Feb. 2011, https://developer.pidgin.im/ticket/16801. Accessed 13 Sep. 2018.
[20] “GitHub – loki-project/loki-messenger: Signal — Private Messenger for ….” 24 Aug. 2018, https://github.com/loki-project/loki-messenger. Accessed 13 Sep. 2018.
[21] “Tox should be resilient to Sybil attack. · Issue #517 · TokTok/c-toxcore ….” https://github.com/TokTok/c-toxcore/issues/517. Accessed 14 Sep. 2018.
[22] “GitHub – irungentoo/toxcore: Tox Onion routing spec..” https://github.com/irungentoo/toxcore/blob/5ea703c844b12e86702c35b53b0b798fe5f86634/docs/Prevent_Tracking.txt  Accessed 14 Sep. 2018.
[23] “Cryptoeconomics of the Loki network.” 11 Jul. 2018, https://loki.network/Cryptoeconomics. Accessed 14 Sep. 2018.
[24] “White Paper – Loki Network.” 13 Jul. 2018, https://loki.network/wp-content/uploads/2018/08/LokiWhitepaperV3_1.pdf. Accessed 14 Sep. 2018.

Loki Service Nodes: Brief Functionality Overview

Loki first Monero Fork with Masternode

As Loki is the first Monero fork (and CryptoNote coin, by extension) to have an active implementation of Masternodes, we are staggering releases and adding features as we go. This is new territory and each change we make to the the Monero codebase must be extensively tested before release.

What Loki Service Nodes do in the short term?

As part of the 1.0.0 release, Loki Masternodes (called Service Nodes) will have minimum functionality; they will store a full copy of the blockchain, and every hour they will publish an uptime proof, which is essentially a ping to the network letting the network know that they are still live. Nodes that have not submitted an uptime proof in 2 hours will be deregistered by voting quorums. Voting quorums are randomly selected sets of 10 nodes which vote on the state of the network every block.

Although the first implementation of Masternodes on a Cryptonote coin is a large move forward in the Masternode world, the major advantages that Service Nodes provide during this beginning stage will be greater privacy when transacting. However, Loki Service Nodes have larger plans ahead, and release 1.0.0 represents only the foundation.

In the Medium Term (3-6 Months)

In the medium term we are working towards making Service Nodes useful to the end user. This includes a couple of essential features:

  • Every Service Node will now be a remote node that serves the blockchain to users.
  • Every Service Node can now run tests and collect data on other Service Node performance; they can assess blockchain storage, bandwidth statistics, and provide message storage for Loki Messenger.
  • Based on these tests, Service Nodes can deregister any underperfoming node if the voting quorum reaches consensus.
  • Lokinet will be deployed on Service Nodes, along with the Loki Message server.

Adding these features to Service Nodes allows us to deploy our first end-user Loki Service called Loki Messenger. Loki Messenger (based on the Signal protocol) allows users to communicate more privately than ever through the first market-based Sybil resistant mixnet network, Lokinet.

In the Long term (6-12 Months)

In the long term Loki Service Nodes will need to have high capacity bandwidth connections to provide to the Loki network with routing data. Lokinet will become a fully fledged mixnet providing anonymous access to the internet, and will also have direct integration with browsers, providing an integrated solution for private messaging, internet access and finances .

Want to Know More?

Our Whitepaper details the technicals behind Loki’s network architecture and Service Node functionality, and our Cryptoeconomics paper provides an in-depth analysis on the economics around our Service Nodes.

Laying Down Layer One: Loki

Over the last three months, there has been significant focus on Loki’s layer two, with numerous papers and articles revealing the true scope of Loki’s Service Node functionality with Loki now becoming a fully fledged mixnet. There has also been much talk about how Loki as a currency, or layer one transactional medium, will function in this framework. Initially we envisioned Loki would act as an access token to prevent Sybil attacks, however there are some downfalls of that system which we addressed in an article here. Given we have focused so much on Loki’s second layer, it’s time to give Loki’s first layer some explanation, and demonstrate why Loki is not only an advancement in layer two design, but also what makes it a worthwhile cryptocurrency.

A Move Towards Scaling

Monero and most other Cryptonote coins have dynamically scaling block sizes, meaning there is no hard limit to how many transactions can theoretically take place on the blockchain. However in practice, nodes must transmit data between each other, and as each block is accepted into the network and the block size grows, low performance nodes can struggle to keep up with the higher bandwidth requirements and suffer computational stress trying to verify all transactions. This can centralise the operation of full nodes to miners, who make up one of the only parties that have an incentive to operate full nodes.

If we can create a way to incentivise the operation of full nodes, we can avoid the aforementioned issues. This is one of the goals of Loki Service Nodes; to create a network of full nodes that are incentivised to hold and serve a full copy of the blockchain. These nodes must meet standards of service that are tested by a distributed method of flagging called Swarm Flagging. Because nodes are competing for a limited block reward and can be removed from the staking reward pool, they are always incentivised to serve copies of the blockchain to users and relay transactions.

Theoretically, this means that Loki can scale to handle much larger blocks and thus, handle a higher transaction throughput. This is predicated on the fact that the full nodes operating on the Loki network offer higher bandwidth/storage and compute performance than nodes on the Bitcoin or Monero network.

Instant Transactions with Blink

In a typical blockchain system, the confirmation time for any given transaction is the time it takes for a transaction to be included in a block. However, because of competing miners, withheld blocks, and Finney attacks, recipients usually require a number of additional blocks to be created on top of the block which holds a transaction before it is considered to be complete.[1] Depending on a multitude of factors specific to each blockchain, this process can take 10-60 minutes, which is inconvenient for merchants and customers who must wait for confirmations before they release goods or commence services.

Because of Loki’s Service Node architecture, near instant transactions are possible. Blink enables the same transactions that would occur on the Loki mainchain to be confirmed in seconds rather than minutes, assuring both the sender and the receiver of the validity of the transaction, and protecting the receiver against a double spend.

Blink works in a similar fashion to DASH’s InstantSend.[2] However unlike DASH’s InstantSend, Loki maintains all of its privacy properties throughout the process. Any third party looking at a Blink transaction will have no idea of the amount, nor the address of the sender and receiver. This opens up a range of new use cases for Loki, where face-to-face payments become increasingly practical and online payments become quicker and easier for users.

Stable and Formally Defined Funding Model

Funding models for cryptocurrencies are generally tricky, weak and informal, and donation only models can lead to the creation of special interest groups like blockstream, Bitcoin Unlimited and Bitcoin ABC. These groups typically act as for profit companies who drive an agenda that might not align with the community as a whole. The downside to most formally defined models is they act as a sort of tax, either through emissions or some kind of fee. This can be seen to take choice away from users as they are unable to allocate their funds to the projects they see as important.

Attempting to solve some of the aforementioned issues, Monero maintains a forum funding system, which is fully funded by a donations model. Projects vetted by the the Monero core team are featured on the Seeking Funding page, and users are free to donate Monero to projects they feel are worthy. The Monero core team also has an official donations wallet which often contributes large amounts of Monero to projects seeking funding. The advantage of the donations model is that users have full autonomy over how they spend their funds and what specific projects they support. However, there are also disadvantages to this model: funding is never guaranteed for high quality projects, and a large number of the projects receive about 1/5th of their donations from their ‘General Donations’ fund for Monero itself. The ability for a community like Monero to continue to self-fund and provide core contributions may decrease over time, and that’s something we want to avoid with Loki.

Loki’s long-term funding model is quite different from the donations model used by the cryptocurrencies mentioned above, and we think it will provide a significant advantage to consistent development, which will be in the interest of our users. Proposed in the whitepaper V3 is a revised governance block reward, which allocates 5% of each block reward to fund governance operations. Of this, 5% block reward 3.75% is controlled by the Loki Foundation, a registered Australian non-profit which is legally bound to spend the block reward as per its constitution.

“facilitating the development of an open source, highly secure, decentralised data

transmission network that allows individuals, business and government to freely

transact and communicate without the threat of malicious third party interference”

The other 1.25% is controlled by the Service Nodes through the Loki funding system. The Loki funding system is an entirely non-custodial system of proposal funding, meaning the Loki Foundation cannot control how its funds are allocated. Because Service Nodes are not bound by Australian law or a constitution, this greatly expands the range of proposals that can be funded. To distribute funds to proposals, Service Nodes vote on proposals that occur on-chain, and funding is allocated every two months via special funding blocks which pay a portion of their block reward to proposal addresses. Because Service Nodes represent players with a high stake in the Loki system, they are incentivised to vote on proposals which will increase the value of their stake.

Remote Node Availability

Due to the design of all CryptoNote coins, the blockchain cannot be easily queried by connection to a full node. Instead of simple queries being made for the balances of public keys, full nodes must transmit full blocks to users, and the user has to scan every transaction in the block and identify whether they can calculate the private spend key for the destination stealth address. This results in significant stress being placed on every remote node operator with no reward, and Monero and other Cryptonote coins therefore rely on the altruism of community members to fund these operations, which can be problematic.

It is common for mobile users in Monero to cycle through 3 or 4 remote nodes before connecting to one that is reliable. Additionally, as any user can become a remote node that serves blocks to the community, there is the possibility that “popular” remote nodes will provide an altered history of the blockchain. Though this altered history cannot be used to directly steal a user’s funds, in combination with other malicious attacks, a remote node could potentially convince a user to send funds twice to someone who has already received the transaction.

By rewarding Service Nodes, Loki creates a large, decentralised network of nodes with a full copy of the blockchain. These nodes are incentivised to serve copies of the blockchain to users and relay transaction. If a user chooses to connect to these nodes at random, ‘popular’ nodes are no longer an issue. This also balances the load of remote syncing across the whole network instead of onto a select few nodes.

Lokinet, SNApps and Highly Integrated Payments

Work is ongoing on Lokinet, which when fully launched will be a private, decentralised and Sybil resistant overlay network for the internet. You can read a detailed article about it here.

Anyone can host services on Lokinet, which will be called SNApps (Service Node Applications). With SNApps, any web developer will be able to host websites that are completely anonymous; the website owner won’t know the IP address of their visitors, and and the visitors won’t know the IP address of the website they connect to. All content hosted inside Lokinet will be accessible through the Loki browser.

The Loki browser will have an inbuilt wallet. Users will be able to fund this wallet with Loki, and the browser will automatically hook into SNApps that display Loki addresses for payments. This will make it very easy for a user to operate a store, or take or make payments for goods and services while maintaining anonymity between both networking and transactional layers. Lokinet will also have exit functionality, so any website operator who serves a website on the wider internet will be able to implement these hooks for users of the Loki browser to easily manage Loki payments.

In Summary

Loki’s value is derived not only from an inventive layer two, but also as a layer one transactional medium, or cryptocurrency. Although Loki is moving away from the use of $LOKI as simply an access token, there are still some significant advantages to $LOKI over other privacy based coins. Most of these advantages are a result of the widely distributed set of Sybil resistant nodes, called Service Nodes.  Due to Loki’s high scalability, Loki can handle a higher transaction throughput and offer higher bandwidth/storage and compute performance than nodes on the Bitcoin or Monero network. Leveraging Service Nodes, Loki can be sent near instantly and privately using Blink bringing instant new use-cases. Loki’s unique funding model provides strong governance and avoids the pitfalls and potential risks that donation-only models pose. Due to Loki’s incentivised Service Nodes, remote syncing loads are balanced across the whole network and the issues caused by ‘popular’ nodes are avoided. Layer one, coupled with an impressive layer two provides a whole suite of services to assist Loki users transact and communicate with absolute freedom.


[1]  “Irreversible Transactions – Bitcoin Wiki.” 15 Mar. 2018, https://en.bitcoin.it/wiki/Irreversible_Transactions. Accessed 25 Apr. 2018.
[2] “Whitepaper · dashpay/dash Wiki · GitHub.” https://github.com/dashpay/dash/wiki/Whitepaper. Accessed 27 Jul. 2018.

TLDR: Why Loki Should Change its Emission Curve

This article is intended as a basic overview as to the reasoning behind changing Loki’s emission curve. To this purpose we have largely simplified the factors and influences at play; for a more in depth understanding, please refer to our paper Loki Cryptoeconomics: Alterations to the Staking Requirements and the Emission Curve.

DISCLAIMER

This article contains charts and figures which include examples of return of investments and prices for the Loki cryptographic coin. These prices are examples only and are not a prediction, forecast, or representation as to any actual likelihood of price movement of the Loki cryptographic coin. The payments shown in the examples below are general in nature and will only take effect if the planned hardfork occurs. Factors outside the control of Loki could impact what actual payments are made to Service Nodes. Those parties not operating a Service Node should not rely on these examples when deciding whether or not to participate in the Loki project. This article should be read together with the Loki whitepaper and full Loki Cryptoeconomic report.

The main goals in changing the Loki emission curve are to:

  1. Maintain Loki’s Sybil attack resistance, by
  2. Ensuring that enough Service Nodes are incentivised to run, by
  3. Aiming to keep the return on investment (ROI) for running a Service Node at an acceptable level.

The current emission curve is problematic because an excess of Loki is being produced which could lead to a large number of Service Nodes in the early years. While this doesn’t sound like a bad thing, considering our commitment to a decentralised network and Sybil resistance, it will become an issue when the Service Node rewards are split between too many Service Nodes.

While the price of Loki fluctuates with the cryptocurrency market, real world costs in running a Service Node exist, and the reward each Service Node receives for running must be greater than the real world cost of running. In other words, Service Node operators must be making an acceptable profit, or there won’t be incentive for them to run.

Chart 1

Chart 1 demonstrates that our current emission curve will result in many Service Nodes entering the network in the first few years, with the return on investment (ROI) quickly dropping below 0%. If too many Services Nodes run, the rewards are not worthwhile, and Services Nodes will leave resulting in a more centralised network.

Chart 2

Chart 2 depicts the effects of Loki’s proposed new emission curve, where there are less Service Nodes from the outset, but the return on investment (ROI) remains positive. This is better for the network in the long term because these Service Nodes will be continually incentivised to run (providing market-based Sybil resistance), while retaining a decentralised network.

For further information regarding Loki Service Node game theory, and Loki Cryptoeconomics, please refer to the following reports: