Jump to content

Snider

Administrators
  • Content Count

    1172
  • Joined

  • Last visited

  • Days Won

    23

Everything posted by Snider

  1. Snider

    Weekly Dev Update #133

    Hey y’all, This week has been the first week back after the Christmas holidays, so our dev updates will be back to their usual length from here on out. This week, the Session team worked to finish the final Session protocol implementation, specifically focusing on closed groups. The Lokinet team submitted their TUN refactor code which is expected to improve performance, especially on Windows. The Loki Core team worked on various Oxen rebranding projects, mostly focusing on the wallets. Loki Core Add API for staked amount on pending transactions https://github.com/loki-project/loki-core/pull/1386 Strip Android libs, disable Trezor & protobuf https://github.com/loki-project/loki-core/pull/1388 Backport Oxen rebranding from dev branch https://github.com/loki-project/loki-core/pull/1387 Fix Windows CLI bug https://github.com/loki-project/loki-core/pull/1385 Update electron wallet file name https://github.com/loki-project/loki-core/pull/1384 Update dependencies https://github.com/loki-project/loki-core/pull/1383 iOS and Android package upgrades https://github.com/loki-project/loki-core/pull/1382 Add optional stake amount calculation to RPC https://github.com/loki-project/loki-core/pull/1381 Oxen rebranding https://github.com/loki-project/loki-core/pull/1380 Lokinet This past week, Lokinet development resumed with significant work on a big “TUN refactor” PR (fTUN is the name of the programmable virtual network interface driver that Lokinet uses to provide local virtual addresses). This throws away a big chunk of borrowed code in favour of a streamlined implementation, which is always nice, but more importantly it fixes a longstanding issue with Windows performance where we have continually seen considerably worse throughput and latency numbers on Windows compared to Linux or macOS. We still have more testing and some known issues to stamp out, but we hope to get release 8.1.3 out, particularly for Windows users, in the near future. TUN code refactor https://github.com/loki-project/loki-network/pull/1495 macOS build instruction fixes https://github.com/loki-project/loki-network/pull/1506 Add full-static-deps armhf build (+upload) https://github.com/loki-project/loki-network/pull/1505 Session We’re finishing off the remaining Session Protocol changes this week. This primarily means changing closed groups to use the Session Protocol instead of our implementation of sender keys. Session iOS Fix bug where attachments would sometimes not download https://github.com/loki-project/session-ios/pull/330 Full Session V2 protocol implementation https://github.com/loki-project/session-ios/pull/325 Reorganise files https://github.com/loki-project/session-ios/pull/331 Full list of commits can be found here https://github.com/loki-project/session-ios/commits/dev Session Android Core refactor ongoing https://github.com/RyanRory/loki-messenger-android/commits/refactor Session protocol V2 implementation https://github.com/loki-project/session-android/pull/396 Full list of commits can be found here https://github.com/loki-project/session-android/commits/dev Session Desktop WIP closed group changes https://github.com/loki-project/session-desktop/pull/1424 Fix conversation message list https://github.com/loki-project/session-desktop/pull/1423 Add tests for Session protocol https://github.com/loki-project/session-desktop/pull/1421 Improve message polling for open groups https://github.com/loki-project/session-desktop/pull/1419 Fix issues with voice recording for voice messages https://github.com/loki-project/session-desktop/pull/1417 Thanks, Kee The post Weekly Dev Update #133 appeared first on Loki. View the full article
  2. Overview This is the v0.17.1.9 minor point release of the Monero GUI software. This is a recommended release that contains mitigations against the ongoing memory exhaustion attack. The latest CLI release notes can be found on the precedent blog post Some highlights of this minor release are: Update monero submodule to v0.17.1.9 Windows GUI binary is now reproducible Add high DPI support on Windows The complete list of changes is available on GitHub, along with the source code. Contributors for this Release This release was the direct result of 3 people who worked, largely unpaid and altruistically, to put out 12 commits containing 99 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are: xiphon Snipa selsta Download The new binaries can be downloaded from the Downloads page or from the direct links below. Windows, 64-bit Windows, 64-bit (Installer) macOS, 64-bit Linux, 64-bit A complete guide for the GUI wallet is included in the archives, but an online version is available. Download Hashes If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes: monero-gui-win-x64-v0.17.1.9.zip, 862aa9a6564a60be3e70ee30eb061d5186a141ce62842b3d741558470c255988 monero-gui-install-win-x64-v0.17.1.9.exe, edc47b1540510640a40e8d52ad4ab3a6220f935e881fd65b02ccce94a28c3fa2 monero-gui-mac-x64-v0.17.1.9.dmg, c8a8ea012e8731bfacd17434fdd3a0f03302fc61d7187d218da5ff6a6e869f0b monero-gui-linux-x64-v0.17.1.9.tar.bz2, 6334acbe9877e2e86b1902b111abc59e170aedc701ea71cbae49830191bbd745 A GPG-signed list of the hashes is at https://getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys). To ensure that the files you download are those originally posted by the maintainers, you should both check that the hashes of your files match those on the signed list, and that the signature on the list is valid. Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced). View the full article
  3. Overview This is the v0.17.1.9 minor point release of the Monero software. This is a recommended release that contains mitigations against the ongoing memory exhaustion attack. Some highlights of this minor release are: Add different limits for epee binary format for P2P and RPC Add more sanity checks on data size (portable_storage) Fix deadlock banning while updating peer lists Add aggressive restrictions to pre-handshake p2p buffer limit Add a max levin packet size by command type Restrict duplicate keys and unnamend sections in epee binary format More sanity checks in new chain block hashes Minor bug fixes The complete list of changes is available on GitHub, along with the source code. Contributors for this Release This release was the direct result of 7 people who worked, largely unpaid and altruistically, to put out 30 commits containing 362 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are: luigi1111 Snipa moneromooo vtnerd selsta xiphon binaryFate Download The new binaries can be downloaded from the Downloads page or from the direct links below. Windows, 64-bit Windows, 32-bit macOS, 64-bit Linux, 64-bit Linux, 32-bit Linux, armv7 Linux, armv8 Android, armv7 Android, armv8 FreeBSD, 64-bit Hashes If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes: monero-win-x64-v0.17.1.9.zip, a3e6e2f55deb487f6b4a33cf430d82d62e986d37d7d589dcb33a4ff0a13a062b monero-win-x86-v0.17.1.9.zip, bb3c633a3d8ac160bc9c75ef514a9cbc77f1f45bdbd220d1963d78d66435c23a monero-mac-x64-v0.17.1.9.tar.bz2, d4850ae45eee67868140183cd8c00f9e1f9e1cc5e415b00bc78c14c7bab85834 monero-linux-x64-v0.17.1.9.tar.bz2, 0fb6f53b7b9b3b205151c652b6c9ca7e735f80bfe78427d1061f042723ee6381 monero-linux-x86-v0.17.1.9.tar.bz2, 1f51206c1996a577f976c0526b93cc495fe577db21f68b55636dce926f201206 monero-linux-armv8-v0.17.1.9.tar.bz2, ef16c3aefc8a17f0a547ffec9e2f087923c6bf293b9538294d14cbd318f1ab98 monero-linux-armv7-v0.17.1.9.tar.bz2, c8b226af900b018fade24742e5936b0ef6cec3fcdbc8a57a4b3f3d6d2507a2ec monero-android-armv8-v0.17.1.9.tar.bz2, 2c45e0fb364ff2e60aa9cdf0d3faef145b22a8632b3336cc248eeba24352d39b monero-android-armv7-v0.17.1.9.tar.bz2, c7192caf85f82ecdd1e7299c9ae6314fe2fb02ed9b7035a426a8644b676cc75f monero-freebsd-x64-v0.17.1.9.tar.bz2, 3052f691a1a7631ba50c3f4d6f1b1355bdcc9a8c0c617cf56ced400afa1ea402 A GPG-signed list of the hashes is at https://getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys). To ensure that the files you download are those originally posted by the maintainers, you should both check that the hashes of your files match those on the signed list, and that the signature on the list is valid. Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced). View the full article
  4. Towards the end of 2020, we announced the biggest change to the Loki Project since launch: Loki is rebranding to become Oxen. There have been plenty of questions about what the rebrand entails, when everything will be happening, and what our users need to do (spoiler alert: Loki users and $LOKI holders don’t need to do anything whatsoever). To minimise uncertainty and confusion, today we’re announcing our roadmap and timeline for rolling out the Oxen rebrand. For an overview of the reasons behind the rebrand, head over to our rebrand announcement blog. What’s happening today (6 Jan 2020, AEDT): Today we’re dropping the first taste of Oxen’s gorgeous new branding: A landing page is now live at oxen.io. Head on over to feast your eyes on Oxen’s logo and a peek at the colour scheme we’ll be using. What’s happening tomorrow (7 Jan 2020, AEDT): Tomorrow is when the rollout really kicks off. Our social media accounts, Telegram community, and contact email will officially switch over to Oxen equivalents. An updated desktop wallet with Oxen branding will also be released tomorrow, and our exchange listings will start swapping from $LOKI to $OXEN (note: these are cosmetic changes only; $LOKI holders do not need to take any action). All Loki users can continue using their current wallets and services without having to update — everything will continue working as normal. But if you want to see the slick new branding in the wallet, you should update regardless! What’s happening over the coming weeks: Over the following weeks, our listings on other service providers like CoinMarketCap and CoinGecko will make the switch to $OXEN. We’ll also be releasing completely new mobile wallets, rewritten from the ground up to be faster, better, and, of course, with that beautiful new Oxen branding. The older mobile wallets will continue to function, but keep an eye on our social channels for links to the new mobile apps when they’re available — we know you’re going to love them. We’re also hard at work on the full Oxen website, which will be live at oxen.io in early February, along with fully reworked and rebranded documentation for every part of the project and our tech stack. In the meantime, the existing loki.network website will remain live until the rollout is completed. Regarding wLoki: The wLoki transition is going to be a little bit more involved. We’ll make an announcement with more information in the coming days. For now, everything will continue working as usual, under the wLoki (Wrapped Loki) name. How you (yes, you!) can help We’re incredibly excited to begin the rollout of the Oxen branding in earnest. But we know that a staggered rollout like this means that there may be some confusion, especially for newcomers to the Oxen (Loki) community. So we’re calling on you, our loyal community members, to help clear things up. If you run across someone who’s unsure what’s going on or why, don’t hesitate to jump in and explain — or just refer them to our blog. Looking ahead With the Oxen rebrand rolling out, we’re more bullish than ever about the future of the project we’ve built together. The future is bright, and we can’t wait to make this journey with you, our community. It’s time for the Year of the Ox. Let’s go. The post Oxen rebrand rollout: Our roadmap appeared first on Loki. View the full article
  5. Snider

    Weekly Dev Update #132

    Hey y’all, Today is the first day back for most of the Loki team after our Christmas break, so there’s a bit less in this dev update than usual. Rest assured, the Loki team is getting straight back onto the development train, working on essential Session features like reimplementing multi-device and building out Session Protocol support for closed groups. The Lokinet team is working on some Windows optimizations which should increase download speeds through exit nodes. Loki Core P2P network changes to reduce possibility of DoS attacks https://github.com/loki-project/loki-core/pull/1379 Fix wallet out of sync issue https://github.com/loki-project/loki-core/pull/1374 Service Node changes to increase time synchronicity https://github.com/loki-project/loki-core/pull/1377 Loki -> Oxen name change branch https://github.com/darcys22/loki-core/commits/oxen-rebrand Change stake amounts to uint64_t’s https://github.com/loki-project/loki-core/pull/1376 ,https://github.com/loki-project/loki-core/pull/1375 Session Before the holiday period, we rolled out the backwards-compatible version of the Session Protocol, and the feedback has been overwhelmingly positive. We will be making various improvements over the next few weeks to further increase stability, particularly for closed groups. Session iOS Begin working on Session Protocol changes for closed groups https://github.com/loki-project/session-ios/commits/session-protocol Session Desktop Fix audio recording view https://github.com/loki-project/session-desktop/pull/1417 Fix moderator crown https://github.com/loki-project/session-desktop/pull/1410 Thanks, Kee The post Weekly Dev Update #132 appeared first on Loki. View the full article
  6. Overview This is the v0.17.1.8 minor point release of the Monero GUI software. This is a recommended release that contains mitigations against the ongoing memory exhaustion attack. The latest CLI release notes can be found on the precedent blog post Some highlights of this minor release are: Update monero submodule to v0.17.1.8 UI tweaks to LineEdit component Minor bug fixes The complete list of changes is available on GitHub, along with the source code. Contributors for this Release This release was the direct result of 3 people who worked, largely unpaid and altruistically, to put out 12 commits containing 99 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are: xiphon Snipa selsta Download The new binaries can be downloaded from the Downloads page or from the direct links below. Windows, 64-bit Windows, 64-bit (Installer) macOS, 64-bit Linux, 64-bit A complete guide for the GUI wallet is included in the archives, but an online version is available. Download Hashes If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes: monero-gui-win-x64-v0.17.1.8.zip, 0c4ce3953824e6e65e2913fb1cb246ebe2742386821d2b92b4a6b6251c66f901 monero-gui-install-win-x64-v0.17.1.8.exe, 81dcefcf42127101568357f56afdbe0c92d1f8b153dff09ae2d062ba96579f4e monero-gui-mac-x64-v0.17.1.8.dmg, f9ad5567e6e1e4a88213190cbde6d974265640438e9f2de41ce0d4839cb021f4 monero-gui-linux-x64-v0.17.1.8.tar.bz2, b9ea5890033a3d67f14abe401c223c5b33947689abaeacf9905e57b811840853 A GPG-signed list of the hashes is at https://getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys). To ensure that the files you download are those originally posted by the maintainers, you should both check that the hashes of your files match those on the signed list, and that the signature on the list is valid. Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced). View the full article
  7. Overview This is the v0.17.1.8 minor point release of the Monero software. This is a recommended release that contains mitigations against the ongoing memory exhaustion attack. Some highlights of this minor release are: Protocol: drop nodes if they claim new data but only give stale data Add some sanity checks on data size (portable_storage) Fix some issues using connections after shutdown, add buffered SSL handshake detection Optional DNS based blocklist (--enable-dns-blocklist) Ban lists may now include subnets The ban command can now load IPs from a file (ban @filename) RPC: add busy_syncing, synchronized fields to get_info RPC: limit the number of txes for get_blocks.bin P2P: ignore incoming peer list entries when we have them blocked P2P: remove peers from grey and anchors lists when blocked Restrict public node checks a little, warn about untrusted nodes Minor bug fixes The complete list of changes is available on GitHub, along with the source code. Contributors for this Release This release was the direct result of 7 people who worked, largely unpaid and altruistically, to put out 45 commits containing 530 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are: TheCharlatan luigi1111 Snipa moneromooo vtnerd selsta anon Download The new binaries can be downloaded from the Downloads page or from the direct links below. Windows, 64-bit Windows, 32-bit macOS, 64-bit Linux, 64-bit Linux, 32-bit Linux, armv7 Linux, armv8 Android, armv7 Android, armv8 FreeBSD, 64-bit Hashes If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes: monero-win-x64-v0.17.1.8.zip, 55bafa33142b2aa979e5f6b4a6ddb60584bc9e9434e3a8c0a7fd8c9852bbcd7e monero-win-x86-v0.17.1.8.zip, 4bd0c594c59de2815e91e7560be5b52370abb351f425c2ea1434a0ae4205c30a monero-mac-x64-v0.17.1.8.tar.bz2, b969d7c8855d59b6962227a5a68f507f183253d06acd548b41673c647317de48 monero-linux-x64-v0.17.1.8.tar.bz2, b566652c5281970c6137c27dd15002fe6d4c9230bc37d81545b2f36c16e7d476 monero-linux-x86-v0.17.1.8.tar.bz2, 827e6e30296135494e80fcd54b0c8e64532b0ec8bdbbbec445860ce47d6f0d87 monero-linux-armv8-v0.17.1.8.tar.bz2, e8580f776152757bf07b0ca9dc3c1fbb4033b0956ab76599ff642fdb84427d1e monero-linux-armv7-v0.17.1.8.tar.bz2, 83f2d8fd32f17b1f6669736015ad25e613987e69c8b052600ac9b8942370ba19 monero-android-armv8-v0.17.1.8.tar.bz2, 1598b73ac35e8c7f35a60cf4afc93d915954e0a3939d5d81ec040d3294eda162 monero-android-armv7-v0.17.1.8.tar.bz2, 0ce30e0882dbdf4fd12d29c556bd805c1ff6e7012a9f028a742726a6e57374a6 monero-freebsd-x64-v0.17.1.8.tar.bz2, 2911c3b605262edaa8e634067c2ba04069990d2bb668b990bfd1a5c35858aaf3 A GPG-signed list of the hashes is at https://getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys). To ensure that the files you download are those originally posted by the maintainers, you should both check that the hashes of your files match those on the signed list, and that the signature on the list is valid. Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced). View the full article
  8. Snider

    Bulletproofs+ in Monero

    Summary Code is now available for Bulletproofs+, a zero-knowledge proving system that can be used in the Monero protocol in place of the existing Bulletproofs zero-knowledge proving system. The new construction would make transactions smaller, faster for wallets to generate, and faster for network participants to verify. While the code is functional and includes tests for the underlying algorithms, it should be reviewed by third-party auditors if chosen for deployment in a future Monero network upgrade. The code is permissively licensed in the hope that it can be broadly useful. Thanks to the Multidisciplinary Academic Grants in Cryptocurrencies (MAGIC) nonprofit organization for coordinating and supporting the grant for this implementation, and to the donors who made this work possible. Resources Bulletproofs preprint by Benedikt Bünz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter Wuille, and Greg Maxwell. This is the preprint (later published after peer review) used as the basis for the current Monero protocol implementation. Bulletproofs+ preprint by Heewon Chung, Kyoohyung Han, Chanyang Ju, Myungsun Kim, and Jae Hong Seo. This is the preprint used as the basis for the proposed Monero protocol implementation. Bulletproofs+ code by Sarang Noether. This is the new implementation code written for compatibility with the Monero codebase. Consensus-related code by moneromooo. This code is necessary for a network upgrade that would include Bulletproofs+ proofs as a consensus rule. Range proving in zero knowledge The Monero confidential transaction protocol requires the use of a zero-knowledge range proving system. Because inputs and outputs in Monero transactions have their value hidden, it's necessary to secretly prove that they represent valid amounts to avoid overflows that would fool the protocol's balance checks. The constructions used for range proving have evolved over time. Originally, the Monero protocol used a variation of ring signatures for this purpose; however, the resulting proofs were very large and slow to generate and verify, leading to slow synchronization of the blockchain and a large amount of chain bloat. This was overhauled after the release of Bulletproofs, a much more efficient range proving system. With Bulletproofs, range proofs are much smaller and faster to verify; further, multiple proofs can be verified at the same time in a batch, leading to even more efficient synchronization. A newer preprint modifies the Bulletproofs construction to produce Bulletproofs+, an even more efficient range proving system. Range proofs in Bulletproofs+ retain a similar underlying structure to those in Bulletproofs; however, they are slightly smaller, faster to generate, and faster to verify. Implementation code is now available that is compatible with the Monero codebase for easy deployment. Efficiency Side-by-side efficiency comparisons between Bulletproofs and Bulletproofs+ range proofs are possible using the performance test framework in the Monero codebase. The size and timing characteristics of range proofs depend on the structure of the transaction that uses them. Because of the way that both the Bulletproofs and Bulletproofs+ algorithms work, the number of outputs in a transaction is effectively rounded up to the next power of two for range proving purposes, with a maximum of 16 outputs permitted in a transaction. The vast majority of Monero transactions contain two outputs, but 16 outputs is also common for pool payouts and other purposes. Size "Regardless of the number of outputs in a transaction, the corresponding Bulletproofs+ range proof is 96 bytes smaller than a Bulletproofs range proof." This table shows the reduction in size for the most common 2-output transaction types seen on the Monero network. Spent inputs Current size New size Reduction, % smaller 1 1.42 kB 1.33 kB 6.6% 2 1.92 kB 1.83 kB 5.1% The results are clear. Bulletproofs+ range proofs are smaller than Bulletproofs range proofs, saving space on the blockchain! Time Proof generation time is typically not an area of practical concern, since wallet software only needs to do this when making a transaction. However, it's worth noting that a 2-output Bulletproofs+ range proof (the most common) generates 10.2% faster! Proving times for other numbers of outputs scale roughly linearly. Proof verification time, on the other hand, is very important! Network participants need to verify large numbers of range proofs when joining the network and synchronizing to obtain new blocks. Fortunately, Bulletproofs+ range proofs (like those in Bulletproofs) can be verified in batches much more efficiently than doing so individually. We can see the differences clearly. This table shows the percent reduction in verification time between the Bulletproofs and Bulletproofs+ algorithms for proofs comprising different numbers of outputs. Tests for verifying single proofs are median values over 10000 randomized tests. Tests for verifying batches of proofs are median values over 1000 randomized tests, where each batch contains 64 proofs. Absolute times are not listed, since they depend on the computing environment; however, relative times are generally comparable and consistent. Outputs per proof Single proofs, % faster Batched proofs, % faster 2 1.5% 5.3% 4 0.5% 9.2% 8 1.6% 9.2% 16 0.9% 10.8% The results are clear. Bulletproofs+ range proofs are faster to verify than Bulletproofs range proofs, leading to faster synchronization! Thanks to Mortanta Manolete for designing the Bulletproofs+ logo! View the full article
  9. Dear community, Today, and after a year-long (but needed) testing period, we are glad to announce that the X-Cash public blockchain is ready to move from Proof of Work consensus algorithm to our new and customized: Delegated Proof of Private Stake consensus algorithm. What is DPoPS? The DPOPS (standing for Delegated-Proof-of-Private Stake) is a brand new and unique Delegate-Proof-of-Stake consensus integrated into X-Cash, an open-source fork of Monero which has since the beginning of the project brought new innovation to the privacy coin space (notably FlexPrivacy, public & private transactions on the same blockchain, from the same wallet). Characteristics The top 50 delegates are elected as block verifiers. Using a variation of Delegated Byzantine Fault tolerance consensus where 55% consensus must be reached for a new block to be added to the network. DBFT allows for up to 45% of the elected block verifiers to be faulty. The system will still be able to produce a new block. Using Verifiable Random Functions (VRF) to select the next block producer in the system. This allows for a random, but a verifiable way of selecting the next block producer. Staking The block reward is given to the block verifier responsible of forging the block, and shared with their voters. Reserve proof-based voting/staking system: the XCASH’s stake always stays in your wallet. There is no lockup period. The staked XCASH always remain in your wallet and you can use them at any time. However, moving them from your wallet will cancel your entire staking No need to keep your wallet/computer online if you are staking towards a shared delegate Voting The minimum stake to vote for a delegate is 2 million XCASH. The election process occurs in every block. New votes will be taken into account at the top of the next hour. Your current vote will automatically get cancelled if you change your vote to a different delegate. There are no voting fees. You can cast a new vote or switch your vote as many time as you like. Blocks Blocks can be verified from the delegates explorer with a detailed explanation of the block content. The voting and reserve bytes data is held in a decentralized database system. The block format is designed to store a hash of the reserve bytes data, pointing to the decentralized database, to reduce size increase of the blockchain. Schedule With everything being ready, we have decided to make the switch from the PoW algorithm to DPoPS consensus algorithm at block 800,000, or around February 4th, 2021 at current block time. There are several things to take into consideration before the release of the mainnet. The switch to mainnet will be organized as followed. Registration Period Strart: January 4th, 2021 The registration will enable the delegates to start registering their nodes and open the community voting for them. The registration will start on January 4th and will last until the block 800,000. This period is 1-month long, to enable everyone to prepare their nodes, start communicating around and accepting votes. Delegates — You have a consequent amount of XCASH, and are looking at getting a delegate position and securing the X-Cash public network? Delegates elected in the top 50 get a block verifier position and get rewarded with the block reward. If you are planning on running a delegate node, you will be able to register as a delegate on the 4th of January. You can start preparing your node in advance by following the extensive guide to becoming a block verifier on the X-Cash public network. You will have the time to decide if you want to run a shared delegate (people vote for you and help you get elected, but in return, you share the reward with them), solo delegate (running with you own XCASH without the help of voters, but keep the whole reward for yourself), and the new private group delegate (an agreed-upon list of voters managed by a delegate to control the voting dilution). Voters — You plan to vote to elect a delegate, and get a share of the block reward in return? We will release everything you need to know to vote securely at the start of the registration period. The 2.0.0 wallet binaries to start voting will be released on the 4th of January, and we will provide a full comprehensive guide to use the CLI interface and vote for your preferred delegate. Here are a few considerations to have in mind to be ready at the start of the registration period: The minimum amount of XCASH to stake/vote is 2,000,000 (Two millions) XCASH. Meaning that if you are trying to vote from a wallet with less than 2M XCASH in it, your vote will be refused. At the beginning, you will only be able to vote from a CLI wallet and the Android wallet. We will provide an easy guide to help you vote if you have never used the CLI interface. You won’t be able to vote from the X-Bank directly. It means that you will have to withdraw your XCASH into an X-Cash wallet to be able to vote and stake your XCASH. We will provide a guide for that as well. Please be minded that you won’t get a share of the block reward from your vote before the block 800,001. But it is a good idea to be ready and have your vote prepared to your delegate so you can stake right away. Switch to mainnet Date: February 4th, 2021 (time will be adjusted depending on when we reach block 800,000) When we arrive at block 800,000 (eight hundred thousand), the network will pause for a couple of hours, and the blockchain will resume by forging the 800,001st block under the new DPoPS consensus algorithm. What should I do now? There is still some time before the start of the registration period (January 4th, 2021), and we are taking the time to produce the necessary guide and tutorials for you to make an educated decision for your votes or your decision to run a delegate. Please don’t hesitate to come and discuss with any of the delegates on our Discord Server. 🙏 Thanks This wouldn’t have been possible without the help of all the participants in the beta & alpha, that took their time, knowledge, and implications into testing and improving the consensus. So many feedback has been taken into account and used to improve the onboarding and user experience of delegates and the stability of the network. From all the team and the community of the X-Cash Foundation, we would like to thank and acknowledge the participants of the beta. 👏👏 +------------------------------------+------------------+ | Delegate Node Name | Delegate Name | +------------------------------------+------------------+ | xcash-ju.fr | Ju | | swan-x | Cygnus | | XCAjoca | cajoca | | x-staking | N3me5is | | xcash.one | Executor | | xcash.it | CryptoDuke | | snakeway | Snakeway | | x-delegate | Element56 | | xcashcolombia | Fidentis | | xcash_lt | Mantas | | *.xcash.rocks | Miaumiau | | xcash-dpops.com | Neppers | | grizzly & aurora | UrsaMajor | | Atlantis-X | Thomas The Cat | | xcashdelegate.com | Miraculu | | Redstar-1 & Redstar-2 | Alibaba | | xcashdelegate.ph | Mryoso1994 | | *inkie | Twinkie | | CryptoWorld | aquila-audax | | 8bit.services | SHA | | DELEGATE_DON'T_HATE | IdzaMeMario | +------------------------------------+------------------+ This list is based on the work of Ju, and might be missing some members. Please contact me (paulxcash#2676 on Discord) if you are missing of the list so I can add you. These people have tested the consensus and additionally, have thoroughly tested their setup to run a stable node. You can be sure that the X-Cash network will be secured with them running a node. Also, more than a year ago, people have participated in the first alpha test and brought a lot feedback and improvements, and we want to thank them. Picatax, Galapagos, akhenaten, Bowcat, Bry Guy, Cygnus, Demo2004, element56, herominers.com, Klendhaar, MadMason, qf3l3k, Quetio, snakeway passer, tjs, Twinkie, UrsaMajor, Zaffy, 𝓕𝓻𝓸𝓰. Useful links Delegate explorer: http://delegates.xcash.foundation/dashboard The delegate explorer tracks the registered delegates and important statistics about the forging of blocks. Discord server: https://discord.gg/4CAahnd The community is gathered on Discord, and you will find most of the delegates there. Don’t hesitate to come by and ask questions. Documentation: https://docs.xcash.foundation/dpops/get-started Everything you need to know about the DPOPS, how to set up a delegate node, and to vote. DPoPS Mainnet: Release and schedule was originally published in X-CASH on Medium, where people are continuing the conversation by highlighting and responding to this story. View the full article
  10. Snider

    Weekly Dev Update #131

    Hey Y’all, This week marks the start of the holiday season for most of the Loki team, so expect to see a little bit less content in the dev updates until the start of the new year. However, work is still ongoing, with a focus on Session and Loki Core. On the Session front, we released a new update on all platforms with new encryption protocol changes which you can read about here. On the Loki Core side, we finished Ledger support (which will be submitted to Ledger tomorrow), and we also worked on a number of quality of life fixes for wallet and service node users. Loki Core Fix staking requirement tests https://github.com/loki-project/loki-core/pull/1373 Begin changing crypto implementations to use Libsodium https://github.com/loki-project/loki-core/pull/1372 Fix some stake unlock wallet_api code compilation problems https://github.com/loki-project/loki-core/pull/1371 Uptime proof version details https://github.com/loki-project/loki-core/pull/1370 Add field which details the reason for a deregistration https://github.com/loki-project/loki-core/pull/1369 Session Last week we released a significant update for all Session clients. This update moves Session to the Session Protocol, its own stateless encryption protocol, which should resolve many of the underlying issues we were having in conversation management. It should also allow us to more quickly develop features like multi-device and account restoration, without the solutions becoming overly complex. Session iOS Various fixes to iOS application https://github.com/loki-project/session-ios/commits/master Work ongoing into Session Protocol refactorization Session Android Ongoing work can be found here https://github.com/loki-project/session-android/commits/master The team is primarily focusing on Session protocol refactorisation Session Desktop Fix conversation list item https://github.com/loki-project/session-desktop/pull/1400 Merge Session react refactorisation https://github.com/loki-project/session-desktop/pull/1398 Ongoing work to refactor message sending and receiving to use Session protocol Thanks, Kee The post Weekly Dev Update #131 appeared first on Loki. View the full article
  11. Overview This is the v0.17.1.7 minor point release of the Monero GUI software. This is a recommended release that contains P2P network layer improvements. The latest CLI release notes can be found on the precedent blog post Some highlights of this minor release are: Ask for writing desktop shortcut on first start (Linux) Fix wallet initialization flag handling Get back "Sending transaction …" splash Disable QML cache Minor bug fixes The complete list of changes is available on GitHub, along with the source code. Contributors for this Release This release was the direct result of 4 people who worked, largely unpaid and altruistically, to put out 16 commits containing 51 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are: luigi1111 xiphon Snipa selsta Download The new binaries can be downloaded from the Downloads page or from the direct links below. Windows, 64-bit Windows, 64-bit (Installer) macOS, 64-bit Linux, 64-bit A complete guide for the GUI wallet is included in the archives, but an online version is available. Download Hashes If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes: monero-gui-win-x64-v0.17.1.7.zip, d6bc6edd9fb0cd867933ff2a66ee99cca03869d728b43d42c98c333570c529f3 monero-gui-install-win-x64-v0.17.1.7.exe, 21fd01bb5c1fa169067208d0f7311d1ebec4e5b187285e5231823b72d6fb1951 monero-gui-mac-x64-v0.17.1.7.dmg, 1664860f4fae066695a74c04b55caa6421a8a10df5bbeb554c2e6dea89336710 monero-gui-linux-x64-v0.17.1.7.tar.bz2, 9a51b62ff422263d73bda1287ab65434602861d03819a15b3cefdab30e9145ec A GPG-signed list of the hashes is at https://getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys). To ensure that the files you download are those originally posted by the maintainers, you should both check that the hashes of your files match those on the signed list, and that the signature on the list is valid. Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced). View the full article
  12. Overview This is the v0.17.1.7 minor point release of the Monero software. This is a recommended release that contains P2P network layer improvements. Some highlights of this minor release are: P2P: include first new block in chain entry response P2P: more restrictive checks on chain entry response Fix syncing with --sync-pruned-blocks flag Update OpenSSL to 1.1.1i Minor bug fixes The complete list of changes is available on GitHub, along with the source code. Contributors for this Release This release was the direct result of 5 people who worked, largely unpaid and altruistically, to put out 24 commits containing 154 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are: luigi1111 Snipa moneromooo selsta hyc Download The new binaries can be downloaded from the Downloads page or from the direct links below. Windows, 64-bit Windows, 32-bit macOS, 64-bit Linux, 64-bit Linux, 32-bit Linux, armv7 Linux, armv8 Android, armv7 Android, armv8 FreeBSD, 64-bit Hashes If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes: monero-win-x64-v0.17.1.7.zip, 4e1352b383095e9d4393a40785e159d6a4a83bca69f304a2dba258d370074ad0 monero-win-x86-v0.17.1.7.zip, ef47d1160f3926b9046b1ee0ac324b8d8c6196f8c93d685ef8e4b7e3274372fc monero-mac-x64-v0.17.1.7.tar.bz2, 0bf79a44d01a5f7970d237344bc1a5268cf307dd2d0e9b09258f1d8d4fedbb94 monero-linux-x64-v0.17.1.7.tar.bz2, 98ce0d22db0d1112114bbad4c9773d1490d30e5c643423c2e5bffc19553207f9 monero-linux-x86-v0.17.1.7.tar.bz2, 4d9730765cb5979234e83f1cdfdf23a9fff7946a11c7fcedea7e1effe6074d93 monero-linux-armv8-v0.17.1.7.tar.bz2, 17a39df633eea37eba4871dcad29ddc1b56af37039e32f10c0492d9fa9ac0e48 monero-linux-armv7-v0.17.1.7.tar.bz2, 952221a6f2b449892e9a51de1b5b63bac9faf4748789b12c12d616aab5d8389f monero-android-armv8-v0.17.1.7.tar.bz2, c629ab6d69d91ef61ca073c9b64479eac51ab7c3bdb0daf44cb8f971a3ba51d3 monero-android-armv7-v0.17.1.7.tar.bz2, 814312f44f5e9be92b8d090b0b5126bd8f747ce325f185832290b98c29a00d44 monero-freebsd-x64-v0.17.1.7.tar.bz2, 50a36a796cbe3de569c26344af311b43afb0a44693383c088685830876a0f0e1 A GPG-signed list of the hashes is at https://getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys). To ensure that the files you download are those originally posted by the maintainers, you should both check that the hashes of your files match those on the signed list, and that the signature on the list is valid. Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced). View the full article
  13. Snider

    Weekly Dev Update #130

    Hey Y’all, This week might seem a little scant for the dev update, but that’s because most of the work we have been doing is still contained to commits on remote or local branches. For example, the Session team is about to publish a refactor of the Session iOS sending and receiving pipeline, and work on the same refactor is progressing quickly on Android. Additionally, the Session desktop team is also about to publish the React refactored desktop application. The Loki Core team is finishing the final parts of Ledger integration, specifically focusing on staking and submitting LNS transactions from a Ledger device. Loki Core Service Node time synchronization fixes https://github.com/loki-project/loki-core/pull/1367 Generate transaction for staking unlock https://github.com/loki-project/loki-core/pull/1364 Ledger support for SN registration, staking, and unlocking from a Ledger device https://github.com/loki-project/loki-core/pull/1195, https://github.com/loki-project/loki-ledger-app/commits/dev Ledger support for LNS transactions Lokinet What went on last week with Lokinet: Little PR news to report this week as Lokinet’s lead developer (Jeff) has been taking a much-needed, long-overdue vacation. We have some preliminary Android work ongoing (no PR yet), and generally are pretty excited with how the 0.8.2 release is performing and being received. We’ve also been having some ongoing discussions about the feasibility of developing and distributing small “plug and play” Lokinet routers that would make Lokinet SNApp and exit support simple, even on devices where Lokinet isn’t available. We’re spending some time this week on Lokinet rebranding: much as “Session” has its unique identity beyond the Loki blockchain, Lokinet’s rebrand aims to accomplish the same (no, it won’t be called “Oxennet”). If you have been holding onto a killer replacement name idea, now’s the time to send it in! Session Session iOS Full list of commits can be found here https://github.com/loki-project/session-ios/commits/dev Primarily, the team has been focusing on the Session iOS refactor, which is slated to go live this week. Session Android Session Android is now undergoing the same sending and receiving pipeline refactor, the majority of the work can be found in this branch https://github.com/RyanRory/loki-messenger-android/commits/refactor Session Desktop Session desktop React refactor is nearing completion, with a release slated for this week. https://github.com/loki-project/session-desktop/pull/1381 Thanks, Kee The post Weekly Dev Update #130 appeared first on Loki. View the full article
  14. Overview This is the v0.17.1.6 minor point release of the Monero GUI software. This is a recommended release that contains P2P network layer improvements. The latest CLI release notes can be found on the precedent blog post Some highlights of this minor release are: Fix transactions getting incorrectly marked as failed Minor bug fixes The complete list of changes is available on GitHub, along with the source code. Contributors for this Release This release was the direct result of 4 people who worked, largely unpaid and altruistically, to put out 22 commits containing 228 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are: luigi1111 xiphon Snipa rating89us selsta Download The new binaries can be downloaded from the Downloads page or from the direct links below. Windows, 64-bit Windows, 64-bit (Installer) macOS, 64-bit Linux, 64-bit A complete guide for the GUI wallet is included in the archives, but an online version is available. Download Hashes If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes: monero-gui-win-x64-v0.17.1.6.zip, 15fac8ad47f1c1a78f92b46692875261d2a3c67a742cb8f43bbed05dc5beb289 monero-gui-install-win-x64-v0.17.1.6.exe, 18bb1b4c5f762bd9eacabececc012cd077cac4d9dc64f46b42c4ea68cdbfa70e monero-gui-mac-x64-v0.17.1.6.dmg, dd3e909c2b2d61f6158def93ec544897ea5cd4c22fa9a8a8398a6c511ba5ec47 monero-gui-linux-x64-v0.17.1.6.tar.bz2, 413d41f8e349b52db60c6932182f852c34587f55f7b4436fe72a0bb7245830c3 A GPG-signed list of the hashes is at https://getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys). To ensure that the files you download are those originally posted by the maintainers, you should both check that the hashes of your files match those on the signed list, and that the signature on the list is valid. Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced). View the full article
  15. Overview This is the v0.17.1.6 minor point release of the Monero software. This is a recommended release that contains P2P network layer improvements. Some highlights of this minor release are: P2P: add scoring system to drop peers that don't behave P2P: drop peers that decrease claimed height P2P: drop peers that spam peer lists P2P: drop peers that don't reply to queries Add –rpc-restricted-bind-ip option Do not use peer_id tracking method over i2p/tor Minor bug fixes The complete list of changes is available on GitHub, along with the source code. Contributors for this Release This release was the direct result of 6 people who worked, largely unpaid and altruistically, to put out 19 commits containing 828 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are: vtnerd luigi1111 Snipa moneromooo selsta hyc Download The new binaries can be downloaded from the Downloads page or from the direct links below. Windows, 64-bit Windows, 32-bit macOS, 64-bit Linux, 64-bit Linux, 32-bit Linux, armv7 Linux, armv8 Android, armv7 Android, armv8 FreeBSD, 64-bit Hashes If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes: monero-win-x64-v0.17.1.6.zip, 40e07fdd8af9a8f5c34bddd826e26036c609bf5eacaf337b38e7ac3644647135 monero-win-x86-v0.17.1.6.zip, a63a1ff1766d9f02f8cd4b8260260cec9cfdf8fa1371143cc68ff1ffee18efd1 monero-mac-x64-v0.17.1.6.tar.bz2, 1b03e2e45b9e8fce461b3f33986122c036f636d4a1019c47b24e7b81c7f1db15 monero-linux-x64-v0.17.1.6.tar.bz2, 01bb6e18773a461a4dcfe2a6d4e4f7e1708b26634bc56696d68c539c3a66f81a monero-linux-x86-v0.17.1.6.tar.bz2, 300e7608927867d63765704a19baa90366b5897e3cef8a56da29ae3a6a5b97a3 monero-linux-armv8-v0.17.1.6.tar.bz2, 874d3de908fb4301de19301b928a1c477a883c40b2491b3b3193df99561a8904 monero-linux-armv7-v0.17.1.6.tar.bz2, 018270d8dde8e895fdc7b5b6de95c36b7e7a63d46406339f810b6fdf91e0b8bc monero-android-armv8-v0.17.1.6.tar.bz2, 0dc3cc265ae0365cb927c235f9ba4391f3c2be7043d183769de5b9b97736b359 monero-android-armv7-v0.17.1.6.tar.bz2, 2ab2e4c715a3978ed36c55848313f8a252b1f7141910c0bcbd52070fcaefcff1 monero-freebsd-x64-v0.17.1.6.tar.bz2, 1ad59103c9ea3a2256c8f4b7066cefd7ce2ebd2b52360edb539115c80a7e6ee1 A GPG-signed list of the hashes is at https://getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys). To ensure that the files you download are those originally posted by the maintainers, you should both check that the hashes of your files match those on the signed list, and that the signature on the list is valid. Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced). View the full article
  16. We have collaboratively been working through what should go into the Lethean roadmap and how we broadcast activity. The Lethean official website is now updated with the most current roadmap: https://lethean.io/roadmap At this stage only completed and actively worked on items are disclosed. Our most recent roadmap updates have been focusing on: - Giving Lethean a new look with a fresh new website! - Making it simpler to stand-up a node, a lot simpler. - Promoting Lethean — In doing so, we attract attention and gain momentum with increased community involvement. - More exchange listings and maintaining these relationships. As you may be aware the Lethean community contributes it’s time on a voluntary basis in managing this project. This means we cannot provide accurate timelines for when roadmap items will be completed and this specific information is therefore removed. The great news is our team is growing with members eager to make an impact on the Lethean project. We are confident and excited about this and look forward to releasing updates on the project as they become available. Why not have your say about what should be the focus right now for Lethean? Reach us on any of our official channels. In our opinion, the more minds we put together the better things will be. View the full article
  17. Eth 2.0 is live. As of 12am UTC on Tuesday, 1 Dec, the first stage of Ethereum’s evolution into a Proof of Stake (PoS) blockchain has now begun. If PoS sounds familiar, that’s probably because Loki has been full PoS since the Salty Saga hardfork back in October. But what is Proof of Stake, anyway? And why is it such a big deal? Proof of Work, work, work, work, work, work… All blockchains rely on something called a consensus mechanism to confirm transactions as valid and enter them into the blockchain. There are a handful of different consensus mechanisms in use, but the two most common types are Proof of Work and Proof of Stake. Until now, the primary version of the Ethereum blockchain has been based on a Proof of Work (PoW) consensus mechanism. PoW is most commonly known as mining. Fundamentally, “mining” crypto through PoW means competing with other miners to solve mathematical problems. The first worker to provide a valid solution attaches that solution — the literal proof of work — to a “block” of crypto transactions, marking those transactions as valid and adding them to the blockchain. That miner then receives the block reward (a certain amount of that blockchain’s crypto) for validating that block, and the process begins again. But PoW has a few fundamental limitations that hold back PoW-based blockchains. For one, PoW on most blockchains has a significant hardware barrier to entry. Back in the early days of Bitcoin, mining BTC was as easy as firing up a mining tool on your GPU and letting it run. These days, that’s still technically true — but now you’re competing with massive server farms full of ASICs (specialised processors designed purely to mine BTC), making it enormously difficult for normal users to participate in the ecosystem. Another issue with PoW is power consumption. As we talked about here, PoW crypto mining is a huge power sink. In 2017, Bitcoin mining alone used over 30 terawatts of power globally — that’s more electricity than the entire country of Ireland consumes in a year. Not only does this cause local issues like electrical grid brownouts and blackouts, it’s also a serious environmental problem on a wider scale. Proof of Stake: Stakin’ for that bacon So, PoW has some problems. But what’s the alternative? You guessed it — Proof of Stake, as featured in Loki’s very own Salty Saga hardfork 2 months ago, and now the core building block of Eth 2.0. In a Proof of Stake blockchain, you can stake (lock up) a certain amount of crypto — the staking requirement — in order to run a node on that blockchain’s network. Once your node has been staked, it has a chance of being chosen to create blocks of transactions (and earning the corresponding block reward by doing so). PoS blockchains typically place staked nodes into an ordered queue, ensuring that nodes receive block rewards regularly (the exact time between rewards varies proportional to the number of nodes on the network). Proof of Stake has some serious benefits compared to PoW. PoS ensures that anyone who can afford the staking requirement (and a few dollars per month for a VPS) can run a full node on the network with a reward rate (typically) significantly higher than rewards earned from investing the same amount into mining hardware. At the same time, requiring node operators to own and stake an amount of crypto ensures that all node operators have skin in the game: every operator is also a holder of the blockchain’s token, incentivising them to work to increase the token’s value. PoS can also provide a high level of resistance to Sybil attacks and 51% attacks. Such attacks involve one person or entity gaining control of the majority of computing power on a blockchain network, enabling the attacker to create an alternate history of transaction blocks which will be accepted by all blockchain nodes because that alternative chain has more PoW behind it than the real chain. A PoW-based blockchain will always theoretically be vulnerable to a Sybil attack, because anyone with access to sufficient computing power could reverse old transactions by reorganizing the blockchain. In a PoS blockchain, however, controlling the majority of nodes on the network requires controlling at least as much of the total crypto supply as is already staked into existing nodes. If a sufficiently large amount of that crypto is already staked into existing nodes, such an attack becomes near-impossible. Eth 2.0 and Proof of Stake: Looking forward Loki and Eth are both going all-in on PoS (though Eth 2.0 won’t be fully operational until sometime in 2022). A huge project like Eth throwing its weight behind PoS is a massive vote of confidence, and yet another confirmation that Loki made the right call with our switch to PoS back in October. So what does this mean for you? In a nutshell: better, more secure blockchains that are easier to participate in, and more environmentally friendly to boot. We’re excited to see more blockchain projects migrating to PoS, and we can’t wait to see where the future of PoS blockchains takes us. The post High stakes: Eth 2.0, PoS, and the future of blockchain tech appeared first on Loki. View the full article
  18. Snider

    Weekly Dev Update #129

    Hey Y’all, This week we worked on fixing up various bugs found in the Lokinet GUI. The Session team continued working on the client refactor and also published a new desktop release which fixed a few bugs. The Loki Core team continued their efforts to integrate Loki into Ledger devices, making the new code compatible with CLSAG transactions. Loki Core Generate transaction for stake unlocking, to properly show in wallet history https://github.com/loki-project/loki-core/pull/1364 Error when trying to sign using watch only wallet https://github.com/loki-project/loki-core/pull/1360 Fix command to restore ED25519 key https://github.com/loki-project/loki-core/pull/1362 Remove obsolete json serialisation https://github.com/loki-project/loki-core/pull/1359 Extensive updates to the Ledger support to bring it up-to-date with Loki 8.x with new CLSAG transaction support, optimizations, and usability improvements https://github.com/loki-project/loki-ledger-app/commits/dev and https://github.com/loki-project/loki-core/pull/1195 Loki Electron Wallet Add sign and verify features to the GUI wallet https://github.com/loki-project/loki-electron-gui-wallet/pull/234 , https://github.com/loki-project/loki-electron-gui-wallet/pull/235 Lokinet You can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time. What went on last week with Lokinet: We shipped Lokinet 0.8.2 on all platforms last week; this fixed a few issues on Linux/Windows, and was our first public 0.8 series release for macOS. Since then we’ve had a few bug reports (keep them coming!) and have been addressing some of the issues. Lokinet PR Activity: 0.8.2 release https://github.com/loki-project/loki-network/pull/1492 Add user-requested feature to allow killing of established exit client sessions https://github.com/loki-project/loki-network/pull/1496 Revamp and refactor tun code for significantly better performance, simpler code, and proper IPv6 traffic carrying support https://github.com/loki-project/loki-network/pull/1495 Made window closing hide to tray rather than exiting the GUI https://github.com/loki-project/loki-network-control-panel/pull/89 Add a Close menu option on Windows https://github.com/loki-project/loki-network-control-panel/pull/90 Fix macos bootstrapping and lokinet.exe spawning on Windows https://github.com/loki-project/loki-network-control-panel/pull/91 Session Session iOS Fix crash on typing indicator https://github.com/loki-project/session-ios/pull/315 Further commits to iOS sending and receiving refactorisation https://github.com/loki-project/session-ios/pull/313 Session Android Structural refactoring step 1 https://github.com/loki-project/session-android/pull/385 Structural refactoring step 2 https://github.com/loki-project/session-android/pull/386 Open group info update refactorisation https://github.com/loki-project/session-android/pull/384 Session Desktop Package and release new version 1.4.2, which includes better onion request file handling and UI fixes https://github.com/loki-project/session-desktop/pull/1394 Change push notification handling endpoint https://github.com/loki-project/session-desktop/pull/1393 Loki Storage Server Fix header parsing issues https://github.com/loki-project/loki-storage-server/pull/398 Increase LokiMQ request timeouts https://github.com/loki-project/loki-storage-server/pull/397 Increase response body limit from 8MB to 10 MB https://github.com/loki-project/loki-storage-server/pull/396 Thanks, Kee The post Weekly Dev Update #129 appeared first on Loki. View the full article
  19. We’ve talked a lot about the benefits of Proof of Stake for the Loki blockchain, but there’s another huge upside to PoS compared to our old hybrid PoS-PoW consensus mechanism: it’s a lot kinder to the planet. Proof of… Harm? Proof of Work — the system many people know as “crypto mining” — has some very real benefits when it comes to securing blockchains. But it has some nasty downsides, too, and one of the worst is power consumption. To dive into exactly why that is, we need to take a brief look at what Proof of Work actually entails. Fundamentally, “mining” crypto through Proof of Work means competing with other miners to solve mathematical problems. The first worker to solve a problem attaches the solution — the literal proof of work — to a “block” of crypto transactions, marking those transactions as valid and adding them to the blockchain. Seems simple enough, right? Well, yes and no. The average user’s desktop PC draws anywhere between 300 and 500 watts of power when it’s being pushed to its limit. A dedicated crypto mining rig, with an array of high-powered graphics cards or dedicated ASICs, can draw several thousand watts — and those rigs are often left on 24/7, maximising the chance of solving blocks to get that sweet, sweet block reward. When you consider that there are millions of people mining different crypos all over the world, all that power usage adds up. It was estimated that in 2017, Bitcoin mining alone used over 30 terawatts of power globally — that’s more electricity than the entire country of Ireland consumes in a year. When you factor in all the other Proof of Work cryptocurrencies, and the fact that the number of miners is only going up, crypto mining is consuming a truly insane amount of electricity. And when the vast majority of electricity worldwide is still drawn from non-renewable sources like coal and gas, crypto mining starts to look like a serious environmental crisis in the making. Go green or go home So what can we do? Simple — ditch PoW. Proof of Stake and other alternative consensus mechanisms don’t rely on competitive problem-solving in the same way Proof of Work does, making them exponentially more power-efficient and significantly reducing their impact on the environment. And when Proof of Stake has so many other benefits for the blockchain ecosystem too, it’s even more of a no-brainer. With Salty Saga and Pulse, Loki isn’t just setting up our ecosystem for the next decade of crypto — we’re doing what we can to help the planet by massively reducing the Loki blockchain’s carbon footprint. The post Pulse for the planet: How Salty Saga makes Loki greener than ever appeared first on Loki. View the full article
  20. Overview This is the v0.17.1.5 minor point release of the Monero GUI software. This release improves simple mode reliability. The latest CLI release notes can be found on the precedent blog post Some highlights of this minor release are: Simple mode: skip syncing nodes Write QML cache to portable folder Linux: enable high DPI support Minor bug fixes The complete list of changes is available on GitHub, along with the source code. Contributors for this Release This release was the direct result of 4 people who worked, largely unpaid and altruistically, to put out 22 commits containing 228 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are: luigi1111 xiphon Snipa selsta Download The new binaries can be downloaded from the Downloads page or from the direct links below. Windows, 64-bit Windows, 64-bit (Installer) macOS, 64-bit Linux, 64-bit A complete guide for the GUI wallet is included in the archives, but an online version is available. Download Hashes If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes: monero-gui-win-x64-v0.17.1.5.zip, a5ed83ffeec340b6695c4dcf0305decd5c419a97572e104c323b956deeac3c3d monero-gui-install-win-x64-v0.17.1.5.exe, 89e6bad3e8b5b1a57c647f7ddb30ebe4476c74db5730738c0cb7115fb8e44b65 monero-gui-mac-x64-v0.17.1.5.dmg, 7c7812263ab242f954534d062984e63cbe34211d8a6fd7f08e4bacfeb52ad1ec monero-gui-linux-x64-v0.17.1.5.tar.bz2, 577c5b2bcef436cffb57e4addf3ae9b669733f9aae83dc74f5025c76671667ed A GPG-signed list of the hashes is at https://getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys). To ensure that the files you download are those originally posted by the maintainers, you should both check that the hashes of your files match those on the signed list, and that the signature on the list is valid. Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced). View the full article
  21. Mumble is a fantastic open-source voice chat platform known for its reliability and ease of use. And Lokinet is a cutting-edge onion routing network that offers unparalleled security and anonymity potential. Well what if you could run a Mumble server over Lokinet, combining Mumble’s ease of use with Lokinet’s security and anonymity to create the ultimate secure voice chat service? In this article, we’re going to cover how to do exactly that — with just 15 minutes of your time and $3 a month, you and your organisation can create one of the most secure voice chat platforms possible. A Mumble server running over Lokinet on a server you control gives you absolute certainty that your voice conversations, associated metadata, and other Mumble activity cannot be stored or recorded, because no computer ever knows who is talking to whom — not even the Mumble server itself. So long as you trust the device that you run the Mumble server on (which you can, because it’s yours), you can be certain that no one else on earth can eavesdrop on your conversation — or even know that you’re connected to the server at all. If this is your first time using SSH and Linux stuff, don’t stress. We’ll walk you through every step! With that, let’s get to it. Step 1: Rent a VPS The first thing you’ll want to do is rent yourself a VPS (Virtual Private Server) to host your Mumble voice chat server. You could run the Mumble server from your own computer instead, but if you want the server to stay up 24/7, without having to leave your own PC on all the time, a VPS is the way to go. Mumble’s chat server has extremely low system requirements, so a VPS with any amount of storage and at least 512MB RAM will do the trick — you can find VPSs that meet these requirements for around US$3 a month. Try https://www.hetzner.com/cloud, or https://evolution-host.com/vps-hosting.php if you want to pay in Loki/Oxen! When ordering, select Ubuntu 20.04 or Debian 10. Step 2: Prepare your VPS Once you have access to your new VPS, you’re almost ready to install Lokinet, but there’s a little bit of preparatory work to do first. Start by opening a command prompt on your local machine (Terminal on macOS, any command prompt on Linux, or PowerShell on Windows 10). SSH into your VPS with this command: ssh root@[VPS IP address] Replacing [VPS IP address] with the IP of your VPS. It’ll prompt you for a password which will usually be provided to you by the VPS host. More advanced users can and should disable root password access and instead use SSH keys, but if that sounds hard, don’t worry about it for now. As you learn more about Linux, you’ll get more familiar with these best practices. Once you’ve logged in, we’re ready to roll. First, we’ll update our package lists to make sure our VPS sees the most recent versions of all available packages. Type: sudo apt update You’ll see a bunch of package lists being downloaded. Once this command completes, run the following command to upgrade any outdated packages currently installed on the VPS: sudo apt upgrade We’ll also need to make sure the curl command is installed before we proceed. Run this command: which curl It should output the location of your installed curl command. If you get an error, install curl: sudo apt install curl Then run which curl again to make sure curl is installed. Success? Congrats, you’re ready to move on to the next step: Step 3: Install Lokinet To install Lokinet, we need to add the Lokinet repository. Run the following command to install the public key used by the Lokinet dev team to sign Lokinet binaries: curl -s https://deb.imaginary.stream/public.gpg | sudo apt-key add - Then run the following command to tell apt where to find the Lokinet packages: echo "deb https://deb.imaginary.stream $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/imaginary.stream.list Next, update your repository package lists again with: sudo apt update And now, install Lokinet: sudo apt install lokinet Congrats, Lokinet is now installed and running in the background. We’re nearly there. Step 4: Installing the Mumble server Run this command: sudo apt install mumble-server That’s it. The Mumble server is now installed. On to Step 5: Step 5: Setting up a persistent keyfile This step is a bit more involved. We need to set up Lokinet to always generate a keyfile in the same directory, so it will work consistently. Linux servers don’t have a graphical interface, but they do ship with some in-terminal text editors. We need to edit a file now, so start by opening your lokinet.ini file with this command: sudo nano /etc/loki/lokinet.ini Using the arrow keys, move the cursor down to the [network] section of the file. Remove the # from before the “keyfile=” line, then add the following after the = symbol: /var/lib/lokinet/mumble.private Then hit Ctrl+X. Type “Y” (for yes) when asked if you want to save your changes, then press Enter to save and exit. Now that you’ve exited nano, you’re back in the terminal. Restart Lokinet to generate a keyfile for Mumble: sudo systemctl restart lokinet Step 6: Binding the Mumble server to Lokinet Now we need to make sure your Mumble server is using Lokinet for all traffic. Start with this command to grab the IP address we need to bind Mumble to: dig @127.3.2.1 +short localhost.loki This command will output 2 strings of text: a long string of random letters and numbers ending in .loki, and an IP address (a number in the format xxx.xx(x).x.x). Select and copy (Ctrl+C on Windows or Linux; Cmd+C on macOS) the IP address. Some SSH clients allow you to copy by highlighting the text and right-clicking on it as well. Now, we need to point the Mumble server to that IP address. Use this command to open the configuration file for the Mumble server: nano /etc/mumble-server.ini Using the arrow keys, navigate down to the line “;host=” under the section Specific IP or hostname to bind to. Delete the ; from the start of the line, then paste the IP address we copied earlier after the = symbol. Hit Ctrl+X to exit. Type “Y” when asked if you want to save your changes, then press Enter to save and exit. Back at the command line, restart the Mumble server to apply changes: systemctl restart mumble-server Step 7: Done! Congrats! A Mumble server is now up and running on your VPS, and all its traffic is being routed through Lokinet. All that’s left is to grab the Lokinet address of the Mumble server and give it to anyone you want to be able to connect. In case you missed it, run this command to find the Lokinet address of the Mumble server: dig @127.3.2.1 +short localhost.loki This is the same command we ran earlier, but this time, pay attention to the long string of characters ending in .loki (be sure to include the .loki part). This is the Lokinet address of your secure, onion-routed Mumble server. Copy this address and provide it to anyone you want to be able to connect to the server — all they have to do is paste the address into the Address field of the Add Server dialog in the Mumble client, add a username and label to identify the server, hit OK, and connect! Mumble can be downloaded for free on all major platforms. Anyone that wants to access your secret Mumble server will also need to have Lokinet installed and running. To download and install Lokinet, just head to https://lokinet.org/. Further Lokinet guides can be found at https://docs.loki.network/Lokinet/LokinetOverview/. And that’s it! Only 15 minutes and $3 later, you can now have completely surveillance-free conversations over the internet. We hope to integrate voice features into Session to make it even easier to access secure voice channels with this level of privacy and security. In the meantime, though, this Mumble/Lokinet setup is perhaps the most secure voice channel option available. This unique combination of services is just one example of the power of the Oxen tech stack — stay tuned for more guides and articles about what Oxen’s tech can do. Have fun! The post 15 minutes and just $3 a month: Putting the most secure voice service at your fingertips appeared first on Loki. View the full article
  22. Overview This is the v0.17.1.5 minor point release of the Monero software. This is a recommended release that improves Dandelion++ perfomance. Some highlights of this minor release are: Change Dandelion++ fluff probability to 20%, and embargo timeout to 39s Fix timeout checks for forwarded and Dandelion++ stem txes Improve peer selection in Dandelion++ stem phase Skip non-synced bootstrap daemons in –no-sync mode Check imported multisig curve points are in main subgroup Better log message for unusable anonymity networks Minor bug fixes The complete list of changes is available on GitHub, along with the source code. Contributors for this Release This release was the direct result of 7 people who worked, largely unpaid and altruistically, to put out 25 commits containing 203 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are: luigi1111 Snipa moneromooo xiphon hyc vtnerd selsta Download The new binaries can be downloaded from the Downloads page or from the direct links below. Windows, 64-bit Windows, 32-bit macOS, 64-bit Linux, 64-bit Linux, 32-bit Linux, armv7 Linux, armv8 Android, armv7 Android, armv8 FreeBSD, 64-bit Hashes If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes: monero-win-x64-v0.17.1.5.zip, 4bb0fca53bc58c1167bc0a258f61dd69a54507fd83ad37edf4213b4f30df8c94 monero-win-x86-v0.17.1.5.zip, 7dc0565a2880b38e73d85599153a31bbed85965963c6f74e1a5cf6dbd06f619e monero-mac-x64-v0.17.1.5.tar.bz2, adfc663b2b36b0cb2fdfcc35185b3d93c8c2256de06da01521e555b7b20ee292 monero-linux-x64-v0.17.1.5.tar.bz2, 95666508e695637830b4c1700538c717ff97f02f181fbb337a109763372c8d34 monero-linux-x86-v0.17.1.5.tar.bz2, c5b19fa1db2de6a66e475e634b07f2b5f74d5cd41e968aa0ed34ffd8f91f527f monero-linux-armv8-v0.17.1.5.tar.bz2, 50f113959bcc230860ff77cbac03a2713db772a72e80afe50f511418f9e9d97f monero-linux-armv7-v0.17.1.5.tar.bz2, 99fa5eb56616c1b7b6aef69572b8c51efa813bfaff2f2336ac982b449e8ee2a1 monero-android-armv8-v0.17.1.5.tar.bz2, 01998179f2c39d97f4e204b1323c17ca35c5797c558a9c51ad3f8a21c23620fe monero-android-armv7-v0.17.1.5.tar.bz2, 972f4ed467e34ea783fb66ad6f50749c2b7b3d9f77bb2825e70a8763d84b00f2 monero-freebsd-x64-v0.17.1.5.tar.bz2, 8fead098417cd4d3896012e485494efec8851c28abcb1883c3a1716652390321 A GPG-signed list of the hashes is at https://getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys). To ensure that the files you download are those originally posted by the maintainers, you should both check that the hashes of your files match those on the signed list, and that the signature on the list is valid. Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced). View the full article
  23. Snider

    Weekly Dev Update #128

    Hey Y’all, This week the Lokinet team continued working on fixes for the Mac release, which had some unresolved issues in the installer/uninstaller. The Loki Core team worked on the 8.1.4 release, which fixes a few issues exchanges were encountering and adds some new features to the wallet which are likely to be used in the Chainflip Service Node airdrop. Capping things off, the Session team began a large refactorisation effort which we will be talking about publicly in the coming weeks. Loki Core Remove unused wallet address parameter https://github.com/loki-project/loki-core/pull/1357 List current stakes https://github.com/loki-project/loki-core/pull/1356 Add GUI wallet snapshot builds https://github.com/loki-project/loki-core/pull/1354 Only compile CN_Monero_hash on Android https://github.com/loki-project/loki-core/pull/1353 Add new staking methods to wallet API: requestStakeUnlock, canRequestStakeUnlock https://github.com/loki-project/loki-core/pull/1352 8.1.4 release https://github.com/loki-project/loki-core/releases/tag/v8.1.4 [LokiMQ] Fix compatibility with newer cppzmq https://github.com/loki-project/loki-mq/pull/23 [LokiMQ] Issue new 1.2.2 release https://github.com/loki-project/loki-mq/pull/26 Lokinet You can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time. What went on last week with Lokinet: Various PRs to fix various minor Linux, Windows, and macOS bugs found since last week’s 0.8.1 release. We’re nearly ready for an updated release for Linux/Windows (and initial 0.8 series release for Mac) with just a couple small issues left before the release. Lokinet PR Activity: Fix Windows exit enabling causing lokinet GUI updates to timeout https://github.com/loki-project/loki-network/pull/1473 Fix exit routing configuration on some Linux systems https://github.com/loki-project/loki-network/pull/1480 Fix liblokinet-cryptography installation location on Linux https://github.com/loki-project/loki-network/pull/1482 Make key loading failures more serious errors https://github.com/loki-project/loki-network/pull/1437 Properly restore DNS settings on uninstall (macOS) https://github.com/loki-project/loki-network/pull/1478 Fix macos uninstaller not properly shutting down Lokinet https://github.com/loki-project/loki-network/pull/1484 https://github.com/loki-project/loki-network/pull/1488 [LokiMQ] Fix potential segfault on destruction (triggered on macOS Lokinet GUI shutdown) https://github.com/loki-project/loki-mq/pull/25 Clean up DNS handling code https://github.com/loki-project/loki-network/pull/1490 Improve path handover reliability https://github.com/loki-project/loki-network/pull/1491 Fix errors at launch on older versions of Qt https://github.com/loki-project/loki-network-control-panel/pull/77 Make “notray” mode the default so that the lokinet GUI behaves more like a regular desktop application https://github.com/loki-project/loki-network-control-panel/pull/80 Use a single LokiMQ connection between GUI and backend instead of 4 separate ones https://github.com/loki-project/loki-network-control-panel/pull/79 Remove no-longer-required macOS entitlements https://github.com/loki-project/loki-network-control-panel/pull/86 Session Session iOS Session iOS sending and receiving pipeline refactorisation continues https://github.com/loki-project/session-ios/commits/refactor-4 Fix open group avatar issues https://github.com/loki-project/session-ios/pull/314 Session Android Link preview improvements https://github.com/loki-project/session-android/pull/382 Polish translation fixes (Thanks to community contributor Kacper1263 for this) https://github.com/loki-project/session-android/pull/383 Session Desktop Continue the React refactorisation https://github.com/Bilb/loki-messenger/commits/react-refactor Thanks, Kee The post Weekly Dev Update #128 appeared first on Loki. View the full article
  24. Lokinet exit nodes have been on the bucket list for Lokinet since launch — and this week, exits have entered the building. That’s right, this is not a drill, Lokinet exit node functionality is making its way to a Lokinet client near you. If you’ve been following Lokinet for a while, you’ll know just how big of a deal this is. But if you’re new to the Lokinet landscape, or just want to brush up on the basics of onion routing, you’ve come to the right place. Lokinet exit nodes: How they work, what they do, and what they mean for you In a nutshell, Lokinet exit nodes allow you to onion-route all your internet traffic over Lokinet. Every site you browse, every meme you share, every video you stream — all that traffic is completely anonymised by Lokinet’s onion routing. With exit nodes, Lokinet functions similarly to a VPN — but better. Let’s break down how all that works. When you enable exit node browsing and connect to an exit node through the Lokinet client, your traffic is encrypted multiple times, once for every node it will travel through, then sent to a Lokinet “edge node” — your entry point to the Lokinet network. That node forwards your traffic through the network until it reaches a “pivot node”, which knows the location of the exit node you’re connecting to. That pivot node then relays your traffic — still fully encrypted — to the exit node. The exit node then decrypts your traffic and forwards it to its destination. The process for incoming traffic is the same in reverse. A typical Lokinet exit node path But hold on a minute. The exit node decrypts your traffic? How anonymous can this be if the exit node knows what you’re sending and receiving? The answer is simple: the exit node may know what traffic is passing through it, but it never knows who is sending or receiving that traffic. If you connect to a Lokinet exit node to send dankmeme.gif to someone on Facebook, the exit node may know that you’re sending something to someone on Facebook — but it won’t know who is sending it. And if the traffic is secured using HTTPS, the node won’t know exactly what you’re sending, either. Your ISP will know that you’re connected to Lokinet, but they won’t know whether you’re even connected to an exit node. And because Lokinet is fully decentralised, unlike VPN providers, there’s no central authority that can log your IP address, even if they wanted to. When you’re browsing through a Lokinet exit node, no other server, anywhere on the internet, ever gets the complete picture about what you’re accessing. The first Lokinet node you connect to will know your IP address, but because your traffic is already fully encrypted, that node won’t know what you’re sending or receiving — all they know is that you’re using Lokinet in some way. The nodes in between that node and the exit node know absolutely nothing — they can’t see your IP or the contents or destination of the traffic they’re relaying; all they see are unreadable packets of data that they need to pass along the chain. And the exit node decrypts your traffic, but that node has no clue who sent it. Full anonymity, powered by Lokinet. Lokinet exit node release: What works, what doesn’t, and what we want to know In a nutshell, everything should “just work”. You should be able to enter an exit node’s details in the Lokinet client, enable it, and voila — you should be browsing the clearnet through Lokinet. You can check whether it’s working by using a site like WhatsMyIP: load it up before connecting to an exit node, check your IP, connect to an exit node and check your IP again. You should see your IP change once you’re browsing via Lokinet. Wondering where to find those exit node details? There’s currently one exit node available, accessed via this address: exit.loki However, there are a few provisos. There may be some service disruptions during this initial period, as until more nodes become available, everyone will be using the same exit node — the node may experience performance bottlenecks with all that traffic running through it. And if you’re hoping to use Lokinet exits to stream Netflix, you may run into issues. Netflix blocks most known VPS providers, so depending on where the exit node you’re using is hosted, you might not be able to anonymously catch up on Stranger Things. We’ll be keeping our ears to the ground for any and all bug reports and other issues you might encounter. If you run into any issues with the GUI, problems connecting to or using exit nodes, or anomalous CPU or memory usage, let us know and we’ll look into it. We’d also love to see some SpeedTest results with exit nodes enabled — it should be pretty smooth, but the proof is in the pudding. And if you have any other feedback, questions, or suggestions, don’t hesitate to reach out. Happy anonymous browsing! The post Lokinet exit nodes: Onions gone wild appeared first on Loki. View the full article
  25. When the Salty Saga hardfork landed, we made the decision to set aside 6 LOKI per block for the first six months following the hardfork as a fund to incentivise liquidity for Chainflip and wLOKI. With the recent announcement that Chainflip will be forming its own blockchain, this is no longer necessary, because Chainflip can provide its own incentives. With that in mind, the Loki Foundation has resolved to burn this liquidity provision. This will be the largest public burn in Loki’s history. While that is the most important part of this announcement, in the interests of transparency, we will outline more information about the burn in this article. How the liquidity provision worked The liquidity provision was to be paid out at 6 LOKI per block, starting at height 641,111. However, this is actually only paid once a week, at heights divisible by 5,040. This means that the first reward was actually received at block height 645,120, then 650,160, and so on, with the final reward scheduled to be received at block height 766,080. Each reward is 42,840 LOKI — with 30,240 of that being the provision, and 12,600 being the governance reward. Twenty-five rewards are set to be received over the 6-month-life of the provision, totalling 756,000 Loki. As things stand, the liquidity provision will automatically terminate at block height 770,711, and it would require a hardfork in order to remove the 6 LOKI per block reward any earlier. Although there may be a hardfork before this, we’re not planning to complete a mandatory upgrade solely to amend the block reward before block height 770,711. Mandatory upgrades require a lot of coordination and administration on the part of the Loki Foundation, the Loki team, and the Service Node operators who run the network. To keep things as simple and transparent as possible, all of the unused rewards received as a part of this provision will be publicly burnt. Burning is already enabled by the Loki blockchain, and is regularly used for Blink transaction fees as well as Loki Name Service Registrations. This means we can complete the burn using a modified wallet without making any changes to the blockchain itself. How much of the liquidity provision was used Because Chainflip has only been in internal testing thus far, the liquidity fund has only been used to incentivise wLOKI liquidity on Uniswap. The first two rewards (totalling 60,480 LOKI) were used as a part of the wLOKI incentive scheme, which successfully bootstrapped liquidity on Uniswap. This leaves 695,520 LOKI which will be burned. For now, there are no immediate plans to run future incentive schemes for wLOKI on Uniswap, but the experience garnered from creating wLOKI, forming the Uniswap pair, and building the wLOKI bridge has already been of immense value to the project. Come and talk to us The decision to burn the Loki which was set aside for Chainflip liquidity makes the most sense for the project — and is hugely positive news for the Loki community, given that a large amount of LOKI is now scheduled to be publicly burnt. While burning is the simplest solution for this specific provision, we’re still interested in setting aside parts of the reward in the future for either liquidity or other community projects. However, this reward was approved by the community and the Foundation specifically to provide liquidity incentives for Chainflip, and it wouldn’t be appropriate for us to redirect these funds for anything else. In the interest of including the community in all major decisions regarding the project, we will re-consult with you about any new rewards, liquidity provisions, or funding for other projects. There will also be an upcoming LRC to discuss the overall emission scheme of the project. Keep an eye out for an announcement about that — as per usual, we invite everyone in the community to come and offer their thoughts and opinions. With that in mind, if you do want to talk to us about the burn — don’t hesitate to reach out to us via our Telegram community, Twitter, emailing team@loki.network, or any of our other social channels. The post Let it burn: What we’re doing with the Loki Liquidity Provision appeared first on Loki. View the full article
×
×
  • Create New...