Weekly Dev Update #26

Hey Y’all,

Another weekly Dev Update for everyone. We released Festive Freya Version 2.0.1 this week which fixed a number of subtle bugs that we introduced in 2.0.0. Both 2.0.0 and 2.0.1 are compatible with the Festive Freya hardfork, but we recommend you update if you experienced any issues with RPC or IP resolution.

Loki Core

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

We’d like to welcome Lilac to the community development team. She’s currently working on some potential iOS support.

We could really use your help. To be considered for inclusion in packaging distribution, we need people to star, watch and fork our github repo. If you have a github account, please consider helping us out.

  • Progress continues on libllarp
    • Rewrote DNS functions
    • Try to set_cap on install
    • Update man pages
    • Make sure all paths tics even expired
    • Disable locking on pathsets
    • Pull router out of pathbuilder, use context router
    • Build fixes for MacOS, RPI, Windows
    • Reaccelerate DNS responses if we already have a map/path
    • Re-add MX support
    • Prevent exits from communicating with bogons
    • Bootstrap shell script correctness
    • Convert llarp_logic to C++ class
    • Convert to use cmake install
    • Limiting on path building
    • Make sure exit router is known before flushing or ticking endpoint
    • Replace PubKey/SecretKey with RouterID
  • GitHub Pulse Stats for the last week: Excluding merges, 5 authors have pushed 34 commits to master and 34 commits to all branches. On master, 127 files have changed and there have been 18,437 additions and 1,122 deletions.
  • Changes can be found at:
  • Current version: v0.3.1

Loki Messenger



Loki’s Response to the Assistance and Access Bill 2018

As many of you may have been tracking, the Australian Parliament has been deliberating on a piece of legislation for the last couple of months called the Telecommunications and Other Legislation Amendment (Assistance and Access) Bill 2018. This bill seeks to give Australian law enforcement and intelligence agencies powers to force tech companies and telcos operating in Australia to do any number of things. Here’s a partial list:

(a)  removing one or more forms of electronic protection that are or were applied by, or on behalf of, the provider; or

(b)  providing technical information; or

(c)  installing, maintaining, testing or using software or equipment; or

(d)  ensuring that information obtained in connection with the execution of a warrant or authorisation is given in a particular format; or

(f)  assisting with the testing, modification, development or maintenance of a technology or capability; or

(h)  modifying, or facilitating the modification of, any of the characteristics of a service provided by the designated communications provider; or

(j)  an act or thing done to conceal the fact that any thing has been done covertly in the performance of a function, or the exercise of a power, conferred by a law of the Commonwealth, a State or a Territory, so far as the function or power relates to:

(i)  enforcing the criminal law and laws imposing pecuniary penalties; or

(ii)  assisting the enforcement of the criminal laws in force in a foreign country; or

(iii)  the interests of Australia’s national security, the interests of Australia’s foreign relations or the interests of Australia’s national economic well-being.

Pretty scary stuff, huh? We thought so too. We’ve been tracking the progress of the bill and have been trying to analyse it to work out what the implications might be for software companies both inside and outside of Australia, and especially for Loki.

The Assistance and Access Bill 2018 (Shortened to AAA18 for the rest of the article) gives Australian agencies the ability to issue 3 types of notices to ‘communications service providers.’ The definition of ‘provider’ in the legislation is very broad. Pretty much anyone that provides any service or product that involves the internet could fall under its scope, and the notices that can be issued increase in scope and obligation, and are called Technical Assistance Requests (TARs), Technical Assistance Notices (TANs), and Technical Capability Notices (TCNs). The latter is a legally enforced instruction to create or modify features to give an agency a new technical capability. Although this notice must come from the Attorney General of Australia, the scope for new espionage tools to be created by this notice is extremely broad.

The scariest thing about this bill is the penalties given to providers who leak information about the investigation or notice, or refuse to comply with the notice. Jail sentences as long as 10 years could apply to a whistleblower, and given that these notices could be issued to companies and individuals that provide services to Australians, these notices could be issued to almost anyone around the world. With strong extradition treaties, this legislation could reach people across the nations of the Five Eyes Alliance (UK, US, AU, NZ, CA) and beyond. Some, myself included, strongly suspect that this is a coordinated effort by the Five Eyes alliance to gain access to the world’s most popular applications, as the UK recently pushed through an amendment to the already controversial Investigatory Powers Act of 2016, so that it is now quite closely aligned with this new Australian legislation. They even use similar terms, with the main similarity being the Technical Capability Notice.

