Merge branch 'master' into master

.ruby-version

+2.4.1

CONTRIBUTING.md

+# General Guidelines
+
+- Commits should be [atomic](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention) and diffs should be easy to read. Please try to not mix formatting fixes with non-formatting commits
+- The body of the pull request should:
+  * contain an accurate description of what the patch does
+  * provide justification/reasoning for the patch (when appropriate)
+  * include references to any discussions such as other tickets or chats on IRC
+- If a particular commit references another issue, please add a reference. For example "See #123", or "Fixes #123". This will help us resolve tickets when we merge into `master`
+
+# [Code of Conduct (22/C4.1)](http://rfc.zeromq.org/spec:22)
+
+## License
+
+Copyright (c) 2009-2015 Pieter Hintjens.
+
+This Specification is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.
+
+This Specification is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License along with this program; if not, see <http://www.gnu.org/licenses>.
+
+## Language
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
+
+## Goals
+
+C4 is meant to provide a reusable optimal collaboration model for open source software projects. It has these specific goals:
+
+- To maximize the scale and diversity of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;
+- To relieve dependencies on key individuals by separating different skill sets so that there is a larger pool of competence in any required domain;
+- To allow the project to develop faster and more accurately, by increasing the diversity of the decision making process;
+- To support the natural life cycle of project versions from experimental through to stable, by allowing safe experimentation, rapid failure, and isolation of stable code;
+- To reduce the internal complexity of project repositories, thus making it easier for Contributors to participate and reducing the scope for error;
+- To enforce collective ownership of the project, which increases economic incentive to Contributors and reduces the risk of hijack by hostile entities.
+
+## Design
+
+### Preliminaries
+
+- The project SHALL use the git distributed revision control system.
+- The project SHALL be hosted on github.com or equivalent, herein called the "Platform".
+- The project SHALL use the Platform issue tracker.
+- The project SHOULD have clearly documented guidelines for code style.
+- A "Contributor" is a person who wishes to provide a patch, being a set of commits that solve some clearly identified problem.
+- A "Maintainer" is a person who merges patches to the project. Maintainers are not developers; their job is to enforce process.
+- Contributors SHALL NOT have commit access to the repository unless they are also Maintainers.
+- Maintainers SHALL have commit access to the repository.
+- Everyone, without distinction or discrimination, SHALL have an equal right to become a Contributor under the terms of this contract.
+
+### Licensing and Ownership
+
+- The project SHALL use a share-alike license, such as the GPLv3 or a variant thereof (LGPL, AGPL), or the MPLv2.
+- All contributions to the project source code ("patches") SHALL use the same license as the project.
+- All patches are owned by their authors. There SHALL NOT be any copyright assignment process.
+- The copyrights in the project SHALL be owned collectively by all its Contributors.
+- Each Contributor SHALL be responsible for identifying themselves in the project Contributor list.
+
+### Patch Requirements
+
+- Maintainers and Contributors MUST have a Platform account and SHOULD use their real names or a well-known alias.
+- A patch SHOULD be a minimal and accurate answer to exactly one identified and agreed problem.
+- A patch MUST adhere to the code style guidelines of the project if these are defined.
+- A patch MUST adhere to the "Evolution of Public Contracts" guidelines defined below.
+- A patch SHALL NOT include non-trivial code from other projects unless the Contributor is the original author of that code.
+- A patch MUST compile cleanly and pass project self-tests on at least the principle target platform.
+- A patch commit message SHOULD consist of a single short (less than 50 character) line summarizing the change, optionally followed by a blank line and then a more thorough description.
+- A "Correct Patch" is one that satisfies the above requirements.
+
+### Development Process
+
+- Change on the project SHALL be governed by the pattern of accurately identifying problems and applying minimal, accurate solutions to these problems.
+- To request changes, a user SHOULD log an issue on the project Platform issue tracker.
+- The user or Contributor SHOULD write the issue by describing the problem they face or observe.
+- The user or Contributor SHOULD seek consensus on the accuracy of their observation, and the value of solving the problem.
+- Users SHALL NOT log feature requests, ideas, suggestions, or any solutions to problems that are not explicitly documented and provable.
+- Thus, the release history of the project SHALL be a list of meaningful issues logged and solved.
+- To work on an issue, a Contributor SHALL fork the project repository and then work on their forked repository.
+- To submit a patch, a Contributor SHALL create a Platform pull request back to the project.
+- A Contributor SHALL NOT commit changes directly to the project.
+- If the Platform implements pull requests as issues, a Contributor MAY directly send a pull request without logging a separate issue.
+- To discuss a patch, people MAY comment on the Platform pull request, on the commit, or elsewhere.
+- To accept or reject a patch, a Maintainer SHALL use the Platform interface.
+- Maintainers SHOULD NOT merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 1-2 days).
+- Maintainers SHALL NOT make value judgments on correct patches.
+- Maintainers SHALL merge correct patches from other Contributors rapidly.
+- The Contributor MAY tag an issue as "Ready" after making a pull request for the issue.
+- The user who created an issue SHOULD close the issue after checking the patch is successful.
+- Maintainers SHOULD ask for improvements to incorrect patches and SHOULD reject incorrect patches if the Contributor does not respond constructively.
+- Any Contributor who has value judgments on a correct patch SHOULD express these via their own patches.
+- Maintainers MAY commit changes to non-source documentation directly to the project.
+
+### Creating Stable Releases
+
+- The project SHALL have one branch ("master") that always holds the latest in-progress version and SHOULD always build.
+- The project SHALL NOT use topic branches for any reason. Personal forks MAY use topic branches.
+- To make a stable release someone SHALL fork the repository by copying it and thus become maintainer of this repository.
+- Forking a project for stabilization MAY be done unilaterally and without agreement of project maintainers.
+- A stabilization project SHOULD be maintained by the same process as the main project.
+- A patch to a stabilization project declared "stable" SHALL be accompanied by a reproducible test case.
+
+### Evolution of Public Contracts
+
+- All Public Contracts (APIs or protocols) SHALL be documented.
+- All Public Contracts SHOULD have space for extensibility and experimentation.
+- A patch that modifies a stable Public Contract SHOULD not break existing applications unless there is overriding consensus on the value of doing this.
+- A patch that introduces new features to a Public Contract SHOULD do so using new names.
+- Old names SHOULD be deprecated in a systematic fashion by marking new names as "experimental" until they are stable, then marking the old names as "deprecated".
+- When sufficient time has passed, old deprecated names SHOULD be marked "legacy" and eventually removed.
+- Old names SHALL NOT be reused by new features.
+- When old names are removed, their implementations MUST provoke an exception (assertion) if used by applications.
+
+### Project Administration
+
+- The project founders SHALL act as Administrators to manage the set of project Maintainers.
+- The Administrators SHALL ensure their own succession over time by promoting the most effective Maintainers.
+- A new Contributor who makes a correct patch SHALL be invited to become a Maintainer.
+- Administrators MAY remove Maintainers who are inactive for an extended period of time, or who repeatedly fail to apply this process accurately.
+- Administrators SHOULD block or ban "bad actors" who cause stress and pain to others in the project. This should be done after public discussion, with a chance for all parties to speak. A bad actor is someone who repeatedly ignores the rules and culture of the project, who is needlessly argumentative or hostile, or who is offensive, and who is unable to self-correct their behavior when asked to do so by others.
+
+# Addendum to [Code of Conduct (22/C4.1)](http://rfc.zeromq.org/spec:22)
+
+## License
+
+Copyright (c) 2017 The Monero Project
+
+## Language
+
+The "Monero Site Maintainer Team" is defined in this document as the following users:
+- fluffypony
+- anonimal
+
+### Development Process
+
+- Maintainers MUST NOT merge pull requests in less than 168 hours (1 week) unless deemed urgent by the Monero Site Maintainer Team

