Weekly Dev Update #27

Hey Y’all,

Festive Freya and bulletproofs are now active, reducing the average transaction size by about 90% and fees by about 25 times!

Anyone who is having issues syncing past the hard fork height of 161849 should download the point release here for the CLI https://github.com/loki-project/loki/releases/tag/v2.0.2, and here for the GUI: https://github.com/loki-project/loki-gui/releases/tag/v2.0.2

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/uguu25519, https://www.twitch.tv/neuroscr

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:
    • Make sure debug doesn’t output binary
    • Update introset if no good paths
    • IntroSet responses clear updating flag
    • Fixed unhandled key ‘q’ issue for hidden services
    • Flush SN traffic queues
    • Random.snode hostname
    • Expire old SN sessions
  • Platform and packaging updates:
    • BSD: Pktinfo fixes
    • Windows: fix C++ atomics
    • Clean up CMakeLists
    • Improve cmake options documentation
    • Include lokinet-bootstrap in make install
    • Change unreliable OpenDNS defaults to CloudFlare
  • Clean up continues
    • Convert llarp_router, llarp_nodedb, and llarp_crypto to C++ class
    • Removed dead address_info code
    • Converted CoC to CONTRIBUTING
    • Move all headers into llarp/
    • Create .cpp placeholders for all .hpps
    • Make sure C headers don’t have C++
  • GitHub Pulse Stats for the last week: Excluding merges, 5 authors have pushed 56 commits to master and 56 commits to all branches. On master, 367 files have changed and there have been 7,642 additions and 4,427 deletions.
  • Changes can be found at: https://github.com/loki-project/loki-network/
  • Current version: v0.3.1 https://github.com/loki-project/loki-network/releases/tag/v0.3.1

Loki Messenger



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.


There weren’t many famous leprechauns, but Simon was one of them. He was, on Christmas Eve, hanging out with his friend Lucky (another famous leprechaun). Every Christmas Eve, Lucky and Simon would eat, drink, and get into the festive spirit. Rescuing Christmas was Simon’s job, and he pulled it off flawlessly every year. Everyone forgets how pivotal Simon is to the Christmas process – maybe it is because he is seldom talked about. Alison, his mum, even forgets to get him a gift on his birthday. So Simon hangs out with the only friend he has who sometimes remembers him, Lucky. Only this time, their hang was different. Never before had lucky been so handsy- he was touching Simon a lot more than was usual.

“Why are you being so touchy?”

“All I’m doing is trying to show my friend some affection.”

Simon felt uncomfortable, so he decided to drive home as he needed to prepare for Santa’s arrival. To his surprise, his car would not work- did somebody mess with his engine?

Only a series of well thought out contemporary dance moves would save him from his current handsy predicament. He pranced and danced and jumped and jived. Immediately, Harriet the contemporary dance fairy appeared in front of him.

“Do you have a wish for me, young leprechaun?”

“Engineering knowledge of the motoring kind would be appreciated, my car doesn’t seem to work.”

Harriet did a small, contemporary dance number that Simon was sure would have been impressive if he understood its underlying message a little more.


Simons car still did not start. Realisation hit that Harriet’s contemporary magical dancing powers were not working, and there was now a very solid chance Simon would not be at his house in time for Santa’s arrival. Everybody knows (but it is easily forgotten and seldom talked about) that Simon is needed on Santa’s Sleigh or the Christmas presents will not be delivered. Awkwardly Harriet exited the scene, and all seemed lost.

Luckily, Simon was at Lucky’s house and his residence was known to be the luckiest place on earth. It so happened that another magical deity appeared before Simon- Loki, the trickster god of the Norse.

“Do you need a hand?”

Enthusiastically, Simon nodded.

Now Loki well knew what the problem with Simon’s car was, but he’s a tricky little guy, the trickiest in fact.

“The problem is your engine’s fried.”

It was a surprisingly unlucky thing that was happening at Lucky’s house, Simon thought to himself.

“Tell me, what should I do?”

“You can use my car, it’s fast and it will get you to your house in time for Santa to pick you up.”

Fantastic news this was to Simon. Rolling around in Loki’s Rolls Royce didn’t seem like a bad option.

“Only thing is, if you’re going to use my Rolls Royce, I’m going to use your car to drive around in after I fix it.”

