Weekly Dev Update #8

Hey Y’all,

Another weekly dev update to keep everyone up to speed:
Loki Base Layer

  • Pull request submitted for Time Locked transactions to now be locked per output instead of the whole of the transaction: https://github.com/loki-project/loki/pull/104). Testing still needs to be done.
  • Enable storage of the Service Node list in the database, this will reduce time spent scanning the blockchain on startup. Testing still required.

Service Nodes

  • Pull request has been submitted and is in review for quorum cop polling the state of the network. It currently integrates with de-registration to autonomously monitor and vote off nodes on the network. https://github.com/loki-project/loki/pull/105
  • Continue writing tests for preventing regressions on service nodes.
  • Began writing startup guides describing the process of setting up a Service Node. The guide should be detailed enough for the process to be clear for beginners.
  • Set-up multiple VPS/Dedicated servers to come to a better understanding of bandwidth requirements and identify ‘Exit Friendly’ hosting providers.
  • Signatures added to Service Node registration. https://github.com/loki-project/loki/pull/102
  • Multi-party registration TX with automatic payout share calculation for contributors- work in progress.

LLARP / Lokinet

If you’re lucky and join our Discord, you might also catch Jeff or Ryan (the developers of LLARP) live streaming as they code: https://www.twitch.tv/uguu25519 , https://www.twitch.tv/neuroscr

  • Progress continues on Libllarp
    • More hidden services/DHT work
    • Endian correctness
    • Message ordering fixing
    • Started Android, Arm and Windows platform work
    • Memory management clean up
    • Started on dynamic default configuration
  • Multithreaded DNS library (PR6)
    • Continued llarpification of code
    • Refactor pass to make it cleaner
    • Got multithreaded version passing benchmark
    • Allow configuration of upstream DNS server and port
  • GitHub Pulse Stats for the last week: Excluding merges, 3 authors have pushed 92 commits to master and 92 commits to all branches. On master, 145 files have changed and there have been 7,565 additions and 2,564 deletions.
  • Most changes can be found at https://github.com/loki-project/loki-network/commits/master.


Weekly Dev Update #7

Hey Y’all,

Big week, big update!

Loki Baselayer

Service Nodes

LLARP / Lokinet

  • If you’re lucky and join our Discord, you might also catch Jeff or Ryan the developers of LLARP live streaming as they code: https://www.twitch.tv/uguu25519 https://www.twitch.tv/neuroscr
  • Progress continues on LibllarpUpdate protocol docs on dht and SNApps
  • Start implementing SNApps
  • Fix various code regressions
  • Refactored Libllarp-platform from Libllarp
  • Improvements to DHT to make testing the testnet easier
  • Multithreaded DNS library started
  • Working DNS client implementation
  • Working DNS server implementation and testing
  • Created hook for future handling of .loki address look ups
  • Llarpification and librarification of DNS client/server
  • GitHub Pulse Stats for the week: We think excluding merges, 2 authors have pushed 29 commits to master and 49 commits to all branches. On master, 277 files have changed and there have been 11,222 additions and 6,615 deletions.
  • Most changes can be found at https://github.com/loki-project/loki-network/commits/master
  • Current version: v0.0.1 https://github.com/loki-project/loki-network/releases/tag/v0.0.1

Architecture Team

  • We released a lot of content this week, including the economic proposal, which contained both the newly proposed emissions curve and the staking requirement. We also released a full game theoretical breakdown of the considerations we took into account regarding the staking requirement authored by Dr Brendan Markey Towler.
  • All papers we publish will now be located here https://loki.network/papers
  • We are still collecting feedback on the staking requirement
  • New work is beginning to focus on the operation and user experience of Lokinet, right now specifically focusing on Domain name schemes and human readable usernames.


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.


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:

Changing the Loki Emission Curve

We’re very pleased to present this proposal to the community after many weeks of patience. We have reviewed the Loki cryptoeconomics extensively with assistance from Dr Brenden Markey Towler of the University of Queensland, working with the RMIT Blockchain Innovation Hub.

Today we present two documents. The first is our economics paper: Proposal: Alterations to the Loki Cryptoeconomics. This document outlines the problems we have considered, some solutions to them, and an explanation of our final selection.

The second is a report by Dr Brenden Markey-Towler, Cryptoeconomics of the Loki network,  which lays out the game theory at play in the Loki ecosystem. This report goes into some of the mathematics at play and makes some cases for potential solutions based on that maths. Our proposal to the community makes several references to this report, so if you want a greater understanding of the formulas we have used to derive values in our proposal, you can look there.

