Jump to content

Loki

Sign in to follow this  
  • entries
    236
  • comments
    0
  • views
    34372

Entries in this blog

Snider

We’ve talked a lot about the benefits of Proof of Stake for the Loki blockchain, but there’s another huge upside to PoS compared to our old hybrid PoS-PoW consensus mechanism: it’s a lot kinder to the planet.

grinch-1.png

Proof of… Harm?

Proof of Work — the system many people know as “crypto mining” — has some very real benefits when it comes to securing blockchains. But it has some nasty downsides, too, and one of the worst is power consumption. To dive into exactly why that is, we need to take a brief look at what Proof of Work actually entails.

Fundamentally, “mining” crypto through Proof of Work means competing with other miners to solve mathematical problems. The first worker to solve a problem attaches the solution — the literal proof of work — to a “block” of crypto transactions, marking those transactions as valid and adding them to the blockchain. Seems simple enough, right? 

Well, yes and no.

The average user’s desktop PC draws anywhere between 300 and 500 watts of power when it’s being pushed to its limit. A dedicated crypto mining rig, with an array of high-powered graphics cards or dedicated ASICs, can draw several thousand watts — and those rigs are often left on 24/7, maximising the chance of solving blocks to get that sweet, sweet block reward.

When you consider that there are millions of people mining different crypos all over the world, all that power usage adds up.

It was estimated that in 2017, Bitcoin mining alone used over 30 terawatts of power globally — that’s more electricity than the entire country of Ireland consumes in a year. When you factor in all the other Proof of Work cryptocurrencies, and the fact that the number of miners is only going up, crypto mining is consuming a truly insane amount of electricity. And when the vast majority of electricity worldwide is still drawn from non-renewable sources like coal and gas, crypto mining starts to look like a serious environmental crisis in the making.

Go green or go home

So what can we do? Simple — ditch PoW. Proof of Stake and other alternative consensus mechanisms don’t rely on competitive problem-solving in the same way Proof of Work does, making them exponentially more power-efficient and significantly reducing their impact on the environment.

And when Proof of Stake has so many other benefits for the blockchain ecosystem too, it’s even more of a no-brainer.

With Salty Saga and Pulse, Loki isn’t just setting up our ecosystem for the next decade of crypto — we’re doing what we can to help the planet by massively reducing the Loki blockchain’s carbon footprint.

The post Pulse for the planet: How Salty Saga makes Loki greener than ever appeared first on Loki.


View the full article

Snider

Mumble is a  fantastic open-source voice chat platform known for its reliability and ease of use.

And Lokinet is a cutting-edge onion routing network that offers unparalleled security and anonymity potential.

Well what if you could run a Mumble server over Lokinet, combining Mumble’s ease of use with Lokinet’s security and anonymity to create the ultimate secure voice chat service? In this article, we’re going to cover how to do exactly that — with just 15 minutes of your time and $3 a month, you and your organisation can create one of the most secure voice chat platforms possible. 

A Mumble server running over Lokinet on a server you control gives you absolute certainty that your voice conversations, associated metadata, and other Mumble activity cannot be stored or recorded, because no computer ever knows who is talking to whom — not even the Mumble server itself. So long as you trust the device that you run the Mumble server on (which you can, because it’s yours), you can be certain that no one else on earth can eavesdrop on your conversation — or even know that you’re connected to the server at all.

If this is your first time using SSH and Linux stuff, don’t stress. We’ll walk you through every step! With that, let’s get to it. 

Step 1: Rent a VPS

The first thing you’ll want to do is rent yourself a VPS (Virtual Private Server) to host your Mumble voice chat server. You could run the Mumble server from your own computer instead, but if you want the server to stay up 24/7, without having to leave your own PC on all the time, a VPS is the way to go. Mumble’s chat server has extremely low system requirements, so a VPS with any amount of storage and at least 512MB RAM will do the trick — you can find VPSs that meet these requirements for around US$3 a month. 

Try https://www.hetzner.com/cloud, or https://evolution-host.com/vps-hosting.php if you want to pay in Loki/Oxen! When ordering, select Ubuntu 20.04 or Debian 10.

Step 2: Prepare your VPS

Once you have access to your new VPS, you’re almost ready to install Lokinet, but there’s a little bit of preparatory work to do first. Start by opening a command prompt on your local machine (Terminal on macOS, any command prompt on Linux, or PowerShell on Windows 10). SSH into your VPS with this command:

ssh root@[VPS IP address]

Replacing [VPS IP address] with the IP of your VPS.  It’ll prompt you for a password which will usually be provided to you by the VPS host. More advanced users can and should disable root password access and instead use SSH keys, but if that sounds hard, don’t worry about it for now. As you learn more about Linux, you’ll get more familiar with these best practices.

Once you’ve logged in, we’re ready to roll. First, we’ll update our package lists to make sure our VPS sees the most recent versions of all available packages. Type:

sudo apt update

You’ll see a bunch of package lists being downloaded. Once this command completes, run the following command to upgrade any outdated packages currently installed on the VPS:

sudo apt upgrade

We’ll also need to make sure the curl command is installed before we proceed. Run this command:

which curl

It should output the location of your installed curl command. If you get an error, install curl:

sudo apt install curl

Then run which curl again to make sure curl is installed. 

Success? Congrats, you’re ready to move on to the next step:  

Step 3: Install Lokinet

To install Lokinet, we need to add the Lokinet repository. Run the following command to install the public key used by the Lokinet dev team to sign Lokinet binaries:

curl -s https://deb.imaginary.stream/public.gpg | sudo apt-key add -

Then run the following command to tell apt where to find the Lokinet packages:

echo "deb https://deb.imaginary.stream $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/imaginary.stream.list

Next, update your repository package lists again with:

sudo apt update

And now, install Lokinet:

sudo apt install lokinet

Congrats, Lokinet is now installed and running in the background. We’re nearly there.

Step 4: Installing the Mumble server

Run this command:

sudo apt install mumble-server

That’s it. The Mumble server is now installed. On to Step 5:

Step 5: Setting up a persistent keyfile

This step is a bit more involved. We need to set up Lokinet to always generate a keyfile in the same directory, so it will work consistently. Linux servers don’t have a graphical interface, but they do ship with some in-terminal text editors. We need to edit a file now, so start by opening your lokinet.ini file with this command:

sudo nano /etc/loki/lokinet.ini

Using the arrow keys, move the cursor down to the [network] section of the file. Remove the # from before the “keyfile=” line, then add the following after the = symbol:

/var/lib/lokinet/mumble.private

Then hit Ctrl+X. Type “Y” (for yes) when asked if you want to save your changes, then press Enter to save and exit.

Now that you’ve exited nano, you’re back in the terminal. Restart Lokinet to generate a keyfile for Mumble:

sudo systemctl restart lokinet

Step 6: Binding the Mumble server to Lokinet

Now we need to make sure your Mumble server is using Lokinet for all traffic. Start with this command to grab the IP address we need to bind Mumble to:

dig @127.3.2.1 +short localhost.loki

This command will output 2 strings of text: a long string of random letters and numbers ending in .loki, and an IP address (a number in the format xxx.xx(x).x.x). 

Select and copy (Ctrl+C on Windows or Linux; Cmd+C on macOS) the IP address. Some SSH clients allow you to copy by highlighting the text and right-clicking on it as well.

Now, we need to point the Mumble server to that IP address. Use this command to open the configuration file for the Mumble server:

nano /etc/mumble-server.ini 

Using the arrow keys, navigate down to the line “;host=” under the section Specific IP or hostname to bind to. Delete the ; from the start of the line, then paste the IP address we copied earlier after the = symbol. Hit Ctrl+X to exit. Type “Y” when asked if you want to save your changes, then press Enter to save and exit.

Back at the command line, restart the Mumble server to apply changes:

systemctl restart mumble-server

Step 7: Done!

Congrats! A Mumble server is now up and running on your VPS, and all its traffic is being routed through Lokinet. All that’s left is to grab the Lokinet address of the Mumble server and give it to anyone you want to be able to connect. In case you missed it, run this command to find the Lokinet address of the Mumble server:

dig @127.3.2.1 +short localhost.loki

This is the same command we ran earlier, but this time, pay attention to the long string of characters ending in .loki (be sure to include the .loki part). This is the Lokinet address of your secure, onion-routed Mumble server. 

Copy this address and provide it to anyone you want to be able to connect to the server — all they have to do is paste the address into the Address field of the Add Server dialog in the Mumble client, add a username and label to identify the server, hit OK, and connect!

Mumble can be downloaded for free on all major platforms. Anyone that wants to access your secret Mumble server will also need to have Lokinet installed and running. To download and install Lokinet, just head to https://lokinet.org/. Further Lokinet guides can be found at https://docs.loki.network/Lokinet/LokinetOverview/.

And that’s it! Only 15 minutes and $3 later, you can now have completely surveillance-free conversations over the internet. We hope to integrate voice features into Session to make it even easier to access secure voice channels with this level of privacy and security. 

In the meantime, though, this Mumble/Lokinet setup is perhaps the most secure voice channel option available. This unique combination of services is just one example of the power of the Oxen tech stack — stay tuned for more guides and articles about what Oxen’s tech can do. 