Gemfile

+source 'https://rubygems.org'
+
+gem 'jekyll'
+gem 'jekyll-paginate'
+gem 'builder'
+gem 'rubysl-rexml'

Gemfile.lock

+GEM
+  remote: https://rubygems.org/
+  specs:
+    addressable (2.5.1)
+      public_suffix (~> 2.0, >= 2.0.2)
+    builder (3.2.3)
+    colorator (1.1.0)
+    ffi (1.9.18)
+    forwardable-extended (2.6.0)
+    jekyll (3.5.2)
+      addressable (~> 2.4)
+      colorator (~> 1.0)
+      jekyll-sass-converter (~> 1.0)
+      jekyll-watch (~> 1.1)
+      kramdown (~> 1.3)
+      liquid (~> 4.0)
+      mercenary (~> 0.3.3)
+      pathutil (~> 0.9)
+      rouge (~> 1.7)
+      safe_yaml (~> 1.0)
+    jekyll-paginate (1.1.0)
+    jekyll-sass-converter (1.5.0)
+      sass (~> 3.4)
+    jekyll-watch (1.5.0)
+      listen (~> 3.0, < 3.1)
+    kramdown (1.14.0)
+    liquid (4.0.0)
+    listen (3.0.8)
+      rb-fsevent (~> 0.9, >= 0.9.4)
+      rb-inotify (~> 0.9, >= 0.9.7)
+    mercenary (0.3.6)
+    pathutil (0.14.0)
+      forwardable-extended (~> 2.6)
+    public_suffix (2.0.5)
+    rb-fsevent (0.10.2)
+    rb-inotify (0.9.10)
+      ffi (>= 0.5.0, < 2)
+    rouge (1.11.1)
+    rubysl-rexml (2.0.4)
+    safe_yaml (1.0.4)
+    sass (3.5.1)
+      sass-listen (~> 4.0.0)
+    sass-listen (4.0.0)
+      rb-fsevent (~> 0.9, >= 0.9.4)
+      rb-inotify (~> 0.9, >= 0.9.7)
+
+PLATFORMS
+  ruby
+
+DEPENDENCIES
+  builder
+  jekyll
+  jekyll-paginate
+  rubysl-rexml
+
+BUNDLED WITH
+   1.15.4