Thankfully, AAA18 does explicitly state that these notices cannot be used to force a company to break its own encryption, introduce security flaws, or deliberately ignore existing flaws. It also explicitly says that these notices cannot be used to introduce a ‘systemic weakness’ into the product or service. There were a great many concerns about the definition of ‘systemic weakness’ being too vague in the legislation. The final amendment to the bill gave us the following definitions:

systemic vulnerability means a vulnerability that affects a whole class of technology, but does not include a vulnerability that is selectively introduced to one or more target technologies that are connected with a particular person. For this purpose, it is immaterial whether the person can be identified.

systemic weakness means a weakness that affects a whole class of technology, but does not include a weakness that is selectively introduced to one or more target technologies that are connected with a particular person. For this purpose, it is immaterial whether the person can be identified.

target technology :

                    (a) for the purposes of this Part, a particular carriage service, so far as the service is used, or is likely to be used, (whether directly or indirectly) by a particular person, is a target technology that is connected with that person; and

                    (b) for the purposes of this Part, a particular electronic service, so far as the service is used, or is likely to be used, (whether directly or indirectly) by a particular person, is a target technology that is connected with that person; and

                    (c) for the purposes of this Part, particular software installed, or to be installed, on:

                             (i) a particular computer; or

                            (ii) a particular item of equipment;

                           used, or likely to be used, (whether directly or indirectly) by a particular person is a target technology that is connected with that person; and

                    (d) for the purposes of this Part, a particular update of software that has been installed on:

                             (i) a particular computer; or

                            (ii) a particular item of equipment;

                           used, or likely to be used, (whether directly or indirectly) by a particular person is a target technology that is connected with that person; and

                    (e) for the purposes of this Part, a particular item of customer equipment used, or likely to be used, (whether directly or indirectly) by a particular person is a target technology that is connected with that person; and

                     (f) for the purposes of this Part, a particular data processing device used, or likely to be used, (whether directly or indirectly) by a particular person is a target technology that is connected with that person.

For the purposes of paragraphs (a), (b), (c), (d), (e) and (f), it is immaterial whether the person can be identified.

What this effectively means is that providers can not be forced to make changes to their products that negatively affect every user of that product. Instead, they can only be ordered to create the means by which they could selectively inject weaknesses or vulnerabilities into a specific product in use by a specific targeted person.

However, AAA18 gives the legislative authority for agencies to create and install monitoring tools and other intrusive mechanisms into all kinds of software and hardware. For this iteration of the bill, these tools can only be switched on and used to target crimes with minimum sentences of 3 years or more. However, there is nothing to say that won’t change and very little oversight is required by this bill. It is also extremely problematic that these tools will even exist in the first place. If they fall into the wrong hands, the effects will be devastating. The NSA in the US developed a range of surveillance techniques that were eventually leaked and used against American interests by criminals and foreign governments, and the same will likely happen here.

The introduction of AAA18 and its UK equivalent means that applications such as WhatsApp, Signal, Facebook Messenger, Gmail, and any other popular communications medium can silently turn into a monitoring device for ASIO, ASDS, AFP, GCHQ, MI5, and so on. The companies behind these products can’t utter a peep about these notices or their repercussions, or warn their users. They are even given protections to indemnify themselves against any civil cases caused by any later discovery of eroded privacy.

This bill does not require these companies to break the encryption of their systems, but there are plenty of other things these agencies could force companies to create and install, such as tools that would allow them to remotely pull information from a specific user’s device post-encryption, or gain access to these services’ servers where treasure troves of metadata could be harvested. Every ‘private’ messaging application out there could now be forced to send data back to intelligence agencies about who is communicating to who and when the communications are taking place. This isn’t hypothetical anymore – these powers are now law, and companies across the world can be compelled to follow them.

We will not know how widely these powers will be deployed until the first annual report is released. All it takes is one TCN for each of Facebook, Google, and WhatsApp, and the vast majority of private communications will be corruptible at the whim of the UK/Australian Intelligence and Law Enforcement community. The information that they can gather from this can easily be shared across the Five Eyes Alliance, effectively giving these tools to the governments of the whole English speaking world.