Have fun!

The post 15 minutes and just $3 a month: Putting the most secure voice service at your fingertips appeared first on Loki.


View the full article

Snider

Weekly Dev Update #128

Hey Y’all, 

This week the Lokinet team continued working on fixes for the Mac release, which had some unresolved issues in the installer/uninstaller. The Loki Core team worked on the 8.1.4 release, which fixes a few issues exchanges were encountering and adds some new features to the wallet which are likely to be used in the Chainflip Service Node airdrop. Capping things off, the Session team began a large refactorisation effort which we will be talking about publicly in the coming weeks. 

Loki Core 


Lokinet

You can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What went on last week with Lokinet: Various PRs to fix various minor Linux, Windows, and macOS bugs found since last week’s 0.8.1 release.  We’re nearly ready for an updated release for Linux/Windows (and initial 0.8 series release for Mac) with just a couple small issues left before the release.

Lokinet PR Activity:


Session

Session iOS 

Session Android

Session Desktop


Thanks,  

Kee 

The post Weekly Dev Update #128 appeared first on Loki.


View the full article

Snider

Lokinet exit nodes have been on the bucket list for Lokinet since launch — and this week, exits have entered the building.

That’s right, this is not a drill, Lokinet exit node functionality is making its way to a Lokinet client near you. If you’ve been following Lokinet for a while, you’ll know just how big of a deal this is. But if you’re new to the Lokinet landscape, or just want to brush up on the basics of onion routing, you’ve come to the right place.

Lokinet exit nodes: How they work, what they do, and what they mean for you

In a nutshell, Lokinet exit nodes allow you to onion-route all your internet traffic over Lokinet. Every site you browse, every meme you share, every video you stream — all that traffic is completely anonymised by Lokinet’s onion routing. With exit nodes, Lokinet functions similarly to a VPN — but better. Let’s break down how all that works.

When you enable exit node browsing and connect to an exit node through the Lokinet client, your traffic is encrypted multiple times, once for every node it will travel through, then sent to a Lokinet “edge node” — your entry point to the Lokinet network. That node forwards your traffic through the network until it reaches a “pivot node”, which knows the location of the exit node you’re connecting to. That pivot node then relays your traffic — still fully encrypted — to the exit node. The exit node then decrypts your traffic and forwards it to its destination. The process for incoming traffic is the same in reverse.

Diagram-1-01-1024x193.pngA typical Lokinet exit node path

But hold on a minute. The exit node decrypts your traffic? How anonymous can this be if the exit node knows what you’re sending and receiving?

The answer is simple: the exit node may know what traffic is passing through it, but  it never knows who is sending or receiving that traffic. If you connect to a Lokinet exit node to send dankmeme.gif to someone on Facebook, the exit node may know that you’re sending something to someone on Facebook — but it won’t know who is sending it. And if the traffic is secured using HTTPS, the node won’t know exactly what you’re sending, either. Your ISP will know that you’re connected to Lokinet, but they won’t know whether you’re even connected to an exit node. And because Lokinet is fully decentralised, unlike VPN providers, there’s no central authority that can log your IP address, even if they wanted to.

When you’re browsing through a Lokinet exit node, no other server, anywhere on the internet, ever gets the complete picture about what you’re accessing. The first Lokinet node you connect to will know your IP address, but because your traffic is already fully encrypted, that node won’t know what you’re sending or receiving — all they know is that you’re using Lokinet in some way. The nodes in between that node and the exit node know absolutely nothing — they can’t see your IP or the contents or destination of the traffic they’re relaying; all they see are unreadable packets of data that they need to pass along the chain. And the exit node decrypts your traffic, but that node has no clue who sent it. Full anonymity, powered by Lokinet.

Lokinet exit node release: What works, what doesn’t, and what we want to know

In a nutshell, everything should “just work”. You should be able to enter an exit node’s details in the Lokinet client, enable it, and voila — you should be browsing the clearnet through Lokinet. You can check whether it’s working by using a site like WhatsMyIP: load it up before connecting to an exit node, check your IP, connect to an exit node and check your IP again. You should see your IP change once you’re browsing via Lokinet.

Wondering where to find those exit node details? There’s currently one exit node available, accessed via this address: exit.loki

However, there are a few provisos. There may be some service disruptions during this initial period, as until more nodes become available, everyone will be using the same exit node — the node may experience performance bottlenecks with all that traffic running through it. And if you’re hoping to use Lokinet exits to stream Netflix, you may run into issues. Netflix blocks most known VPS providers, so depending on where the exit node you’re using is hosted, you might not be able to anonymously catch up on Stranger Things.

We’ll be keeping our ears to the ground for any and all bug reports and other issues you might encounter. If you run into any issues with the GUI, problems connecting to or using exit nodes, or anomalous CPU or memory usage, let us know and we’ll look into it. We’d also love to see some SpeedTest results with exit nodes enabled — it should be pretty smooth, but the proof is in the pudding. And if you have any other feedback, questions, or suggestions, don’t hesitate to reach out.

Happy anonymous browsing!

The post Lokinet exit nodes: Onions gone wild appeared first on Loki.


View the full article

Snider

When the Salty Saga hardfork landed, we made the decision to set aside 6 LOKI per block for the first six months following the hardfork as a fund to incentivise liquidity for Chainflip and wLOKI. With the recent announcement that Chainflip will be forming its own blockchain, this is no longer necessary, because Chainflip can provide its own incentives. 

With that in mind, the Loki Foundation has resolved to burn this liquidity provision.

This will be the largest public burn in Loki’s history. While that is the most important part of this announcement, in the interests of transparency, we will outline more information about the burn in this article. 

How the liquidity provision worked

The liquidity provision was to be paid out at 6 LOKI per block, starting at height 641,111. However, this is actually only paid once a week, at heights divisible by 5,040. This means that the first reward was actually received at block height 645,120, then 650,160, and so on, with the final reward scheduled to be received at block height 766,080. 

Each reward is 42,840 LOKI — with 30,240 of that being the provision, and 12,600 being the governance reward. Twenty-five rewards are set to be received over the 6-month-life of the provision, totalling 756,000 Loki. 

As things stand, the liquidity provision will automatically terminate at block height 770,711, and it would require a hardfork in order to remove the 6 LOKI per block reward any earlier. Although there may be a hardfork before this, we’re not planning to complete a mandatory upgrade solely to amend the block reward before block height 770,711. 

Mandatory upgrades require a lot of coordination and administration on the part of the Loki Foundation, the Loki team, and the Service Node operators who run the network. To keep things as simple and transparent as possible, all of the unused rewards received as a part of this provision will be publicly burnt. Burning is already enabled by the Loki blockchain, and is regularly used for Blink transaction fees as well as Loki Name Service Registrations. This means we can complete the burn using a modified wallet without making any changes to the blockchain itself.

How much of the liquidity provision was used

Because Chainflip has only been in internal testing thus far, the liquidity fund has only been used to incentivise wLOKI liquidity on Uniswap. 

The first two rewards (totalling 60,480 LOKI) were used as a part of the wLOKI incentive scheme, which successfully bootstrapped liquidity on Uniswap.

This leaves 695,520 LOKI which will be burned.

For now, there are no immediate plans to run future incentive schemes for wLOKI on Uniswap, but the experience garnered from creating wLOKI, forming the Uniswap pair, and building the wLOKI bridge has already been of immense value to the project.

Come and talk to us

The decision to burn the Loki which was set aside for Chainflip liquidity makes the most sense for the project — and is hugely positive news for the Loki community, given that a large amount of LOKI is now scheduled to be publicly burnt. 

While burning is the simplest solution for this specific provision, we’re still interested in setting aside parts of the reward in the future for either liquidity or other community projects. However, this reward was approved by the community and the Foundation specifically to provide liquidity incentives for Chainflip, and it wouldn’t be appropriate for us to redirect these funds for anything else. In the interest of including the community in all major decisions regarding the project, we will re-consult with you about any new rewards, liquidity provisions, or funding for other projects.

There will also be an upcoming LRC to discuss the overall emission scheme of the project. Keep an eye out for an announcement about that — as per usual, we invite everyone in the community to come and offer their thoughts and opinions.
With that in mind, if you do want to talk to us about the burn — don’t hesitate to reach out to us via our Telegram community, Twitter, emailing team@loki.network, or any of our other social channels.

The post Let it burn: What we’re doing with the Loki Liquidity Provision appeared first on Loki.


View the full article

Snider

Hey Y’all, 

This week we released exit node support for Lokinet, with a new Windows and Linux GUI client. On the Session side of things, the team continued its work re-factoring the sending and receiving pipelines on iOS. Meanwhile, the Loki core team focused on some required patches for the 8.1.3 release, as well as some new features such as signing ASCII strings using your wallet keys. 

Loki Core 


Lokinet

You can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What went on last week with Lokinet: We got the Lokinet 0.8.1 release for general use out the door last week for Windows and Linux users. On macOS we ran into some last minute issues which warranted holding back for some fixes — which we should have ready to go this week (along with a few other small fixes for Windows and Linux for minor issues that have been reported in the past few days). This means Lokinet users can start accessing sites via LNS names, and can start experimenting with exit node support! We’d love to get your feedback on what works and what doesn’t so don’t be afraid to file bug reports or come talk to us directly.

