Jump to content
Exchange Prices

Loki

Sign in to follow this  
  • entries
    37
  • comments
    0
  • views
    226

Entries in this blog

Snider

Festive Freya Announcement

 

We are super excited to announce the next release for Loki, which will contain Bulletproofs, along with a few larger quality of life changes for Service Node staking.

 

Features include:

  • Add Bulletproofs;
  • Lower transaction fees in accordance with Bulletproofs;
  • Add staking from the GUI wallet;
  • Governance wallet payout changed from once per block to once per 5,040 blocks, this reduces blockchain bloat;
  • IPV6 Support for Loki Daemon and Loki wallet CLI;
  • Zawy difficulty adjustment algorithm patch;
  • Service Node grace period added, Service Nodes that consecutively register within a time frame at the end of their staking period will not be deregistered;
  • Fix for the common “No known outputs” bug;
  • Integration testing framework;
  • Increased visibility of when locked amounts are being received;
  • Increased visibility for the unlock time of staking transactions;
  • Add the SwarmID field to all Service Nodes which provides the framework for the logical grouping of nodes;
  • Merge Monero upstream,  this includes over 1,000 commits that Monero has added over the last three months;
  • Merge Monero GUI Upstream which fixes a number of bugs in the GUI wallet;
  • Add versioning to Service Node uptime proofs — nodes reporting old versions past the hardfork will be de-registered.

 

Below is the schedule for the hardfork, with all changes available for testing on testnet between the 20th and the 30th of November. We encourage everyone to jump onto testnet soon so that the team can find bugs and update binaries before the 30th of November, when the final binaries will be released.

 

FestiveFreyaUpdatePeriod-300x56.png

 

Who needs to update?

Everyone — including users, miners and Service Node operators. Once the hardfork occurs, you will not be able to send Loki unless you update to the new wallet.

 

Will my Service Node be affected?

Yes, in this hardfork we will be adding an extra field to uptime proofs: each node will report its version number, and nodes exhibiting the incorrect or no version number will be deregistered as a result of quorum testing. To ensure safe operation, you must update your Service Node to version 2.0.0 (Festive Freya) before 13 December 2018.

We have made an instructional video guide on how to safely update a Service Node, here.

 

Will Autostaking be affected?

Yes, although we are not making any specific changes to autostake, the introduction of bulletproofs makes old wallets incompatible with the protocol upgrades. This means that if you want to autostake, you will need to shutdown any running Loki wallets (listed as loki-wallet-cli) and start a new autostaking wallet that can submit transactions with bulletproofs.

 


View the full article

Snider

Weekly Dev Update #22

Hey Y’all,

Another weekly Dev Update for you to peruse. Just a note, we’re moving Dev updates to Mondays instead of Fridays, so keep your eyes peeled each Monday.

Loki Messenger


LLARP / Lokinet

  • Released Lokinet 0.3.1: “Kuz Yolo”
  • Progress continues on libllarp
    • Started on Docker support
    • Fix endian in tun ip checksumming
    • Jsonrpc unit tests
    • Make sure HasPathToService actually has a sendable state
    • Client config gen to include a sample hidden service again
    • A lot of C++ correctness clean up
    • Always remove DHT node even if not valid
    • Update android version
    • Enable warnings as errors
    • Start to add tcp event support to windows
    • Updates for ancient raspi buildchain
    • Remove variable length assignments
  • DNS Library
    • Remove 2 second delay for prebuilt paths
  • GitHub Pulse Stats for the last week: Excluding merges, 6 authors have pushed 58 commits to master and 59 commits to all branches. On master, 164 files have changed and there have been 9,708 additions and 5,240 deletions.

Loki Core

Thanks,  

Kee


View the full article

Snider

 

Over the course of this article I will analyse three key elements which all messenger applications must consider.  

  • Metadata: Any information, aside from the actual message, which is transmitted and can be exposed to third parties.
  • Encryption: How your messages are encoded to obfuscate their content.
  • Scalability and Attacks: How well the messenger responds to increases in usage and if there are any known attack vectors or exploits to the specific system.

I will also explore how centralisation/decentralisation can affect the privacy and security of each element. Centralisation, in this context, refers to whether the messenger architecture has a group of permissioned non federated servers, which are the sole servers and can hold or relay messages.

Through these lenses, I will examine the most popular messaging services which claim to be encrypted, or private, along with Loki messenger.

  • Centralised server models, like Telegram, Facebook Messenger, Signal, Whatsapp or XMPP (Federated)
  • Decentralised messengers like Tox and Bitmessage
  • Mixnet based messengers like Loki Messenger

 


Metadata

Think about it like this: if I send a letter by post to my friend, I will put their full name and address on the front, and my full name and address on the back so that I can receive a reply. Although no one can see inside my letter and read its contents, the postal service now has a good idea of who I am, who I sent my letter to, and what time I sent my letter. This information is typically referred to as metadata.  

 

1-300x178.png

 

Here’s a great quote from Kurt Opsahl from the EFF, writing on the topic of government metadata collection:

“They know you rang a phone sex service at 2:24 am and spoke for 18 minutes. But they don’t know what you talked about.

They know you called the suicide prevention hotline from the Golden Gate Bridge. But the topic of the call remains a secret.

They know you spoke with a HIV testing service, then your doctor, then your health insurance company in the same hour. But they don’t know what was discussed.” [1]

And Michael Hayden (former Director of the NSA)

We kill people based on metadata” [2]

Now how does this relate to private messaging?

 

Centralised services

When you use a service like Whatsapp, Telegram or Signal, you connect directly to a server owned by one of these companies. When you send a message, you must somehow tell that centralised server who you are and who the recipient of your message is. You will also typically give up your IP address and your phone number, depending on the client you use.

These centralised services have the capacity to collect metadata. Some providers, like Whatsapp and Facebook Messenger, openly admit to collecting and storing their user’s metadata. [3][4] Some services, like Signal and Telegram, have policies against storage of user metadata. [5][6] These policies require a significant amount of trust, however it has been shown countless times that as soon as trust is involved in user privacy, companies and governments will violate that trust. Look no further than popular ‘private’ email service, Hushmail, which was compelled legally to hand over users’ private information to governments. [7] The only solution to this problem is for these centralised, privacy centric services to never have the ability to collect sensitive user data.

(A note on XMPP)

Messengers based on XMPP are slightly different in their construction since they operate on a federated model. [8] This means that only a protocol is provided, users/providers can operate their own servers (which means that metadata is held by individual servers), and users have more choice in the parties they trust to store their data. This is a step in the right direction, though XMPP servers can still collect this data and have the ability to transmit it to third parties.

 

Decentralised Services

So how do the decentralised models deal with metadata? Well, there’s a few out there and they each approach metadata in a different way.

Services like Tox, and other P2P messengers, by their very nature do not require metadata to be stored on any centralised server, since messages are routed directly to their participants rather than traveling through servers or hopping through a mixing network. On the surface this can sound great, but really it gives more power to ISPs. Although the packets of data may be encrypted, ISPs can see the IP address of the person you are messaging, and if they can resolve the IP address of the recipient then they are able to very accurately ascertain information on who you messaged and at what time. This is something centralised services (Telegram, Signal, and WhatsApp) prevent. If encrypted properly, your ISP only knows you are communicating with a messaging service server, and never knows the actual IP address of your recipient.

Bitmessage is one of the other fully decentralised messaging models and might be the next best for hiding message metadata. Bitmessage operates a floodfill network, meaning that messages aren’t directed towards specific participants like they are in most other networks. In Bitmessage, every user is distributed a copy of every encrypted message. Once a user receives a message, they must attempt to decrypt the payload. This means when I want to send a message, I “flood” the message to the peers I know, who then flood the message to the peers they know. This technique makes it difficult to ascertain whether a user is merely relaying a message, or if they are the source of the message. It is also imposible to ascertain whom the true recipient is, as all clients receive all messages and attempt to decrypt them. However, there are significant downsides to operating floodfill networks, such as the high bandwidth consumption and computational overhead of attempting to decrypt each message you receive.

 

Loki Messenger  

Loki Messenger uses a number of different techniques for obfuscating metadata. In the context of the above, it is close to a mashup of Bitmessage and the Tor network. Like Bitmessage, Loki Messenger uses a decentralised set of nodes (Service Nodes) to relay messages to other users. Service Nodes are incentivised by the Loki blockchain and undertake the job of relaying messages to receive a small reward in cryptocurrency.

To avoid metadata collection in both offline and online communications, a method called onion routing is employed. Onion routing in Loki positions a set of randomly selected (simplified) Service Nodes between the user and the destination of their message. As the message hops through each Service Node toward the final recipient, a layer of encryption is removed. This onion routing provides a number of protections:

  1. In a typical connection it is not possible for a single Service Node to gather enough metadata to form a connection between the sender and receiver of a message.
  2. Service Nodes are run by the community, and are globally distributed, which makes targeted legal action difficult.
  3. Service Nodes require a large amount of the Loki cryptocurrency, meaning they are staked into the system. Any actions which reduce the usefulness of the Loki Messenger will likely also reduce the value of the Loki cryptocurrency. This financially incentivises good behaviour.  