For advocates of digital privacy such as myself, this is a very concerning development. If anything, it only strengthens the need to shift the paradigm in communication tools so that they are decentralised, open source and private by default. If we succeed, laws such as these can’t dissolve our ability to collectively access private spaces online. I have said this before, but access to these online spaces is critical to a healthy 21st century democracy, and our governments are too quick to dismiss the need for widespread digital security.

How it will affect Loki

Obviously, we were terrified when we first saw this bill. The potential for the project to be entirely undermined by this legislation did not go unnoticed. We had begun to consider how we might set up failsafes to allow people to catch bad code being injected into our codebase, or to pay someone external to Loki to do regular inspections of our binaries that we release and ensure they are not leaking extra information or mismatching the codebase in some way.

If we were to be issued a TCN, we would not be able to tell anyone about it. If we set up some sort of canary system, we could be imprisoned. So whatever failsafe we did set up would have to be external to Loki, and would have to be regularly auditing us to make sure we haven’t been compromised before a TCN was issued.

We had also considered that we may have to leave Australia altogether. However, given the legislation allows them to target any company whether they are in Australia or not, and given most of the Loki team currently lives in Australia and has family here, this would be a very extreme and difficult move to make. None of us would ever be able to return home if we were issued a notice and refused to comply. We may have simply been extradited out of wherever we moved to anyway, so this option seemed extreme and ineffective. New amendments to the bill make this move unnecessary.

Our analysis of the bill and its proposed amendments lead us to the following conclusions:

  • With the addition of the amendment defining ‘systemic weakness,’ any modification to the Loki source code that gives authorities new capabilities would almost certainly be classed as a systemic weakness. Thus, we see it is a nearly impossible that we would be forced to implement any privacy degrading code into the software that we release to the public.
  • It is feasible that we may be forced to develop an alternative client software for authorities to use with additional data collecting features or something of the sort. Thankfully, given the network is regulated by Service Nodes, the authorities would still need to own 40%+ of the entire Service Node network to make this effective for widespread surveillance. Given our economic assumptions as outlined in our Cryptoeconomics proposal, this is likely to be prohibitively expensive for the government, particularly if the usage of Loki is so high that it is worth the government issuing a TCN in the first place.
  • As long as we are able to keep our code open source, we can guarantee that our code will always be auditable. As such, it may make sense to go over our existing licenses and convert them to GPLv3 to prevent closed source software derived from our implementation from appearing. We will require written permission from the copyright holders of the projects we have forked in order to achieve this.
  • As Loki is a decentralised system with extensive privacy protections, there is very little we as the Loki team can do to de-anonymise our users even if we wanted to. The extent of the information we might be able to provide to authorities are all known attacks such as DPI and traffic shape correlation, however we don’t have any additional information at hand than any other node operator on the network. This means that if we are issued a notice, we won’t be of much use to these agencies anyway.

The chances that Loki will eventually be issued a notice are fairly high, however such a notice would not result in compromising the privacy that our system provides.

The same can not be said of other communication platforms, where the service provider has central control over the data being transported. Your phone number is attached to your WhatsApp and Signal accounts, and all of the metadata that you create is now up for grabs. The case for a system like Loki has never been stronger. Only by decentralising the routing and storage of communications can it become truly private under this new legislation.

What you can do to stay private on the internet

With this new legislation, it is important to understand and be vigilant about our privacy on the internet. Wherever practical, using open source software is a good start to protecting one’s privacy. Open source software is much more trustworthy than closed source applications as the code is generally reviewed by people form all over the world. If any backdoors or questionable features are added to this software, alarm bells should be ringing shortly afterwards.

Whenever possible, you should also always build the open source software you are using from source. This will remove another layer of trust, as you’ll know the application you build is running exactly what is in the codebase you want to use. Nothing extra, nothing less. It is entirely feasible that modified versions of applications can put in place instead of the real ones if a notice compels a developer to do so. Reproducible builds help to mitigate against this, and this is something we are now striving towards, but it is your responsibility to check you didn’t get served a fake version of the application you want to use.

VPNs are a decent first step in protecting network privacy, but this legislation could severely undermine their utility. If the VPN you use is compelled to install monitoring systems in their service, you might just be handing your browsing and connection information straight over to the authorities and be none the wiser.