Lokinet PR Activity:


Session

Session iOS

Message sending and receiving pipeline refactorisation https://github.com/loki-project/session-ios/pull/313, https://github.com/loki-project/session-ios/pull/311, https://github.com/loki-project/session-ios/pull/308 

Use LSRPC /v3 & fix open group profile picture bug https://github.com/loki-project/session-ios/pull/310 

Fix sender keys issues https://github.com/loki-project/session-ios/pull/312

Session Android

Session Desktop

Thanks,  

Kee

The post Weekly Dev Update #127 appeared first on Loki.


View the full article

Snider

You might not have heard about it yet — but Lokinet just got a massive update. The release of Lokinet proof of soon (yes, that’s what it’s called) brings two major upgrades to Lokinet’s usability and functionality: exit node functionality and LNS integration. 

Where we’re going, we need exit nodes

What’s an exit node, you ask? Well, when you used older versions of Lokinet, you were only surfing Lokinet, not the internet. The things that make Lokinet what it is — onion encryption and Service Nodes — didn’t play nice with the regular ol’ world wide web. While everything functioned properly when you’re accessing SNApps inside the walled garden of Lokinet, venturing to the wider plains of the internet was going to take a little bit of extra work. 

To roam the wide open plains of the internet at large with all the anonymity protections of Lokinet, we needed something called exit nodes

qvxcgcANYU05DXSRJzO0b5kmvM-QxsOXK9_f822A

Exit nodes are the gateways between Lokinet and the clearnet — websites on the ‘normal’ internet. Facebook. YouTube. Google. Amazon. With exit nodes, all of them can be accessed through Lokinet. 

Want to watch a video without being haunted by related ads for the next two weeks? 