When a direct link between users cannot be established (the recipient is offline), Loki can also enable metadata protection for offline messages. This is done through a process called Swarm messaging. Each Loki Messenger user resides in a swarm of 10 Service Nodes. To contact another user, I can use their public key to figure out their swarm identity. My message is then sent to one of the ten nodes in their swarm, which will flood the message to the 9 others. When the user comes online, they will randomly query a node in their swarm. If that Service Node is holding a message for them, the user will download it directly from the Service Node.

 

4-300x128.png

 

Alice sends a message to Bob, Bob’s assigned Swarm is B, When Bob comes online, he queries a random node in his swarm and receives Alice’s message.

 


Encryption

Encryption refers to the methods each messenger uses to obfuscate the actual data inside a message. It’s easy to think of encryption as an on/off switch, but in actuality encryption is more like a volume knob – there are various features and implementation details which can marginally increase or decrease the security of the encryption in an app.

5-300x227.jpg

Centralised services

There is significant variance when it comes to how Telegram, Whatsapp, Signal and Facebook Messenger deal with encryption – with some services providing strong, mandatory and auditable encryption, and others providing much weaker protections.

 

Signal

Signal is widely considered to be the best private messaging app when it comes to encryption standards as all Signal conversions are end to end encrypted by default. Signal uses the aptly named Signal protocol, which is developed as an open source project by Open Whisper Systems. [9][10] The Signal protocol has also undergone a security audit, and the results were generally positive finding only minor vulnerabilities. [11]

When correctly implemented, the Signal protocol maintains both Perfect Forward Secrecy (PFS) and Deniable Authentication (DA) in both synchronous (online) and asynchronous (offline) messages. Signal also applies encryption automatically to group chats. PFS is the ability for a protocol to tolerate the loss of a private key, without compromising the privacy of other encrypted messages that are not part of the exposed session key. DA is the ability for each party to prove to themselves that a message was signed by the other participant, but can also deny this fact to a third party. The combination of both properties allows for a messenger where messages are end to end encrypted, selective key loss is tolerable, and the origin of sent messages can never be proven to any party other than the desired recipient. These are very strong guarantees, which in essence emulate the properties of a real world conversation. Hence, a messenger with both these properties is typically referred to as an Off The Record (OTR) messenger.

 

WhatsApp

WhatsApp provides end to end encryption on all messages by default (including group chats), and it uses the Signal protocol for its encryption. WhatsApp also maintains a public partnership with Open Whisper Systems, who assisted them in their implementation of the Signal protocol. [12] However, WhatsApp is not open source, which means there must be a degree of trust that WhatsApp’s implementation of the Signal protocol doesn’t expose vulnerabilities.  

 

Telegram

Telegram provides end to end encryption, but only does so for ‘secret chats.’ These chats are opt in, which means usage is low. Telegram does not yet support encrypted group chats.

For the encryption of its secret chats, Telegram currently uses the MTProto 2.0 protocol, which provides both PFS and DA. The MTProto protocol is a unique protocol, and like Signal, MTProto 1.0 has undergone formal security audits. Though in the case of MTProto 1.0, it was found that MTProto:

“is not IND-CCA secure, since it is possible to turn any ciphertext into a different ciphertext that decrypts to the same message.” [13]

With researchers also mentioning that

“The take-home message (once again) is that well-studied, provably secure encryption schemes that achieve strong definitions of security (e.g., authenticated-encryption) are to be preferred to home-brewed encryption schemes.” [14]

Since this audit, Telegram has overhauled its MTProto protocol and released version 2.0, which addresses many of the concerns that were raised in the independent security audits. [15] However many have lost trust in MTProto’s security guarantees based on the aforementioned attacks.

 

Facebook Messenger

Facebook Messenger provides two person end to end encrypted chats, but like Telegram, this encryption is only offered in ‘secret conversations’ and are opt in, meaning that the majority of users are left unprotected. For encryption, Facebook uses the Signal protocol, similar to WhatsApp (owned by Facebook), and is not open source meaning it is difficult for users to verify Facebook’s claims beyond assurances from Open Whisper Systems that the “integration was done appropriately.” [16]

 

Decentralised services

Tox

Tox provides end to end encryption by default on all chats (including group chats). Tox clients all implement the Tox protocol, which uses libsodiums crypto_box implementation. Tox provides PFS and DA for all messages (other than friend requests), however Tox does not support the sending of offline messages. [17] Tox has not undergone a security audit and has come under less cryptographic scrutiny, compared to centralised messengers, due to its smaller user base.

 

Bitmessage

Bitmessage’s encryption is the most basic of the available decentralised messengers. This is mainly due to its asynchronous (offline) operation. Bitmessage encrypts only for longterm public key/private key pairs, meaning that it does not maintain PFS or DA. Bitmessage has not undergone a formal security audit, though community members expressed concern around some of the design decisions, which led to updated designs being released. [18]

XMPP

Since XMPP is simply a protocol, it does not enforce any type of message encryption. Though there are a number of plugins for XMPP servers and clients to enable OTR messaging, like Pidgin’s OTR, and OMEMO extensions. [19]

 

Loki Messenger

Loki Messenger is a fork of the Signal messenger, which means Loki Messenger fully implements the Signal protocol and maintains all the properties of OTR. All Loki Messenger code is open source, allowing users and auditors to ensure the viability of our implementation. [20] There are a number of differences between Loki Messenger and Signal messenger, though encryption wise the only major difference is the storage of pre keys, which in the case of Loki Messenger does not occur on a set of centralised servers, but as the result of prekeys being passed as extra data in message payloads.

 


Scalability and Attacks

Although there are effective methods for relaying messages across infrastructure that is being passively surveilled, these methods often present a clear trade-off to the end user or relay operators; an increase in bandwidth, or processing power for a increase in privacy. In addition, we should consider specific attacks that can be effective against both centralised and decentralised architectures.

 

Centralised Services

Established centralised messaging services like Signal, Telegram, and WhatsApp all have frameworks which enable them to scale with their users. Because they make no overt attempt to obfuscate metadata on a protocol level, their servers can simply relay messages from the source directly to the destination – this level of activity has low overheads. Centralised server models also have an easier time dealing with spam, since they can (and do) impose identity thresholds. These thresholds commonly require a user to sign up to their service using a valid mobile phone number. This limits the number of fake accounts a malicious actor can create.  

However, this type of centralisation can also present significant problems. Primarily, these services become centralised points of data collection, meaning they can expose themselves to requests from law enforcement or face legal action for activity that is occurring on their platforms. It also creates a honeypot for hackers seeking to obtain sensitive information. Additionally, most of these messengers are free to use, which means they need alternative means to pay for the infrastructure costs and staff. In order to create a viable business model, these businesses often attempt to montiese their user base by selling user data to advertisers.

 

Decentralised Services

Decentralised services primarily suffer attacks related to their inability to associate a physical identity with each one of their virtual users. This makes many decentralised models vulnerable to Sybil attacks, which can manifest as denial of service attacks or attacks that are used to passively surveil the network.

In particular services, like Bitmessage, which maintain no concept of a trusted authority, an attacker can generally operate a large portion of the client architecture and pretend to be many legitimate users. In this instance, the attacker could attempt to flood a large number of messages into the system inundating its network. Bitmessage has provided a solution to this through a small proof of work which is generated for each message sent, making it prohibitively costly for an attacker to spam thousands of messages using numerous fake identities.

A separate kind of Sybil attack can target network routing architecture. As there is a relatively low cost to running this architecture, operating a majority of the routers in the network can enable passive temporal analysis. In Tox, this can lead to flooding the DHT (a distributed table which holds the state of the network) with malicious nodes which can then segment users, cause denial of service to the ‘real’ Tox network, or even errode the effectiveness of the onion routing that Tox uses to update its DHT. [21][22]  

 

Loki Messenger

Loki introduces proof-of-work (PoW) on messages that are stored offline. Depending on the Time To Live (TTL) on the message, the difficulty of the PoW is adujsted to be easier or more difficult. For messages that do not require storage, there is no PoW needed as the overhead of processing these messages on Service Nodes is relatively low.

Loki Messenger is able to reduce the impact of Sybil attacks on the routing architecture by requiring that each Service Node lock a large amount of Loki in a special time-locked transaction. This creates an inherent market-based Sybil resistance, making it prohibitively expensive for any single actor to own a large enough number of nodes to perform effective temporal analysis. [23]

Additionally, requiring that each Service Node stake an amount of Loki makes enforcement of good behaviour much easier. If a Service Node is acting poorly, then their stake will remain frozen and they will not receive any rewards for their staking period. This negative consequence (loss of opportunity cost) constitutes a programmatically self-policed punishment system which is run by the Service Nodes themselves in a system called ‘swarm flagging.’ [24]

 


Summary

The messenger landscape is full of emerging and established projects. It is important for consumers to critically analyse each messenger against key metadata, encryption, and scalability/attack resistant criteria. Although some messengers may provide strong encryption, they may not protect users’ metadata. As data breaches on centralised services continue, consumers are calling for more privacy centric applications. As the decentralised ecosystem grows, centralised services like WhatsApp, Signal and Telegram will have to compete against decentralised or federated alternatives. Ultimately, the service which maintains the highest privacy and best user experience is likely to be the winner of this battle.

 


 

References

[1] “Why Metadata Matters | Electronic Frontier Foundation.” 7 Jun. 2013, https://www.eff.org/deeplinks/2013/06/why-metadata-matters. Accessed 10 Sep. 2018.