The crux of the matter is that we propose to initiate a hardfork at block height 64324, or approximately the 30th of July, 2018. This hardfork will only change one parameter in the current Loki implementation, which is the emission curve. The reason for this change is that we have come to the conclusion that the current emissions scheme would be completely untenable as a sustainable rewards scheme for the Service Nodes whilst retaining Sybil attack resistant properties. As it turns out, this is a very complex subject, so we strongly encourage you to Read the proposal.

As we believe this to be a time sensitive matter, please present any feedback you have in the Discord channel under #governance

Gaming This Change

A concern we have had while constructing this proposal is the potential repercussions in years to come. A number of accusations could arise as a result of this proposal, even if it is successful and has the desired effects we have described.

An example of such an accusation could be that the Loki core team deliberately set the emissions curve to be high at the beginning of the project in order to crash the price, during which, we could have accumulated Loki at very low prices, implemented this change to cut emissions, and then sold at a higher price.

We set the original emission curve to be as high as it is for a couple of reasons. Firstly, Monero uses the same emission curve, so it seemed reasonable that we inherit it from our parent project. Knowing that this would mean very high inflation (at least at first), we believed it would help us argue against a concern that turns out to have been far less prominent than we had anticipated: our premine. Our 15% premine has successfully funded this project for the next 3 years, provided incentive to the founders, advisors, and investors, and has allowed this project to scale and evolve at a rapid pace. However, community concerns over ‘premines’ have historically been a common occurrence in the cryptocurrency community, and we wanted to make sure that by the time Service Nodes launched, enough Loki had been emitted to counteract the argument that the founders or Foundation could have dominance over the network based on the ownership of their Loki. However, if one accepts the 59% presale of premined coins alone to have actually taken place, it is already mathematically impossible for all the remaining parties who control premined Loki to collude and achieve Service Node network dominance without purchasing more. The high emissions have resulted in a very large hashrate compared to the size of our market, which has meant there has been ample distribution of Loki amongst several thousand miners.

While we are proposing to cut the emission curve, it is not for the purpose of or own personal gain, or the gain of the Loki Foundation. Since the launch of the mainnet, the Loki Foundation has participated very little in the Loki market, only making relatively minor purchases of Loki to pay certain parties for their efforts without touching Foundation reserves. Similarly, the founders have only ever made minor purchases of Loki for their own personal use, and certainly haven’t sold any. The first vesting period has not yet elapsed for any of the founders or advisors, which can be verified by anyone using the information disclosed in the premine report. This can also be used to verify the impossible chances of founder dominance when Service Nodes launch.

We hope that by disclosing our intentions and concerns we can form an ongoing trust with the community and continuously strive towards transparency.

And so, with those concerns laid out, we propose to implement this change to the emissions curve as soon as possible. If you haven’t already, please read the proposal and submit your feedback or signal your support.

Technical Details

In the coming days, we will release a new binary for Loki. Once this binary is released, all users of Loki must update their daemons within 7 days. This includes all pools, exchanges, remote nodes, and users operating their own nodes. Where possible, we will reach out to all concerned parties that we are aware of and inform them of this change.

After block height 64324, the Loki block reward will go from being calculated in terms of the circulating supply with an emission speed factor of 20, to be derived from the block height. Defining the base block reward based on height will mean that the typical block size penalty will simply under-emit if miners attempt to create abnormally large blocks. However, this should not negatively impact Service Nodes as we attend to apply this penalty on the miner’s reward output only once the Service Node hardfork takes place in the coming months.

Once the new binary is running, users will not need to do anything to initiate this hardfork. The new emission rules will roll over automatically at block 64324.

Stay tuned to the Loki communication channels for updates on the binary release.

Weekly Dev Upate #6

Weekly dev update for Y’all, a little late this week since we were busy writing papers 🙂

Service Nodes

LLARP / Lokinet

If you’re lucky and join our Discord, you might also catch Jeff or Ryan the developers of LLARP live streaming as they code: https://www.twitch.tv/uguu25519 , https://www.twitch.tv/neuroscr

  • Progress continues on libllarp
  • DHT query iteration fix
  • Convert C files to C++, API clean up, IWP refactor https://github.com/loki-project/lokinetwork/pull/4
  • Base32 utilities
  • Outbound pump tweaks
  • DHT Refactor
  • Load Hidden Service set up from service.ini
  • DHT/Path builder now handles intro messages
  • Implement sending a collection of random paths as a pathset
  • DHT Router Contact search can now search for multiple contacts in one query
  • Clean DHT timeouts
  • Pathset validation
  • Event Loop only run if we have traffic
  • Resend fragments support
  • Don’t disable private interface if used for NAT
  • Start on libllarp-platform refactor and dns library
  • Updated LLARP’s command line utility
  • Ability to set log level
  • Ability to display info on any RC file
  • GitHub Pulse Stats for the last week: Excluding merges, 3 authors have pushed 18 commits to master and 30 commits to all branches. On master, 124 files have changed and there have been 3,821 additions and 3,320 deletions.
  • Most changes can be found at https://github.com/loki-project/loki-network/commits/master
  • Current version: v0.0.1 https://github.com/loki-project/loki-network/releases/tag/v0.0.1