Want to access content that isn’t available in your country :(? 

Well, now you can. 

The release of exit node functionality opens up a whole new world of possibilities for Lokinet. As you might already know, Lokinet is unlike any other onion router. It operates on the protocol layer, so it’s the first onion router with exit functionality that can actually deliver speeds that won’t give you dial-up flashbacks — and it works with practically any application out of the box. With exit node functionality, Lokinet can effectively be used as though it’s a supercharged VPN — to protect and anonymise your day-to-day internet usage.

Getting it set up is incredibly simple. All you have to do is open the Lokinet GUI and type in the address of the exit node you would like to use. For now, there is only one — exit.loki — and it doesn’t require an authentication code. Once you’ve input the address of the exit node and started Lokinet, you can start browsing the internet in sweet, sweet privacy. 

Say my name, say my name

Although exit node functionality is the biggest upgrade to Lokinet yet — this next feature might be a close second. We have now released full LNS integration for Lokinet. If you’ve used Lokinet before, you will know that addresses look something like this: 

http://dw68y1xhptqbhcm5s8aaaip6dbopykagig5q5u1za4c7pzxto77y.loki/wiki/

Not that easy to remember. With LNS, addresses can be anything. You could have net.loki, privacy.loki, or even loki.loki. This will make sharing and remembering Lokinet sites much, much easier in the future. 

We’ve already got a couple of Lokinet sites up and running that are using LNS, and you can test them out right now: 

Arweave.loki

Blocks.loki 

Get in on the action

There has never been a better time to start surfing on Lokinet. At the moment, exit functionality is live and operational on Linux and Windows, and the macOS version will be arriving shortly. 

You can grab the latest version here and start using Lokinet to secure all the internet traffic on your computer — whether it’s in your browser, an email client, or a messaging app (we’ve heard of one you might like). 

The post Lokinet gets exits: to the clearnet, and beyond! appeared first on Loki.


View the full article

Snider

Introduction

Since we started in 2017, Loki has grown exponentially. After beginning as an ambitious Monero fork, our scope has dramatically expanded into a full privacy suite: a private messaging app, an onion routing network, a private PoS cryptocurrency, and a foundation dedicated to building and supporting free, accessible, decentralised, open-source privacy tools. 

We have proven ourselves to be a community-first, transparent, development-led team. Always have been, always will be. We work for our community, and we’re always adapting to make sure we’re bringing value to the project and providing you with the best applications possible.  In recent months we announced our foray into the DeFi space with our support of Chainflip, a decentralised cross-chain asset swapping service being built on Loki. Chainflip has been met with enormous excitement and support from the Loki community, and the initial centralised version (beta) was due to be released this month.

However, recent developments in the regulatory landscape have made us pause and consider the best way forward for both Chainflip and the Loki Project. The knock-on effects of those recent regulatory developments are far-reaching, and they’ll have dramatic effects on the crypto space as a whole — so the Chainflip team has been hard at work finding the best way forward for the project. 

While the Chainflip team has been planning for their future, we’ve also had the opportunity to take a step back and consider our overall strategy at Loki. You might’ve noticed things have been unusually quiet for the last month or so. That’s because we’ve been busy behind the scenes intensely planning the next big step for Loki, and now we’re ready to share it with you. 

At Loki, we care deeply about what we’re building, the community that has helped make it possible, and the potential of all of the incredible technology already under our belt. The question we’ve been working to answer is: how can we ensure all our projects have the opportunity to reach their full potential? How can we ensure that all of our products and technologies remain relevant and growing, not just for the next year, but for the next 5 years and beyond?

What we’re announcing

Today, we’re announcing some radical changes that will future-proof the project, our product suite, and our commitment to free, open-source decentralised privacy tools. There’s a lot going on at Loki, and this is quite a dense set of announcements. We’re sure you’ll have questions after this first round of announcements, so please join CEO Simon Harman and CTO Kee Jefferys for a live community roundtable later today (Tuesday November 10) at 4pm AEDT. Simon will also be running additional AMA sessions at 10am AEDT on Wednesday November 11, and at some point on Thursday and Friday (times TBC), to ensure we can answer all your questions and respond to all your feedback throughout the week. Submit your questions through Menti or share them in our community chats and social channels — we’ll be sure to address every question we can.

With that, let’s get into the announcements!

An evolution for Loki

The word Loki is something that means a lot of different things to a lot of different people. Loki has already evolved an incredible amount over the last 3 years. Our technology stack continues to grow, with a wide range of tools and protocols that make developing decentralised secure applications much easier — not just for us, but for everyone. We’ve built Session, Lokinet, and all of the utilities on the Loki Blockchain itself, and in so doing, we’ve also built a number of libraries, protocols, and other tools to make these decentralised applications possible.

The answer to the question “What is Loki?”  depends on who you ask. Some people are deeply interested in the power of the Loki blockchain. Others see the importance and potential of Session, and will mostly describe Loki in terms of secure messaging. And some love Loki for Lokinet, and can see a bright future for  a crypto-backed competitor to Tor and VPN services. Finally, there’s Chainflip — the newest member of the family. Lots of people are super excited about the prospect of Chainflip, and for some it was the first time they’d ever heard of Loki.

The Loki Project has so much depth, so many tools, and so much utility that it can be hard to summarise all the things this project does. For those that do their research, it’s a compelling, interesting, and promising project with abundant possibility. But the feedback we’ve received suggests that to most newcomers, the Loki Project comes across as a bewildering array of seemingly unconnected products and features. The same principle applies to our current technology stack: there’s a lot there, but it’s very hard for external developers to understand, contribute to, and most importantly, leverage to their own advantage. 

Above and beyond this confusion, the Loki brand itself — while beloved in the Loki community — is seen as old and outdated by many key players in the crypto industry. To put it bluntly, this is limiting the project’s growth potential. The wider crypto market seeks out fresh brands with fresh narratives, and our marketing team has gotten bigger, better, and more capable of creating and building more compelling brands than Loki — brands like Session. Now, it’s time for us to convert our branding expertise into market capitalisation. While we love the name Loki, and we are sure many in the community do too, the name carries too many negative connotations in the wider market — connotations that make it difficult for us to reach new network participants.

Today’s announcements aim to begin the process of addressing these issues. Loki is growing and evolving, and in recognition of this evolution, the entire project is being renamed and rebranded. 

OXEN: A new era for Loki

As we’ve already said, the network we’ve built has grown, and shown that it’s easily capable of powering applications like Session and Lokinet. But the Loki Network can be a whole lot more than just the applications we’re developing.

With everything we’ve built — it’s time to hand over the keys to the Ferrari.

The tools, protocols, and libraries we’ve built can power much more than just Session and Lokinet. They can be the building blocks everyone uses to create a new wave of privacy technologies.

Of course, we’ll still be hard at work developing Lokinet and Session as well, but all of the late nights and double espressos that go into our work won’t just benefit those applications, but an entire ecosystem of development utilities. Oxen won’t just be the backbone of our products, but the fabric we all use to weave a privacy revolution.

Oxen gives developers looking to enhance their products with greater privacy and security a real package to work with. We haven’t widely talked about what we know is possible with the Oxen stack, because until more recently, that stack didn’t exist. But now, we’ve built it. Three years in, it’s mature and robust, and we’re excited to see other technology companies, projects, and communities use the Oxen stack to make things like: 

  • A truly encrypted Slack/Mattermost competitor
  • Truly encrypted voice and video call service (Yes, much better than Zoom or Jitsi, which aren’t really that well-secured at all)
  • Peer-to-peer networking replacement library for blockchain projects (much easier to deploy than libp2p, for instance, due to common features with ZMQ)
  • Onion VPN marketplace powered by Oxen
  • Secure onion-routed HTTPrequest library (onion requests) used to secure simple web traffic between client and server without requiring a VPN or OS level support
  • Redundant messaging utilising the swarm protocol (superior protocol to Bitmessage)
  • Virtual LAN functionality to enable private networks to form on the public internet (a more versatile, easier-to-use version of Hamachi)

Truthfully, this is much closer to the original vision of Loki — using staked nodes to provide services. The scope of the Oxen network isn’t limited to the potential of Session and Lokinet. While they’re great examples of some of the possible applications of the Oxen stack, so much more can be done. 

2020 has made it obvious that there is a demand for privacy in all areas of digital communication and collaboration. Zoom is the most talked-about piece of technology of the year — and it’s been widely panned for its privacy and security failings. Tools like Slack, Microsoft Teams, Discord, WebEx, and Trello have become essential to the daily operations of people around the world. These tools are useful, but their models for privacy and security are lagging behind. 

The Oxen stack is the answer to this problem. 

We’re not just talking about a few purpose-built privacy tools. We’re talking about empowering the most-used technologies in the world to become properly private and secure with relatively straightforward implementations and integrations. 

When we set out to make Session and Lokinet, this didn’t exist. We’ve had to build it ourselves, but now — everyone that comes after can stand on our shoulders. Privacy should be a non-negotiable part of modern technology, but a lot of the time it gets dumped in the too-hard basket. 

Oxen puts privacy at the fingertips of developers and users alike. And to slingshot adoption of Oxen’s tech stack into the exosphere, we’re spinning up a new business development division to create new opportunities and build relationships with developers and organisations who will benefit from leveraging Oxen’s tech stack. This active stance will radically increase adoption and use of our technologies across every sector we’re involved in, and help to ensure that both the Oxen project and the wider technology ecosystem will benefit from what we’ve built.

Over the coming days, weeks, and months, Loki will evolve into Oxen. You’ll start to see the changes rolling in as you get a taste for the new brand, new tickers pop up on places like CoinMarketCap, and a brand-spanking-new website. We’re excited to take you on the journey with us — the journey from Loki to Oxen. As Loki, we’ve already accomplished so much together, and as Oxen we’ll do even more. 

You’ve probably noticed that we haven’t mentioned Chainflip’s place in Oxen’s bold new plan just yet — and that’s because Chainflip has a bold new plan all of its own. Just like Oxen, there are lots of exciting new developments for Chainflip that we’re sharing with you today.  

What’s next for Chainflip 

The Chainflip team’s original plan was for Chainflip to be rolled out in several stages, each with decreasing levels of centralisation. That’s no longer possible, and although the initial centralised version has essentially been completed, releasing it as is would be unacceptably risky. To address this, the first version of Chainflip will now be fully decentralised — but this means extra development resources will be required to deliver Chainflip in a timely manner. Today, we’re announcing some changes which will give Chainflip the resources it needs to grow quickly, while ensuring that our major projects — Oxen, Lokinet, and Session — can continue to be developed without interruption.

Chainflip was always going to take significant work to build — and this is doubly true if it’s going to be decentralised from day one. Having said that, completion of the centralised version is still an enormous milestone for Chainflip— it will accelerate testing and development of the decentralised version. The current version has been modularised so that each of the components can be decentralised independently of one another, which means the Quoter and front-end work is already largely finished.

With that in mind, the process of building the decentralised version of Chainflip could really benefit from extended resources. The DeFi space is growing quickly, and we think Chainflip is one of the most crucial additions to the ecosystem. At the moment, there is a gap in the DeFi ecosystem — trustless asset swapping services with a positive permissionless user experience. This is a hole Chainflip will patch, and as the DeFi industry matures, it’s a gap that needs to be filled. 

We want the Chainflip team to have all the resources they need to bring a fully-fledged version of the product to market as soon as possible. Chainflip needs its own blockchain to fulfil its potential.

With its own purpose-built blockchain, Chainflip will be delivered more quickly, more completely, and be well positioned to succeed as a long term project. Although it would still be possible, using the Loki blockchain would hold Chainflip back from both a technological and regulatory perspective. We want to deliver the best version of Chainflip, and this is the best way to achieve that.

With this plan, both Oxen and Chainflip will thrive. Not only will Chainflip have everything it needs to succeed, but we won’t have to divert any resources away from Oxen or its projects like Session and Lokinet. The Oxen community will be rewarded for all of their support for the project. Further, because the Foundation has already contributed to the Chainflip project, it has negotiated with the Chainflip team to ensure that this new direction for Chainflip will be significantly beneficial for the Foundation, too.

Chainflip ICO and OXEN swapping program

Now that Chainflip is standing on its own two feet, it’s going to need its own resources. Chainflip will be completing a fundraising round in order to give itself all the tools it needs to rapidly accelerate development timelines and ensure the product is released in a fully decentralised manner with all of the proposed features.

This way, the fully realised version of Chainflip will be delivered to your doorstep as soon as possible.

Loki has been a huge supporter of Chainflip, and there are plenty of people holding Loki because of their interest in the product. Chainflip wants to recognise those people, and so in order to bootstrap its own community, the project will be offering a token burning program using LOKI/OXEN. As much as 9% of the presale supply will be made available to swap LOKI/OXEN at preferential rates for Chainflip tokens. This program will be rolled out in 3 tranches at decreasing rates in each round, meaning the sooner users participate, the better rate they’ll get per LOKI/OXEN token. There are also plans being put in place to preference current SN operators at the best swap rates in the first round of the burn in recognition of the work they provide. This swap program gives current LOKI/OXEN holders the opportunity to decide whether they want to stay involved with both Oxen and Chainflip, or merely one or the other — without having to buy any new tokens to do so.

After the successful issuance of the main Chainflip token, the LOKI/OXEN collected in this program will be publicly burned. Details on the burning program will be released in the coming weeks, as there are still some important legal questions to be answered surrounding the specifics of this program.

Chainflip is still in the early stages of fundraising, and while entities are being spun up and legal advice is being finalised, very few details can be shared publicly. Based on early conversations, and with pre-seed funding already secured, lots of work has already been completed that — depending on the outcomes of the legal advice — could allow Chainflip to close the private components of the presale by the end of the year.

For the time being, though, the only way to gain exposure to Chainflip tokens is by holding Loki and waiting for the burning program. We believe this fact will stimulate organic demand for Loki as the project makes the transition to Oxen. 

As for the 6 Loki per block that was earmarked for incentivising Chainflip liquidity,  that allocation may be retargeted to support other aspects of the project — like further incentivising Service Node operators or supporting other community projects — or possibly removed entirely. We’ll consult the community in the near future about the best way to utilise this part of the block reward going forward, and your input will be key to this decision.

Session and Lokinet: The future is bright

Meanwhile, Session and Lokinet are full steam ahead. 

Lokinet is about to get a rebrand all to itself. We’ve already mentioned this a couple of times over the last few months, but the rebrand is now getting close to being fully released. Over the years, our marketing team has gotten a lot better at building and establishing striking brands — and Lokinet is ready for a new look. On top of a completely overhauled visual identity, Lokinet will be getting a new name — just in time for the much-vaunted imminent release of exit node functionality. 

We think Lokinet’s exit node marketplace is going to solve a lot of the problems faced by current traffic-anonymising applications. Of course, Tor has long been both a bulwark and a trailblazer in the privacy community, but it suffers from crippling speed and user experience issues due to being an application-layer protocol. You can download Lokinet right now and see for yourself its speed and ease of use. Likewise, while VPNs offer convenience and ease of use — they can only offer so much protection. A plug-and-play onion routing network like Lokinet represents a huge leap forward for anonymous internet usage, and we’re actively seeking out VPN companies to plug their existing VPN infrastructure into the Oxen onion VPN marketplace, which will help bootstrap the network’s capability and bring traffic to the Oxen marketplace.

On top of this, Session is already a fully-functioning product that thousands of people are using every day. Earlier this year, we showed that we can drive huge user numbers for Session. We have the data, we know we can do it. Session already has over 400,000 downloads. Our marketing efforts were put on pause to give our Session developers some wiggle room to polish the app — but now it’s ready. Session is in the best place it’s ever been, and we’re just about ready to unleash the marketing budget and strategy that we’ve been building up for the last six months. Session is ready to become a truly mass-market messaging app, with plans in place to grow the user base to over 1,000,000 users in 2021.

Oxen will be at the vanguard of a privacy technology revolution. Session and Lokinet are proof of the incredible applications that can be built using this platform, and now the tech stack we’ve spent three years building along the way can be put to work — for the benefit of the entire privacy community. 

Of course, this is a lot of information to come out all at once. We are extremely excited about these changes, and we invite you to come and speak with Kee and Simon later today (Tuesday November 10) at 4pm AEDT on YouTube — keep an eye on our socials for a link. Simon will also be running additional AMA sessions at 10am AEDT on Wednesday November 11, and at some point on Thursday and Friday (times TBC), to ensure we can answer all your questions and respond to all your feedback. Submit your questions through Menti or share them in our community chats and social channels — we’ll be sure to address every question we can.

Welcome to Oxen. Loki, evolved.

The post Major project announcement: A bright future for Loki appeared first on Loki.


View the full article

Snider

Hey Y’all, 

This week the Session team worked primarily on refactorisation. On iOS, this refactorisation occurred in the sending and receiving pipelines, and on desktop it occurred as part of our ongoing effort to refactor elements of the application into React. The Loki Core team published the iOS and Android wallets, and fixed a bug that was causing transactions to temporarily display as if they had failed. The Lokinet team worked on DPI scaling for small screen sizes, which is the last thing to be resolved before the exit node GUI is ready for release. 

Loki Core 

Loki Android Wallet

Loki iOS wallet 


Lokinet

You can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What went on last week with Lokinet: We pushed out a couple of release candidates for 0.8.1 last week, but at the end of the week and over the weekend identified a couple of last-minute breaking issues with recent changes that need to be fixed before we deploy the update. We hope to have these addressed quickly for a public stable release within the next day or two.

Lokinet PR Activity:


Session

Session iOS 

Session Android

Session Desktop

Session Open Group Sever 


Thanks,  

Kee

The post Weekly Dev Update #126 appeared first on Loki.


View the full article

Snider

Hey Y’all, 

This week the Loki core team continued working on getting the iOS and Android wallets to work properly with Salty Saga. Meanwhile, the Session team worked on various UI fixes and investigated a few issues we were having with Session open groups and the Session file server. The Lokinet team followed up on some internal testing feedback and fixed a number of windows GUI bugs. 

Loki Core

Loki Android Wallet

Loki iOS wallet 

  • iOS wallet updates for Salty Saga (no PR yet)

Lokinet

You can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What went on last week with Lokinet: We fixed a bunch of last minute cosmetic issues, made some small fixes, and put out a release candidate. Barring no major issues, we expect this to become the release (with perhaps minor additional fixes) later this week.

Lokinet PR Activity:


Session

Session iOS 

Session Android

Session Desktop

Thanks,  

Kee

The post Weekly Dev Update #125 appeared first on Loki.


View the full article

Snider

Hey Y’all,

This week the core team continued working on updating the Android and iOS wallets to make them compatible with Loki 8.x.x. The Session team integrated the onion requests v2 framework — which cuts down on the size of messages and increases the maximum attachment size. On the other side of the pond, the Lokinet team implemented some more aggressive router profiling and path rebuilding changes which should increase client stability.

Loki Core

Loki Android Wallet


Lokinet

You can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What went on last week with Lokinet: We’ve been concentrating on the final 0.8.1 release build: fixes for macOS, more Windows fixes, more robust path building, as well as various last minute fixes to small issues.

Lokinet PR Activity:


Session

Session iOS

Session Android

Session Desktop

Session Push notification server

Session Open group server

Thanks,  

Kee

The post Weekly Dev Update #124 appeared first on Loki.


View the full article

Snider

Hey Y’all, 

This week’s Dev Update is a little lighter as lots of the work we did this week got rolled into last week’s late Dev Update. The Loki core team is focusing on new releases of the GUI wallets for iOS, Android and Desktop devices. The Lokinet team continues to weed out issues on Windows,while the Session team is focusing on the new onion requests framework and polishing push notifications on Android.

Loki Core 

Loki Wallets 


Lokinet

You can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What went on last week with Lokinet: More intensive Windows bug squashing and testing.  We’ve identified some more minor bugs, bottlenecks and excessive CPU usage on Windows over the last few days of testing. We’re working hard to squash them and get a new Windows release build out in the coming days.

Lokinet PR Activity:


Session

Session iOS 

Session Android

Session Desktop

Session Open group server

Thanks,  
Kee 

The post Weekly Dev Update #123 appeared first on Loki.


View the full article

Snider

Hey Y’all, 

The dev update is a little later this week due to the craziness of the Loki Salty Saga hardfork. All bases were loaded with Salty Saga this week, obviously this involved lots of work on Loki core and the Loki wallets to make sure everything was working for the hardfork. The hardfork has also made a new and improved Session onion requests protocol possible, which the Session team is now focused on implementing. Meanwhile, the Lokinet team worked on ensuring the Windows GUI is properly functioning and assessing the stability of the network as the hardfork occurred.

Loki Core 

Loki Wallets 


Lokinet

You can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What went on last week with Lokinet: This past week and a half was spent making some configuration improvements from Service Node operator feedback, along with whipping the GUI control panel into shape — particularly on Windows and Mac. While Lokinet itself has been running fine from Service Nodes and the command-line interface , the client interface for this release proved to be a bit more troublesome. After some painful days of die-hard Linux users being forced to deal with all of Windows’ wonders (and the resulting functionally infinite profanity), we’ve nearly solved the issues and hope to get a stable GUI release for all three platforms early next week.

Lokinet PR Activity:


Session

Session iOS 

Session Android

Session Desktop

Thanks,  

Kee 

The post Weekly Dev Update #122 appeared first on Loki.


View the full article

Snider

Without doubt, the Loki Pulse upgrade is our biggest ever blockchain update. Pulse (our proof-of-stake transition) is the most visible feature in this release, but there are also a ton of other under-the-hood implementations: 

  • We completely replaced the RPC layer 
  • We added Lokinet LNS registrations 
  • We cleaned up massive chunks of the code 
  • We upgraded to (and have made good use of) C++17 
  • We imported lots of changes from Monero (such as transitioning to smaller transactions) 
  • We also made tons of smaller fixes in nearly every part of the code. 

But of course, the biggest feature is Pulse, and it really is a big change!

Quick overview of Pulse

Pulse is our protocol to replace PoW (proof-of-work), where miners were spending lots of CPU cycles computing RandomX (Loki variant) hashes to find a sufficiently difficult block to be accepted by the network. (Generally this is done by updating a single “nonce” value in the block which generates a completely different proof-of-work hash, and then seeing if this hash is acceptable for the network; the vast majority are not). That mined block rewards the miner that found a valid nonce, but also includes a predefined reward that was paid to Service Nodes for the services they provide.. While PoW has served us well in getting to this point, we now have a robust Service Node network that is more than capable of doing the job of securing the Loki blockchain.

Enter Pulse. Under Pulse we add more responsibilities to the Service Node network: they now take turns creating the block, and instead of spending CPU cycles to find a magic nonce value, they build a quorum of 11 validators who receive the block from the block creator, contribute a random value (for chain entropy), and sign off on this block. Once they have enough validator signatures (at least 7 of 11 are required), they distribute the signed block to the network. Network acceptance then depends on having enough valid signatures rather than a hash with enough proof of work. 

It’s a bit more involved than that in the details: for instance, the random values are revealed in multiple steps so that all participants have to generate and commit to a random value before they see the random values of anyone else. There is also a fair amount of complexity in how the quorums get chosen, how we select backup quorums in case a quorum fails to produce a block in time, and so on. If you love this sort of thing, there are a lot of details in the pull request descriptions for the Pulse implementations that you can read on GitHub.

Pulse launch

Aside from being a big release, this is also our most tested release: we created a “devnet” network for early, rapid development long before we merged Pulse onto our regular testnet, and then tested on the testnet for several weeks to nail down all the possible weird corner cases and edge cases that can come up in a transition like this. We have “fakechain” test code that creates a new network from scratch, registers Service Nodes, and generates Pulse blocks. We were pretty confident that it works well, given what we’ve thrown at it over the past months of development. 

We rolled out the update, and nervously waited for the network upgrade block (block 641111) to appear, COVID-style virtual champagne emojis at the ready.

2 minutes go by. No block.

3 minutes. 5 minutes. 10 minutes. No block.

At this point the conclusion was inevitable: something went wrong. Over the next hour we analyzed nodes, debug logs, etc. to figure out where things went wrong. What we figured out is that network nodes were disagreeing about which nodes were supposed to be in each of those Pulse quorums. This meant that a Service Node would produce a signature and try sending it to its quorum, saying “I am Pulse validator #7, here is my signature.” Receiving Service Nodes would completely reject it: the signature wouldn’t validate because they would have a completely different idea of who validator #7 is supposed to be — and if the network can’t agree on who is supposed to sign the blocks, then Pulse doesn’t work at all.

Some more investigation led us to the cause. One of the implementation details of Pulse is that we pseudorandomly select validators in such a way that everyone agrees (or at least, is supposed to agree) on which validators get selected by using randomness from past blocks on the chain. However we also don’t want the same validator to get used repeatedly to make it more difficult for any single Service Node to have any meaningful influence on the chain: thus we sort everyone according to when they last participated in a Pulse quorum, and use the first half of this list to select random members. As long as everyone agrees on the order of previous validators, this all works out: everyone ends up selecting exactly the same 11 random Pulse quorum validators, and thus they know which Service Node public keys they need to validate signatures against.

Once we figured out that the problem was here, we nailed it down to a more specific issue: that big sorted list of nodes (from which we select the quorum) was sorting differently on different nodes: network nodes seemed to have a different idea of when other nodes had last participated. Eventually this led us to the bug: when a node upgraded from 7.1.x to 8.1.0, we would assign the last-participated time for peer nodes to the last time that node was rewarded, which seemed reasonable. But that broke quite badly because we only ever update that last-participated value starting at the Pulse fork block. The end result is that a node upgraded at block 640000 and a node upgraded at block 640100 would end up with completely different “last participated” values, and then when we hit the first Pulse block, they completely disagree about who should go next. 

Our fix was simple enough. when upgrading to 8.1.1, every peer’s “last participated” value got set to 0 so that everyone could agree on the sorted list again.

So why didn’t we catch this bug earlier on testnet/devnet/test code? Well, it turns out that the bug was certainly there, but because our testing apparatus upgrades all our nodes at the same time (automatically, as soon as we push new commits to the dev branch), it didn’t have the opportunity to occur: they all had a “wrong” sort order, but they also all agreed on the sort order. 

That let the 8.1.1 release resolve the main issue, but we hit a built-in emergency fallback. The network tries to generate Pulse blocks, and keeps trying once/minute cycling through different backup quorums until some quorum manages to create a block with the required signatures. If this goes through 254 failed rounds, the network gives up and waits for a proof-of-work block to be mined, restarting Pulse quorum attempts after the next block. This was designed to essentially allow us to fix a problem in a scenario exactly like this: pause the chain and get out an emergency fix to get it going again. 

This actually exposed a second problem given that the stall happened at the very beginning of the Pulse chain: Pulse blocks are all considered to have an artificial difficulty value of 1 million as if they were on a network with a paltry 8.3kH/s of hash, allowing a mined block to be found within a few minutes by a single desktop class machine. However, in this case, all the past blocks that are used to determine the difficulty were from a network with a hashrate of several MH/s. Thus 8.1.1 has a second fix to ignore all the pre-Pulse blocks when determining difficulty and go directly with the 1M difficulty.

One last change we put in was to disable Service Node testing for a week since 8.1.0 nodes would be unable to sync the chain once it started again. As a consequence, we still have a few (around 7% at the time of writing) nodes still on 8.1.0 or 7.1.x; while they should have been decommissioned and deregistered by now, they are kept alive by this extra margin to give them time to upgrade. 

With the fixes applied, we deliberately broke the testnet in the same way with different “last participated” orderings for peers and tested its ability to recover. It did, and so we rolled out the fixes to the community and asked people to update, and meanwhile mined the 641111 block to get the network rolling again.By the time we got a fix deployed, we’d gone past the block 254 stall point.

So what happens now?

Pulse is designed to be fairly robust against nodes that are down. We don’t want the network to grind to a halt because someone decided to install an update or reboot their Service Node at the wrong time. Thus we use backup quorums, as I described above, so that even if a big chunk of the network isn’t available, the backup quorums randomly select different nodes until we find one that works. We call these “Pulse rounds.” Round 0 is the normal block where the next SN reward winner in the queue gets to produce the block (and earns any tx fees on top of the Service Node block reward!), and 11 random validators; if that quorum fails to produce a block within 60 seconds of when it was supposed to, round 1 begins by selecting a new set of 11 random validators and a random block producer. This backup producer still has to pay the queued SN reward winner its basic fee, but gets to reward itself with any earned TX fees, splitting the fees among the operator and contributors.

You can see this happening in the first few blocks after 641112 (which is the first actual Pulse block; 641111 was supposed to be, but ended up as a fallback mined block): https://lokiblocks.com/range/641111/641121

The network took quite a while after that to find block 641112, which it did at round 67 (you can see this on the block details page on the block explorer: “Block type: Pulse ? | 67” is indicating the Pulse round) because we only had Loki Foundation and team members’ nodes updated at this point. As community members started updating, Pulse blocks started coming faster, coming in at rounds 12, 0, 7, 1, 0 over the next five blocks.

Looking at recent blocks with 93% of the network on the 8.1.1 release, the vast majority are now “round 0” blocks with an occasional round 1 block. 

We also built Pulse to be able to recover from slow blocks or long delays (as we had here): rather than producing blocks at the regular 2-minute interval, if the chain is behind schedule it speeds up, starting new Pulse quorums blocks after 90 seconds rather than 120 seconds. You can see this as well in recent blocks on the explorer with most being about 90s apart. If you hover your mouse over the “Next Pulse: …” indicator at the top of the main block explorer page, you can see how far behind target we are.) For example, as of writing this post, here are the top 20 blocks:

https://lokiblocks.com/range/642775/642794

Most of these around slightly over 90s apart, though some still are a bit longer: if one or more validators that get selected are 8.1.0 (or 7.x) nodes, it adds about 15-20 seconds before the quorum gives up on getting a response from those nodes and goes ahead without them. Some are longer still (such as block 642789), which generally means a backup quorum had to get involved to make a block. 

Since our fixes, things are moving forward, the blocks are rolling (or perhaps you could say, “pulsing” ?) and Pulse is working exactly as intended, despite the network being still slightly degraded. By next week, testing will turn on again, we’ll kick off the last non-upgraded nodes, and we’ll catch up to the target height and end up with the smooth, consistent 2 minute blocks that Pulse is designed to produce. 

So all-in-all, one tiny bug completely ground things to a halt despite all of the testing and effort that went into this release, but with it fixed, things are looking great. As much as I wish our initial 8.1.0 release had done the job, I’m pretty pleased with how things are working since fixing that (tiny, tiny and yet huge) bug.

— Jason

The post Pulse launch: What went wrong and what went right appeared first on Loki.


View the full article

Snider

Hey Y’all, 

This week the Loki team released the Loki software suite for the Salty Saga hardfork; the whole Loki team has been working very hard on new releases, including releases for the Loki storage server, Lokinet, Loki Core and even Session. If you are a Service Node, operator make sure to follow these instructions to update: https://docs.loki.network/ServiceNodes/DebianPackageGuide/#upgrading 

