Weekly Dev Update #3

Hey Y’all,

Got a new weekly update, NOW WITH ADDED ANNOUNCEMENTS

Service Nodes


LLARP / Lokinet has been announced and you can read more about it here.

I will now be featuring it in my weekly updates.

If you’re lucky and join our Discord, you might also catch Jeff, the lead developer of LLARP live streaming as he codes: https://www.twitch.tv/uguu25519

  • Progress continues on LLARP / Lokinet:
    • Separated libllarp from daemon
    • Python scripts for creating a group of test nodes on the loopback interface
    • Improved the Distributed Hash Table (DHT) design
    • Started removal of timer system
    • Created pluggable path building architecture, including its first implementation
    • Run cryptography and db/disk functions in their respected threads
    • C++17 FileSystem polyfill for Apple’s LLVM 3.8ish compiler
    • Initiated work on unit tests using Google’s test framework https://github.com/google/googletest
  • Updated LLARP’s command line utility
    • Implemented import and export functions to interact with node database
    • Fixed bug, where newly generated router contacts weren’t given an encryption key
  • GitHub Pulse Stats for the last week (at the time of this writing): Excluding merges, 3 authors have pushed 30 commits to master and 30 commits to all branches. On master, 64 files have changed and there have been 2,398 additions and 1,097 deletions.
  • All changes can be found at here

Architecture Team

  • White Paper V3 moves into its final edit stage.
  • The Economic White Paper is now complete- the handover process to an economist has began, and they will assess our assumptions as well as reinforce the paper with their own metrics.

We also got our first two officially merged pull requests to Monero here and here, and we still have 2 active pull requests that are waiting! This is something we hope to continue to do as we find features, bugs, and refactor elements of the Monero source.  

Thanks,  

Kee



LOKINET

Loki’s Exploration into the Mixnet Space

 

We have been dropping lots of not-so-subtle hints that we have been working on a decentralised mixnet, and it’s finally time to reveal what we’ve been working on. This article, along with the soon-to-be-released white paper version 3 should get everyone up to speed on Lokinet.

Mix What?

Mixnet is a term used to describe an overlay network that operates on top of the internet. You might have heard of Tor or I2P- these are both mixnets. So what’s the idea behind a mixnet? Typically, when you make a connection to a website, your IP address is visible to the web service you connect to. Internet IP addresses are similar to street addresses in the physical world; they identify where information (known as ‘packets’) should be sent. The problem is that every time you connect to a web service, you give away your IP address. This makes internet browsing anonymously very difficult. Services you connect to can use your IP address to work out your general location, and state level actors can use legal processes to extract your IP address from web services and connect your IP address with your real world identity.

The solution to this problem is a mixnet. Mixnets work by using groups of nodes (other computers) all around the world. Instead of your connection going directly to the web service, it first hops through multiple nodes selected at random. These nodes are typically called ‘relays’ or ‘routers,’ and the path you create through them is called a ‘circuit’ or ‘tunnel’.

When using a mixnet, your connection to a web service does not look like it is coming from you. The web service only sees the IP address of the node that is the last hop in your circuit. Similarly, your internet service provider (who can usually see the connections you make to web services) only sees your connection to the first node in your circuit. To make things even trickier, most mixnets use techniques called “Onion Routing” and “Garlic Routing.” With these techniques, each hop in your circuit only knows the previous node (where the packet came from) and the next node (who they need to send the packet to). They do not know where the packet originated from, which means they do not know who you are. This limits the information that even dishonest nodes can gather about you when you use a mixnet.

Loki is building its own mixnet. Why? There are perfectly good mixnets out there right now, why don’t I just use those?

Well…

The Problem With Current Mixnets

 

Although there are several mixnets currently in use, this article will focus on problems with the two largest and most used: Tor, and I2P.

Tor

Tor has been the most used anonymous mixnet for the past 10 years. The Tor network maintains a high level of censorship resistance, and is a valuable tool for preserving internet privacy. Tor, however, is not a decentralised network. Tor is reliant on a group of “Directory Authorities,” which are centralised servers operated by a group of volunteers close to the Tor Foundation [1]. These Directory Authorities perform two main functions; they provide a list of all of the nodes so that users can create circuits, and they categorise nodes according to their speed (fast or slow). Nodes are given less or more responsibility based on these results.


This high level of centralisation means Tor can face attacks. In 2014, Tor received information of a credible threat to take down the Directory Authority servers [2]. Since the location of the Directory Authority servers is known, collaboration between the German and US governments or the US and Netherlands Governments would be enough to shut down five of the ten Directory Authority servers. A take-down of five or more Directory Authorities would result in a highly unstable Tor network, with new nodes being greatly diminished in their ability to interact with the network.

I2P
I2P takes a slightly different approach to a mixnet. I2P doesn’t use centralised Directory Authorities, it uses a “Distributed Hash Table” (DHT). A simplified explanation of how a DHT works is that each node holds a table that specifies every other node on the network, and how to contact them. This means no centralised authority is needed, which in turn offers less single points of failure. However, because of this weaker consensus model, nodes in I2P can hold different versions of the state of the network. This can create confusion when circuits are created and can result in unreliable circuits.

 

Unlike Tor, I2P lacks formal support for accessing the internet anonymously. I2P only formally allows for accessing internally hosted websites, which they call “Eepsites”. This has greatly reduced the ability for the I2P network to reach users whose main purpose for using anonymising networks is to access the wider internet. I2P is built so that the majority of users that connect to the I2P network also become nodes in the network. This is problematic as the resulting network often lacks sufficient bandwidth speeds to be able to build fast tunnel, and because the tunnel speed in I2P is bottle-necked by the least capable node, this results in reduced performance for the end user.