Architecture Team

  • Whitepaper V3 is out! https://loki.network/whitepaper
  • Wrapping up papers on Staking requirements and the economics of Loki, expect these two papers to be out very soon.

Loki Android Wallet

Loki Wallet

  • Pull request for exporting transactions to a CSV file from the cli wallet. This feature will eventually be merged upstream to Monero. https://github.com/loki-project/loki/pull/96
  • Loki-gui has been pushed to 0.1.1 which includes the daemon hotfix (v0.1.1), updating some missing translations and a fix to make the QR code on the Receive Page scannable (previously unscannable due to the dark background).


Weekly Dev Update #5

Hey Y’all,

New week, new update!

Service Nodes

LLARP / Lokinet

If you’re lucky and join our Discord, you might also catch Jeff or Ryan the developers of LLARP live streaming as they code: https://www.twitch.tv/uguu25519https://www.twitch.tv/neuroscr

  • Progress continues on libllarp
    • Removed session deadlock
    • Keepalive timeout adjustments
    • Inbound codel/queue fixes
    • Add inbound server connections to DHT
    • Get link by public signature key
    • Handle out of order messages better
    • Prevent path latency tests from stacking
    • Worked on serving from NAT hosts
    • Various DHT fixes
  • Updated LLARP’s command line utility
    • Make –locate exit after response
    • Fix double free on exit
    • Refactor RC display function
  • GitHub Pulse Stats for the last week: Excluding merges, 1 author has pushed 22 commits to master and 22 commits to all branches. On master, 119 files have changed and there have been 7,093 additions and 432 deletions.
  • Most changes can be found at https://github.com/loki-project/loki-network/commits/master Current version: v0.0.1 https://github.com/loki-project/loki-network/releases/tag/v0.0.1

Architecture Team

  • Whitepaper V3 has been handed to an editor, we should expect to have a copy out mid-late next week, editing/formatting is taking longer than expected.
  • After more research, we have handed over some fixed values needed for final models to Dr Brendan. This includes assumptions about values like Service Node operation cost, newly proposed emissions curve, and target nodes on Lokinet.

Loki Android Wallet

  • First release of the Loki android wallet is out, you can download and the APK here https://github.com/loki-project/loki-android-wallet/releases/tag/v1.0.2
  • Please note that the Loki mobile wallet is currently in Alpha. It will move onto the Google Play Store once feedback from users has been collected.
  • Big thanks to the Monerujo team for their efforts in making this wallet possible.


Preventing Sybil Attacks: Runes, PoW, and CAPTCHAs

Put simply, Sybil attacks are where one person or entity creates multiple fake identities, usually to either subvert some part of a reputation system, or to effectively create large scale denial-of-service attacks. [1] Sybil attacks present problems to systems that maintain a low barrier of identification. With Loki’s focus on privacy and its P2P nature, methods are required to identify unique individuals without requiring some proof of personhood (i.e. government ID or License) .

In Loki’s case, Sybil attacks could be used to either spam path creation on Lokinet (more on this later) or, more worryingly, to force Service Nodes to store offline messages on behalf of the attackers, quickly exhausting the storage capacity of Service Nodes. Without user verification, both of these attacks could have a potentially crippling effect on the use of Lokinet and Loki Messenger.

There have been a number of software tools devised to identify legitimate, unique identity without requiring real world ID. Most people interact with these tools everyday- the most common being CAPTCHAs. In a CAPTCHA, a human is faced with a problem that is typically hard to solve for a computer but easy for a human. This slows down the automation process that a malicious party would use to construct large numbers of identities. Another system commonly used is browser fingerprinting. Services like Cloudflare use these tests often, with the idea being that they can determine, through the use of cookies, referrals and a number of other browser specific cues provided through javascript, whether a user is a robot.

Although the above methods provide some effective protections from Sybil attacks, they all require a strong element of centralisation in that they require a centralised server to verify the solution to each CAPTCHA. Unfortunately, this goes against Loki’s core philosophy of decentralisation. There are two well used and well studied systems, however, that allow us to achieve a similar effect without the same centralisation. The first is proof-of-work (PoW); in this system, the user performs a set of difficult calculations and then attaches this as a certificate to send a message or create a path. An attacker who pretends to be thousands of different people, would be required to perform that calculation thousands of times, costing money in computing cycles and making the attack considerably more difficult and inefficient.