Loki Core 

The default GitHub branch for Loki core has changed to the “dev” branch, to better reflect our progress as we code. At the same time a new `stable` branch has been created to contain updates to our current release (8.x) version. The `master` branch, which previously contained our current release code, has been retired.

Loki Wallets 


Lokinet

You can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What went on last week with Lokinet: The past week in Lokinet was all focused on last-minute fixes to get 0.8.0 out the door, dealing with some last-minute issues that cropped up. Releases are always a bit challenging because different configurations and environments (e.g. actual mainnet instead of testnet) make things pop up that need urgent fixes before we roll out the release. But we got through it and got the release out the door! Our next steps for this upcoming week are to follow up with new builds for the Lokinet GUI (aka Control Panel) and installers for Windows, Mac, and new Debian/Ubuntu packages for Linux, as well as addressing a few issues that came up in the 0.8.0 upgrades that have happened (such as improving the descriptiveness of some error messages).

Also note that, as in loki-core, we’ve changed our branch policy: the default code branch that you see on GitHub is now our development branch (`dev`) rather than the stable release branch.  We’re now putting our stable release code (e.g. for 0.8.x updates) in a new `stable` branch and are retiring the old `master` branch.

Lokinet PR Activity:


Session

Session iOS 

Session Android

Session Desktop


Thanks,  

Kee 

The post Weekly Dev Update #121 appeared first on Loki.


View the full article

Snider

Hey Y’all, 

This week, our efforts were focused on two major endeavours: getting the final fixes in for the upcoming Loki Salty Saga hardfork, and working on a major update for Session closed groups and push notifications, which will be rolling out imminently. We also made more quality of life upgrades to the Loki electron wallet and put the finishing touches on the Lokinet GUI, specifically on Windows support. 

Loki Core 

Loki Wallets 


Lokinet

You can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What went on last week with Lokinet: This week saw various small cleanups, fixes, and pre-release last-minute changes aimed at getting Lokinet ready and packaged for the upcoming hard fork. We still have a few minor items left, but overall 0.8 is shaping up to be a solid release.

Lokinet PR Activity:


Session

Session iOS 

Session Android

Session Desktop


Thanks,  

Kee 

The post Weekly Dev Update #120 appeared first on Loki.


View the full article

Snider

The ball is well and truly rolling for Loki and DeFi, and we’ve got even more exciting news to share with you. 

Blockswap is rebranding to become Chainflip

That’s right! An even fresher look for a fresh new project. Blockswap is now Chainflip. We know you’ll all be keen to check out Chainflip’s refreshed visuals, so head on over to Chainflip.io and check out this tweet to see the ocular spectacular! 

The team behind everyone’s favourite upcoming cross-chain swapping service has made the decision to change Blockswap to Chainflip. Although we were fans of the Blockswap name, the team ran into some unexpected competition for the Blockswap domain and SEO namespace, and so was unable to carve out enough dominance to really make Blockswap stand out. The team always intended to overhaul the Blockswap branding closer to launch, so instead of simply overhauling the visual design, the entire brand has been recreated under the Chainflip banner with a strong new identity. This will help the Chainflip to stand out against the backdrop of other DeFi projects. 

Because Chainflip is yet to launch and still only beginning to build its brand, now is the perfect time to change the name and brand to something much stronger and unique — it costs very little and stands to make it easier to educate the ecosystem about the product. This is the start of the next chapter for Chainflip — we think that with this new identity, Chainflip stands a much better chance of being adopted by the DeFi community as it is rolled out.