A better approach is to use some sort of mixnet. Tor is the obvious choice for the time being, but when Lokinet is launched, you should use it, as you’ll will be able to use essentially any program you like straight out of the box (it’s both TCP and UDP friendly). You’ll enjoy low latency, and a dedicated network of incentivised nodes that you can reasonably trust to not be largely comprised of nodes run by surveillance agencies.

I hope this article has clarified the situation for you, and given you some insight to why decentralised privacy is so important. If you’d like to follow what we’re doing at Loki, head to https://loki.network

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 ( 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.


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.


[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.

Service Node Autostaking Announcement

We are very quickly approaching the date where the first Service Node will be deregistered because of a natural expiry. On October the 20th, 30 days since the first Service Node being registered, the first group of Service Nodes will undergo deregistration.

There is a couple of things we wanted to go through for Service Node operators so they understand what the process is of re-registering, and issue a few warnings about Autostaking. If you are presently intending on using autostaking, you should read this announcement very carefully.

Updating software

The downtime between two registration periods is one of the best times to update your Service Node to the latest version of the Service Node software, as it can be done without the risk of accidentally deregistering your node.
The latest version of the Service Node software can be found here https://github.com/loki-project/loki/releases/latest and we have also complied a written guide and a video guide on how to update your Service Node software.

Solo Operators

If you are a solo operator and used autostake, then you must ensure that whatever computer you issued the stake command from is online during your re-registration period. You must also ensure that there is still a process running called loki-wallet-cli as this wallet will scan the blockchain and recognise when your node has been de-registered, and as soon as your funds become unlocked it will restake your Loki.
If Autostaking fails for any reason then solo operators can run the prepare_registration command on their Service Node again and run the outputted command in their wallet. This will stake your Loki again.

Closed Pools

A closed pool is a pool in which each contributor is specified by their staking address and the amount they are contributing. If you are staking Loki without running a node, ask your operator whether you are in an closed or open pool, they should be able to give appropriate guidance.
If you are Autostaking in a closed pool as a participant we highly recommend that you contact your pool operator and switch away from autostaking back to manual staking. Disabling autostake is as simple as ending the wallet process (called loki-wallet-cli) on your machine, this can be done by using:

On Linux: pkill loki-wallet-cli or
ps aux | grep loki-wallet-cli and using the process id quoted and running kill <process ID>

On Windows: you can use task manager to find the loki-wallet-cli process and terminate it

On Mac: you can use the activity monitor to find and terminate loki-wallet-cli

The main reason we recommend disabling autostake is because in a closed pool if any participant decides they will not stake during the next registration period, you may lock up your Loki without being able to fill the vacancy left by the deserting party.

If you are staking without using autostake, contact your pool operator and ask them whether there has been any changes to their node, they will give you their Service Node pubkey and they can also tell you how much Loki is required during the next registration period (Remember the amount of Loki required to stake is decreasing overtime).

You can use this information and re-run the stake command, as stated above we recommend you do not use autostake unless you have high confidence that all your collaborators will also restake their contributions.

stake <Service Node Pubkey> <address> <contribution amount>

For operators of closed pools we recommend that you contact all participants in your pool and recommend they disable autostake before re-registration begins, unless you can ensure a scenario where you have high confidence in all staking participants. Operators who are also using autostake to re-register their Service Node should consider their pool participants and whether they will be staking in the next period, if not they may need to adjust their pool using the prepare_registration command.

Open Pools

Open pools are pools for which there is no specified contribution addresses. Anyone can contribute to an open pool without notifying the pool operator.
For open pools in version 1.0.4 we have disabled the autostake feature. This is due to the high risk for operators or contributors to inadvertently lock funds due to a lack of communication. Additionally using autostake in open pools in the current implementation fails to reduce the amount of the stake as per the decreasing staking requirement.

Therefore we recommend that anyone who operates or is a participant in an an open pool terminate any wallet which is autostaking. Open pools are still available in version 1.0.4, however they only allow the client to use the stake command without the auto flag.  

As with all other Loki, Loki that was staked in open pools will be unlocked and the user is free to use this Loki in the same open pool (if it exists) by using the stake command as shown below:

stake <Service Node Pubkey> <address> <contribution amount>

Operators of open pools can also continue running open pools without autostake by running the prepare_registration command and submitting output through their wallet, users can be notified of the specifics of the new open pool when it is available.

User experience
We are looking at making changes to the user experience of staking in the future which will make the process less clunky and also reduce the risk of the user locking their funds without acting intentionally dishonestly.

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.