README.md

@@ -40,25 +40,20 @@ If for any reason you have questions or need to contact us, you can find us on t
 
 ## 2.0 What you'll need
 
-* Jekyll: Getmonero.org is made using a simple, static website generator called [Jekyll](https://jekyllrb.com/). You will need it installed on your system to test any changes that you made. If you're using a Linux-based system you can just follow the instructions on the website to get up and going. If you're using Windows, you will want to check out [this site](http://jekyll-windows.juthilo.com/) for instructions on how to get Jekyll working on your system.
+* Jekyll: Getmonero.org is made using a simple, static website generator called [Jekyll](https://jekyllrb.com/). You will need it installed on your system to test any changes that you made. If you're using Windows, you will want to check out [this site](http://jekyll-windows.juthilo.com/) for instructions on how to get Jekyll working on your system. If you're using a Linux-based system you can just follow the instructions on the website to get up and going:
+  * Install Ruby
+  * Install Bundler: `gem install bundler`
+  * Install Jekyll with all dependencies (run from the project directory): `bundle`
 
 * GitHub: Pretty much everything in Monero is hosted on [GitHub](https://github.com) and uses Git as the primary version control system. If you're not familiar with how to use Git, you can check out [this tutorial](https://guides.github.com/activities/hello-world/) for a good overview. It will take you through pretty much everything you'll need to know to edit the website. If you haven't already, register for GitHub and fork the [Monero Website repository](https://github.com/monero-project/monero-site).
 
-* Markdown experience: To write pages, you're going to need to know how to use Markdown. It's basically a in-between language that enables people who don't know HTML to just write, and it will be compiled into HTML for you. You can find a great Markdown cheat sheet with examples [here](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet). IF you need more help, Google and YouTube are great resources.
+* Markdown experience: To write pages, you're going to need to know how to use Markdown. It's basically an in-between language that enables people who don't know HTML to just write, and it will be compiled into HTML for you. You can find a great Markdown cheat sheet with examples [here](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet). IF you need more help, Google and YouTube are great resources.
 
 *Note: If you're confused, feel free to click other files in the same directory (folder) that you are in for the step that you are on to see some working examples. Compare them to the instructions and you should understand better.*
 
-* Jekyll Gems: The current iteration of the getmonero.org website uses the following plugins:
-  * [jekyll-paginate](https://jekyllrb.com/docs/pagination/)
-  * builder
-  * rubysl-rexml
-  * In the event that more gems are added, this documentation will be updated to reflect the changes needed to build the site.
-
-*Note:* To install them all at once, use the command: `gem install builder rubysl-rexml jekyll-paginate`
-
 Once you have the above list of things, it's typically a good idea to build the website from your local computer to make sure it works before you make any changes. To do this, complete the following steps:
 
-1. Navigate to the your local `monero-site` repository.
+1. Navigate to your local `monero-site` repository.
 2. Serve the website: `jekyll serve`
 3. Open a browser and go to [http://127.0.0.1:4000](http://127.0.0.1:4000).
 4. If all went well, you should see the Monero website and you're ready to make changes.
@@ -69,12 +64,21 @@ The average Monero user that will want to contribute to the website should proba
 
 If you are a web developer and would like to make large macro-level changes, it would be best to get in contact with rehrar. The HTML/CSS framework is custom, though quite easy to use for a seasoned developer. Still, there are some pages that are more complicated than others and would require fair amounts of styling changes should the structure change significantly.
 
-This website is completely open-source however, and anything and everything is available for changing should the community deem it necessary.
+This website is completely open-source however and anything and everything is available for changing should the community deem it necessary.
 
 Every section from here on out will talk about how to make a specific type of web page. It will start with a bullet point list of what to do for the advanced among you that just want a quick overview. For those who are still learning this list is followed by a detailed explanation, starting with example front matter. Any variable in the front matter written in all caps you are expected to change (make sure your changes are not all caps though). It will then lead you through the rest of the process until it's time to type your content.
 
 All external links must have http:// or https:// in front of them or they will not redirect properly.
 
+### 3.1 Housekeeping
+#### GitHub Issues
+We ask that if you open an issue on the site that you remain available for clarifying questions or corrections. We do our best to close issues that are resolved when we make changes to the site, but If your issue is resolved by a contributer and the issue is not closed we ask that you close it in a timely manner. A contributer (rerhar, SamsungGalaxyPlayer, or other community members, etc) may ask you to close an issue after it's confirmed fixed. Please review the changes to the site and close your issue if you can verify that it's fixed.
+
+#### Pull Requests
+Contributers should use [issue keywords](https://help.github.com/articles/closing-issues-using-keywords/) to make it easier for maintainers to close issues when they merge. Include close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved, etc in the commit message or pull request description, so that the correct issue can be closed if your PR is merged. (Example: 'fixes #1234' could close Issue 1234 when merged.)
+
+Pull requests allow others to make comments or review your changes to the site. We ask that you remain available to comment or make changes to your PR. Pull requests with pending changes for more than 30 days will be closed and need to be resubmitted in the future. Sometimes someone else's changes might make your changes conflict with the current site. If that happens you may need to rebase your PR. (If you're unsure about how to do so, you can reach out to other contributers on IRC (freenode #monero) and someone should be able to walk you through it.
+
 ## 4.0 How to make a blog post
 
 ### 4.1 Quick Start
@@ -111,7 +115,7 @@ You're all done. Submit a PR and wait for it to be reviewed and merged. Be sure
 
 ### 5.1 Quick Start
 
-* Make file in /resources/user-guides with a .md ending and no spaces in filename.
+* Make file in /resources/user-guides with an .md ending and no spaces in filename.
 * Front Matter as in 5.3
 * Write User Guide
 * Add guide using markdown in the correct category in /resources/user-guides/index.md being careful not to mess with any indentation
@@ -139,7 +143,7 @@ DO NOT CHANGE ANYTHING IN THIS DOCUMENT BESIDES WHAT YOU ARE INSTRUCTED TO.
 
 This file will look quite different because it's HTML. Don't panic. Simply Ctrl + F (i.e. the find feature) and search for the category that you want to put your User Guide in. You will see there are some sections that are not indented like the others. They are flush with the left side of the screen. **Do not change the indentation.** You can put markdown in these areas.
 
-Once you've identified the non-indented area under the category you would like your User Guide to be under, you can use markdown to insert your link underneath the others. `[TITLE OF USER GUIDE](LINK-TO-USER-GUIDE.html)`. Please note that the file name in between the paranthases must be EXACTLY the same name as the file name you made in step 5.2, but with a `.html` at the end instead of `.md`.
+Once you've identified the non-indented area under the category you would like your User Guide to be under, you can use markdown to insert your link underneath the others. `[TITLE OF USER GUIDE](LINK-TO-USER-GUIDE.html)`. Please note that the file name in between the parentheses must be EXACTLY the same name as the file name you made in step 5.2, but with a `.html` at the end instead of `.md`.
 
 In the event that you think your User Guide should be in a new Category that doesn't exist yet, contact rehrar to make one for you.
 
@@ -294,9 +298,9 @@ and paste it IN THE CHRONOLOGICAL ORDER that it will be in. So if there is an ev
 
 Fill in the data as follows:
 * `event:` The name of the event goes here as well as the date. The recommended format is: `Event Name - January 1st, 2000`
-* `where:` Where the event will take place. Vanue name and address are recommended.
+* `where:` Where the event will take place. Venue name and address are recommended.
 * `when:` Date and time
-* `description:` Descriptoin of the happenings of your event
+* `description:` Description of the happenings of your event
 * `link:` The website of your event (if applicable, this can be left blank and everything will be ok). This link must have http:// at the beginning if it is an external link.
 
 **Make sure the indentation is EXACTLY the same as the other proposals in the area. If it's not the jekyll build WILL fail.**
@@ -324,7 +328,7 @@ Find the year that you want to update and copy the code below:
   date:
   status:
 ```
-and paste it in the correct years `accomplishments:` section IN THE CHRONOLOGICAL ORDER that it will be in. So if there is a accomplishment that happened/is happening before the one you are inputting, make sure it is higher up than yours. If there is an accomplishment that happened/is happening AFTER yours, make sure it is after yours. If you don't have exact dates, just do your best to estimate.
+and paste it in the correct year's `accomplishments:` section IN THE CHRONOLOGICAL ORDER that it will be in. So if there is a accomplishment that happened/is happening before the one you are inputting, make sure it is higher up than yours. If there is an accomplishment that happened/is happening AFTER yours, make sure it is after yours. If you don't have exact dates, just do your best to estimate.
 
 Fill in the data as follows:
 * `name:` The name of the accomplishment. Try to keep it short, a sentence or two at most.
@@ -358,7 +362,7 @@ Find the category that best describes your business/service and copy the code be
 and paste it in the correct category under the `merchants:` section.
 
 Fill in the data as follows:
-* `name:` The name of the the business/service.
+* `name:` The name of the business/service.
 * `url:` The external url of the business/service. This link must have http:// (or https://) at the beginning if it is an external link.
 
 **Make sure the indentation is EXACTLY the same as the other proposals in the area. If it's not the jekyll build WILL fail.**
@@ -376,7 +380,7 @@ You're all done. Submit a PR and wait for it to be reviewed and merged. Be sure
 ## 12.0 How to add a question to the FAQ
 
 ### 12.1 Copy/Paste Code
-Navigate to the `/get-started/faq` folder and open the `index.md` file. Inside you will see HTML code, but you will see it is very repetetive.
+Navigate to the `/get-started/faq` folder and open the `index.md` file. Inside you will see HTML code, but you will see it is very repetitive.
 
 Copy the code below:
 ```
@@ -392,7 +396,7 @@ CHANGE ANSWER
 
 </div>
 ```
-And paste it at the very bottom of the file. Literally underneath everything else.
+And paste it at the very bottom of the file (literally underneath everything else).
 
 Now we're going to change just a couple of things. Find the section with:
 ```
@@ -428,4 +432,4 @@ Redistribution and use in source and binary forms, with or without modification,
 
 3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
 
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
\ No newline at end of file
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

_data/merchants.yml

@@ -34,12 +34,14 @@
       url: https://www.kraken.com/
     - name: BIT.AC
       url: https://bit.ac/
-    - name: Premium investment and exchange services
+    - name: Kaiserex
       url: https://www.kaiserex.com/
     - name: Magnetic Exchange
       url: https://magneticexchange.com
     - name: ArbitrCoin
       url: https://arbitrcoin.com      
+    - name: Anycoindirect
+      url: https://anycoindirect.eu/
 - category: Block Explorers
   merchants:
     - name: ChainRadar
@@ -47,7 +49,7 @@
     - name: MoneroBlocks
       url: http://moneroblocks.info
     - name: MoneroExplorer
-      url: https://explorer.xmr.my/
+      url: https://moneroexplorer.com/
     - name: MoneroHash Explorer
       url: https://monerohash.com/explorer/
     - name: xmrchain.net
@@ -60,6 +62,8 @@
       url: https://monero-merchants.com
     - name: Paybee (Private Beta)
       url: https://payb.ee/
+    - name: Monero WooCommerce Extension (PHP)
+      url: https://github.com/monero-integrations/monerowp
 - category: Libraries and Helpers
   merchants:
     - name: monero-nodejs (Node.js)
@@ -78,6 +82,8 @@
       url: https://github.com/MalMen/PHP-Monero
     - name: Monero-PHP (PHP)
       url: https://github.com/PsychicCat/monero-php
+    - name: Monero Payments Library (PHP)
+      url: https://github.com/monero-integrations/monerophp
 - category: Tools
   merchants:
     - name: nestorgames
@@ -114,16 +120,12 @@
       url: http://www.guitartheoryrevolution.info/blog/guitar-theory-revolution-store/
     - name: MyMonero Web-based Wallet
       url: https://mymonero.com
-    - name: Pradeep Atluri, Psychiatrist, New York
-      url: http://dr.mindsci.com/
     - name: Simple, no non-sense hosting
       url: https://rootbox.host/
     - name: Web Developer - Stefanos
       url: http://www.stefanosioannou.com/web-development-monero-accepted
     - name: XMR.to Monero to Bitcoin Payment Service
       url: https://xmr.to
-    - name: algoStrategic - Internet Marketing and Web Development
-      url: https://algostrategic.com
     - name: Emmanuel Galang, Canada Immigration and Refugee Lawyer
       url: https://galanglaw.com/
     - name: Web Developer - Python with Django web framework
@@ -131,7 +133,13 @@
     - name: FlokiNET
       url: https://flokinet.is
     - name: Nerdzy Lawn Care
-      url: http://www.nerdzy.net
+      url: http://www.nerdzy.net/index.php/lawn-care/
+    - name: Njalla - privacy-aware domain registration
+      url: https://njal.la/
+    - name: Elise Hawkins Nutritional Therapy  
+      url: http://www.elisehawkinsnutritionaltherapy.com
+    - name: Koddos - hosting and DDoS protection services
+      url: http://koddos.net
 - category: Goods
   merchants:
     - name: CryptoMercado - coffee and snacks
@@ -156,6 +164,16 @@
       url: https://synntechgaming.com
     - name: Elise Hawkins Nutritional Therapy  
       url: www.elisehawkinsnutritionaltherapy.com
+    - name: SilverRound.com - Gold and Silver Dealer
+      url: https://silverround.com/
+    - name: Bitgild - Gold and Silver
+      url: http://www.bitgild.com
+    - name: Ivan Multimedia Productions
+      url: http://ivanmultimediaproductions.webs.com
+    - name: Celestion Shop
+      url: https://www.celestionshop.com/
+    - name: Molecule Store
+      url: https://moleculestore.com
 - category: Entertainment
   merchants:
     - name: MoneroDice
@@ -163,4 +181,4 @@
     - name: SafeDice
       url: https://safedice.com
     - name: Crypto Games
-      url: https://www.crypto-games.net/
+      url: https://www.crypto-games.net/
\ No newline at end of file

_data/team.yml

@@ -46,7 +46,7 @@
   member:  
     - name: dEBRUYNE
       url:
-    - name: SamsungGalaxyPlayer
+    - name: Justin Ehrenhofer
       url:
     - name: gingeropolous
       url:
@@ -61,4 +61,4 @@
     - name: Brandon Goodell (Surae Noether)
       url:
     - name: Sarang Noether
-      url:
\ No newline at end of file
+      url:

_includes/header.html

@@ -60,6 +60,7 @@
                             <a href="/resources/moneropedia/">Moneropedia</a>
                             <a href="/resources/user-guides/">User Guides</a>
                             <a href="/resources/developer-guides/">Developer Guides</a>
+                            <a href="/resources/vrp/">Vulnerability Response</a>
                           </div>
                      </div>
                  </div>
@@ -147,6 +148,7 @@
                             <a href="/resources/moneropedia/">Moneropedia</a>
                             <a href="/resources/user-guides/">User Guides</a>
                             <a href="/resources/developer-guides/">Developer Guides</a>
+                            <a href="/resources/vrp/">Vulnerability Response</a>
                           </div>
                     </div>
                   </div>

_posts/2017-05-17-disclosure-of-a-major-bug-in-cryptonote-based-currencies.md

@@ -47,3 +47,60 @@ Identity element = "010000000000000000000000000000000000000000000000000000000000
 Curve order (little endian) = "edd3f55c1a631258d69cf7a2def9de1400000000000000000000000000000010"
 
 For each transaction key image, check ((key image * curve order) == (identity element)); reject transaction if false.
+
+### Appendix: Commitment Text \#1
+
+As committed via the payment ID in Monero transaction ID dff7a79e44f9392e19fe5205c389d3e799f89c62d90d624219618d754b806e04, the text below has a sha3-256 (ie. keccak-256) hash of 21f0216fbbdc3dc590903b579282878705ed2adab7d8213328d962c76e806d84:
+
+~~~
+Problem:
+The so-called "key image" as used in Cryptonote coins utilizing elliptic curve ed25519 can be modified in a special way, allowing double-spends. I leave out exact details in this draft to give some time for mitigation.
+
+Hash (keccak-256) of details, to be released later: <4402e902f1ac8cec96a17453dcae307d21a7995a94b76e9c3eb7ca7baeffb8c8> 
+
+
+Mitigation:
+Several options exist for mitigation; I include the simplest, least invasive here.
+
+To mitigate, check key images for correctness by multiplying by the curve order l. Check that the result is the identity element.
+
+I include hexadecimal values of each:
+Identity element = "0100000000000000000000000000000000000000000000000000000000000000"
+Curve order (little endian) = "edd3f55c1a631258d69cf7a2def9de1400000000000000000000000000000010"
+
+For each transaction key image, check ((key image * curve order) == (identity element)); reject transaction if false.
+~~~
+
+### Appendix: Commitment Text \#2
+
+As noted in the previous commitment, the text below has a sha3-256 (ie. keccak-256) hash of 4402e902f1ac8cec96a17453dcae307d21a7995a94b76e9c3eb7ca7baeffb8c8:
+
+~~~
+Dirty Details:
+Adding one of the (non-idenitity) "torsion", or small subgroup, points to a key image allows up to 7 double spends to be performed per output (8 total spends). The reason this is possible is that multiplying any of these small subgroup
+points by 8 returns the identity element (a kind of zero point). This means that multiplying the sum of a "normal" point and a torsion point by 8 (or a multiple of 8) will return the same point as multiplying the normal point by 8;
+the small subgroup point is "factored out". This allows a signature to verify on an alternate key image *so long as* the relevant scalars are multiples of 8. Cryptonote does not use scalars that are automatically multiples of 8 (whereas
+vanilla EdDSA does), but this is only a slight hurdle. An attacker need only choose the relevant scalars to be a multiple of 8 (in certain cases he cannot choose, and must instead create trial scalars until getting the desired result).
+
+Alternate mitigations:
+1. Multiply each key image by 8, then the result by 8^-1 (mod l), to get the proper key image in the correct subgroup. Reject double spends, or if the result is not the same as the input. Unwieldy.
+2. Mutliply each key image by 8 before storing in the key image list/checking for double spends. Quite invasive, as it requires redoing the existing key image list.
+
+
+Extra details:
+Monero's (and all CryptoNote coins') elliptic curve, ed25519, has a basepoint group cofactor of 8. There are 8 subgroups in ed25519, of the following sizes:
+1 ----|
+2     | --- small subgroups
+4     |
+8 ----|
+l (basepoint subgroup) ---|
+2*l                       | --- large subgroups
+4*l                       |
+8*l (all curve points) ---|
+
+Each small subgroup point is contained in the next larger small subgroup, and also in the corresponding large subgroup (superimpose small/large). Each large subgroup is contained in the next larger one as well. The only small subgroup
+point contained in subgroup 1 and l (basepoint subgroup) is the identity element, which works as a kind of zero (no effect on point addition). Mutliplying any point by its subgroup order will return the idenitity element (same as multiplying
+by 0). Mutliplying any point by 2, 4, or 8 will move it to the corresponding most exclusive subgroup (e.g., a point in 8*l subgroup multiplied by 4 would move to the 2*l subgroup, a point in the 8 subgroup multiplied by 2 would move the 4
+subgroup, and so on). Adding a small subgroup (non idenitity) point to a key image in the basepoint subgroup "knocks" it out of that subgroup and into one of the larger ones. Since the order of that subgroup is not l but some multiple,
+multiplying as in the proposed mitigation above does not return the identity element.
+~~~
\ No newline at end of file

_posts/2017-07-09-logs-for-the-Kovri-dev-meeting-held-on-2017-07-09.md

+---
+layout: post
+title: Logs for the Kovri Dev Meeting Held on 2017-07-09
+summary: Brief review of what has been completed since last meeting, discussion of meta issues, and code & open tickets discussion
+tags: [dev diaries, i2p, crypto]
+author: dEBRUYNE / fluffypony
+---
+
+*July 9th, 2017*  
+
+# Logs  
+
+**\<anonimal>** 1. Greetings  
+**\<anonimal>** 2. Brief review of what's been completed since the previous meeting  
+**\<anonimal>** 3. Contributor FFS check-in / status  
+**\<anonimal>** 4. Open Meta issue review https://github.com/monero-project/meta/issues  
+**\<anonimal>** 5. Code + ticket discussion / Q & A  
+**\<anonimal>** 6. Any additional meeting items  
+**\<anonimal>** 7. Confirm next meeting date/time  
+**\<anonimal>** Hello! :)  
+**\<MoroccanMalinois>** hi  
+**\<rehrar>** Yo  
+**\<ArticMine>** hi  
+**\<anonimal>** Hi MoroccanMalinois rehrar ArticMine  
+**\<anonimal>** fluffypony too?  
+**\<i2p-relay> {-fluffypony}** yes  
+**\<anonimal>** Hi fluffypony  
+**\<anonimal>** 2. Brief review of what's been completed since the previous meeting  
+**\<anonimal>** On my end: testnet development and related collab with MoroccanMalinois and lazygravy + SSU/Ident collab/PR review with MoroccanMalinois (and related research/development), rehrar collab for his site related work, some collab with serhack/ericcion Italian translations for kovri-site, email + PR collab + R&D with rbrunner on the windows InnoSetup installers, Monero project work (monero svn to git for  
+**\<anonimal>** unbound), work with pigeons on setting up kovri.i2p (now online!), answer various IRC/reddit Q&A + related collab.  
+**\<rehrar>** This past week was launching the Monero website. Now that's basically done.  
+**\<anonimal>** Some various things here and there, I2P/Tor family node research and more.  
+**\<anonimal>** Some French + Russian kovri-site translations are in the works, they are in the PR pit.  
+**\<anonimal>** Same with kovri repo, I have yet to review the new MM PR's.  
+**\<anonimal>** Did we miss anything else?  
+**\<anonimal>** 3. Contributor FFS check-in / status  
+**\<anonimal>** I'm here, checked-in! MoroccanMalinois is here. Yay!  
+**\<MoroccanMalinois>** i will be ok with a milestone in next meeting if last PR's get merged :)  
+**\<anonimal>** Excellent, I'm sure they will.  
+**\<anonimal>** re: FFS check-in, MoroccanMalinois is doing great. I can't review myself, anyone else on point 3.?  
+**\<anonimal>** Well, I *can* review myself, but that wouldn't be fair now would it? ;)  
+**\<MoroccanMalinois>** lol  
+**\<i2p-relay> {-fluffypony}** lol  
+**\<i2p-relay> {-fluffypony}** leave it to the community to review  
+**\<anonimal>** With the exception of this intermittent week, point 2 shows that I've been active and busy, that I can say the least.  
+**\<anonimal>** Alright, moving on. 4. Open Meta issue review https://github.com/monero-project/meta/issues  
+**\<anonimal>** Starting from the top down, #80  
+**\<anonimal>** rehrar, any news on that front?  
+**\<anonimal>** #77 and #78, fluffypony what do you think?  
+**\<i2p-relay> {-fluffypony}** checking  
+**\<rehrar>** Sorry. Afk 2 min  
+**\<i2p-relay> {-fluffypony}** what's a topic  
+**\<i2p-relay> {-fluffypony}** lol  
+**\<i2p-relay> {-fluffypony}** anonimal: won't web hooks for -site and -docs be too distracting?  
+**\<rehrar>** This week is all Kovri for me.  
+**\<rehrar>** I'll be writing the brief tomorrow and presenting it  
+**\<anonimal>** fluffypony: well, not for me: it would be helpful because of the sometimes very large notification lists I get in github.  
+**\<rehrar>** I'll also be importing the tech from the new Monero website to Kovri. That which is applicable.  
+**\<anonimal>** Awesome rehrar  
+**\<anonimal>** fluffypony: is it too much?  
+**\<i2p-relay> {-fluffypony}** I don't mind activating it, it's your call :)  
+**\<anonimal>** Can we give it a trial run?  
+**\<anonimal>** (e.g., do it until too many people complain)  
+**\<serhack>** Hey anonimal  
+**\<serhack>** How are you?  
+**\<anonimal>** fluffypony: re: topics, quick link https://help.github.com/articles/classifying-your-repository-with-topics/  
+**\<anonimal>** Hi serhack  
+**\<i2p-relay> {-fluffypony}** tks  
+**\<anonimal>** serhack: sono stanco, ma we can chat more after the meeting  
+**\<ArticMine>** On 4 there is Project licensing #85 impacts kovri  
+**\<serhack>** Oh okay  
+**\<ArticMine>** Was opened to get feedback  
+**\<rehrar>** Kovri doesn't have to have the same license as Monero, right?  
+**\<anonimal>** ArticMine: I took a quick look at that earlier this week, will look again now.  
+**\<i2p-relay> {-fluffypony}** rehrar not necessarily, but might be better if we did  
+**\<moneromooo>** kovri's library part will be used by monero at some point.  
+**\<i2p-relay> {-fluffypony}** I don't see a reason to have different licenses  
+**\<anonimal>** BSD-3, yes I believe so.  
+**\<anonimal>** re: licensing, no matter what, we'd need to adhere to the licenses of all bundled dependencies, right?  
+**\<ArticMine>** Yes  
+**\<ArticMine>** That is part of the issue in 85  
+**\<ArticMine>** I2P is effectively GPL v2  
+**\<moneromooo>** "I2P" ? The Java router ?  
+**\<ArticMine>** Yes java  
+**\<anonimal>** Huh? Java I2P?  
+**\<ArticMine>** java makes I2P GPL v2  
+**\<anonimal>** I don't see how that applies to us as we're not using any of their code.  
+**\<anonimal>** And most of the important bits are "free (adj.): unencumbered; not under the control of others", whichever license that equates to.  
+**\<ArticMine>** Not directly to kovri  
+**\<anonimal>** Open specification is different than implementation in terms of licensing, right?  
+**\<ArticMine>** but that is why 5 was opened to deal with this discussion  
+**\<ArticMine>** 85  
+**\<anonimal>** If monero goes dual-license, then we must?  
+**\<ArticMine>** Not necessarily  
+**\<anonimal>** Ok. I'll need more thought on this. I can add to the next agenda too. Does anyone have any strong feelings on this now?  
+**\<ArticMine>** I think it is best if we discuss it on Github under 85  
+**\<ArticMine>** Then we can look at it in the next meeting  
+**\<rehrar>** I have strong feelings to go proprietary.  
+**\<moneromooo>** er, we would not do that.  
+**\<rehrar>** But aside from that let's move on.  
+**\<rehrar>** I kid.  
+**\<anonimal>** ArticMine: ok.  
+**\<anonimal>** re: #63, rehrar did you figure out your git branching issue?  
+**\<rehrar>** Web launch took priority.  
+**\<rehrar>** We've been feverishly working on it and it is done for now. I've been reading into branches yes.  
+**\<rehrar>** Sorry, also headed to Mexico atm. :/ So my replies will be intermittent.  
+**\<rehrar>** Should be resolved in the next two days.  
+**\<anonimal>** I haven't made any new contributions to it yet so I don't think it's done for now ;)  
+**\<rehrar>** No, I meant the website