[2] “Former NSA boss: “We kill people based on metadata”” https://youtu.be/UdQiz0Vavmc?t=27s  Accessed 10 Sep. 2018.

[3] “WhatsApp security and role of metadata in preserving privacy, https://arxiv.org/ftp/arxiv/papers/1701/1701.06817.pdf. Accessed 5 Jul. 2018.

[4] “Facebook scraped call, text message data for years … – Ars Technica.” 24 Mar. 2018, https://arstechnica.com/information-technology/2018/03/facebook-scraped-call-text-message-data-for-years-from-android-phones/. Accessed 5 Jul. 2018.

[5] “Battle of the Secure Messaging Apps: How Signal Beats WhatsApp.” https://theintercept.com/2016/06/22/battle-of-the-secure-messaging-apps-how-signal-beats-whatsapp/. Accessed 10 Sep. 2018.

[6] “Telegram Privacy Policy – Telegram Messenger.” https://telegram.org/privacy. Accessed 10 Sep. 2018.

[7] “Hushmail warns users over law enforcement backdoor • The Register.” 20 Nov. 2007, https://www.theregister.co.uk/2007/11/20/hushmail_update/. Accessed 10 Sep. 2018.

[8] “XMPP | XMPP Main.” https://xmpp.org/. Accessed 11 Sep. 2018.

[9] “GitHub – signalapp/libsignal-protocol-c: Signal Protocol C Library.” https://github.com/signalapp/libsignal-protocol-c. Accessed 11 Sep. 2018.

[10] “Open Whisper Systems – Wikipedia.” https://en.wikipedia.org/wiki/Open_Whisper_Systems. Accessed 11 Sep. 2018.

[11] “A Formal Security Analysis of the Signal Messaging Protocol.” 27 Oct. 2016, https://eprint.iacr.org/2016/1013.pdf. Accessed 11 Sep. 2018.

[12] “Signal >> Blog >> Open Whisper Systems partners with WhatsApp to ….” 18 Nov. 2014, https://signal.org/blog/whatsapp/. Accessed 12 Sep. 2018.

[13] “On the CCA (in)security of MTProto – Cryptology ePrint Archive.” https://eprint.iacr.org/2015/1177.pdf. Accessed 12 Sep. 2018.

[14] “On the CCA (in)security of MTProto – Cryptology ePrint Archive.” https://eprint.iacr.org/2015/1177.pdf. Accessed 12 Sep. 2018.

[15] “MTProto Mobile Protocol – Telegram APIs.” https://core.telegram.org/mtproto. Accessed 12 Sep. 2018.

[16] “Signal >> Blog >> Facebook Messenger deploys Signal Protocol for ….” 8 Jul. 2016, https://signal.org/blog/facebook-messenger/. Accessed 12 Sep. 2018.

[17] “otr-like offline messages · Issue #1432 · irungentoo/toxcore · GitHub.” https://github.com/irungentoo/toxcore/issues/1432. Accessed 13 Sep. 2018.

[18] “My Security Analysis of Bitmessage.” 20 May. 2013, https://bitmessage.org/forum/index.php?topic=1666.0. Accessed 13 Sep. 2018.

[19] “#16801 (Add OMEMO Encryption support to XMPP) – Pidgin.” 10 Feb. 2011, https://developer.pidgin.im/ticket/16801. Accessed 13 Sep. 2018.

[20] “GitHub – loki-project/loki-messenger: Signal — Private Messenger for ….” 24 Aug. 2018, https://github.com/loki-project/loki-messenger. Accessed 13 Sep. 2018.

[21] “Tox should be resilient to Sybil attack. · Issue #517 · TokTok/c-toxcore ….” https://github.com/TokTok/c-toxcore/issues/517. Accessed 14 Sep. 2018.

[22] “GitHub – irungentoo/toxcore: Tox Onion routing spec..” https://github.com/irungentoo/toxcore/blob/5ea703c844b12e86702c35b53b0b798fe5f86634/docs/Prevent_Tracking.txt  Accessed 14 Sep. 2018.

[23] “Cryptoeconomics of the Loki network.” 11 Jul. 2018, https://loki.network/Cryptoeconomics. Accessed 14 Sep. 2018.

[24] “White Paper – Loki Network.” 13 Jul. 2018, https://loki.network/wp-content/uploads/2018/08/LokiWhitepaperV3_1.pdf. Accessed 14 Sep. 2018.


View the full article

Snider

Weekly Dev Update #21

Hey Y’all,

Some bigger changes going in this week as we prepare for our next hardfork, the date of which should be announced soon so watch out for updates in the community channels!

Loki Core



LLARP / Lokinet

We welcome our new full-time Lokinet developer, Michael https://github.com/mt2309. He started by cleaning up our CMakefile – you will see more commits from him over the coming weeks

  • Progress continues on libllarp
    • Support older versions of rapidjson
    • Make jsonrpc server build optional
    • More event loop TCP support
    • Fix timers to use less energy for better laptop support
    • Establish a max ev write buffer
    • Static analysis clean up
    • Call DHT clean up timer
    • Flush kqueue on tick
    • Give HS look up 20s instead of 10s
    • FreeBSD build instruction
    • sh support for bootstrap
    • FreeBSD: add route, disable special tun behaviour
    • Man page updates
    • Modenise CMake build, now requires 3.7
    • Dtrace profiler start
    • Use event loop for time
    • Recuse Windows files from old builder repo
    • Added intel intrinsics for 32bit AVX
    • Clean up a lot of MSVC compiler support
    • Refactor Windows event loop and got it working correctly
  • DNS library
    • Static analysis fixes
    • MX and TXT record support
  • GitHub Pulse Stats for the last week: Excluding merges, 4 authors have pushed 57 commits to master and 58 commits to all branches. On master, 121 files have changed and there have been 17,151 additions and 993 deletions.
  • Most changes can be found at:
    https://github.com/loki-project/loki-network/
  • Current version: v0.3.0
    https://github.com/loki-project/loki-network/releases/tag/v0.3.0

Loki Messenger

Thanks,

Kee


View the full article

Snider

Full Time Developers

  • With seven full time developers we were able to launch Service Nodes in September, two months early.
  • Managed to run a test version of Lokinet on a private testing network successfully.
  • Research, review, find and fix critical bugs for Loki and exchanges trading Loki.
  • We have noticed increasing difficulty in fixing bugs and merging changes from Monero as Loki moves away from Monero’s original code. There will be an increase in developer resources to merge these changes in the future.

Network Infrastructure & Performance Testing Services

  • In depth network testing on the Loki Testnet resulted in the ability to find and fix critical bugs before Service Nodes were released on Mainnet.
  • Extensive load testing for the Service Node network was performed with the assistance of RPM Solutions.
  • Lokinet decentralised nodes were tested for the first time during this period on a private network, delivering exceptional results. “Able to stream HD media” -Jeff, Lead Developer on Lokinet.

Marketing Services

  • Completion of the first Twitter bounty program, which resulted in increased awareness and community growth.
  • Consistent creation of Loki content, management of social media platforms and channels with 24/7 admins delivering live communications and active community assistance.
  • During this cycle, we have been able to collect relevant marketing data from media created. We have collected data across all current media platforms to be able to maximise growth going forward.
  • We have assisted Loki’s push into the masternode market by communicating with Masternodes.online and Masternodes.pro. We are expecting an influx of Loki adopters with the statistics these services are expected to provide shortly.

Media Services

  • Release of ‘This is Loki’ animation, on track to be out most viewed video on YouTube.
  • Weekly Dev updates, educational videos and guides released in reference to I2P and Service Node setup.
  • A newsletter created for early adopters of Loki was emailed out to a select few, updating them on the inner workings of the network, as well as instructions on how to set up a Service Node, which was well received.

Documentation Services

  • Mkdocs, a wiki style page for all relevant information about Loki, has started coming together and is currently hosted on Github here: https://loki-project.github.io/loki-docs/.
  • The Service Node Portal has been updated with full guides on Service Node setup best practices.
  • Readme files added and updated, these can be found on Github.
  • We have created and released a detailed ROI calculator for Service Nodes in the form of an Excel spreadsheet, for Windows and Mac OS.

PR Services

  • After communicating with over five different PR companies, we selected Wachsman to assist Loki with public image and respectable media connections.
  • We have liaised with Wachsman to deliver timely details for press releases and media placements.
  • Currently there is a positive outcome from Wachsman, and we will most likely continue to use their services going forward.

Conference Attendance and Promotional Services

  • We have represented Loki at the Zero Knowledge Summit in Berlin, Germany.
  • We represented Loki at local event spaces such as the Blockchain Centre, Melbourne University, and YBF Ventures.
  • Interviews with ETH Berlin, Dezentral meetings, attending an FBG networking event and Wirtschaft event.

Research & Development Services

  • Loki Messenger, Lokinet/ LLARP, Service Nodes, multiple Loki wallets and Loki core code have been heavily researched and are in different stages of testing currently. An accurate week by week breakdown of each service currently being worked on has been documented thoroughly and can be found on our social channels and our blog.

Data Analytics & Market Research Services

  • The data analysed from Twitter, YouTube, Reddit, Loki website, Discord, Facebook and Bitcoin Talk have seen increased user interaction and community growth.
  • We are able to use this to increase marketing efficiency for future awareness campaigns.