The second commonly used system is fee-for-service; every time a user utilises the system to create a tunnel or send a message, they pay a fee. With this model it becomes costly to spam the network due to the additional fees invoked.

Both of these systems have some inherent flaws. The difficulty (pun intended) with PoW systems is deciding how hard it should be to produce one of these proofs which you can attach to a message or path creation. Make it too hard, and users with low spec computers or mobile devices will struggle to use your system. Make it too easy, and it will be cheap enough for an attacker to produce large quantities of proofs, negating the effectiveness of your system. The major issue with fee-for-service models is that they restrict usage of the service you provide. As services are increasingly provided for free, users have become reluctant to go through the process of purchasing a cryptocurrency and paying micro transactions each time they send a message. Additionally, since the groups that potentially benefit the most from Loki are the underprivileged, marginalised and persecuted, requiring them to purchase Loki from an exchange would be a non-starter.

So, what does Loki do differently? Previously, Loki presented the idea of Runes and the Runechain- with Runes representing a medium term (30 Days) access token to the Loki network that could be mined and sold. However, over time we have realised that Runes are not the most optimal solution. Runes present a number of issues. First, if Runes ever become profitable to mine, then average users will lack the means to produce them from a home computer. This would be the natural result of miners rushing to produce a profitable token that they can sell, increasing the hashrate significantly and strangling out the average consumer. In turn, this would mean that users would have to buy Runes from somewhere… But where? A centralised exchange? This creates another vector for temporal analysis where exchanges can collect the identity of users and link this with sold Runes, essentially assigning real IP addresses to Lokinet users. It has become clear that Runes create more problems than they solve; they also increase the complexity of Loki, in requiring two separate blockchains be maintained.

What’s the solution? Loki can functionally prevent Sybil attacks using a PoW system- it just needs a little tweaking, hence the new scheme: Loki Messenger now requires a Blake2b hash with sufficient difficulty to be produced for every offline message sent. This hash is attached to the header of each message, which is functionally similar to schemes used by Bitmessage and Hashcash. [2][3]

However, unlike other PoW systems, the difficulty of Loki’s hash function is based on the desired Time-To-Live (TTL) for each message. This means that if User A wants to send a message that lasts on User B’s swarm (an article on swarms will be coming soon) for 6 hours, the POW User A needs to calculate will be much less difficult than a message that needs to last for 24 hours. This difficulty adjustment method combats the constant rise in difficulty that stops low computing power individuals from using Loki messenger.

This scheme operates similarly for path creation in Lokinet. The fear with path creation is that users can request for Service Nodes be part of their paths. If they spam this process and require that Service Nodes stay in their paths for long periods of time, they can end up saturating Service Nodes with unnecessary paths that won’t be used. This would deny service to legitimate users. To prevent this, paths that are longer lived than the default path TTL will be required to attach a PoW to their request, this PoW difficulty rises linearly with the TTL for the path.

By using a TTL adjusted PoW system, Loki can prevent Sybil attacks while maintaining an equitable network that is free and open to users all over the world, as well as to those who may not have access to Loki or a powerful computer.

[1] “The Sybil Attack – The Free Haven Project.” https://www.freehaven.net/anonbib/cache/sybil.pdf. Accessed 25 Jun. 2018.
[2] “Bitmessage: A Peer-to-Peer Message Authentication and Delivery ….” 27 Nov. 2012, https://bitmessage.org/bitmessage.pdf. Accessed 25 Jun. 2018.
[3] “Hashcash – A Denial of Service Counter-Measure – Hashcash.org.” 1 Aug. 2002, http://www.hashcash.org/papers/hashcash.pdf. Accessed 25 Jun. 2018.

Weekly Dev Update #4

Hey Y’all,

Got a Winter weekly update for you.

Service Nodes

LLARP / Lokinet

If you’re lucky and join our Discord, you might also catch Jeff or Ryan the developers of LLARP live streaming as they code: https://www.twitch.tv/uguu25519https://www.twitch.tv/neuroscr

Architecture Team

  • Whitepaper V3 is in a round-table edit phase and 3rd party review, should be published mid – late next week.
  • We have continued to work with Dr Brendan Markey Towler and we have produced an 11 page paper detailing the game theoretical approach for how the staking requirement should be set, we still need to graph out some final values but were getting close to presenting our model.

Loki Android Wallet

Making good progress, should have the beta APK out for testing next week, Google play store will probably take a bit longer.