Mysterious was the way that Loki said it, but Simon didn’t have a problem with that. Perfect. Everyone was in agreement. Only a moment ago Simon was making wishes to dance gods, and now he was about to drive in a real Rolls Royce. Possibly the luckiest turn of events that could have eventuated. Lucky Simon. Ecstatically, he jumped into Loki’s car, but as soon as he closed the door behind him he was immediately teleported somewhere else!

“Where am I?”

He looked around and noticed that he was surrounded by thick, unforgiving jungle. Obviously he was far away from his home.

“Will I ever get home for Christmas?”

Everyone knows that Loki is a trickster, and boy, did Simon get tricked good. Relief swept over him as he remembered he still had the Rolls Royce. Even though there was no way that it would be driving anywhere through this jungle thicket, he still felt hopeful having a piece of civilisation close by. Lifting his head, he ventured forth into the jungle. Over vines. Over roots. Keeping a look out for dangerous jungle hazards like panthers and tribal hunters with poison darts. It might have been a lost cause, but it was better than doing nothing. Next to him he saw a little hut- maybe there would be someone he could get directions from. Gas was leaking out the top of the hut, but it was a very pleasant smelling gas. Totiki, the magical tribal woman, appeared from inside the hut.

“Oroboros alorobos!” Unsurprisingly she didn’t speak English.

“Santa needs me, can you help in any way?”

Every chance of saving Christmas was reliant on what Totiki did next. Totiki smoked from her magical smoking pipe, she laughed and did a handstand. Hope was lost and Simon sat down, put his head in his hands and wept.

“Is helping to Santa really what you want to do?” She spoke some English after all, it seemed.

“I need to or Christmas will be ruined, Santa needs me to help him deliver all the presents.”

“Not this Christmas, is that your job.”

Frustratingly, she sometimes talked backwards like Yoda. Orangutans howled from the trees as Simon faced this new truth. Ruining Christmas was not something he wanted any part of. Maybe there wasn’t anything he could do to stop it. And maybe this was meant to be, or predetermined in some way.

“That trickster god really got me good.”

Isolation was the only thing Simon could feel right now, but he was determined not to give up. Out of her mouth he snatched the magical smoking pipe. Next minute he was running through the jungle. All he could hear now were her angry cries coming from the hut. Gripping the pipe firmly between his fingers, he took a puff and wished with all his might that he would be back home and ready for Santa to visit. A swirl of smoke surrounded him, and whisked him up in the air and away.

“I’m flying, I’m flying home!”

Nothing besides smoke could be seen, all he knew was that he was travelling speedily through the air. Slowly, he began to decelerate and descend, his magical journey was coming to an end.

Touching his feet on the ground, the smoke cleared away and he realised he had arrived back at the hut with Totiki. Her beady little eyes watched him as she cackled out loud.

“I’m never getting home for Christmas.”

Maybe he never would.

Weekly Dev Update #25

Hey Y’all,

By the time this Dev Update is out, the Festive Freya mandatory upgrade period will have begun. This means ALL SERVICE NODE OPERATORS, ALL POOLS, AND ALL USERS NEED TO UPDATE to the Festive Freya release in anticipation for our December 13th network upgrade.

For Service Node operators you can get the new CLI wallet and Daemon here: https://github.com/loki-project/loki/releases/tag/v2.0.0

You can read more about the network upgrade and the features we are adding here: https://medium.com/@LokiNetwork/festive-freya-announcement-84ea86cc5574
Loki Core

LLARP / Lokinet

  • Progress continues on libllarp
    • Handle SIGTERM properly
    • Refactored how cascading configuration works
    • Removed auto mode for tun
    • Change AVX2 default to off, has to now be explicitly requested in a build
    • Make sure vanity nonce is updated
    • Change DHT router lookup to be able pass additional data
    • Added being able to tell difference between being overload or having no working endpoints
  • Vanity Hidden Service Address Generator
    • Started on reference (SLOW) (.loki) name generator
  • DNS library
    • Started infrastructure for .snode lookups
  • GitHub Pulse Stats for the last week: Excluding merges, 1 author has pushed 11 commits to master and 11 commits to all branches. On master, 42 files have changed and there have been 1,307 additions and 376 deletions.
  • Most changes can be found at:
  • Current version: v0.3.1

Loki Messenger