Problems With Both


Neither I2P nor Tor have fully mitigated Sybil attacks. A Sybil attack occurs when sufficiently motivated attackers (who have enough time and capital) buy large numbers of nodes in the system and perform attacks where traffic is correlated between nodes. This significantly decreases privacy [3]. Additionally, both networks are operated entirely by volunteers who donate both their time and money to the operation of nodes.

We believe that if the correct incentives are provided, networks like Tor and I2P can be grown and strengthened against attacks, and potentially provide a better service that extends beyond volunteering.

What Lokinet Does Differently

 

The combination of the Loki Service Node network and the underlying protocol of Lokinet (LLARP) provides a solution for the issues discussed with Tor and I2P. Lokinet operates without Directory Authorities and instead relies on a DHT built from blockchain staking transactions, which permissions each Service Node to act as a router on the network. In Lokinet, nodes are not sorted on performance by a centralised authority, but as the result of “Swarms” (groups of other service nodes) that assess each node and make judgements on their performance.

This process of decentralised registration in order to become a node on Lokinet also extends to de-registration. Lokinet enforces (by consensus) minimum standards for bandwidth, message storage and blockchain storage. This means when building circuits through the network of nodes, the speed at which packets will be sent and received will be much faster than other mixnets that still allow for slow nodes to route. Additionally, in Lokinet every Service Node also acts as an exit node allowing access to the wider internet, and not just internal services (which we call SNApps).

This high bandwidth low latency network architecture is achieved by not requiring Lokinet users to be nodes. Only Service Nodes (which, by their nature are proven to be high quality) are allowed to be connected to in the network. Lokinet actually disallows users to route packets in the system, meaning that Lokinet exposes a much lower attack surface for a Sybil attack due to the significant capital outlay required to begin Service Node operation. This means there will be a greatly reduced chance that privacy on the network will be compromised by correlation attacks.

Lokinet offers a strong array of incentives, more than any other mixnet currently in operation. Each Service Node is paid for the services they provide through block rewards, and instead of relying on volunteers, Lokinet relies on Service Node operators that are financially incentivised to act honestly and provide high levels of service to the network, increasing the value of their stake.

Why Do I Care About Any Of This?

 

We can build a system that provides users with a way to access the internet and internally hosted sites, faster and more anonymously than ever before.

Powering this whole network is the Loki cryptocurrency which will also be implemented right into the Lokinet browser (similar to the Tor browser). Users who set up internally hosted sites will be able to accept payments anonymously and will also be contactable through the the Loki browser without ever having to leave the network.

How Far Along Are You?

 

Over the last 3 months, we have been working hard on LLARP (the underlying routing protocol).

For those curious about the acronym, it stands for, “Low Latency Anonymous Routing Protocol”. Currently most of the code is infrastructure code, and our progress can be seen here. 

Lokinet is still quite a while away, and as always we will keep everyone updated on our progress. Additionally, if you’re a developer or a keen code monkey, please reach out to us or start contributing by making a pull request, issue etc. We have bounties set aside for open source development.

Who Is Working On This?

 

We’ve hired a couple of network programming specialists. First, we have Jeff, who has a lot of experience working on mixnets. You might have seen him roaming around in the Loki discord. He has worked on I2P extensively (specifically the C++ implementation of I2P called I2PD), and he also worked briefly on Kovri. Second, we have Ryan, who is a network application developer and has worked across a number of low latency streaming platforms with a focus towards network engineering. You can check out both of their github profiles below.

https://github.com/majestrate

https://github.com/neuroscr

 

I Want More Details! Give Me The Protocol Definition & The Design Docs!  

 

What a specific request… SURE! You can find both here, in the readme.


[1] “Tor Project: Docs.” https://www.torproject.org/docs/faq#KeyManagement. Accessed 12 Jun. 2018.
[2] “Possible Upcoming Attempts to Disable the Tor Network | Tor Blog.” 19 Dec. 2014, https://blog.torproject.org/possible-upcoming-attempts-disable-tor-network. Accessed 12 Jun. 2018.
[3] “Identifying and Characterizing Sybils in the Tor Network.” 25 Feb. 2016, https://arxiv.org/abs/1602.07787. Accessed 21 Jun. 2018.

Weekly Dev Update #2

Hey Team,

Back again with another weekly update.

Service Nodes


Android Mobile Wallet


Architecture Team

  • White paper V3 moves into editing phase, cleaning up the finer points and making sure all of the wording is correct, content is all in.
  • Economic white paper describing staking requirements is 30-40% done, we are in the process of engaging a number of Universities to seek expert advice in the model we will present.

We also have still have some active pull requests to Monero, which is delivering on a promise we made a few months ago that we would upstream changes we found valuable. https://github.com/monero-project/monero/pulls/jcktm

Thanks,
Kee

Weekly Dev Update #1

Hey Team,
I’m going to start giving weekly updates on what the development team is up to. It can be hard for the community to see what we’re working on as we sometimes operate out of our own Loki forks, then merge back when things are ready to move into production. My hope is that these updates will shed light on the project’s development.

This weeks updates

Service Nodes


Android Mobile Wallet


Architecture Team

  • Continued work on White Paper Version 3, especially focusing on governance models and Swarm testing. You can join in on the governance discussion on discord here .
  • Began writing a paper to justify decisions to change the dynamic collateralisation equation and present a clear and defined economic case for the staking requirement.

We also have 4 active pull requests that add small functionalities to Monero, which is delivering on a promise we made a few months ago that we would upstream changes we found valuable.

There’s heaps more exciting stuff going that we can’t talk about just yet (mixnets, wink wink), but we’ll keep everyone updated as we progress.

Thanks,  
Kee