Administration & Bookkeeping Services

  • As the 2018 Tax year has been completed, we are in the middle of wrapping up all available data in relation to the private sale and tax incentives for the LAG by researching and communicating with accountants, tax specialists and R & D consultants.
  • General bookkeeping of accounts, reconciling transactions, and storing crypto transaction data in an easy to understand way for future use.

View the full article

Snider

Weekly Dev Update #20

Hey Y’all,

Lots of hiring this week! We have brought on two new members who will be joining us in the coming weeks – I will introduce them once they complete their first pull requests.

Daemon


Service Nodes


LLARP / Lokinet

We are looking for experienced sysadmins to run nodes that connect to our toynet. Please join Discord room called #Lokinet and we can add you to the node operator role. You can host a hidden service or browse existing hidden services.

  • Progress continues on libllarp
    • More memleak fixes
    • Fix DHT bug
    • Bundle libsodium
    • Network event changes
    • Drop ninja support, use make -jX now where X is the number of cores you have available
    • MacOS: Tun flush
    • Limit introset propagation
    • Always use random established path
    • Only publish introset to nearest router
  • libAbyss
    • More implementation
    • Start TCP event work
  • DNS library
    • Refactoring of data structures
  • GitHub Pulse Stats for the last week: Excluding merges, 3 authors have pushed 65 commits to master and 74 commits to all branches. On master, 254 files have changed and there have been 24,917 additions and1,841 deletions.
  • NOTE: Loki Builder compile helper is now deprecated and integrated with main repo.

Loki Messenger


Thanks,  

Kee

 


View the full article

Snider

Weekly Dev Update #19

Hey Y’all,

Things are moving along at a fast pace as we hire more developers.

Service Nodes

TLDR: Be very careful if you are using autostake in an open or closed pool.


LLARP / LokinetIf you’re lucky and join our Discord, you might catch Jeff or Ryan, the developers of LLARP, live streaming as they code.

Again, special thanks to our community contributors, Despair (AKA Pickle Rick) and Cathugger.

  • Released LokiNET 0.3.0: “i can’t believe it’s not i2p”
    • https://github.com/loki-project/loki-network/releases/tag/v0.3.0
    • More robust packet support, better path building, improved DHT handling of RCs, MacOS run support, new config locations, more sane timeouts, .loki hidden service addresses, Reverse DNS support, and better memory management
    • We urge all Lokinet toy node operators to upgrade ASAP, as they’ll be unable to communicate as the network upgrades.
  • Progress continues on libllarp
    • Make tunnel interface fragmentation-aware
    • Cleanup UDP handling
    • One’s complement math improvements
    • Tunnel packet filtering at destination
    • Drop too large packets, instead of truncating
    • Additional streaming improvements: support DCCP (improving congestion control) and UDP-Lite
    • TCP checksum improvements
    • Better IPv4 bogon checking on RCs to prevent bogons to end up on public routers descriptions
    • Handle expire intro before building next message
    • Log endpoint when requesting introsets
    • Make sure event loop doesn’t overflow
    • On HS lookup failure, try random path
    • IP range tools
    • Handle case of no backup path better by
    • More unit tests
    • Win32: separate read/write event ports to avoid overwriting queue events
    • Win32: clean up and various define clean up
    • Fix memory leak in routing messages
    • Change UTP queue size from 128 to 1024
  • libAbyss 
    • Set up basic README
  • DNS library
    • Improve handling of .loki lookups
    • Reverse DNS lookups for dynamically handed out IP addresses
    • Handle various error conditions better
    • Make reverse DNS matching smarter
  • GitHub Pulse Stats for the last week: Excluding merges, 4 authors have pushed 36 commits to master and 36 commits to all branches. On master, 46 files have changed and there have been 758 additions and 325 deletions.
  • Compile helper (include assets, initial seed routers and dependencies)
    https://github.com/loki-project/lokinet-builder

Loki Core


Loki Messenger

Thanks,  

Kee


View the full article

Snider

 

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

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

 

Updating software

The downtime between two registration periods is one of the best times to update your Service Node to the latest version of the Service Node software, as it can be done without the risk of accidentally deregistering your node.

The latest version of the Service Node software can be found here https://github.com/loki-project/loki/releases/latest and we have also complied a written guide and a video guide on how to update your Service Node software.

 

Solo Operators

If you are a solo operator and used autostake, then you must ensure that whatever computer you issued the stake command from is online during your re-registration period. You must also ensure that there is still a process running called loki-wallet-cli as this wallet will scan the blockchain and recognise when your node has been de-registered, and as soon as your funds become unlocked it will restake your Loki.

If Autostaking fails for any reason then solo operators can run the prepare_registration command on their Service Node again and run the outputted command in their wallet. This will stake your Loki again.

 

Closed Pools

A closed pool is a pool in which each contributor is specified by their staking address and the amount they are contributing. If you are staking Loki without running a node, ask your operator whether you are in an closed or open pool, they should be able to give appropriate guidance.

If you are Autostaking in a closed pool as a participant we highly recommend that you contact your pool operator and switch away from autostaking back to manual staking. Disabling autostake is as simple as ending the wallet process (called loki-wallet-cli) on your machine, this can be done by using:

 

On Linux: pkill loki-wallet-cli or

ps aux | grep loki-wallet-cli and using the process id quoted and running kill <process ID>

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

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

 

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

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

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

 

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


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

 

Open Pools

Open pools are pools for which there is no specified contribution addresses. Anyone can contribute to an open pool without notifying the pool operator.

For open pools in version 1.0.4 we have disabled the autostake feature. This is due to the high risk for operators or contributors to inadvertently lock funds due to a lack of communication. Additionally using autostake in open pools in the current implementation fails to reduce the amount of the stake as per the decreasing staking requirement.

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

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

 

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

 

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

 

User experience

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


View the full article

Snider

Weekly Dev Update #18

Hey Y’all,

Lots of code going in this week, with some big design decisions especially around Swarms and Loki Messenger.

There was also a new release of the the Loki CLI wallet and daemon, which all Service Node operators should update to. The release does not include consensus changes but does change how autostaking works, making users much less likely to lock funds unintentionally by autostaking.

The release is here: https://github.com/loki-project/loki/releases/latest and there is also a video guide on how to update here: https://youtu.be/u7kyAoBsQIY.


Service Nodes


LLARP / Lokinet

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

Special thanks to our new contributor, CatHugger, who’s pitched in and helped organise some of our network structures.

  • Progress continues on libllarp
    • Windows work on tunnel code
    • Only publish HS if we have a minimum of 3 paths
    • Don’t publish all path builds
    • Put router profiling back in place, adjust algorithm
    • Play with threading crypto functions again
    • Update logging time format to be more human readable
    • Make logger memory churn lower
    • Better handover logic
    • Initial admin API for managing a live router
    • Several memory corruption fixes
    • Clear re-used restructures in tun interface to stop info leaking
    • A ton of tun interface protocol clean up
    • Fix Introset expiration bug
    • Introset code refactoring
    • Implement “No Logging” level
    • Lots of minor fixes
    • Improve documentation
  • DNS library
    • Additional cleanup
    • Started DNS Unit tests
    • Initialisation everything in header
    • Disable SOA packet crashes for now
    • Question parsing correctionness
    • Improve documentation
  • GitHub Pulse Stats for the last week: Excluding merges, 4 authors have pushed 80 commits to master and 80 commits to all branches. On master, 79 files have changed and there have been 2,116 additions and 594 deletions.Most changes can be found at: https://github.com/loki-project/loki-network/
  • Current version: v0.2.2 (next one coming soon!) https://github.com/loki-project/loki-network/releases/tag/v0.2.2
  • Compile helper (include assets, initial seed routers and dependencies) https://github.com/loki-project/lokinet-builder

Loki Messenger


Loki Core

Thanks,

Kee


View the full article

Snider

Weekly Dev Update #17

Hey Y’all,

Another weekly Dev Update for everyone.

Service Nodes


LLARP / Lokinet

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

  • Progress continues on libllarp
    • Optimise the router’s inbound links data structure
    • More keepalive tuning
    • Support tunnel “packet info” for better multiplatform support
    • MacOS tunnel support is now fixed
    • No longer stores Introsets when forwarding
    • Improve autoconfiguration
      • A default “hidden service” is made for client access, and configuration option to enable, disable or auto-config
      • -g for router auto-config, -c for client auto-config
      • Detect if you’re already using any private network ranges
      • Make it play more nicely with existing hidden service definitions
      • Don’t overwrite configs unless -f is present
    • Give lookup more time: adjust timeout from 5s to 10s
    • Only consider introductions that don’t expire in the next 2 minutes
    • Don’t establish outbound context for previously made inbound sessions
    • “cache convo tag and drop traffic”
    • Deallocate previous Introset before replacing
    • Brought Windows build up to date
    • Make sure Windows build doesn’t crash if only one network interface
    • Made AVX2 codepath 32-bit clean
    • Fix bencoding for ILP32/LLP64
    • MacOS/BSD (kqueue) updates
    • Try to improve path handovers
    • Improve transit message padding to the nearest MESSAGE_PAD_SIZE
    • Adjusted DST awareness on timestamps
    • Fix DHT double free
    • Remove dead code
    • Path Info hashing
    • Swap out intro with next intro as it is safe
    • Update protocol docs
    • Give paths more time to build: timeouts changed from 15s to 30s
    • Minimum time between each path build changed from 5s to 10s
    • Minimum path latency adjusted: from 10s to 5s
    • Path timeout changed from 20s to 10s
    • Stricter profiling of paths/routers
    • 2 path build fails before kicked (changed form 8)
    • Try to build path 5 times before failing
    • Don’t prematurely close sessions
  • DNS library
    • Rely on llarp::Addr more to allow easier IPv6 support
    • Make DNS server port configurable at compile time (DNS_PORT)
    • Made sure DNS relay works with default “hidden service”
    • Update DNS daemon to just run a router (similar to Lokinet), scheduled to be downgraded to just a integration test
    • Mapping an address now does it on all hidden services/tunnel as there is only one DNS server (on most non-“netns-linux” platforms)
  • GitHub Pulse Stats for the last week: Excluding merges, 3 authors have pushed 93 commits to master and 93 commits to all branches. On master, 86 files have changed and there have been 3,898 additions and 4,874 deletions.
  • Most changes can be found at: https://github.com/loki-project/loki-network/
  • Current version: v0.2.2 (next one coming soon!) https://github.com/loki-project/loki-network/releases/tag/v0.2.2
  • Compile helper (include assets, initial seed routers and dependencies) https://github.com/loki-project/lokinet-builder

