Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. Today
  3. Yesterday
  4. Last week
  5. Earlier
  6. Hey guys. Can somebody help me? I wanted to have some fun and start mining Monero. This is my config: { "autosave": true, "donate-level": 2, "cpu": true, "opencl": true, "cuda": true, "pools": [ { "url": "pool.hashvault.pro:3333" }, { "url": "pool.hashvault.pro:443", "user": "-------------", "keepalive": true, "tls": true } ] } I generated on website. Can you help me with user? What should I put there? A wallet address? (i have Coinomi wallet). Where to get it? Don't have any serious expectations about mining but i have a PC with two RTX 3060 so maybe i will dig something in free time just to be happy, even if it will be worth 1$ 🙂 Thank you in advance.
  7. Snider

    X-Network Buy Back

    Dear community, In accordance with our statement on September 13th, 2020, we are providing you with an update on the buyback of XCASH from X-Network. https://medium.com/x-cash/announcement-x-cash-buy-back-6083451f97f Between September 16th, 2020 and December 20th, 2020, we have acquired a total of 823,298,490 XCASH to our initial inventory of 10Billions XCASH. These funds have been added back to the company’s address (X-Network Inventory Fund) and can be verified with its reserve proof on the Segregated Funds page. With this buyback, our objective is to support the price and confirm our commitment, after 2 years and a half of hard work, to make X-Cash a successful project. The funds will remain locked and be used later on to support the growth of the project. These initiatives will include: - Liquidity program for market-makers - Grant to the foundation to support development - Exchange listing contributions - Support the X-Cash Foundation’s infrastructure & marketing costs On behalf of all the contributors, I would like to thank you for the support throughout the years. We will keep on working towards developing great technology and reinforcing our communities thanks to the various initiatives we have started in the past months. Guilhem X-Network Buy Back 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
  8. I recently came across a bounty in the TRTL Discord for an article about TurtleCoin. The requirements were loose, it was mainly just a length requirement, so I figured I’d brew up some coffee and give it a shot. Thanks to Keda666 for reminding me to post this. Starting a coin network is easy. Taking care of one, helping it grow, keeping it healthy, giving it good guidance — those are the hard parts. My name is RockSteady, and TurtleCoin is my problem child. With an introduction like that, you might be thinking that I regret creating TurtleCoin or that it is a mistake in the sense that it was a failure, but quite the opposite as Bob Ross might say. TurtleCoin was created at the height of the crypto-boom of December 2017. At the time you could create literally anything, put “crypto” in the name, and sell it for millions, even if it didn’t exist (RIP BitConnect, never forget). Out of the plethora of networks that were coming out, a little privacy category emerged. You had DASH and the masternode networks, you had Zcash with the optional privacy networks, then you had Bytecoin, Monero and the rest of the Cryptonote family with stealth addresses and fulltime privacy… and off standing in the corner, struggling for attention and trying to peer above the shoulders of the Cryptonote family is little TurtleCoin with a pizza stained shirt and light coating of Pabst Blue Ribbon. As you may or may not know, TurtleCoin was a fork of Bytecoin. Incidentally, TurtleCoin and Monero for the first 3 years shared the same codebase, which came from an old retired version of Bytecoin. The way the privacy works in TurtleCoin and Monero is that if you think of every transaction as a handful of coins and dollars, each coin or dollar is matched up with a handful of others on the network and spent in a way that an observer can’t tell whose coins participated in the transaction, and nobody can scope out your transaction history or balance without being given keys to see it. So, big deal, right? You fork some code, then change all the mentions to the old guys, throw in a little pizzaz, maybe some ninja turtle memes, and boom you’re off to the races, right? Shitcoin starter pack. Unfortunately that is mostly true for some networks, at least to get the coin off the runway and into the sky. It takes almost zero work to fork code, change some variables and launch a network, but if the hundreds of projects people created based on our code are any indicator, it takes much much more than that to keep a network functioning and thriving. Lets get to the problem child part. A big reason why none of these forked networks exist anymore is that your network is like a little pot of gold, always out of reach, but for those smart enough you can find ways to make things easier as miner, or when all else fails, make things harder for everyone. Over the years, through the system of mining coins alone, we have seen it all with regards to the measures people will take to overcome the rules of the network to drive up their profit just a few points while having disastrous effects for the rest of us. At times we have seen people forging timestamps for mined blocks, pulse mining the network to skew the difficulty enough so that many coins are produced in an hour, then when the difficulty climbs as a result, the miner leaves for another network with lower difficulty and leaves us to mine slow blocks for an hour before they return as the difficulty goes back to normal. Wash, rinse repeat. We even saw people so bold as to incorporate TurtleCoin as the payload of botnets, presumably to get more mining power. Miners and their grubby little hands were the least of our troubles, along the way we noticed bugs that either got exploited and created a fire that we had to put out (like the fusion spam), or bugs that hadnt yet been exploited luckily (like the remote RPC bug). Sometimes when you fork code from others, this is the risk you take. Maybe it is getting clearer why we don’t have as many TurtleCoin forks around anymore. If it isn’t so clear, here is an analogy — If you put a plane in the air, and stop refueling it, it will eventually touch the ground. With all of these problems, TurtleCoin still prevails, and has not to this day had a single attack on the protocol that caused a loss of funds from any user, and with a pot of gold at the end of the rainbow as big as the remaining emission, nobody has exploited that either. (at the time of this writing, TurtleCoin still has 91% of the supply left to be mined) Three years later, TurtleCoin still receives new code every day, new features, improvements, fixes — and still has users transacting despite the price being the lowest it has ever been in history. During these three years, as a team we have seen hundreds of networks spawn from the TurtleCoin code. These networks may have been other peoples hopes and dreams, Id imagine. “Finally this will be the one” some of the forkers might say, before they sell off their entire premine and start the next project. Today I can think of two networks that forked us that are still functioning, and of those two, when I think of how many receive software updates, Id have to say it is maybe one that is still actively developed. As we round our way into the second era of TurtleCoin, the one where we scrap all code and write something new from scratch, I hope some of this funny business in the markets changes, and I do hope that all the forkers out there get their act together, however irrational they may be. TurtleCoin is our hopes and dreams, our pot of gold, our problem child. TurtleCoin is actively developed and every bit as serious of a project as others, it just has a funny name. Accept no imitations, TurtleCoin is here to stay. When you think privacy, utility, and low cost transactions without showing the world your balance, think TurtleCoin. When you think about TurtleCoin, think about us, your captains, and a team that wont let you down no matter what the price. Thanks for listening, I hope you all stick with us for TRTL v2.. its a game changer in the works. No more mining, even better privacy, everything new. Get some while you can, don’t say we didn’t warn you. Originally published at TurtleCoin. View the full article
  9. А куда пул вообще пропал? Нужно было посмотреть txid своих старых выплат, а страница тупо пропала.
  10. Mr Bee

    Mining SOLO?

    Dear Community, Reading the "Getting Started" section in the Pool area and some threads on the Forum, I still have a little question. Whom do you recommend mining solo? The hash rate seems to be the same whether I do SOLO mining or not. Thanks! Bee *** My machine is a simple workstation with a slim linux running: * ABOUT XMRig/6.7.0 gcc/9.3.0 * LIBS libuv/1.38.1 OpenSSL/1.1.1i hwloc/2.2.0 * HUGE PAGES supported * 1GB PAGES unavailable * CPU Intel(R) Xeon(R) CPU E3-1280 V2 @ 3.60GHz (1) 64-bit AES L2:1.0 MB L3:8.0 MB 4C/8T NUMA:1 * MEMORY 1.1/15.6 GB (7%) * DONATE 1% * ASSEMBLY auto:intel * POOL #1 pool.hashvault.pro:3333 algo auto * COMMANDS hashrate, pause, resume, results, connection * OPENCL disabled * CUDA disabled
  11. Update: Having applied the Script from the thread linked to above, I get another outcome. Is that as it is supposed to be?? Thanks again Bee alpinehost:/home/alp# chown root /usr/share/hugepages.sh alpinehost:/home/alp# /usr/share/./hugepages.sh enable Huge pages enabled alpinehost:/home/alp# sysctl -a | grep hugep sysctl: error reading key 'net.ipv6.conf.all.stable_secret': I/O error sysctl: error reading key 'net.ipv6.conf.default.stable_secret': I/O error sysctl: error reading key 'net.ipv6.conf.eth0.stable_secret': I/O error sysctl: error reading key 'net.ipv6.conf.lo.stable_secret': I/O error vm.nr_hugepages = 9 vm.nr_hugepages_mempolicy = 9 vm.nr_overcommit_hugepages = 0 alpinehost:/home/alp# The vm.nr_hugepages changed dramatically. What does it mean anyways?
  12. Dear Community, I would like to have these Hugepages supported now :-) I am thus referring to this thread here, which seems to be closed. I have tried the following to enable hugepages AND get them working until 1 GB. See me output: Thanks so far! Bee *** Question: Why is HUGEpages 1 GIg not available? How do I set the value correct? My output: sysctl -a | grep hugep sysctl: error reading key 'net.ipv6.conf.all.stable_secret': I/O error sysctl: error reading key 'net.ipv6.conf.default.stable_secret': I/O error sysctl: error reading key 'net.ipv6.conf.eth0.stable_secret': I/O error sysctl: error reading key 'net.ipv6.conf.lo.stable_secret': I/O error vm.nr_hugepages = 2349 vm.nr_hugepages_mempolicy = 2349 vm.nr_overcommit_hugepages = 0 *** and in xmrig *** ABOUT XMRig/6.7.0 gcc/9.3.0 * LIBS libuv/1.38.1 OpenSSL/1.1.1i hwloc/2.2.0 * HUGE PAGES supported * 1GB PAGES unavailable * CPU Intel(R) Xeon(R) CPU E3-1280 V2 @ 3.60GHz (1) 64-bit AES L2:1.0 MB L3:8.0 MB 4C/8T NUMA:1 * MEMORY 3.2/15.6 GB (21%) * DONATE 1% * ASSEMBLY auto:intel * POOL #1 pool.hashvault.pro:3333 algo auto * COMMANDS hashrate, pause, resume, results, connection * OPENCL disabled * CUDA disabled
  13. 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
  14. 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
  15. 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
  16. Field Engineer is an online marketplace that connects businesses who have jobs with Telecom Engineers who have the skills and availability to complete them.

  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  1. Load more activity
×
×
  • Create New...