The Chainflip team is bringing wLOKI into the fray

As you’ve probably already heard, a wrapped LOKI token called wLOKI will soon be available for trading on Uniswap! Uniswap is the talk of the DeFi town, so it makes sense for LOKI to join in on all the unicorn-based fun. As we explained in our announcement, wLOKI makes it easy for people in the Ethereum DeFi ecosystem to join the Loki community. 

 While we’re huge believers in the future of cross-chain asset swapping, it’s still valuable to connect Loki with existing DeFi infrastructure. wLOKI connects Loki to Ethereum’s established ecosystem, provides a new Loki onboard, and gives you an opportunity to earn some extra LOKI. Win-win-win.

That’s right — you’ll be able to earn LOKI by providing liquidity to the wLOKI/USDT pool on Uniswap. This incentive scheme is provided by the Liquidity Fund being created in the upcoming Salty Saga hardfork, due early next month. Details on the incentive scheme will soon be available directly from the wLOKI bridge, which is nearing completion. This will enable you to swap your wLOKI to LOKI, and your LOKI to wLOKI, all from the Chainflip interface. 

How will liquidity incentives work on Chainflip? 

In case you missed it, we recently wrapped up a Loki Request for Comment discussing changes to the Loki block reward. For the next 6 months, 6 LOKI per block will be directed to the Chainflip liquidity reward fund.

With a 2-minute block time, this is 4,320 LOKI per day, or 30,240 LOKI every single week. Clockwork. This is a significant reward fund up for grabs, which will be used to ensure liquidity is attracted to pools on Chainfip. Liquidity mining is an essential component of guaranteeing Chainflip’s success, and the development of the infrastructure to allow for it in this new cross-chain context is underway. 

To infinity, and beyond!

The road ahead is very exciting for Loki. Crypto needs a decentralised way for tokens and coins to flow seamlessly across chains. Currently, a huge part of the crypto world is cut off from DeFi. This is a whole lot of untapped potential, and Chainflip and wLOKI are set to unlock it. 

We’re extremely energised by the latest developments for Chainflip and wLOKI — hopefully you like the new Chainflip branding as much as we do, and stay tuned for further updates!

If you’d like to talk about Chainflip, follow its Twitter account or jump into the Loki Community Telegram.

The post Chainflip rebrand, wLOKI, and liquidity incentives appeared first on Loki.


View the full article

Snider

Loki’s upcoming Salty Saga 8.0.0 hardfork will bring a bunch of exciting changes to Loki Core and other key components of the Loki privacy suite. As mentioned in the Salty Saga announcement, one of these changes is a restructure of the Loki block reward. If you’ve been following the Improvement Proposals section of Loki’s GitHub, you’ll have an idea what that’s all about — but for everyone else, read on for an explanation of the changes we’re making, and why.

The changes being implemented in Salty Saga are an answer to two crucial questions about the future of the Loki ecosystem.

Firstly, when the Salty Saga hardfork hits mainnet, Loki will be going full Proof of Stake — meaning miners are being eliminated from the Loki ecosystem. The question this raised was: what should be done with the portion of the block reward (6 Loki per block) currently awarded to miners?

The second question was centred around Blockswap, the revolutionary new DeFi initiative being supported by the Loki Project. For those not already familiar with it, Blockswap aims to provide a decentralised, liquidity-pool-based cross-chain token swapping service. Using Blockswap, you will be able to swap any token pair for which there exists a liquidity pool. Here’s the thing though: in order for Blockswap to be a success, liquidity providers must be properly incentivised to stake their assets into Blockswap liquidity pools. Without a liquidity provision incentive to kickstart the Blockswap ecosystem, the entire project could be dead in the water. So, where could such an incentive come from?

We believe we have found a way to kill two birds with one stone and solve one problem with the other. As of the Salty Saga hardfork, the 6-Loki-per-block mining reward will be redirected to a Loki Foundation-controlled Blockswap liquidity fund with a 6 month expiry. This fund will be dedicated to incentivising the staking of assets into Blockswap’s liquidity pools, giving the Blockswap ecosystem a running start.

In the upgrade following Salty Saga, which will include the implementation of Blockswap’s Vault Nodes, this 6 Loki per block may be combined with a 4-Loki-per-block cut from the Service Node reward pool, and  the resulting 10 Loki per block can be granted to Vault Nodes to provide ongoing incentive for staking into VNs. We may open a new LRC before the Vault Node upgrade to discuss the specifics of this plan with the community, and we’ll make an announcement if a new LRC is opened on the topic.

For more information about how the above conclusions were reached, head over to LRC-7 on the LRC section of our GitHub.

The post Pulse check: Salty Saga hardfork brings a new block reward structure to support Blockswap appeared first on Loki.


View the full article

Snider

Hey Y’all, 

This week we finished up some very cool Session features, which will hopefully resolve a number of issues with unreliable push notifications. On the Lokinet side, we did some cross-project work which allows for the human-readable .loki names introduced in the Salty Saga hardfork. Speaking of the hardfork, the Loki Core team forked the public testnet a few days ago, so you can now test Pulse and other goodies. Check it out here: https://loki.network/2020/09/19/salty-saga-testnet-testing-guide/ 


Loki Core 


Lokinet

You can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What went on last week with Lokinet: This week was mostly spent on fixes and polish towards a final Lokinet 0.8 release: working LNS support (now active on testnet), Windows build fixes, and updating various small issues in the code. The biggest user-facing feature this week was the addition of LNS support: .loki LNS domains can be registered (and are working!) on the Lokinet testnet currently, and will be available for registration on the main network as of the Loki 8.x hard fork, tentatively scheduled for early October. Registration periods (or renewals) can be from 1 to 10 years. (Note that they will require the new 0.8 version of Lokinet to actually resolve, but can be tested out now on the public testnet using the Lokinet `dev` branch).

Lokinet PR Activity:


Session

Session iOS 

Session Android

Session Desktop


Thanks,  

Kee 

The post Weekly Dev Update #119 appeared first on Loki.


View the full article

Snider

Come early next week, wLOKI will be issued on the Ethereum blockchain and become available for trading on Uniswap.

As you might’ve already heard — the Loki blockchain is diving headfirst into the DeFi space. To increase the DeFi community’s ability to access and gain exposure to Loki, we’re announcing support for a brand new way of using the LOKI cryptocurrency, called wLOKI.

We’re excited for Blockswap to bring DeFi directly to the Loki blockchain — but there is already a bustling DeFi industry built (mostly) on the Ethereum blockchain. In order for Loki to participate in this established ecosystem, it’s going to need a wrapped token. 

Enter: wLOKI

wLOKI, or wrapped LOKI, is an ERC-20 compatible asset that’s fully backed by LOKI on the Loki blockchain. Initially, the wLOKI wrapping service will be provided by the existing Blockswap team as a part of the swapping service they are already developing, which is currently in the later stages of minimum viable product development. 

As with previous arrangements with wrapped LOKI tokens, the Loki Foundation will oversee and regulate the circulating supply of the ERC-20 token on behalf of the community. 

Why wLOKI?

Although Blockswap aims to eliminate the need to use wrapped tokens for decentralised trading, wrapped assets are still useful for people who need to access services on chains that are not cross-chain compatible.

On top of this, the current king of the DeFi jungle is Uniswap. It’s free to list a token on Uniswap, and it offers a fantastic means of exchange for the wider community. Come early next week, wLOKI will be issued on the Ethereum blockchain and become available for trading on Uniswap. 

We’re also offering an incentive to yield farmers who are able to bootstrap liquidity in the Uniswap wLOKI/ETH pool. If you already have exposure to both ETH and LOKI, this will be an opportunity to earn additional tokens — potentially as much as 15,000 LOKI a week. This reward will be received as wLOKI paid directly to the addresses of the pool liquidity providers. 

Bringing Loki to Uniswap should make it much more appealing to yield farmers and DeFi enthusiasts who are yet to get involved in the Loki project. It’s a great step to boost the interest and activity in the Loki community in the lead-up to Blockswap’s release.

Starting next week, wLOKI will be available for 1:1 transfer with LOKI using a web-based bridge. 

The future of wLOKI

Swaps for the wLOKI token will be supported manually through the bridge at wLoki.io until an equivalent wLOKI/LOKI cross chain liquidity pool is launched on Blockswap. Once wLOKI is integrated on this new DeFi tool, the token can be regulated by arbitraging the price in the pool and adjusting the supply as necessary. This can be automated such that the LOKI backing wLOKI is deposited into the LOKI vault, where it will be managed differently to other LOKI balances in the vaults. This will ensure the future of wLOKI is decentralised, automated, and easy to access.

We’re very confident about the future of cross-chain asset swapping, but it’s still important to connect Loki to existing DeFi infrastructure. By supporting the creation and maintenance of wLOKI, the Loki blockchain can be at the forefront of both the established ecosystem on Ethereum as well as the emergent cross-chain ecosystem. 

If you’d like to speak to us further about wLOKI, you can reach us via team@loki.network, our Telegram community, our Discord, or on any of our social channels. 