Loki Core

  • In process of merging a huge chunk of upstream changes, this includes Bulletproofs.
  • IPv6 first implementation is now finished; this will add client support for IPv6 connections.  Just working on the final details now. https://github.com/loki-project/loki/pull/280

Thanks,

Kee


View the full article

Snider

Weekly Dev Update #16

Hey Y’all,

The dev team had an interesting week, which was primarily spent responding to bugs in the Loki core implementation. Lokinet developers have been working super hard and are getting close to something that is usable by the end user.

***

Releases

This week we published a minor release which can be found here: https://github.com/loki-project/loki/releases/tag/1.0.2 This incorporates fixes for newly operating Service Nodes and prevents a burning bug, mentioned below.

This update does not contain any consensus rule changes and therefore is a non-mandatory upgrade. However, if you are a Loki merchant, you should update immediately. Service Nodes who consistently take their nodes offline should also update. We will publish a guide soon on how to safely update a Service Node, however you should not be concerned unless you are planning to take your Service Node offline for a period of time.

***

Service Nodes

***

LLARP / Lokinet

We are looking for experienced sysadmins for running nodes that connect to our toynet. Please join the Discord room called Lokinet, and we can add you to the node operator role. You can host a hidden service or browse existing hidden services.

  • Progress continues on libllarp
    • Prep for next release
    • FreeBSD Compile fixes
    • Various low level network updates
      • Give protocol a fresh buffer instead of resetting
      • Only tick ev if running
      • Properly close sockets so we don’t run out over time
      • Double max protocol message size to 4k to make sure intros fit inside one packet
      • Increase the UTP socket buckets
      • Improve llarp::Addr utility
      • Start IPv6 support for tun
      • Promote tun to enabled by default, disable tap
    • DHT changes
      • Make sure DHT old RCs updates don’t stomp new ones
      • Try fixing DHT crash
    • Configuration
      • Update testnet config generation
      • Update auto configuration
      • Bootstrap node
    • Sessions
      • Server shutdown now cleans up sessions
      • Prevent dead sessions from updating and building more paths
      • Up session inactivity cost and change timeout to 60s from 10s
    • Introsets
      • Allow node introset to have 10s clock difference
      • Don’t propagate or store introsets on crypto error
      • Made sure timestamp is added to introset (Protocol backwards compatible breaking change)
    • Intros
      • If intro is bad then potentially trigger a manual path rebuild
      • Prevent spamming of intro frames
      • Reset intros before reuse
      • Fix intro matching by removing expiration and latency comparisons
    • Hidden service
      • Make sure hidden service lookups are valid and handle response
      • Optimise hidden service publishing from a random establish path to using a “closer” algorithm
      • Require 6 paths for a hidden service instead of 4
      • Expire outgoing hidden service paths
    • Path building improvements
      • Track path data usage
      • Don’t kill paths when under heavy use
      • Make sure path is recently active (20s) before checking for expiration
      • Only timeout path if no messages received are ever received on it
      • Don’t accept introset if it expires in the next 60s
      • Separate send (40s) and connect (60s) hidden service timeouts
      • Enable path callbacks even if marked bad
      • Reduce outbound path failure by attempting to use parent endpoint’s pathset
      • Path building backoff to prevent DoS in such a way that make sure intros don’t die
      • Preemptively trigger rebuild before expiration to ensure continuity
  • DNS library
    • Support other tun gateways other than 10.x.x.x
    • Refactor .loki lookup into its own file
    • Fix SIGINT handling on DNS binary
    • Moved logic worker loop into DNSc (client) for timers
    • Support multiple DNS IP trackers for netns
    • Allow upstream DNS configuration per tun interface (nameresolver key)
    • Fix PTR query detection to allow reverse DNS to work
    • Fix NXDOMAIN (not found) packet to include question name
    • SOA packet fixes
    • Various header cleanup
    • Make sure all vectors use unique_ptr for tighter memory management
    • Prevent duplicate mappings
  • GitHub Pulse Stats for the last week: Excluding merges, 2 authors have pushed 90 commits to master and 90 commits to all branches. On master, 76 files have changed and there have been 3,606 additions and 1,553 deletions.
  • Most changes can be found at: https://github.com/loki-project/loki-network/
  • Current version: v0.2.2 (next one coming soon!) https://github.com/loki-project/loki-network/releases/tag/v0.2.2
  • Compile helper (include assets, initial seed routers and dependencies) https://github.com/loki-project/lokinet-builder

***

Loki core

  • Fixed a bug affecting Cryptonote coins where no warning was giving for non spendable outputs, leading to effective burning if coins were credited.

https://github.com/loki-project/loki/pull/268

Thanks,

Kee


View the full article

Snider

Weekly Dev Update #15

Hey Y’all,

Last week was our biggest release week so far- SERVICE NODES ARE NOW LIVE!

Service Nodes

