 Show Posts
|
|
Pages: [1] 2 3 »
|
|
A small complication with updating the OP, input requested.
The max length of the title is 80 chars. Currently we are at 60 chars with "[XMR] Monero - A secure, private, untraceable cryptocurrency". Adding " || Latest Version: " already adds 20 chars.
Suggestions?
updated by fluffypony
|
|
|
|
GINGEROPOLOUS's POOL SHAME LIST List updated on the OP. Sorted first by mixin, second by percentage of donation. updated by David Latapie |
|
|
|
Cross-posted from: https://xmrmonero.com/article/en/monero-torrentWe are proud to announce the release of a torrent of Monero 0.8.8.6 for Windows. This gives you a one-step download with everything you need to run a node and GUI wallet on Windows. This torrent includes the blockchain, lightwallet.exe and simplewallet.exe. The complete torrents weights 2.4 Gb. To download, open your favorite torrent application and enter the following magnet link (double click to select it all): magnet:?xt=urn:btih:2F68E7CC7FB7AC264758DE3BBA3108AA87F07C99&dn=bitmonerod.zip&tr=udp%3a%2f%2ftracker.openbittorrent.com%3a80%2fannounce&tr=udp%3a%2f%2ftracker.publicbt.com%3a80%2fannounce&tr=udp%3a%2f%2ftracker.ccc.de%3a80%2fannounce Remember to keep seeding after you downloaded, to make the download faster for the ones who come after you. Below are md5 and virus scans - md5sum bitmonerod.zip: a8f6baf1ae8ac9ad8970f79c0430165d
- md5sum bitmonerod.exe: a8f6baf1ae8ac9ad8970f79c0430165d
- md5sum lightWallet.exe: 6e9aa82cd7388aaf5e408d4a8adb883e
- md5sum simplewallet.exe: d65a3970a03eb2f6f8f2e3e480c42b8e
The executables have been scanned with virustotal. lighWallet.exe has three positives (probably false), the others have none. |
|
|
|
Monero Monday MissivesJanuary 5th, 2015Hello, and welcome to our twenty-second Monero Monday Missive! This is our first Missive for 2015, after a 2 week break over the end of December. We'd like to earnestly thank everyone for their support over the course of this year, and for joining us on the start of our Monero journey. We'd also like to take this opportunity to look back on the past 8 months, and see where we got to. State of Monero: 2014As an open-source project, Monero is built on the back of volunteers, contributors, and donations. So let's start with a financial report. For donations received over the year: we received 21 636.40655 XMR spread over 4343 transactions, and 8.04559 BTC spread over 25 transactions. Thus our average XMR donation is around 5 XMR, and our average BTC donation is around 0.32 BTC. As most of our costs are BTC based, XMR donations were traded into BTC where necessary (typically through OTC trades and not on-market), giving us a rough total of all receipts of 39.536205689 BTC (in XMR donations) + 8.04559 BTC (in BTC donations) = 47.581795689 BTC. Expenditure for the year comprised of 3 totals as some costs could not be settled in BTC or were preferably settled in XMR. Our expenditure was 190.513492 BTC + 1 891.31 XMR + US $5 732.80, which is around the 212 BTC mark. Thus the shortfall of 164.5 BTC was paid out of the Core Team's own pockets in the hopes of recovering the funds later on (ie. just in case anyone was wondering, not only do the core team not get paid at all, but we've put a significant amount of funds into Monero). So, what did our ~212 BTC get spent on over the year? Or, in other words, what did we accomplish? Here's a bit of a taste before we dig into the nitty-gritty: Core DevelopmentWell, let's start by excluding a lot of development done in branches on forks, and focusing on the master branch of the git repo. We inherited the Monero project pretty much from the end of April, with thankful_for_today's last commit on April 30th, 2014. In order to see what we did with some pragmatism we took two folders, on containing the Monero source on April 30th at that last commit, and one containing the Monero source on December 31st. We removed everything in the external/ folder, except the CMakeLists.txt, so that we weren't including external libraries in our count. We then used Araxis Merge to produce a diff report between the two folders (plus Github's compare tool to give us additional information). We then subtracted the license changes we made earlier this year (208 files were affected, which means that for each we have to remove 2 lines from the "removed" count, 1 line from the "changed" count, and 28 lines from the "inserted" count). The summary is below, and whilst it obviously precludes things like where we made several changes to the same line of code, or missteps we reverted, it gives a very general indication of the effort. - 35 weeks of development (245 days) since Monero was inherited by the Core Team - 594 separate commits - 11 contributors - 10 221 modified lines - 12 706 new lines - 32 lines removed Now may be thinking "wow, that's like 94 lines of code a day!", but it's important to remember that included in this are documentation and code comments, mnemonic word lists for several languages, as well as changes made to Bytecoin early on that we merged in. However, it doesn't diminish the gargantuan effort that went into the Monero core over the year, and we are truly grateful to all who have been involved. Some of the highlights of work that was committed to the Monero core master repo over the past 8 months, in chronological order, include - April: - got Monero building and running on OS X May: - removed purposely obfuscated hashing loop - added a 'diff' daemon command to show current estimated difficulty and hash rate - more hashing optimisations, including AES-NI support - new wallet RPC commands: save_bc, getaddress; new daemon RPC commands: mining_status - enabled checkpointing and checkpoint verification - fixed the block reward penalty mechanism and dynamic block sizing - new wallet RPC commands: incoming_transfers - fixed exit flags, added --exit-after-cmd simplewallet flag June: - added payment IDs to simplewallet's 'transfer' RPC command - added Doxyfile for code documentation - refactored parts of simplewallet - added Electrum-style mnemonics to simplewallet - got Monero building and running on Arch Linux - further improvements to hashing algorithm, including huge pages and AES-NI key expansion - added tx auto-splitting and changed transaction creation semantics internally July: - new wallet RPC command: get_bulk_payments; new daemon RPC command: get_connections - new README, license changes to BSD 3-clause August: - optional height parameter for simplewallet refresh - fixed wallet restore from seed - new wallet RPC command: query_key; new wallet commands: seed, viewkey - stopped a major spam attack dead in its tracks - highly sophisticated attack causes the network to fork for 30 minutes, urgently and immediately patched September: - blob checkpointing added (over and above normal block hash checkpointing) - got Monero building and running on FreeBSD - major documentation of several C classes - new versioning system to allow for rapid identification of build commit - started enforcing GPG signed commits and merges, initial GPG keys added - testnet launched - dropped support for Visual Studio, added support for mingw-w64 + msys2 - DNS resolver (libunbound) added, initial OpenAlias support - dynamic file-based checkpointing added - multi-language mnemonics introduced for wallets - new wordlists: Portuguese, and Spanish (first 4 letters unique) - DNS checkpointing added for rapid checkpoint alert / enforcement October: - reworked log level choices - new wordlists: English (first 3 letters unique), as well as Japanese (first 4 letters unique) - PoW algorithm fully documented - switched to RapidJSON for JSON parsing - changed wallet file format (encrypted JSON) - massive CMake overhaul begun by KitWare, the creators of CMake November: - per-kb transaction fees introduced - CMake overhaul completed, dynamic and static builds finally working again on all platforms December: - bug fixes, bug fixes, and more bug fixes The Monero Research LabAnother major effort has been the Monero Research Lab, the MRL. In addition to the members of the core team, the triplets (Surae / Sarang / Shen Noether, obviously pseudonyms) spent months reviewing the CryptoNote whitepaper, publishing a synopsis of their review, and then building on that by doing extensive Monero research and finally producing several important research bulletins. From the ground-breaking chain reaction attacks in MRL-0001 to the deep dive explanation of Monero Ring Signatures in MRL-0003 (and the accompanying Python implementation) it has been 8 months of remarkable output for a group of people that at best only knew of each other very peripherally. The Monero Research Lab members have also engaged regularly with Bitcoin researchers, including a mutually beneficial friendship with Andrew Poelstra who is included in the group of the "MRL Friends". Between the whitepaper annotations, the review, and the MRL research bulletins published in 2014, 655 lines of python were released and over 25 000 words were written, all of which was the culmination of over 197 000 words spent in intense academic discussion. The academics in the MRL also had an opportunity to meet up with Riccardo Spagni (fluffypony) and Tom Winget (tewinget) towards the end of the year, in a weekend of epic nerdiness that included a trip to a natural history museum and getting stuck on the side of the highway with no petrol due to a faulty gauge. Don't worry, the emergency petrol fill up wasn't paid for by donations;) InfrastructureThe Monero web infrastructure consists of 4 key components: web hosting, testing infrastructure, seeding, and download hosting. Our web hosting serves the Monero website, the Monero forum, the Monero Research Lab site, and so on. Testing infrastructure consists of a Mac Mini hosted at MacStadium, as well as a beefy testing box hosted at Hetzner in Germany, on which we have a number of VMs for the various operating systems and variants we target. Our QA lead contributor, Gazby, who has recently started will be bringing the testing infrastructure up to scratch, and adding things like Jenkins for nightly builds and Gitian for deterministic signed releases. Seeding infrastructure consists of several geographically separated boxes that keep the moneroseeds.se/ae.org/ch/li records updated with active seed nodes. Download hosting consists of several servers scattered across the globe (3x USA, 2x UK, 1x Germany), and it serves all static content including the blockchain downloads, Monero binaries, MRL publications, and so on. The Monero blockchain alone is downloaded hundreds of times in a month, with our bandwidth usage regularly exceeding 2tb a month across the download nodes. Obviously this provision is not cheap, which is why your continued assistance to this project is greatly appreciated. OpenAliasAn important project that the Monero Core Team created and developed is OpenAlias. Monero addresses are ugly, complex, and not really human readable. But then, too, so are Bitcoin addresses. Typically most cryptocurrencies attempt to solve this by having some sort of centralised register, say they've developed "aliasing", and call it a day. For Monero, this approach simply wasn't good enough. To understand why it is important to first understand " Zooko's Triangle". Zooko Wilcox-O'Hearn, the incredible brain that has contributed so much to the Tahoe-LAFS distributed file system (and which was first released May 2nd, 2007), posited that any naming or aliasing system has three goals or desirable traits (and we're just going to quote Wikipedia here) - - Human-meaningful: The quality of meaningfulness and memorability to the users of the naming system. Domain names and nicknaming are naming systems that are highly memorable. - Decentralized: The lack of a centralized authority for determining the meaning of a name. Instead, measures such as a Web of trust are used. - Secure: The quality that there is one, unique and specific entity to which the name maps. For instance, domain names are unique because there is just one party able to prove that they are the owner of each domain name. Zooko initially concluded that it was impossible for a naming system to have all 3, and at best it could hope to have 2 of the 3. Subsequently, systems such as Namecoin and Twister proved that it was, in fact, possible to have all 3. Despite that, most of the aliasing / naming implementations that exist today seem to fail on the decentralised aspect (eg. requiring that a block is solved to register an alias centralises it in the hands of the large mining pools, and also limits the number of aliases that can be created a day), and almost always fail on the long-term goal of "human-meaningful". We say the latter because a limited aliasing system where globally unique nicknames are chosen invariably devolves to a post-land-grab scenario where so many variants of "bob" have been acquired that a user is forced to chose bob0923840129832 as his alias, which really doesn't solve the naming issue at all. In addition, it forces the cryptocurrency creator to be the one responsible for solving alias disputes, and in many cases aliases are permanent and cannot be changed if you lose your private key. OpenAlias is different. Not only does it "square Zooko's triangle" (still a unique and difficult to accomplish task), but it allows for the offloading of decentralisation to Namecoin or GNUnet or similar, whilst still allowing for the offloading of conflict resolution to existing systems such as ICANN's ADR (Alternative Dispute Resolution). Best of all, it leverages the fact that so many people and companies *already own their own domain names*, so there is no need for additional complexity. Monero has implemented OpenAlias on quite a basic level, and will be improving its support as time goes on. The OpenAlias project has also not been standing still, and has been working on several sub-projects. GUI and DatabaseWith the two attacks we thwarted in 2014, the GUI development had to take a bit of a backseat. On the other hand, the blockchain database implementation has progressed nicely, and is currently being rebased to the latest master and tests are being updated and created for it. The GUI code alone already consists of 5 213 lines of QML and over 100 lines of C++, and that is well before anything is wired up. The blockchainDB code consists of over 60 commits on the implementation alone (over and above the tons of commits to create the generic classes and implement all the functionality prior to that), with over 5 500 lines of code already part of it. It truly has been a monumental engineering task. Monero ForumA project guided and directed by the Core Team, although primarily written by a contributor (Eddieh), the forum grew out of an interesting need. On the one hand, Monero is still in its infancy, and the Monero sub-Reddit would likely have sufficed for quite some time. On the other hand, there was a general pressure for us to have our own forum, our own home. So why didn't we just use something off-the-shelf? There were several reasons. The primary reason is that most forum software (SimpleMachines, phpBB, Vanilla, etc.) is either too clunky or too old to really be workable in a modern context. And, too, it would be something we would have to live with for a long time (see: Bitcointalk, for instance). Customising existing forum software to suit our needs would not have been cheap (see: Bitcointalk again). Thus a decision was made to see if we could find someone to pursue creating something fresh for us as a peripheral exercise. After 6311 lines of PHP, 1226 lines of CSS, and 135 lines of JavaScript, we're proud of what we've produced. Instead of using antiquated content systems like BBCode, we have MarkDown. Instead of pages and pages of threads, we have infinite scrolling and threaded views. Instead of fundamentally flawed trust systems like "default trust" we have a synchronised copy of the Bitcoin-OTC Web of Trust, allowing users with existing WoT accounts to immediately have their trust groups accessible on the Monero Forum for trading. Instead of only meaningless sorting by date (which we have!) we have posts sorted by weight. Since weight is a product both of post age, insightful/irrelevant votes, and your trust relationship to the poster, you are already able to visit a thread and only see comments that are relevant to you, with all other comments collapsed. We are actively massaging more usefulness out of the weighting, but it is core and fundamental to the forum. Obviously this is a project that still has a LONG way to go to reach maturity. With that in mind, don't forget that you are key to this: if there's something about the forum you don't like, or a feature you want, or a bug you've found, put it in the Meta section of the forum (until we have a github repo that you can post issues to). The Monero MissivesOur first Missive was put out on Monday, June 2nd, 2014, and has been instrumental in collating and bringing together various little snippets and pieces of work and threads every week. In the 30 weeks from that first one till the end of the year we put them on pause for 4 weeks during the attacks in August, and took a 2 week break at the end of the year. The remaining 24 weeks had 21 Missives in them, giving quite a bit of coverage and keeping our userbase as informed as possible. Some Missives are easy and only take us two or three hours to put together. Some Missives are substantially harder due to time constraints, dependencies, research (see: this Missive you're reading, for instance;) or just the sheer amount of stuff that is going on. In total, the 21 Missives we put out over the past 8 months contained nearly 16 000 words over 689 sentences! And just for fun, this Missive took several days to put together (not all day, every day, mind you) and unsurprisingly ends up being our largest Missive by far, at 3 450 words and 111 sentences! Other Core Team ProjectsThe two other projects the Core Team released in the year are the Monero DNS seeder (xmr-seeder), and URS, a Unique Ring Signature signing tool written in Go. Both of them are active contributions to the Monero infrastructure, and continue to be useful and fundamental on a daily basis. External Projects: 2014The Monero Core team and core contributors obviously aren't the only ones working on Monero-related projects. Some highlights from the year include: Node CryptoNote PoolWhen Monero first started there was no open-source pool software for it. Through the collective efforts of zone117x and lucasjones, an open-source pool was developed and released. It was an incredible undertaking, given the monstrous lack of documentation and code comments in the CryptoNote source, and we owe them a debt of thanks. i2pd Development PartnershipInitially this started as a partnership with the i2p team, with a view to getting i2pcpp to a workable stage. When i2pcpp stalled, and on advice from the i2p team, we form the Privacy Solutions working group between Monero, AnonCoin, members of the i2p team, and the i2pd developers. The focus for the past few months has been on i2pd, which has made amazing progress. Since the launch of the PrivacySolutions partnership at the end of July, a series of 692 commits has brought i2pd up to a stage where it can maintain relatively stable connections to the i2p network. ForkGuard and MoneroClubBoth services launched and operated by Atrides, ForkGuard provides realtime information on the current block height for pools and services that run full Monero nodes, and MoneroClub is a listing of localised Monero and fiat OTC trade offers. Atrides isn't stopping there, and for his next project he's looking to produce a Monero fork of OpenBazaar! MyMoneroOwned by Riccardo Spagni (fluffypony) and Risto Pietilä (rpietila), and operated by fluffypony, MyMonero is the first web-based client for Monero. In doing so it closes a major end-user usability gap, and goes a long way towards making Monero useful and usable. Crypto KingdomCreated and started by his lordship, King Risto, Crypto Kingdom is a retro-style virtual world game where players can interact, build, create, and so on. An online playable version is in the works, and as Monero is driving the in-game resources and currency it is well on its way to becoming a fully-fledged microeconomy! Looking Forward: 2015We have a lot in the pipeline for 2015. A few things that we'd like to highlight that you can look forward to: - more MRL academic goodness, including some of the work started at our MRL mini-meetup from 2014 - a finalised, working, tested blockchain DB implementation using LMDB - i2p integration - some additional blockchain DB implementations - finalisation and release of the Monero core GUI - the release of smart mining functionality - the finalisation of a complete overhaul of the RPC functionality - HTTPS and simple auth support for RPC servers - a new, unified, well-documented RPC interface - blocknotify and walletnotify equivalents in the daemon and wallet client - a complete replacement of the wallet/server IPC with 0MQ - multi-signature transactions - open-sourcing the Monero Forum software - the release of some OpenAlias sub-projects And, undoubtedly, much more both for Monero core and related external projects. Of course, none of this would be possible without donations from our users, and we are most appreciative and grateful to those that have donated thus far. We hope that over the next year you will continue to help and assist us - and don't forget our donation addresses are powered by OpenAlias, both XMR and BTC donation addresses are on donate.monero.cc Thank you for a great 2014, and here's to a great 2015! Your Core Team - Riccardo "fluffypony" Spagni, smooth, othe, David Latapie, tacotime, NoodleDoodle, eizh |
|
|
|
Official Monero Forum LinkMonero Monday MissivesDecember 15th, 2014Hello, and welcome to our twenty-first Monero Monday Missive! Major Updates1. We're aware of the 0.8.8.6 slow startup issues on some Windows environments (over an hour for the daemon to startup for some people). We believe we've identified the problem, and will be rolling out a test fix in the next couple of days, for inclusion in 0.8.8.7 2. There have been a number of patches merged over the past week to fix issues with simplewallet's new multi-language mnemonics External ProjectsMyMonero: due to a very broad DDoS attack at the data center in which MyMonero is hosted (not targeted at MyMonero) the service was offline on Sunday for a 12 hour stretch. We are putting some effort in place to ensure this does not happen again in future. New features added this past week: a "copy to clipboard" helper is now available on the right of your Monero address on your dashboard, as well as on the login key review screen and account details screen. In addition, clicking on a transaction in the dashboard or your transaction history screens will show additional details, such as the payment ID used. ForkGuard: added MyMonero.com and MoneroClub.com I2PD: massive progress was made this week adding support for the su3 router update format (the previous .sud / .su2 format being deprecated), which is used to deliver updates to all routers on the i2p network, including: router update alerts, plugin update alerts, reseed data, and news feed items. Details on the su3 format can be found here: https://geti2p.net/en/docs/spec/updatesDev DiaryAccount: still more fixes to the restore paths and multi-lang mnemonics, known issues with UTF-8 on Windows remain Core: libunbound lookups moved to a thread in order to trap for failing / slow DNS lookups Until next week! updated by fluffypony
|
|
|
|
Smart mining reminds me of what smooth wrote months ago (but even better, since no asking, although there should be an option for explicitely deactivate it, for fragile hardware or competing background programs like BOINC): The vision here is a wallet that asks you when you want to install: "Do you want to devote some of you CPU power to help secure the network. You will be eligible to receive free coins as a reward (recommended) [check box]." Get millions of users doing that and it will drive down the value of mining to where neither botnets nor professional/industrial miners will bother, and Satoshi's original vision of a true p2p currency will be realized. |
|
|
|
Official Monero Forum LinkMonero Monday MissivesDecember 8th, 2014 Hello, and welcome to our twentieth Monero Monday Missive! We're combining last week's one with this week's, as last week's Missive was pulled down shortly after being put up due to breaking issues in the Windows build of Monero 0.8.8.5 (since resolved). Thank you for your patience! Major UpdatesMonero 0.8.8.6, recommended update, please take note of new download links: Windows, 64-bit (monero.cc/downloads/win64) - SHA: facbeb2e408cf8b9a46534363eba161dbb047654 OS X, 64-bit (monero.cc/downloads/mac) - SHA: 7069de92083fb7831b063cc152e8f35508ff61bf Linux, 64-bit (monero.cc/downloads/linux) - SHA: 16f3f55bcfbfae6135cbeda6574f651890a8be64 FreeBSD, 64-bit (monero.cc/downloads/freebsd) - SHA: 9fd0005b697e146a26a0bf9e3cd0c89b978f7fbd NOTE: When opening your wallet with simplewallet for the first time with this update you will be prompted to choose a language for your mnemonic seed words, and you will be given a new 25 word mnemonic. You will always be able to restore from the old 24 word mnemonic seed, but it is of course recommended that you move to the newer, more robust mnemonic. 1. We are (finally) happy to release Monero 0.8.8.6. We released 0.8.8.5 last week, but due to a breaking Windows bug we pulled the announcement down until we solved the bug on the weekend. The major changes for 0.8.8.5 include: OpenAlias support, per-kb fees, multi-language mnemonics, file-based checkpointing, MoneroPulse DNS checkpointing, a move from MSVC to an msys2 / mingw-w64 build environment for Windows, and brand new build CMake. 0.8.8.6 adds some important fixes to the multi-language mnemonic system. 2. Due to the launch of MyMonero we feel it prudent to add a new section to the Missives, called "External Projects". This is a section to provide updates on other projects that are not an official part of the Monero Project or collectively created by the Monero Core Team, but is related to Monero in some way - thus OpenAlias would not be part of this section, but MyMonero would. If you have an update you would like included in this section, please email dev@monero.cc for inclusion the following Monday, or send any member of the Monero Core Team a message. If this section becomes overly full we may choose to shutter the section, so please keep updates brief and only those that are important. It is not a marketing area, and so every new mining pool launched or minor feature added to a pool will not be eligible for inclusion (although if you've done something cool, let us know;) 3. We're also quite happy to announce the addition of a new feature to Monero: Smart Mining. This is a feature that will evolve over time, but at its most basic it is something that will allow everyone running the client software to support the network in an unobtrusive manner. Smart Mining detects your CPU usage, and if your CPU is idle and you aren't on battery power (for laptops and/or connected UPS devices) it will begin mining. As soon you switch to battery power or your CPU activity picks up it will pause mining until it sees it is safe to start again. You still set your Monero address for Smart Mining, as always, and whilst your chances of solving a block may be relatively small (for now;) it is still an easy way to support the network without needing to purchase expensive equipment. This work is complete (for Linux) and is currently being tweaked to work on our other supported operating systems. Ongoing process can be followed here: https://github.com/oranjuice/bitmonero/tree/smart-miningExternal ProjectsMyMonero: the various modal windows, such as the login screen, should be displaying correctly across devices now. We are fixing the scroll issues which still plagues these on some devices. Just to make sure everyone is aware after the recent blockchain.info issues: the MyMonero code has unit tests using the Jasmine testing framework for JavaScript, as well as tests for other parts of the backend application. These tests are executed and checked for every commit. We also have had HTTP Strict Transport Security (HSTS) enabled from the beginning, and have various other things enabled for client-side security such as X-Frame-Options set to deny, X-XSS-Protection on, and X-Content-Type-Options set to nosniff. I2PD: for those not aware, the i2pd project is a new implementation of the i2p protocol in C++, and is the software that Monero will use for its connection to the i2p network. The source code of the project can be found here: https://github.com/PrivacySolutions/i2pd - the regular stream of commits is testament to the ongoing progress being made. The i2pd team will provide regular updates on i2p-specific functionality as it is added and the project grows to a point of maturity. Dev DiaryBuild: tests are now disabled when building the build-release, build-debug, or release-static targets. The default make target (all-release) will include tests, as will all test- targets, obviously. Account: lots of fixes to multi-lang mnemonics, although UTF-8 on Windows still seems to be a bit shaky. Core: all 0.8.8.5 and 0.8.8.6 changes have been covered over the past few Missives. Until next week! updated by David Latapie
|
|
|
|
Cross-posted from the official forum. November 24th, 2014 Hello, and welcome to our nineteenth Monero Monday Missive! Major Updates1. It is with great pride that we announce the very first Monero hosted account service (a web wallet for Monero, if you will), which we are certain will provide a level of accessibility that was previously unknown with Monero. My Monero is managed by Riccardo "fluffypony" Spagni, although it was created through the efforts and hard work of many people including members of the Monero Core Team, Lucas Jones, Matthew Little, and seed funding provided by Risto Pietila. All of the heavy lifting is done client-side, which means that My Monero can never spend your funds on your behalf or without your authorisation. However, there is a small compromise in that the server knows your view key, which is necessary in order for it to identify transactions belonging to you. Thus there is some reduction in transactional privacy when using My Monero, as if the service is compromised your view key would be revealed. That having been said, stealth addresses would still be in effect even if the server was compromised, and thus transactions can still be said to be unlinkable. If you are truly concerned about absolute transactional privacy, then running your own Monero node will always be the preferred route.  2. Significant progress has been made to fixing the last few Windows build issues. KitWare have worked with us ensuring that our CMake is 100% up to their best practices, and the resulting 2 905 lines of new CMake (!!!) is evidence thereof: https://github.com/monero-project/bitmonero/pull/180/files. Now that we are seeing light at the end of the proverbial tunnel, we expect to tidy this up by the end of the week and can finally tag-and-release Monero 0.8.8.5. 3. We are working hard on solving the blockchain DB bugs as and where they are found. If all goes well we should have enough of the nuances worked out to have it merged into master within the next 4 weeks. 4. We have seen our QA (automated testing) / CI (Continuous Integration) / Gitian build efforts drag their heels extremely slowly over the past few months, mostly due to specialists in those fields originally interested in helping us finally not being able to commit to any significant period of assistance. We are stepping this up a notch with the assistance of a new contributor, Gazby in #monero-dev, who will focus on the devops work. Dev DiaryCore: msys2 now successfully compiles static releases in PR 180, final testing of new builds will happen this week Core: expect a mass merge of PRs previously waiting this week. If you have a PR with CMake changes in it expect it to be merged and fixed manually, but moving forward CMake changes will have to comply with the new, cleaner CMake. Until next week! |
|
|
|
Cross-posted from https://forum.monero.cc/1/news-and-announcements/98/monday-monero-missives-18-november-17th-2014Monero Monday Missives
November 17th, 2014
Hello, and welcome to our eighteenth Monero Monday Missive!
Major Updates
1. We still have ongoing Windows static build issues, which is preventing us from tagging and releasing Monero 0.8.8.5. It is our highest item of priority at the moment, although the nature of the problem and the geographic / timezone spread of the various people working on it means that testing and reproducing the problems is a painstakingly slow process.
2. On the topic of binaries, we'd like to just remind everyone that the only trustworthy, official binaries are those release by the core team. Any others on any other website may or may not be safe, but it is always recommended that the appropriate level of caution is exercised and that unofficial builds are avoided if possible.
3. Over the weekend of the 8th and 9th of November the Monero Research Lab had a closed mini-meetup in Salt Lake City, Utah, USA. In attendance were surae, sarang, and shen, as well as tewinget and fluffypony. A great time was had by all attendees meeting for the first time, and long academic discussions were the order of the day. Three primary focus areas that the MRL researchers will be looking at going forward are: Difficulty - an initial foray into creating a more robust, well-understood, and documented difficulty retargeting algorithm; Payment IDs - simplifying payment ID use, including stealth payment IDs or encouraging cross-blockchain payment ID collision; Offloading Processing - ways and means to offload viewkey scanning to a hosted daemon in a way that does not reveal the viewkey to the hosted instance
4. Excellent feedback has been received from all those that have been testing the initial blockchain DB implementation. Please keep those coming - of particular use would be to test rollbacks by creating a fake checkpoints.json file. We need to ascertain how performant and reliable rollbacks are on various environments.
Dev Diary
Core: more CMake changes, although lingering issues exist with static mingw-w64 builds (both native and cross-compiling on Arch)
Core: several bug fixes to the multi-language mnemonic system, a more unified JSON library, and others, are in the wings and nearly ready to deploy, pending the CMake issues being resolved
Until next week!
- updated by fluffypony |
|
|
|
crossposted from https://forum.monero.cc/1/news-and-announcements/91/monday-monero-missives-17-november-2nd-2014Monday-ish Monero MissivesNovember 2nd, 2014Hello, and welcome to our seventeeth Monero Monday Missive! This Missive has been horrendously delayed due to travelling, jetlag, and timezones. Nonetheless, we're keeping it short and sweet, as it is a prelude to next week's Missive, in which we hope to have some binaries so you don't have to compile source code to test these new features;) Major Updates1. For those following the database development, we are at a point where it is actually syncing! Our initial observations are that as the blockchain grows LMDB's virtual memory requirements will increase, but since it will rarely touch any of the virtually mapped data the real memory requirements are incredibly tiny. We are currently testing rollbacks and edge-cases, but if you would like to give it a spin (or just check out the nearly 6 000 lines of code that comprise of the blockchain DB clase and the initial lmdb implementation) then you need to clone tewinget's repo and checkout the blockchain branch - https://github.com/tewinget/bitmonero/tree/blockchain (note that this is pretty much Linux only at this stage, Windows and OS X support will come soon) 2. Per-kb fees are ready to go, and has been merged into the master repository! The per-kb fee has initially been set at 0.01 XMR per kb, and we are confident that this will be a suitable fee for the moment. We are not going to enforce a block-point hard fork, but we would appreciate it if major pools could upgrade by Monday. Thereafter, exchanges and users can upgrade over the course of next week as Monero 0.8.8.5 is released. 3. Our shiny new CMake is also nearly ready - there are a few final nigglies on Windows and FreeBSD, and then it'll be all merged in. Dev DiaryCore: LMDB implementation is complete, and is undergoing testing for drastic rollbacks and edge cases. Please grab and test (link is above) Core: per-kb fees merged into master, and switchover to the new fee structure is hoped to happen next week. Until next week! - updated by fluffypony |
|
|
|
Original post is hereMonero Monday MissivesOctober 27th, 2014Hello, and welcome to our sixteenth Monero Monday Missive! Major Updates1. We have made major strides in the initial database implementation (you'll recall from our last Missive that our first implementation will use LMDB), and it is very nearly ready for broader testing. Specifically: the new blockchain is working for most things, but there are bugs with certain aspects of block verification that need to be fixed before it can be more widely tested. If you are particularly intrepid you can already grab it here: https://github.com/tewinget/bitmonero/tree/blockchain and compile it, and thus assist in identifying areas where it breaks down, although such reports are probably best submitted as github issues to tewinget's repository to reduce duplication. Once these and any other major issues have been weeded out the next steps would involve a bit of refactoring, fix cross-platform nigglies, and open it up for general testing. 2. The testing of per-kb fees on testnet, too, has gone exceedingly well. We will be adding the functionality to simplewallet (previously it required manual creation) and hope to deploy that for general testing within the next week. 3. Kitware staff, Ben Boeckel in particular, have spent a lot of time completely reworking our CMake build system and bringing it up to best practices. The fruits of those efforts can be seen on the Pull Request currently undergoing testing: https://github.com/monero-project/bitmonero/pull/180 (feel free to checkout this PR if you'd like to test). Now that the build system is starting to come together in its final form, we are hoping to use it to tag and release 0.8.8.5 during the course of next week. 4. In order to more efficiently deal with changes in the on-disk wallet format we are moving away from the old serialised+encrypted .keys format, and have a new format which is effectively encrypted JSON. This change allows us to note the wordlist language in the wallet format (so that the "seed" command can reflect that choice) and allows for cross-platform compatibility of the .keys file, which we are sure is excellent news for anyone that moves wallets between operating systems and architectures. You can test this in PR 179. 5. There have been a constant string of improvements and changes to the forum software to make it more usable and useful. In particular, new comments in a thread are highlighted within that thread. Additionally, unread threads (or threads with new unread comments) are highlighted by having a green dot next to them. Both of these apply to logged in users only. If you haven't visited the forum, you are encouraged to do so: https://forum.monero.ccDev DiaryCore: LMDB implementation is rough but nearly working (details above). Worth testing cross-platform, least of all from a build perspective. Core: since we have already had to perform the rather annoyingly complex task of offloading MoneroPulse checkpoint checks to a separate thread (so as not to tie anything up during checks) we have begun extending this to other parts of the core that could potentially be or currently are pain points. This does not include the flat-file blockchain saving, as that is going to be deprecated with the move to LMDB, so pools will just need to hang on and deal with that nuisance for a little bit longer. Build: CMake is looking a lot cleaner and easier to grok. It also fixes cross-compile (see: http://www.cmake.org/Wiki/CMake_Cross_Compiling) which means that binaries for all our major supported platforms can be built on a single system. Account: multilang wordlists are now inherent to the wallet/account, so that RPC and CLI calls that retrieve the mnemonic do so in the correct format. This has, in turn, necessitated moving away from the horrible serialised data format for account data. Since epee's JSON library is beyond redemption, we have opted to use RapidJSON instead (which is headers-only and thus straight in the source tree). Until next week! PS. this Missive has the very great honour of being the first one to be finalised and very nearly posted from the air - updated by fluffypony
|
|
|
|
Monero Monday MissivesOctober 20th, 2014Hello, and welcome to our fifteenth Monero Monday Missive! Major Updates1. We are saddened to hear of the implosion of Moolah and how it has hampered Monero users in their attempts to withdraw funds held on MintPal. We have actively reached out to the current management staff to try and assist them with Monero withdrawals, and at this stage we're completely unsure as to what the internal state of their system is. We hope and trust they will resolve it and all affected users will be able to withdraw, and we remain completely available to assist their staff as necessary. 2. It has been a week of fundamentals. Whilst externally visible development is fun and easy to see, there is a dire need to focus on some of the core issues that have been lagging. The longer we wait before addressing these, the harder and more expensive it will be to address them. By spending a little bit of effort now we make Monero more secure and robust for the far future! 3. Excellent progress has been made with an initial blockchain database implementation. The first implementation is using the Lightning Memory-Mapped Database, or LMDB, which is the same high-performance database used by OpenLDAP. We are hopeful that this initial release will be ready for limited testing by next week. You can read more about LMDB here: http://symas.com/mdb/ (it would appear they're in a competition with us for the best looking website of 1995). We are quite confident that this will be the most performant embedded database option for our workloads, but we will be adding additional implementations and comparing their performance going forward. 4. Extensive work is underway with the assistance of NLnet Labs (the creators of Unbound and libunbound) to correctly implement DNSSEC trust anchors in a cross-platform manner. Don't worry, you aren't expected to understand that sentence:) What this means is that it prepares us for more widespread, secure use of the OpenAlias standard. One of the key problems it solves is in allowing all Monero users to securely and safely determine whether an alias has been tampered with or not (although even insecure aliases can still receive payments as long as the sender double-checks and confirms it). 5. To build on what we mentioned last week: we are working directly with Kitware founder Bill Hoffman, along with his colleague Ben Boeckel, to bring our build system (which uses Kitware's CMake and CTest) up to scratch and ensure we are complying with Kitware's best-practices across the board. This may seem like an insignificant effort, but after the difficulties and pain-points we encountered with statically building the Monero 0.8.8.5 release we realised the need for our build environment to be reworked to conform to what Kitware recommends, especially considering the amount of poorly implemented CMake in the reference code we started with. Dev DiaryCore: per-kb fee testing is going well on testnet, although there are some caveats we are working through. Core: work is progressing nicely on a new feature that will allow a raw, static blockchain to be generated so that we can provide that for download instead of the serialised blockchain objects. This will mean that importing this file will take as many as several hours, but your daemon will fully verify the downloaded blockchain instead of just assuming it to be correct. Tests: unit tests have been fixed so that they are now working, and this change is expected to be merged in the next week. Tests: core tests are currently being worked on to bring them up to a 100% working state. The end goal of all of this is the ability to compile for release-test or debug-test, and have all tests pass, every time a new pull request is submitted. Until next week! - updated by fluffypony
|
|
|
|
|
Monero Monday Missives
October 13th, 2014
Hello, and welcome to our fourteenth Monero Monday Missive!
Major Updates
1. The database effort is ongoing, and is currently playing a little bit of catch-up back-porting features and fixes we added to the current codebase.
2. The GUI, too, is progressing at a slightly reduced pace. We hope to update the preview binaries in the next week or two.
3. We are working hard on solving the static build issues to tag and release updated binaries. If you require any of the more recent features it is compile-only at this stage.
4. We are happy to announce that per-kb fees is going to be deployed to testnet over the next couple of days. Barring any major complications, we expect positive testing results, and are hopeful that mainnet can move over to per-kb fees within the next two weeks.
5. A few other things undergoing testing are: parallel support for MSVC 2013 as a build environment, minor tweaks and improvements to the new mnemonic system whereby English words now match on the first 3 letters and not the first 4, asynchronous DNS checkpointing, and support for long / blob hash checkpointing on both the file and DNS side.
Dev Diary
Build: initial work has started on reworking the CMake environment so that it is consistent and extensible. This will reduce build issues further down the line.
Core: per-kb fees are done, and are being deployed to testnet. If you are mining on testnet you don't have to update to that fork/branch, as we want to see more real-world results with both fixed-fee and per-kb miners.
Core: documentation continues, with Doxygen comments now added to the serialisation functions
Core: DNS checkpointing is now asynchronous, and doesn't prevent blocks from being received (in testing)
Core: file and DNS checkpoints now also support blob hash (longhash) checkpointing (in testing)
Wallet: mnemonic lists now support a variable trim length (instead of the previous fixed trim length). English is 3, the rest are 4, and the old English wordlist doesn't really conform to the trim length rule (in testing)
Until next week!
- updated by fluffypony
|
|
|
|
Monero Monday MissivesOctober 6th, 2014Hello, and welcome to our thirteenth Monero Monday Missive! You'll notice a slight change in name - as of today we will be putting out a Missive every Monday. We want to start shifting the Missive from an announcement platform to a "week in review" platform. Traditionally the Missives have been a place for announcements, but all that is about to change. Major Updates1. We are happy to announce the launch of the official Monero forum. You can find it at https://forum.monero.cc Instead of using something existing and off-the-shelf we wrote our own. There were several reasons for this, but the primary reason is that there is functionality we required that simply does not exist in existing forum software. Additionally, the nature of forums has hardly changed in well over 20 years (phpBB was released in 2000, SMF that is used on Bitcointalk was released in 2003). The forum software will be open-sourced and released soon. You will find the following features on the new forum of interest: - A clean, modern, responsive interface that provides a threaded view of posts.
- Support for those that choose to have JavaScript enabled or disabled in their browser.
- Integration into the #bitcoin-otc Web of Trust. Currently this is one-way only, but the OTC WoT will soon start syncing back down.
- In combination with that, GPG authentication that is also used as 2FA. When logging in you can choose how long to remain logged in for, so the level of protection you wish to exercise over your account is up to you.
- The ability to rate users, as with the WoT. Ratings can be from -10 (untrusted) to 10 (trusted). We will also be adding tools to assist in visualising the trust relationships to forum members to assist with and encourage qualitative use of the WoT.
- Posts and comments are weighted, and their position in the forum as well as their visibility is affected by this weighting. The weighting rules are still a work in progress and will mature over time, but they are primarily affected by four things: decrease as it decays over time, increases/decreases as users vote them insightful or irrelevant, and increases/decreases based on votes and child comments from users in your trust group (with influence up to a third level beyond your immediate trust group). The upshot of this is that the posts and comments that are most visible to you, and the order in which posts appear, is unique to you as a user, and depends entirely on your trust relationships. If a post is getting a lot of comments by people that you trust directly or indirectly (trust-of-trust and trust-of-trust-of-trust) you will personally see that post at the top more often than someone else who has no trust relationship with those commenters. We hope that this will, over time, lead to a more personal forum experience, one where troll and shill posts are effectively invisible, and you can focus on the posts and comments most important to you.
- We are in the process of baking the funding system into the forum. You will notice that in the Development category there are 4 special sections: Ideas, Open Tasks, Funding Required, and Work in Progress. The way this will work is that anyone can suggest an idea in the Ideas section, whether it is a Monero feature, a peripheral task, or even something completely unrelated to direct development such as a gathering or conference. Once an idea reaches a level of maturity and community support (commensurate with the complexity of the idea, of course) it will be moved to Open Tasks by the Monero core team. At this juncture, a person, team, group, or even company can pitch to run with the task. Especially if they have not done anything Monero-related previously, they will need to detail why they are best suited to the task, and will need to give some indication as to what the cost will be, even if it is a bit of a thumb-suck. The core team will make a decision as to which candidate/group/team is going to run with the task, and the task will move to Funding Required. At this point the community will be able to fund the effort, with individuals being able to reach status levels and earn badges the more funding they provide. Once funding has exceeded 60% for that task work can begin and the task moves to Work in Progress, with a small stub left in Funding Required until the balance of the funding is met. The person or people working on the task can only request payment at most once a week, and funds will only be released if there is general agreement and observation by the community that the work is being done.
- Posts and comments can contain MarkDown, including links, inline code blocks, multi-line code blocks, bold and italicised text, and inline images.
- Private messaging, forum search, subscriptions, and so on will be added in the near future, but if you have a specific idea please create a post in the "Meta" section of the Monero Forum.
2. We are, therefore, going to be closing some of the threads here on Bitcointalk and linking them to the Monero Forum instead. It would be appreciated if all could follow suite, so that we have a single place for discussion and ongoing Monero-related efforts rather than having things spread out all over the place. 3. We have have been working hard in the background on the codebase, and the following additions are available in the source repository:  - Major overhaul of the mnemonics system. This includes a brand new English wordlist designed from the ground up to minimise variant differences and to encourage adapting or memorising the list. It also adds an extra word as a checksum, so mnemonic seeds are now 25 words instead of 24. Finally, it adds multi-language support, with initial extra word lists in Japanese, Portuguese, and Spanish. If you would like to assist in creating a word list please get hold of us (by posting on the new forum, for instance!)
- The addition of MoneroPulse, a loosely distributed checkpoint alert system. MoneroPulse will allow us to add both block hash checkpoints and blob hash checkpoints (to defeat attacks like the Block 202612 attack). For ordinary nodes that are checked at least occasionally, the daemon will notify you in angry red letters when your local chain doesn't meet a checkpoint. If you run an unattended node (merchant systems, pools, etc.) you will want to turn on the "--enforce-dns-checkpointing" flag so that these checkpoints are enforced and not merely notified.
- In the event of someone being a nuisance and trying to disrupt the Monero blockchain, we can now also distribute checkpoints in a simple checkpoints.json file that can be dropped into the same folder as your blockchain. The JSON format is quite simple, and we have provided an example in the Dev Diary below. The combination of file and DNS checkpointing will allow us to respond extremely quickly and secure the blockchain in the event of an attack. Of course, these measures are temporary, and once the Monero network is significantly larger and stronger they will be unnecessary.
- There have been a number of minor tweaks and bug fixes.
- Please note that static builds still need to be finalised before we can tag a release, but we hope to have new binaries up shortly.
4. The Monero Research Lab is glad to release a new Research Bulletin, MRL-0003, entitled "Monero is Not That Mysterious". In it, the Monero ring signatures are broken down and analysed both cryptographically and mathematically. In conjunction with that, we are happy to announce the release of MiniNero, a Python implementation of the Monero ring signatures. This is a very basic reimplementation that produces valid ring signatures that are nearly Monero compatible, although slight differences occur due to the hashing and packing algorithms. You can find the MiniNero source code on Github: https://github.com/monero-project/mininero5. Monero has been added to the Cryptsy voting list, and within a few short days it has shot up to number 2 on the voting list. Thanks to all that have voted and continue to vote! Dev DiaryCore: file checkpointing. This is in the form of a checkpoints.json file added to the config_folder. This file is checked every 10 minutes, and new checkpoints are always enforced (it is assumed that if an attacker has write access to your config_folder they can just modify your blockchain without needing to do anything else). At its simplest, the file follows this format: { "hashlines": [{ "hash": "7cb10e29d67e1c069e6e11b17d30b809724255fee2f6868dc14cfc6ed44dfb25", "height": 22231 },{ "hash": "bbd604d2ba11ba27935e006ed39c9bfdd99b76bf4a50654bc1e1e61217962698", "height": 202612 }] } Core: DNS checkpointing. This scans TXT records on the domains checkpoints.moneropulse.net/org/se/co every hour and, unless an enforce flag is set, notifies the user where checkpoints do not match. The records are all DNSSEC secured, although there is still some work to be done to provide cross-platform root trust anchors. Build: the build system is a little precarious at the moment. We are working hard on improving it so that builds are easier and less problematic. Our focus is always on making sure the that "usual" dynamic build works, and static builds are thus a secondary concern. At this stage, static builds require a bit of massaging that we hope to have sorted out by the next tagged release. Core: dga has kindly spend some time annotating and documenting the PoW algorithm in code. If you are working with the PoW algorithm you may find his notes in slow_hash.c to be extremely useful and revealing. Until next week! - updated by fluffypony
|
|
|
|
BCX, we'd like to formally respond to this - So what was your reason for attacking Monero and refusing to allow devs to fix your exploit?
They claim they've already TW proofed XMR and do not need any help. ~BCX~ In your post on September 17th you stated that you had found very specific exploits in Monero. Immediately, and in direct response to you, we asked if you could disclose the vulnerability to us privately so we could fix it. You did not respond to our request. Subsequent to that post, in which you stated that you had no need or desire to attack Monero, you announced that you would be attacking Monero, and gave us 72 hours notice. At no point since we asked if you would disclose the exploit privately to us did we, formally or informally, claim that we had "TW proofed XMR". As it states in our ANN on Bitcointalk: "the official core team members are (in no particular order) - tacotime, eizh, smooth, fluffypony, othe, davidlatapie, NoodleDoodle". We cannot control what anyone else says of Monero, and if anyone has implied or stated that a TW-style attack is impossible that is not a view that we share. We are not naive enough to state that Monero is anything-proof, and we cannot categorically state that you do or do not have an exploit as you have not disclosed any details to us. In addition, we have said and continue to say that Monero is alpha-level software, and is nowhere near the level of maturity Bitcoin has (and Bitcoin itself is considered beta software by its developers). We regularly have people providing assistance to the project, be it financial or direct effort or the imparting of some unique observation to us. We warmly invite and encourage assistance from everyone. We would never reject the offer of help unless we had a very specific reason to do so, and we most certainly do not reject your offer of help. We want to continue to make Monero better, and so any assistance you or anyone else can provide is deeply appreciated by us all. Therefore, we openly and kindly invite you to disclose the details of the exploit to us privately so we may analyse and fix any exploits that may exist. You may do so by sending a private message to this account, sending a private message to any of the named core team members as listed above, or sending an email to dev@monero.cc |
|
|
|
Monero MissivesSeptember 15th, 2014Hello, and welcome to our twelfth Monero Missive! This is our first Missive after a bit of a break whilst we thwarted two related blockchain attacks. Nonetheless, we have not sat by idly, we have been finalising and completing a brand new aspect of Monero designed to protect your privacy now and in the future: Major Updates1. The Monero Research Lab is an open collective and a multi-faceted academic group focused on the ongoing improvement of Monero. Membership is not fixed, and comes and goes as researchers become interested in Monero. This isn't a group focused on the addition of "features" to Monero, but rather the analysis and improvement of the underlying core of Monero to make sure that the theories and cryptography behind Monero continue to remain robust and sound. With that in mind, we are proud to announce the release of the first two publications out of the Monero Research Lab: 2. This week Friday we're going to have our second #Monero-Dev Fireside Chat this week Friday, September 19th, 2014, at 10:00 EST which is 14:00 UTC and 16:00 UTC +2. For a full table of the time zones you can refer to this image, or you can use this online tool to add your city and make sure you have the correct starting time. Please note that this is a developer event, and so most of the focus will be from that perspective. 3. To pick up where we left off with our last Missive, we are also happy to announce the availability of Monero merchandise on the Monero Gear store, powered by Zazzle. The advantage of us using Zazzle is that it is on-demand and we never have to worry about print runs or stock or anything. In return we get 15% of each sale as a "royalty" that will go towards enabling further Monero development, although Zazzle do not (yet!) accept Bitcoin or Monero. We hope to add new designs to the store on a regular basis. You can check the store out here: http://www.zazzle.com/monerogear* or take a peek at some of the new designs: 4. We are also pleased to announce the release of URS, a Monero project written in Go that allows you to sign messages using ring signatures as part of a group. The signature can be verified, but it cannot be determined which one of the signatories in the group did the actual signing (just like Monero uses for transactional unlinkability!). You can take a look at the project here: https://github.com/monero-project/urs, and the Bitcointalk thread dedicated to the project is here: https://bitcointalk.org/index.php?topic=768499.05. We have a new tagged release, 0.8.8.4, available for download (binaries: Windows, Mac, Linux, FreeBSD). This adds the following features: - Testnet: we now have an operating testnet. When using bitmonerod or simplewallet you can now use the --testnet flag to use testnet instead of mainnet. Feel free to run a mining node or just a testnet node, we will be setting up email alerts for testnet nodes when an update is pending (although having a few older testnet nodes on the network won't hurt testing).
- FreeBSD Compatability: Monero now works on FreeBSD out the box. We will add it to the ports tree soon. At the moment compilation is no different from regular Linux and Unix compilation, and the same dependencies apply.
- GPG commits: we have begun GPG-signing commits and merges. This is an important step in maintaining the integrity of the codebase, and will ensure that any compromise of our computers or even the github account won't allow a malicious attacker to push code to the repository without the unsigned commits being spotted. Verification can be done by running 'git log --show-signature', which will show and verify signatures. An example of what you should see is below:
- Versioning: versioning is a lot easier, now, as tagged releases from 0.8.8.4 onwards will show version-final (eg. 0.8.8.4-final) as their version, and those built between tagged releases will show version-commithash (eg. 0.8.8.4-9088ea1). We expect this will greatly aid in debugging problems, as we can immediately pinpoint the actual version / commit a user is on.
- Logging: default log levels have been adjusted so that non-critical warnings are now relegated to log-level 1 and above. Apart from the normal reorganisation notifications, the only messages in red that should show up in the daemon are actual errors.
6. We have slowed down development on the GUI to give us a bit more time to focus on the Monero internals. This is especially important given the recent attack. However, work has not come to a complete halt, and so we wanted to show off a couple of pages from the first start wizard. Bear in mind that these aren't mockups, this is the actual running Qt interface: 7. Monero has been added to another exchange, Coin Swap. You can find the market here: https://coin-swap.net/market/XMR/BTCDev DiaryCore: because of all of the rapid changes that we had to merge into master to deal with the aftermath of the block 202612 attack, we have to bring the development branch in sync. At this stage the development branch should not be considered usable until the rebase is complete. Build: the big change is FreeBSD compatibility, as mentioned above. A more subtle change is that the build will now first look for miniupnpc on the local system, and use that if found. If it fails to find miniupnpc it will fall back to the local copy. Build: there is a new Makefile target, release-static, that builds statically linked binaries for redistribution. At this stage it forces 64-bit builds, once we have the embedded database working cleanly we can remove this. Wallet: per-kb fees are nearly complete, and will be deployed to testnet within the next week or so. Once some thorough testing has been done on testnet we can merge this into master, and transaction fees can return to "normal". Blockchain: this took a bit of a backseat with the blockchain attacks. Now that things are back to some semblance of normality, the first implementation can be written. We have chosen LMDB for the initial implementation, as this will allow us to rapidly write a Berkeley DB interface based off of it (they use similar APIs) and thus have a baseline for performance comparisons. Core: all non-critical "errors" and warnings have been moved to log-level 1. As a developer, you may find it useful to run log-level 1 or 2 as your default. Until next week! - updated by fluffypony
|
|
|
|
Monero MissivesAugust 16th, 2014Hello, and welcome to our eleventh Monero Missive! Major Updates1. We know everyone is quite keen to play around with the GUI. We are still doing a great deal of underlying work, but we wanted to get the interface out there for everyone to have a play and see how they like it. There are some bugs (for example, resizing the MiniWindow interface does not work), and there are some spelling errors that we'll fix as we pull everything out for Qt Linguist to handle translation. But if you're happy to play around then please grab a binary - we'll take feedback in the form of github issues as soon as we've finalised the initial release of the interface and have it up there. You can download the interface binary for Windows or Mac. We'll also push a Linux build out in the next day or two once it is confirmed as all working! 2. Our /r/monero sub-reddit broke 600 subscribers! If you are a Redditor and you aren't subscribed, now would be a very excellent time to do so! And whilst you're sorting out your social media, why not make a turn at our Facebook Page and click the "Like" button, and then swing past our Twitter and make sure you're following us:) 3. We are always quite hesitant when it comes to discussing donations, but they have been quite thin, which does make our job that much more difficult. With our increased download and testing equipment costs, we are spread quite thin. But fear not, within the next week or two we are going to have a way you can donate to the ongoing development of Monero whilst still getting something directly. In the interim, please do not forget that the donation addresses are in the OP, and that it is your ongoing support that is helping us plough ahead with development! 4. In case you haven't watched the #Monero-Dev Fireside Chat, we'd like to take a moment to discuss an upcoming terminology change. To take it from the github issue that has been at the centre of the discussion: It's been suggested that "wallet" is a poor description for laymen, and may hinder adoption. It's also arguably sexist - men have wallets, women have purses, and whilst "moneybag" is genderless it's probably the wrong term;) Whilst Monero is quite far from a point where this terminology becomes an issue, it's the sort of change that we can make sooner rather than later. The term we're going to be moving to is "account". We are aware that some may think that this implies centralisation, but there are key advantages to making this switch, especially as it pertains to new users not familiar with cryptocurrencies: - It fits in with the whole "be your own bank" motion, which is a good way to explain cryptocurrency in general to people - The idea of separation of accounts is already familiar to people - a married couple may have a joint account, a company will have an account (or accounts), a savings account would be separate, and so on - People are familiar and happy with paying a fee for moving funds between accounts, so it won't be foreign to them - It's the most familiar path for the general public. They understand creating an account, using a strong password, password recovery, etc. It's a natural transition for them. We expect to make this change sometime in the next month or so when we have our next tagged release. 5. thefunkybits started a Twitter campaign to mention Monero to major exchanges and news outlets. He is paying 0.4 XMR per Tweet, so if that is something you're interested in head on over to his thread on the matter. 6. Atrides, the admin of DwarfPool, released an open-source Monero stratum proxy. This allows multiple mining machines inside of a network to all connect to the proxy server, so that only a single connection to the Internet is made. It's also useful for geographically distributed mining rigs, or even for miners that simultaneously GPU and CPU mine. More info is at his thread, and the code is on his github repo. 7. This week we have been working on finalising the QoS bandwidth control, finalising the mingw64 Windows build system (thus removing the need for Microsoft Visual Studio on Windows builds), and an effort has begun to refactor the wallet code so that integration with the GUI will be much easier later on (and to make things ready for the wallet -> account terminology change). Dev DiaryCore: we are going to be adding a development branch to the main repo so that vaguely working code can be merged there and rebased by all contributors faster. Right now the multiple branches are becoming messy for rebasing. This won't change that the main branch is staging, but it will provide better fluidity, and obviously all the changes can be merged into master when they are ready for broader end-user/environment testing. Ongoing testing of this branch is heavily encouraged, and opening github issues (for issues that actually exist) will be rewarded with 1x our eternal gratitude (limited to 10 per user). Build: most of the mingw64 / msys2 is "done", thanks to the mikezackles' hard work. The branch is currently here: https://github.com/mikezackles/bitmonero/tree/mingw. However, we will be pushing this (which includes the Windows service and daemonize changes, as well as the rpcwallet change) into the development branch on Monday. Once it's up, please test it, especially on Windows environments, so we can start stripping out the VS ifdefs. Wallet: mikezackles is heavily refactoring the wallet code to be more legible, and more in line with our standards and expectations. This effort can be followed here: https://github.com/mikezackles/bitmonero/tree/account_refactorBlockchain: tewinget's abstraction and refactoring of the blockchain functions is coming to a head, and we are hoping to start some specific integrations for performance testing so that an embedded database can be decided on and fixed. Core: QoS will need to be rebased by rfree once the mingw branch is pushed to the development branch. Subsequent to rebasing, it will also be merged in to development, so barring any breaking issues it should be available for general testing within the next week. Until next week! - updated by fluffypony
|
|
|
|
Monero MissivesAugust 10th, 2014Hello, and welcome to our tenth Monero Missive! This Missive was meant to go out on August 10th, but due to a little miscommunication and all the excitement with the new GUI, it went out quite a bit later. Please accept our apologies for the delay in bringing this to you! Major Updates1. We had an extremely successful #Monero-Dev Fireside Chat broadcast last Friday. This was a special event as it let us show off the GUI and talk about all the work that has gone into it thus far. That having been said, the #Monero-Dev Fireside Chats are developer-centric events, so as and when we do them again in future the focus will be more on core components, RPC/IPC, and future development efforts that affect the way developers interact with, expand, and use Monero. We are hoping to do our next #Monero-Dev Fireside Chat in a few weeks once there are more changes that are discussion worth. If you haven't seen the first Fireside Chat, you can always catch-up and watch it here. 2. As mentioned, we showed off the work that has been done thus far on the Monero GUI. There is still quite a bit of work to be done, but we are very proud of what has been accomplished thus far. You can take a look at the work that has been put into the GUI in these screenshots. A couple of common questions that we'd like to address: - This is not a web-based GUI, it is a standalone desktop application, and is thus not open to common web-based UI exploits (XSS and so on) - It is written using Qt, and is completely cross-platform, so it will run on Windows, Mac, and Linux without issue - There are lots of aspects that are a work-in-progress, so if you spot any spelling errors and so on make a note of it and see if it isn't fixed when we push the first release of the interface up on github for everyone to play with before we start integrating it into the code - There is still a lot of work to be done, so we are unable to provide a release timeline, but we are working on it as hard as possible 3. We'd also like to extend a warm thank you to all who have donated. The GUI, and everything we do on Monero, is completely donation supported. Without your effort we would not be able to continue working on Monero at the pace we have been! Don't forget that by donating you can secure your place in the Monero Community Hall of Fame! 4. For those that want to include a price ticker on their website, CoinGecko has an excellent Monero price ticker that lets you display the current Monero price in BTC, USD, GBP, EUR, and lots of other currencies. It's easy to use, and it produces a small snippet you can drop into your website's HTML. 5. Much of the development effort this week has been building up to the Fireside Chat. A major improvement in the development process is the purchase and configuration of a proper test environment, as we move towards a Continuous Integration process that will allow for much faster testing and deployment. We are also rapidly getting to a point where Windows users will be able to compile Monero without needing Visual Studio. Dev DiaryBlockchain: tewinget is starting to bring the abstracted BlockchainDB functions together, as discussed in the Fireside Chat. You can continue to follow his work on his branch: https://github.com/tewinget/bitmonero/tree/bc2Build: rfree has completely overhauled the CMakeLists to make for target-specific builds (ie. binaries can be included and excluded at the command line, test suite can be excluded, and precompiled headers can be used to speed up builds). This is in a PR if anyone wants to test it before merge: https://github.com/monero-project/bitmonero/pull/91Core: part of the PR from rfree is to completely discard the old epee logging system, and move to a logging system he originally developed for Open Transactions. This allows for channeled logging (ie. separation of log levels in log files), as well as a host of other logging improvements. There is still some work to be done on this, but this will be the only logging method available soon, and contributed code will need to use the appropriate calls instead of the old epee calls. Testing: dbit is going to be working on bringing the unit tests up to scratch and on creating missing unit tests. We have now rented a reasonably specced Mac Mini from MacStadium, and quite a beefy test server from Hetzner to handle VMs for all the Windows and Linux flavours needed. We will be purchasing Windows licenses for the test VMs over the coming weeks. Download: after taking quite a financial hit servicing nearly 100tb of blockchain and client downloads over the month of April, we're in the process of moving all downloads on to edge servers in data centers in the US, the UK, and the EU. Servers have been rented, and there is quite a bit of work to be done configuring them. Thankfully, all of these servers are on 1gbps unmetered connections, so that will vastly reduce our bandwidth costs next month. Until next week! - updated by fluffypony
|
|
|
|
|