The post LOKI and ERC-20: wLOKI appeared first on Loki.


View the full article

Snider

If you’re interested in participating in the Salty Saga testnet, here is some technical information to help you get started.

How to get connected 

To use testnet, you’ll need to grab the latest Loki CLI builds, located here. The testnet builds are labelled with the 8.0.0 tag — you should download the highest 8.x.x version. 

To get connected, you’ll need to extract the downloaded folder of binaries and run Lokid with testnet flags (lokid –testnet) to sync the testnet chain.  Then you will be able to run loki-wallet-cli to send transactions, register service nodes and test. 

How to see the chain 

We’ve been working on a Python rewrite of the Loki block explorer which can be found here. It’s not 100% fully functional yet, but you should be able to use it to see details about the transactions you complete on the testnet. 

Where to get testnet Loki 

Message @LokiSNBot on Telegram or Discord using the “Testnet” faucet option to receive testnet Loki. You can use this Loki to register nodes, test transactions, or conduct other tests.

How to run and register a Service Node on the testnet 

Make a note of the path where you extracted the lokid binaries in the instructions above. It will be something like:

/home/username/loki-linux-x86_64-8.0.0-dev-8937ba728/lokid

If you want to run a testnet node on a node that already has running a deb-based service node, run the following commands:

Please note: the testnet blockchain is 800MB, so ensure hat you have adequate space on any mainnet Service Node to run the testnet before syncing.

sudo systemctl edit --full loki-testnet-node

This will open an editor showing you the current testnet lokid service file. You need to make two changes here:

1. On the line reading ExecStart change ‘/usr/bin/lokid’ to the path you noted above (such as ‘/home/username/loki-linux-x86_64-8.0.0-dev-8937ba728/lokid’). Leave the remaining arguments (–config-file, etc.) on the line.

2. You will also need to change the line `Type=notify` to `Type=simple` to work with the downloaded static binaries. 

If you are compiling your own lokid and have the systemd headers installed, you don’t want to do this. If you don’t know what this means, just change it to simple.

Save and quit, then fire up the testnet infrastructure using:

sudo systemctl start loki-testnet-node loki-testnet-storage-server lokinet-testnet-router

This should start up everything you need, and lokid will start syncing the chain. If you want to watch the progress:

sudo journalctl -u loki-testnet-node -af

Once it’s full synced, you can use a testnet wallet, acquire some funds, and prepare and submit a registration. Cd into the loki-linux-x86_64-blahblah directory and use:

./lokid prepare_registration
./loki-wallet-cli --testnet

You should also be able to use the current GUI wallet if you replace its bundled lokid and loki-wallet-rpc binaries with the ones from the above build repository (choose the latest linux/mac/windows build as appropriate).

If you don’t have the debs on the given system, install them, but note that if you don’t want to run a mainnet lokid, storage server, or Lokinet on the given machine, you should run this first to prevent them from starting:

sudo systemctl mask loki-node lokinet-router loki-storage-server

Then you can install as described in the Loki docs, and follow the steps above.

What we want people to test 

  • Registering Service Nodes 
  • Registering .loki LNS names
  • Sending different types of transactions 
  • Attempting to disrupt consensus 
  • Shared contribution nodes
  • Anything else you can think of! 

How do I report bugs? 

Bugs can be reported by filing a Github issue on the Loki core repository or by notifying the Loki team via the usual methods — Session, Discord and Telegram

Happy testing!

The post Salty Saga testnet: Testing guide appeared first on Loki.


View the full article

Snider

It’s finally here! The Pulse hardfork, otherwise known as Salty Saga, is about to launch on testnet. It’s been a long time since our last hardfork back in March — nearly 6 months. With that in mind, we want to run through the typical Loki hardfork process for any new community members going through their first hardfork, or for any veterans needing a refresher.

But first, here’s an overview of some of the biggest new features which are included in Salty Saga:

  • Pulse consensus mechanism
  • Lokinet name registration
  • Changes to Service Node uptime credits
  • CLSAG signatures
  • Changes to the block reward
  • Fixed Service Node staking requirement of 15,000 LOKI 

As you can see, we’ve crammed a lot of significant changes into Salty Saga. There’s also a massive amount of non-user-facing changes, like:

  • Overhauling RPC
  • Merging upstream commits 
  • Changes to staking difficulty to accommodate for Pulse
  • Changes to LNS hashing
  • Changes to LNS owner retrieval
  • Replacing large parts of Epee
  • Fixes for Multisig
  • Changes to Service Node key management

All of these changes will go live at the time of the hardfork, which makes this Loki’s biggest ever hardfork. But, because Salty Saga is such a gargantuan update, our plan for this hardfork is slightly different to the usual.

We aren’t setting a fixed timeline for this release, because we want to give ourselves (and the community) a proper opportunity to test (and, potentially fix) the Salty Saga public testnet. 

The public testnet will launch on September 19th and, assuming all goes well, will run for 1 week. In this scenario, we will announce the start of the week-long upgrade period on September 28th, with a targeted hardfork date of October 5th. 

When the testnet launches, we’ll be looking for testers. If you’re keen to start testing (and potentially earn some Loki), reach out to Kee on Session or via Telegram (@keejef).

Proposed Timeline (subject to change):

G3OJZ9pvprWyfCoGnxBgc3CjAttLhbYb0Z-o-QfA

As per usual, if you have any questions, feel free to contact us via team@loki.network, through our Session open group, our Telegram community channel, the Loki Project Discord, or you can also reach out to us on our socials. 

The post Loki Salty Saga 8.0.0 Hardfork Announcement appeared first on Loki.


View the full article

Snider

Hey Y’all, 

This week the Session team worked on some fixes to light mode and some additional updates to the styling of the app to give it a bit of a facelift. These were the first steps in a larger ongoing visual overhaul, and we’ll have more to share on that front soon. The Loki Core team continued to work through internal Pulse issues with a public testnet release creeping closer by the day. For the first time in a few months we also made some significant quality of life updates to the Electron GUI wallet, including displaying a list of stakeable nodes inside the GUI wallet. The Lokinet team capped things off by working towards final exit-enabled GUI builds. 

Loki Core 

Loki Wallets

Loki Electron Wallet 


Lokinet

You can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What went on last week with Lokinet: This week saw (draft) LNS support for .loki address lookups in Lokinet clients (both in Lokinet and in loki-core, where the registrations are actually made). We also did some more testing and various cleanups of the code base. We think exit support is in decent shape now — it’s working well, but we continue to use it as our daily connection to shake loose more potential issues before the upcoming hard fork release.

Lokinet PR Activity:


Session

Session iOS 

Session Android

Session Desktop


Thanks,  

Kee 

The post Weekly Dev Update #118 appeared first on Loki.


View the full article

Snider

Hey Y’all, 

This week was a big development week for Session — we released UI fixes and light mode! On the Lokinet side, we worked on LNS support and continued testing exit nodes. The Loki Core team continued working on alternate block support for Pulse. 


Loki Core 

Loki Wallets

Loki Electron Wallet 


Lokinet

You can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What went on last week with Lokinet: Lokinet development saw us merge working macOS support for exit mode, exit configuration via the GUI, SRV record support for SNapps, one big performance improvement, and initial work on support .loki LNS lookups. This week we plan to finish off LNS support (to come with the upcoming Loki 8.x Pulse update) and continue testing and polishing exit mode support.

Lokinet PR Activity:


Session

Session iOS 

Session Android

Session Desktop

Thanks,  

Kee 

The post Weekly Dev Update #117 appeared first on Loki.


View the full article

Snider

Hey Y’all, 

This week, the Session team worked on lots of little quality-of-life bug fixes. We’re also implementing a light mode, for those users who prefer to be blinded by their screen. The Lokinet team finished on the command line implementation for exit node tools and moved onto integrating exit node selection into the Lokinet GUI. The Loki Core team worked on Pulse code cleanup and searched for Pulse bugs on the devnet. We also welcomed a new developer, Kyle, who began working on bettering the Loki electron wallet user experience. 

Loki Core 

Loki Wallets

Loki Electron Wallet 


Lokinet

You can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What went on last week with Lokinet: This week we finished off the exit tool plus various associated fixes and merged that (huge) PR into the `dev` branch.  We also started work on updating the GUI so that people other than Linux command-line freaks and lokiMQ hackers can start using Lokinet exit nodes, too. We updated the GUI both for compatibility with current Lokinet dev code, and to add a (quick-and-dirty) GUI exit configuration for broader Loki team testing. SRV record support is imminent with a working implementation already done and just a few last minute testing and fixes needed before PR and review this week. As usual, we also spent time investigating and fixing a few random issues that we’ve noticed over the week of nearly full-time daily exit use.

Lokinet PR Activity:


Session

Session iOS 

Session Android

Session Desktop

Thanks,  

Kee 

The post Weekly Dev Update #116 appeared first on Loki.


View the full article

Sign in to follow this  
  • HashVault Stats

    • Global Hashrate
      2.78 TH
    • Avg Hashrate
      1.91 GH
    • Total Miners
      1458
    • Miners Paid
      41983
    • Total Payments
      1497902
    • Total Hashes
      9.23 EX
    • Blocks Found
      1636354
×
×
  • Create New...