Service nodes are now released! At time time of publishing this, there are 84 Service Nodes now running (https://lokiblocks.com/service_nodes) There have also been a number of pooled Service Nodes, and some even waiting for contributions.


LLARP / Lokinet

If you’re lucky and join our Discord, you might catch Jeff or Ryan, the developers of LLARP, live streaming as they code.

We want to give a special shout out to Despair, an open source contributor who has continued to update the porting Lokinet over to Windows (and improve BSD support).

  • We are looking for experienced sysadmins for running nodes that connect to our toynet. Please join the Discord room called Lokinet, and we can add you to the node operator role. You can host a hidden service or browse existing hidden services.
  • Progress continues on libllarp
    • Start MacOS tun support
    • Make linux tun code more feature complete
    • Made hidden service address to ip address mapping more stable
    • client/hidden services stabilisation (we were able to stream audio/video and post on websites)
    • Now config file location defaults to ~/.loki or you can specify the location to the config file
    • Several session, intro, introset, tuntap, DHT, and nodedb fixes
    • Correctly calculate TCP/IP checksums
    • Keepalive reimplementation and adjustments
    • Adjust path timeouts
    • Build fixes (Windows, Solaris, OpenBSD)
    • Logging juggling: removed some, added some
  • DNS library
    • Integrated hidden service mapping, so we can now resolve .loki addresses
    • Integrate DNS global IP tracker with tun endpoint code for better communication between systems
    • Use DNS to hint at what paths to prebuild
    • Adjusted timeout for linux
  • GitHub Pulse Stats for the last week: Excluding merges, 3 authors have pushed 102 commits to master and 102 commits to all branches. On master, 199 files have changed and there have been 13,454 additions and 7,454 deletions.
  • Most changes can be found at: https://github.com/loki-project/loki-network/
  • Current version: v0.2.2 https://github.com/loki-project/loki-network/releases/tag/v0.2.2
  • Compile helper (include assets, initial seed routers and dependencies) https://github.com/loki-project/lokinet-builder

Thanks,

Kee


View the full article

Snider

Weekly Dev Update #14

Hey Y’all,

Last update before mainnet Service Node launch! It’s getting close now, so make sure you’re ready for when we fork on September 20th at block 101250.

Service Nodes


LLARP / LokiNET

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

  • Released LokiNET 0.2.2: “first mostly working version” https://github.com/loki-project/loki-network/releases/tag/v0.2.2
    • New low-level wire protocol (libμTP: μTorrent Library), DHT network bootstrap, mde IntroSets expire.
    • We urge all lokiNET toy nodes operators to upgrade ASAP, as they’ll be unable to communicate as the network upgrades.
  • Progress continues on libllarp
    • Remove -march=native
    • Updated protocol documentation
    • Close session with invalid router contacts
    • Persist RC from lookups in nodedb
    • Handle updated RCs better, add RC removal from nodedb
    • Attempt to fix segfault on quit
    • Improved logging output
    • Gitlab CI fixes
    • IntroSet validation, expiration and republish refactors
    • Allow multiple tunnel interfaces
    • Tunnel interface fixes and packet info commit, remove queue
    • Improve packet discarding communication (so we can expire disconnected paths)
    • Connect to 10 random routers on startup
    • Improve μTP write pump to improve send rate
    • Fix memory leak on sign/encrypt fail
    • Update DHT nodes to include ones from disk
    • Try to reduce chatter on DHT
    • Up minimum routers to 4, default to 5 and make min/max configurable for path building
    • Verify path latency to have a minimum standard of 10s before considered dead
    • Refactor path state machine
    • Profile will track each routers connect timing history to guess best timeout for it
  • GitHub Pulse Stats for the last week: Excluding merges, 1 author has pushed 44 commits to master and 44 commits to all branches. On master, 176 files have changed and there have been 11,973 additions and 7,125 deletions.
  • Most changes can be found at: https://github.com/loki-project/loki-network/commits/master
  • Compile helper (include assets, initial seed routers and dependencies) https://github.com/loki-project/lokinet-builder

Loki GUI

Thanks,
Kee


View the full article

Snider

 

As Loki is the first Monero fork (and CryptoNote coin, by extension) to have an active implementation of Masternodes, we are staggering releases and adding features as we go. This is new territory and each change we make to the the Monero codebase must be extensively tested before release.

 

What Loki Service Nodes do in the short term? (Right now)

As part of the 1.0.0 release, Loki Masternodes (called Service Nodes) will have minimum functionality; they will store a full copy of the blockchain, and every hour they will publish an uptime proof, which is essentially a ping to the network letting the network know that they are still live. Nodes that have not submitted an uptime proof in 2 hours will be deregistered by voting quorums. Voting quorums are randomly selected sets of 10 nodes which vote on the state of the network every block.

Although the first implementation of Masternodes on a Cryptonote coin is a large move forward in the Masternode world, the major advantages that Service Nodes provide during this beginning stage will be greater privacy when transacting. However, Loki Service Nodes have larger plans ahead, and release 1.0.0 represents only the foundation.

 

In the Medium Term (3-6 Months)

In the medium term we are working towards making Service Nodes useful to the end user. This includes a couple of essential features:

  • Every Service Node will now be a remote node that serves the blockchain to users.
  • Every Service Node can now run tests and collect data on other Service Node performance; they can assess blockchain storage, bandwidth statistics, and provide message storage for Loki Messenger.
  • Based on these tests, Service Nodes can deregister any underperfoming node if the voting quorum reaches consensus.
  • Lokinet will be deployed on Service Nodes, along with the Loki Message server.

Adding these features to Service Nodes allows us to deploy our first end-user Loki Service called Loki Messenger. Loki Messenger (based on the Signal protocol) allows users to communicate more privately than ever through the first market-based Sybil resistant mixnet network, Lokinet.

 

In the Long term (6-12 Months)

In the long term Loki Service Nodes will need to have high capacity bandwidth connections to provide to the Loki network with routing data. Lokinet will become a fully fledged mixnet providing anonymous access to the internet, and will also have direct integration with browsers, providing an integrated solution for private messaging, internet access and finances .

 

Want to Know More?

Our Whitepaper details the technicals behind Loki’s network architecture and Service Node functionality, and our Cryptoeconomics paper provides an in-depth analysis on the economics around our Service Nodes.

 


 

Website

Twitter

Reddit

Bitcoin Talk

Telegram

Discord

GitHub


View the full article

Snider

Weekly Dev Update #13

Hey Y’all,

Another weekly Dev Update for you to peruse.

Service Nodes

Over the weekend we will draft the final binaries for Service Nodes; this will include a hard fork height of (101250) ~September 20th. Thus we will begin the mandatory upgrade period for all Service Nodes. Be on the lookout for posts in the announcements channel on Discord or Telegram.

If you have enough Loki  and are planning to run a Service Node on the mainnet, there is still time to get hands-on and test by using the testnet guide here: https://github.com/loki-project/Meta/blob/master/SNFullGuide.m


LLARP / Lokinet

  • Progress continues on libllarp
    • Replacing IWP with curvecp (https://curvecp.org/) then replaced curvecp with libUTP
    • This should fix handshake problems and reduce the burden of developing our own UDP wire protocol
    • NEW DEPENDENCY: Start using libUTP (micro torrent protocol)
    • NEW LINUX DEPENDENCY: (debian: libcap-dev) for network namespaces
    • Some llarp::addr and interface utility improvements
    • LokiNetwork addressInfo and RouterContact helpers
    • An attempt to implement jemalloc
    • Valgrind some corruption out
    • Some hidden service address fixes
    • Get multiple routers from DHT
  • GitHub Pulse Stats for the last week: Excluding merges, 1 author has pushed 0 commits to master and 15 commits to all branches. On master, 223 files have changed and there have been 10,560 additions and 2,402 deletions.
  • All changes can be found at: https://github.com/loki-project/loki-network/tree/curvecp
  • Current version: v0.1.0 https://github.com/loki-project/loki-network/releases/tag/v0.1.0
  • Compile helper (include assets, initial seed routers and dependencies) https://github.com/loki-project/lokinet-builder

Thanks,
Kee


View the full article

Snider

Weekly Dev Update #12

Hey Everyone,

We keep chugging forward with testnet this week, Lokinet is developing some more user friendly features, and a couple of developers are in Europe traveling for conferences so we have a smaller dev update this week.


Service Nodes


LLARP / Lokinet

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

  • Released LokiNET 0.1.0: “Traffic Correlation Nation”
  • Progress continues on libllarp
    • Start DHT refactor
    • DHT can ask for random peer list (explore packet)
    • Fix DHT feedback loop
    • Linux: Isolate networking into a cgroup (net namespaces)
    • Some file/path utiltiy functions
  • GitHub Pulse Stats for the last week: Excluding merges, 1 author has pushed 8 commits to master and 8 commits to all branches. On master, 57 files have changed and there have been 1,890 additions and 1,253 deletions.
  • Most changes can be found at: https://github.com/loki-project/loki-network/commits/master
  • Compile helper (include assets, initial seed routers and dependencies) https://github.com/loki-project/lokinet-builder

Thanks,
Kee


View the full article

Snider

 

Over the last three months, there has been significant focus on Loki’s layer two, with numerous papers and articles revealing the true scope of Loki’s Service Node functionality with Loki now becoming a fully fledged mixnet. There has also been much talk about how Loki as a currency, or layer one transactional medium, will function in this framework. Initially we envisioned Loki would act as an access token to prevent Sybil attacks, however there are some downfalls of that system which we addressed in an article here. Given we have focused so much on Loki’s second layer, it’s time to give Loki’s first layer some explanation, and demonstrate why Loki is not only an advancement in layer two design, but also what makes it a worthwhile cryptocurrency.

 

A Move Towards Scaling

 

Monero and most other Cryptonote coins have dynamically scaling block sizes, meaning there is no hard limit to how many transactions can theoretically take place on the blockchain. However in practice, nodes must transmit data between each other, and as each block is accepted into the network and the block size grows, low performance nodes can struggle to keep up with the higher bandwidth requirements and suffer computational stress trying to verify all transactions. This can centralise the operation of full nodes to miners, who make up one of the only parties that have an incentive to operate full nodes.

 

If we can create a way to incentivise the operation of full nodes, we can avoid the aforementioned issues. This is one of the goals of Loki Service Nodes; to create a network of full nodes that are incentivised to hold and serve a full copy of the blockchain. These nodes must meet standards of service that are tested by a distributed method of flagging called Swarm Flagging. Because nodes are competing for a limited block reward and can be removed from the staking reward pool, they are always incentivised to serve copies of the blockchain to users and relay transactions.

 

Theoretically, this means that Loki can scale to handle much larger blocks and thus, handle a higher transaction throughput. This is predicated on the fact that the full nodes operating on the Loki network offer higher bandwidth/storage and compute performance than nodes on the Bitcoin or Monero network.

 

Instant Transactions with Blink

 

In a typical blockchain system, the confirmation time for any given transaction is the time it takes for a transaction to be included in a block. However, because of competing miners, withheld blocks, and Finney attacks, recipients usually require a number of additional blocks to be created on top of the block which holds a transaction before it is considered to be complete.[1] Depending on a multitude of factors specific to each blockchain, this process can take 10-60 minutes, which is inconvenient for merchants and customers who must wait for confirmations before they release goods or commence services.

 

Because of Loki’s Service Node architecture, near instant transactions are possible. Blink enables the same transactions that would occur on the Loki mainchain to be confirmed in seconds rather than minutes, assuring both the sender and the receiver of the validity of the transaction, and protecting the receiver against a double spend.

 

Blink works in a similar fashion to DASH’s InstantSend.[2] However unlike DASH’s InstantSend, Loki maintains all of its privacy properties throughout the process. Any third party looking at a Blink transaction will have no idea of the amount, nor the address of the sender and receiver. This opens up a range of new use cases for Loki, where face-to-face payments become increasingly practical and online payments become quicker and easier for users.

 

Stable and Formally Defined Funding Model

 

Funding models for cryptocurrencies are generally tricky, weak and informal, and donation only models can lead to the creation of special interest groups like blockstream, Bitcoin Unlimited and Bitcoin ABC. These groups typically act as for profit companies who drive an agenda that might not align with the community as a whole. The downside to most formally defined models is they act as a sort of tax, either through emissions or some kind of fee. This can be seen to take choice away from users as they are unable to allocate their funds to the projects they see as important.

 

Attempting to solve some of the aforementioned issues, Monero maintains a forum funding system, which is fully funded by a donations model. Projects vetted by the the Monero core team are featured on the Seeking Funding page, and users are free to donate Monero to projects they feel are worthy. The Monero core team also has an official donations wallet which often contributes large amounts of Monero to projects seeking funding. The advantage of the donations model is that users have full autonomy over how they spend their funds and what specific projects they support. However, there are also disadvantages to this model: funding is never guaranteed for high quality projects, and a large number of the projects receive about 1/5th of their donations from their ‘General Donations’ fund for Monero itself. The ability for a community like Monero to continue to self-fund and provide core contributions may decrease over time, and that’s something we want to avoid with Loki.

 

Loki’s long-term funding model is quite different from the donations model used by the cryptocurrencies mentioned above, and we think it will provide a significant advantage to consistent development, which will be in the interest of our users. Proposed in the whitepaper V3 is a revised governance block reward, which allocates 5% of each block reward to fund governance operations. Of this, 5% block reward 3.75% is controlled by the Loki Foundation, a registered Australian non-profit which is legally bound to spend the block reward as per its constitution.

 

“facilitating the development of an open source, highly secure, decentralised data

transmission network that allows individuals, business and government to freely

transact and communicate without the threat of malicious third party interference”

 

The other 1.25% is controlled by the Service Nodes through the Loki funding system. The Loki funding system is an entirely non-custodial system of proposal funding, meaning the Loki Foundation cannot control how its funds are allocated. Because Service Nodes are not bound by Australian law or a constitution, this greatly expands the range of proposals that can be funded. To distribute funds to proposals, Service Nodes vote on proposals that occur on-chain, and funding is allocated every two months via special funding blocks which pay a portion of their block reward to proposal addresses. Because Service Nodes represent players with a high stake in the Loki system, they are incentivised to vote on proposals which will increase the value of their stake.

 

Remote Node Availability

 

Due to the design of all CryptoNote coins, the blockchain cannot be easily queried by connection to a full node. Instead of simple queries being made for the balances of public keys, full nodes must transmit full blocks to users, and the user has to scan every transaction in the block and identify whether they can calculate the private spend key for the destination stealth address. This results in significant stress being placed on every remote node operator with no reward, and Monero and other Cryptonote coins therefore rely on the altruism of community members to fund these operations, which can be problematic.

 

It is common for mobile users in Monero to cycle through 3 or 4 remote nodes before connecting to one that is reliable. Additionally, as any user can become a remote node that serves blocks to the community, there is the possibility that “popular” remote nodes will provide an altered history of the blockchain. Though this altered history cannot be used to directly steal a user’s funds, in combination with other malicious attacks, a remote node could potentially convince a user to send funds twice to someone who has already received the transaction.

 

By rewarding Service Nodes, Loki creates a large, decentralised network of nodes with a full copy of the blockchain. These nodes are incentivised to serve copies of the blockchain to users and relay transaction. If a user chooses to connect to these nodes at random, ‘popular’ nodes are no longer an issue. This also balances the load of remote syncing across the whole network instead of onto a select few nodes.

 

Lokinet, SNApps and Highly Integrated Payments

 

Work is ongoing on Lokinet, which when fully launched will be a private, decentralised and Sybil resistant overlay network for the internet. You can read a detailed article about it here.

 

Anyone can host services on Lokinet, which will be called SNApps (Service Node Applications). With SNApps, any web developer will be able to host websites that are completely anonymous; the website owner won’t know the IP address of their visitors, and and the visitors won’t know the IP address of the website they connect to. All content hosted inside Lokinet will be accessible through the Loki browser.

 

The Loki browser will have an inbuilt wallet. Users will be able to fund this wallet with Loki, and the browser will automatically hook into SNApps that display Loki addresses for payments. This will make it very easy for a user to operate a store, or take or make payments for goods and services while maintaining anonymity between both networking and transactional layers. Lokinet will also have exit functionality, so any website operator who serves a website on the wider internet will be able to implement these hooks for users of the Loki browser to easily manage Loki payments.

 

In Summary

 

Loki’s value is derived not only from an inventive layer two, but also as a layer one transactional medium, or cryptocurrency. Although Loki is moving away from the use of $LOKI as simply an access token, there are still some significant advantages to $LOKI over other privacy based coins. Most of these advantages are a result of the widely distributed set of Sybil resistant nodes, called Service Nodes.  Due to Loki’s high scalability, Loki can handle a higher transaction throughput and offer higher bandwidth/storage and compute performance than nodes on the Bitcoin or Monero network. Leveraging Service Nodes, Loki can be sent near instantly and privately using Blink bringing instant new use-cases. Loki’s unique funding model provides strong governance and avoids the pitfalls and potential risks that donation-only models pose. Due to Loki’s incentivised Service Nodes, remote syncing loads are balanced across the whole network and the issues caused by ‘popular’ nodes are avoided. Layer one, coupled with an impressive layer two provides a whole suite of services to assist Loki users transact and communicate with absolute freedom.

 


[1]  “Irreversible Transactions – Bitcoin Wiki.” 15 Mar. 2018, https://en.bitcoin.it/wiki/Irreversible_Transactions. Accessed 25 Apr. 2018.

[2] “Whitepaper · dashpay/dash Wiki · GitHub.” https://github.com/dashpay/dash/wiki/Whitepaper. Accessed 27 Jul. 2018.


View the full article

Snider

Weekly Dev Update #11

Testing, testing, testing! A Weekly Dev Update full of testing for y’all this week.

Service Nodes


LLARP / Lokinet

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

  • Progress continues on Libllarp
    • Tuntap interfaces work
    • Multiplatform work (BSD, win32, gcc5)
    • CoDel improvements (requeue unprocessed items)
    • Update auto-gen config
    • Memory / IP helper utilities
    • Manual path rebuild
    • Make “Link Relay Commit” packet actually work
    • Make sessions hold paths between routers
    • Path refactor clean up
    • DHT queuing refactor
    • Additional unit tests
  • LokiBuilder updates
    • Submodule syncing
    • More public testnet RCs
    • Windows tun driver
    • Windows installer/uninstaller start
  • GitHub Pulse Stats for the last week: Excluding merges, 3 authors have pushed 55 commits to master and 55 commits to all branches. On master, 79 files have changed and there have been 2,101 additions and 764 deletions.
  • Most changes can be found at: https://github.com/loki-project/loki-network/commits/master
  • Current version: v0.0.3 https://github.com/loki-project/loki-network/releases/tag/v0.0.3
  • Compile helper (include assets, initial seed routers and dependencies) https://github.com/loki-project/lokinet-builder

Architecture Team

  • Progress continues on exploration of Proof of Stake paper for Loki.
  • Will be re-releasing the economic paper as a archival document now that the proposal has been accepted by the community and it has been solidified in code.  

Thanks,  

Kee


View the full article

Snider

Weekly Dev Update #10

Hey everyone,

Big week of testnet changes this week

Service Nodes

0.3.3 Magic Mani tesnet beta, released https://github.com/loki-project/loki/releases/tag/v0.3.3-beta


LLARP / Lokinet

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

  • Released LokiNET 0.0.3 https://github.com/loki-project/loki-network/releases/tag/v0.0.3
    • Various incompatible protocol changes to propel the protocol forward, including SNTRUP, which strengthens the encryption against quantum-based attacks.
    • We urge all Lokinet toy node operators to upgrade ASAP as they’ll be unable to communicate as the network upgrades.
  • Progress continues on Libllarp
    • Use SNTRUP for introset public key
    • Moved netloop and logic into same thread
    • Hidden services should sorta work
    • More android/win32 fixes
    • Implement more tuntap code
    • Fix shadow/test net build
    • Fix RC nickname bug
    • Fix bug in prematurely closing socket under heavy load
    • Configuration/Defaults clean up
    • Hidden services now have a session
    • Move some of protocol handling into crypto thread
    • Intro timeout changed from 5s to 30s
  • LokiBuilder updates
    • llarpd => lokinet
    • Start Debian package support
  • GitHub Pulse Stats for the last week: Excluding merges, 2 authors have pushed 33 commits to master, and 33 commits to all branches. On master, 181 files have changed and there have been 8,181 additions and 1,583 deletions.
  • Most changes can be found at https://github.com/loki-project/loki-network/commits/master
  • Compile helper (include assets, initial seed routers and dependencies) https://github.com/loki-project/lokinet-builder

Architecture Team

  • Began writing a paper exploring block creation via Proof of Stake on Loki, findings will be presented as a proposal before the community and Loki Foundation.

Loki Locker


Loki Messenger

Thanks,
Kee


View the full article

Snider

Hey Everyone,

The development pace in the Loki office has been consistent and quicker than expected, and I’m happy to announce that we will be launching Service Nodes well ahead of schedule. A huge thank you to our two main Service Node developers, jcktm and Doy-lee, who have been putting in long hours to get this out. This will mark the first time Proof of Service has been implemented on a CryptoNote coin and we’re really excited to have everyone onboard to test it out.

How will the rollout/update process work?

TimelineFinal.png

Beginning on 09/08/2018 (August 9th) the testnet will be restarted with Service Nodes enabled. The testnet will operate for two weeks in this state. During this period, we will make final changes to the Service Node software, fix bugs as they are reported to us, and add features which will be useful for the final release. Bugs found by community members in Service Node software will be rewarded with bounties at the discretion of the Loki team and depending on severity.

On 23/08/2018 (August 23rd) we anticipate the release of the final version of the Service node software, including any bug fixes/changes we found in the Service Node testnet period. This release marks a mandatory upgrade period between 23/08/2018 and 20/09/2018. In this period we will contact exchanges, pools, and miners. All clients will need to update their software. Testnet will continue operation with the new changes, however on 20/09/2018 (September 20th) mainnet and stagenet will hard fork and Service Nodes will be released in a production environment.

Service Nodes already set up on testnet will NOT rollover to mainnet, so when the mainnet forks everyone will have the same opportunity to begin operating a service node using real Loki.

What do Service Nodes do in this update?

As part of the rollout process we need to slowly introduce Service Node functionality. In this upcoming fork, Service Nodes will only have the ability to register and receive rewards. There is no complex testing functionality yet enabled. In this fork Service Nodes will not route data other than propagating blockchain data to their peers. However to be rewarded, Service Nodes that are online automatically transmit pings to the network. If a ping is not submitted each hour a node is assumed to be offline and will be deregistered.

More complex functionality is being heavily developed as we speak and will be introduced to Service Nodes over the coming months. However, it is essential that we deploy the base functionality of Service Nodes before we can begin integrating more complex testing and begin routing packets on top of service nodes.

Remaining features that will be introduced over the coming months:

  • Blink (Instant Transactions)
  • Lokinet (Packet Routing & SNApps)
  • Loki Messenger (Message Storage)
  • Enforced Remote Nodes (Light Client Improvements)

How can I register a Service Node on testnet?

You will need the alpha software from here, and instructions on how to use it are here, this also includes a guide on how pooled staking works. This guide assumes you know how the CLI and daemon work. If you don’t, a complete guide on staking is in the works, so sit tight!

To test Service Nodes, you will need:

  • 100 testnet Loki
  • A VPS, or highly available home server
  • The Loki CLI wallet, and the Loki Daemon

On testnet, the staking requirement will be 100 Loki, so everyone can get in and test. We will distribute funds from the testnet foundation wallet, so just ping one of the admins in the Loki telegram or discord and we will send you some testnet Loki to stake. You can also mine testnet loki by running start_mining <address> in lokid.

We’ve also shortened the staking duration to just 2 days in the testnet, so you should be able to test restaking over the next couple of weeks to familiarise yourself with the process.

This would also be a good time for anyone seeking to pool their staking requirement to test out how that functionality works. So jump on testnet and start testing.

How can I provide feedback or submit bugs?

For general feedback and discussion about the software, you can go to the brand new #service-node-testing discord channel.

If you spot bugs in the code or add features to it, you should submit an issue or pull request to GitHub. The devs will review the bugand include any necessary fixes in the final release.

What are the requirements for setting up a Service Node on Mainnet?

We have been testing various VPS providers across the course of the last few months and we will be making some recommendations based on positive experiences. In the beginning Service Node operators will have much more choice about where they set up their nodes due to the significantly lower stresses they face. When Loki Messenger and Lokinet are finished, the bandwidth requirements will become more onerous and low performance nodes will have to upgrade hardware and network connections or risk being kicked off the network by automated bandwidth testing systems. When a date for Lokinet is set, we will warn Service Node operators at least 30 days in advance so that they can upgrade their servers.

Where can I go for more information on Service Nodes?

We are currently setting up a webpage to act as a central point for operators to stay updated with all of the latest information. This portal will be updated as we produce documentation on Service Nodes. We want to make setting up a Service Node as clear as possible, and provide in-depth explanations on how the process works, so operators don’t end up making expensive mistakes.

We are updating the channels in discord to include a dedicated Service Nodes category, so we can have more in-depth discussions about the software and provide support to those having difficulty.

Very exciting times! Let’s get testing, LOKIGANG!


View the full article

Snider

Weekly Dev Update #9

Hey Y’all,

Some big things on the horizon for Loki, and a new dev update so we keep the community in the loop!

Service Nodes


LLARP / Lokinet

If you’re lucky and join our Discord, you might catch Jeff or Ryan, the developers of LLARP, live streaming as they code.

We want to give a special shout out to Despair, an open source contributor who has started porting Lokinet over to Windows (and improve BSD support).

  • Progress continues on Libllarp
    • Protocol updates, hidden service progress and DHT improvements
    • INI writer can now write to an existing INI file and preserve comments
    • Reorganise threading, logic and netio now run in the same thread
    • Fix epoll/kqueue tick logic, add timeouts for kqueue
    • Buffer bit function refactor, also allow aligned buffers to be filled with random data
    • Private IP range 172 accuracy improvements
      • Multiplatform work:
      • Per platform building instructions now in README
      • Android: Fixed headers
      • MacOS: Make pthread CMakeList more favorable to XCode
      • Windows: initial port (requires Windows NT 5.0+)
      • Shared Library and FFI fixes
    • Don’t put private addresses into RCs, allow nicknames and don’t store non-public RCs in nodedb
    • Nodedb now only loads .signed files
    • Deterministic logging and builds
  • DNS library
    • A couple refactor clean up passes
    • Newer hook interface to make .loki handling easier
    • Better packet parser, support SOA response parsing
    • Actually sends NXDOMAIN if not found
    • Handle multiple responses to already answered packets more gracefully
  • GitHub Pulse Stats for the last week: Excluding merges, 4 authors have pushed 50 commits to master and 47 commits to all branches. On master, 100 files have changed and there have been 5,120 additions and 1,116 deletions.
  • Most changes can be found at https://github.com/loki-project/loki-network/commits/master
  • Current version: v0.0.2
    https://github.com/loki-project/loki-network/releases/tag/v0.0.2
  • Compile helper (include assets and dependencies)
    https://github.com/loki-project/lokinet-builder

Loki Locker

Loki Locker will be Loki’s version of MyMonero. A web based wallet you can use to store your Loki. Work has kicked off as a fork of OpenMonero. This should be ready for release quite soon, giving the community another way to store their Loki.

  • Work has continued on the visual redesign of Open Monero you can see a teaser of the visual design here. https://i.imgur.com/ScLpzbM.png
  • Worked on Integrated QR code scanning, and a new interface for transactions.

We also just got our third pull request merged back into Monero, and we’re aiming for our fourth to be IPV6 support to be PR’ed soon.

 

Thanks,  

Kee

 


View the full article

Snider

Weekly Dev Update #8

Hey Y’all,

Another weekly dev update to keep everyone up to speed:

Loki Base Layer

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

Service Nodes

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

LLARP / Lokinet

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

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

Thanks,  

Kee

 


View the full article

Snider

Weekly Dev Update #7

Hey Y’all,

Big week, big update!

Loki Baselayer


Service Nodes


LLARP / Lokinet

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

Architecture Team

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

Thanks,
Kee


View the full article

Snider

 

This article is intended as a basic overview as to the reasoning behind changing Loki’s emission curve. To this purpose we have largely simplified the factors and influences at play; for a more in depth understanding, please refer to our paper Loki Cryptoeconomics: Alterations to the Staking Requirements and the Emission Curve.

 

DISCLAIMER

This article contains charts and figures which include examples of return of investments and prices for the Loki cryptographic coin. These prices are examples only and are not a prediction, forecast, or representation as to any actual likelihood of price movement of the Loki cryptographic coin. The payments shown in the examples below are general in nature and will only take effect if the planned hardfork occurs. Factors outside the control of Loki could impact what actual payments are made to Service Nodes. Those parties not operating a Service Node should not rely on these examples when deciding whether or not to participate in the Loki project. This article should be read together with the Loki whitepaper and full Loki Cryptoeconomic report.

 

The main goals in changing the Loki emission curve are to:

  1. Maintain Loki’s Sybil attack resistance, by
  2. Ensuring that enough Service Nodes are incentivised to run, by
  3. Aiming to keep the return on investment (ROI) for running a Service Node at an acceptable level.

The current emission curve is problematic because an excess of Loki is being produced which could lead to a large number of Service Nodes in the early years. While this doesn’t sound like a bad thing, considering our commitment to a decentralised network and Sybil resistance, it will become an issue when the Service Node rewards are split between too many Service Nodes.

While the price of Loki fluctuates with the cryptocurrency market, real world costs in running a Service Node exist, and the reward each Service Node receives for running must be greater than the real world cost of running. In other words, Service Node operators must be making an acceptable profit, or there won’t be incentive for them to run.

 

chart-1.png

Chart 1

 

Chart 1 demonstrates that our current emission curve will result in many Service Nodes entering the network in the first few years, with the return on investment (ROI) quickly dropping below 0%. If too many Services Nodes run, the rewards are not worthwhile, and Services Nodes will leave resulting in a more centralised network.

 

proposed-chart.png

Chart 2

 

Chart 2 depicts the effects of Loki’s proposed new emission curve, where there are less Service Nodes from the outset, but the return on investment (ROI) remains positive. This is better for the network in the long term because these Service Nodes will be continually incentivised to run (providing market-based Sybil resistance), while retaining a decentralised network.

For further information regarding Loki Service Node game theory, and Loki Cryptoeconomics, please refer to the following reports:


View the full article

Snider

 

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

 

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

 

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

 

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

 

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

 

Gaming This Change

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

 

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

 

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

 

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

 

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

 

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

 

Technical Details

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

 

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

 

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

 

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


View the full article

Sign in to follow this  
×