Update HTTP->HTTPS when both URLs work

EIPS/eip-1.md

@@ -55,7 +55,7 @@ Each status change is requested by the EIP author and reviewed by the EIP editor
 * **Draft** -- Once the first draft has been merged, you may submit follow-up pull requests with further changes to your draft until such point as you believe the EIP to be mature and ready to proceed to the next status. An EIP in draft status must be implemented to be considered for promotion to the next status (ignore this requirement for core EIPs).
   * :arrow_right: Last Call -- If agreeable, the EIP editor will assign Last Call status and set a review end date (`review-period-end`), normally 14 days later.
   * :x: Last Call -- A request for Last Call status will be denied if material changes are still expected to be made to the draft. We hope that EIPs only enter Last Call once, so as to avoid unnecessary noise on the RSS feed.
-* **Last Call** -- This EIP will listed prominently on the http://eips.ethereum.org/ website (subscribe via RSS at [last-call.xml](/last-call.xml)).
+* **Last Call** -- This EIP will listed prominently on the https://eips.ethereum.org/ website (subscribe via RSS at [last-call.xml](/last-call.xml)).
   * :x: -- A Last Call which results in material changes or substantial unaddressed technical complaints will cause the EIP to revert to Draft.
   * :arrow_right: Accepted (Core EIPs only) -- A successful Last Call without material changes or unaddressed technical complaints will become Accepted.
   * :arrow_right: Final (Not core EIPs) -- A successful Last Call without material changes or unaddressed technical complaints will become Final.
@@ -228,7 +228,7 @@ December 7, 2016: EIP 1 has been improved and will be placed as a PR.
 
 February 1, 2016: EIP 1 has added editors, made draft improvements to process, and has merged with Master stream.
 
-March 21, 2018: Minor edits to accommodate the new automatically-generated EIP directory on [eips.ethereum.org](http://eips.ethereum.org/).
+March 21, 2018: Minor edits to accommodate the new automatically-generated EIP directory on [eips.ethereum.org](https://eips.ethereum.org/).
 
 May 29, 2018: A last call process was added.
 

EIPS/eip-1015.md

@@ -28,16 +28,16 @@ Moving to PoS has been on the roadmap since day 0 for ethereum, along with a red
 
 #### Asics and advantadges of PoW
 
-[EIP 960](http://eips.ethereum.org/EIPS/eip-969) proposes a change in algorithm to avoid mining being dominated by ASICS. Counter arguments by Phil Daian argue among others than [resisting economies of scale is futile and there might be specific security advantadges to specialized hardware](https://pdaian.com/blog/anti-asic-forks-considered-harmful/). One of the main arguments for PoW mining, even when it doesn't provide security, it is useful as a fair distribution mechanism, that **PoW allows any person with a computer, internet access and electricity to obtain currency without having to deal with government imposed currency controls**.
+[EIP 960](https://eips.ethereum.org/EIPS/eip-969) proposes a change in algorithm to avoid mining being dominated by ASICS. Counter arguments by Phil Daian argue among others than [resisting economies of scale is futile and there might be specific security advantadges to specialized hardware](https://pdaian.com/blog/anti-asic-forks-considered-harmful/). One of the main arguments for PoW mining, even when it doesn't provide security, it is useful as a fair distribution mechanism, that **PoW allows any person with a computer, internet access and electricity to obtain currency without having to deal with government imposed currency controls**.
 
 #### Recovery Forks
 
-After the Parity Multisig library self destruction, three different strategies have been attempted to recover the funds: [a general protocol improvement to allow reviving self destructed contracts](https://gist.github.com/5chdn/a9bb8617cc8523a030126a3d1c60baf3) (which was considered dangerous), a [general process to recover funds](https://github.com/ethereum/EIPs/pull/867) and a [specific recovery of the multisig library](http://eips.ethereum.org/EIPS/eip-999). The latter two are finding a lot of resistance from the community, but it's unlikely that these issues are going away soon. The affected parties have a large incentive (fluctuating at almost half a billion dollars) to keep trying, and it's an issue that is likely to occur again in the future. If they get reimbursed, [there are many other special cases of ether provably burnt or stuck](https://github.com/ethereum/EIPs/issues/156) that might deserve the same treatment. If they get shut down, they have an incentive to move forward a fork implementation: even if they are a minority chain, it's likely they'll recover an amount larger than 0, which is what they would otherwise, and it means the main ethereum community might lose a valuable team of developers. 
+After the Parity Multisig library self destruction, three different strategies have been attempted to recover the funds: [a general protocol improvement to allow reviving self destructed contracts](https://gist.github.com/5chdn/a9bb8617cc8523a030126a3d1c60baf3) (which was considered dangerous), a [general process to recover funds](https://github.com/ethereum/EIPs/pull/867) and a [specific recovery of the multisig library](https://eips.ethereum.org/EIPS/eip-999). The latter two are finding a lot of resistance from the community, but it's unlikely that these issues are going away soon. The affected parties have a large incentive (fluctuating at almost half a billion dollars) to keep trying, and it's an issue that is likely to occur again in the future. If they get reimbursed, [there are many other special cases of ether provably burnt or stuck](https://github.com/ethereum/EIPs/issues/156) that might deserve the same treatment. If they get shut down, they have an incentive to move forward a fork implementation: even if they are a minority chain, it's likely they'll recover an amount larger than 0, which is what they would otherwise, and it means the main ethereum community might lose a valuable team of developers. 
 
 
 #### Other Public Goods
 
-There are many other types of public goods that could be funded by issuance. By *Public Good*, I'm using a strict definition of something that brings value to everyone, both those who funded it and free-loaders, making it hard to fund it exclusively by traditional private incentives. They can be research, whole network security, [incentivize full clients and networking](http://eips.ethereum.org/EIPS/eip-908), fair distribution of tokens etc.
+There are many other types of public goods that could be funded by issuance. By *Public Good*, I'm using a strict definition of something that brings value to everyone, both those who funded it and free-loaders, making it hard to fund it exclusively by traditional private incentives. They can be research, whole network security, [incentivize full clients and networking](https://eips.ethereum.org/EIPS/eip-908), fair distribution of tokens etc.
 
 ## Proposed Solution
 ### Issuance Contract

EIPS/eip-1066.md

@@ -46,7 +46,7 @@ At time of writing, other than stepping through EVM execution and inspecting mem
 
 Having a fixed set of codes also makes it possible to write common helper functions to react in common ways to certain signals. This can live off- or on-chain library, lowering the overhead in building smart contracts, and helping raise code quality with trusted shared components.
 
-We also see a desire for this [in transactions](http://eips.ethereum.org/EIPS/eip-658), and there's no reason that these status codes couldn't be used by the EVM itself.
+We also see a desire for this [in transactions](https://eips.ethereum.org/EIPS/eip-658), and there's no reason that these status codes couldn't be used by the EVM itself.
 
 ### Smart Contract Autonomy
 

EIPS/eip-1123.md

@@ -77,7 +77,7 @@ contracts.
 > **Note**
 >
 > A [hosted
-> version](http://ethpm.github.io/ethpm-spec) of this
+> version](https://ethpm.github.io/ethpm-spec) of this
 > specification is available via GitHub Pages. This EIP and the hosted
 > HTML document were both autogenerated from the same documentation
 > source.
@@ -174,7 +174,7 @@ name collisions with future versions of the specification.
 <tbody>
 <tr class="odd">
 <td><p>See Also</p></td>
-<td><p>Formalized (<a href="http://json-schema.org">JSON-Schema</a>) version of this specification: <a href="https://github.com/ethpm/ethpm-spec/tree/v2.0.0/spec/package.spec.json">package.spec.json</a></p></td>
+<td><p>Formalized (<a href="https://json-schema.org">JSON-Schema</a>) version of this specification: <a href="https://github.com/ethpm/ethpm-spec/tree/v2.0.0/spec/package.spec.json">package.spec.json</a></p></td>
 </tr>
 <tr class="even">
 <td><p>Jump To</p></td>
@@ -286,7 +286,7 @@ be included in all Packages.
 
 The `version` field declares the version number of this release. This
 value **must** be included in all Packages. This value **should**
-conform to the [semver](http://semver.org/) version
+conform to the [semver](https://semver.org/) version
 numbering specification.
 
 <table>
@@ -1404,7 +1404,7 @@ The `name` field defines which compiler was used in compilation.
 The `version` field defines the version of the compiler. The field
 **should** be OS agnostic (OS not included in the string) and take the
 form of either the stable version in
-[semver](http://semver.org/) format or if built on a
+[semver](https://semver.org/) format or if built on a
 nightly should be denoted in the form of `<semver>-<commit-hash>` ex:
 `0.4.8-commit.60cc1668`.
 
@@ -1435,7 +1435,7 @@ nightly should be denoted in the form of `<semver>-<commit-hash>` ex:
 The `settings` field defines any settings or configuration that was used
 in compilation. For the `"solc"` compiler, this **should** conform to
 the [Compiler Input and Output
-Description](http://solidity.readthedocs.io/en/latest/using-the-compiler.html#compiler-input-and-output-json-description).
+Description](https://solidity.readthedocs.io/en/latest/using-the-compiler.html#compiler-input-and-output-json-description).
 
 <table>
 <colgroup>
@@ -1848,7 +1848,7 @@ a supporting implementation.
 
 -   [Truffle](http://trufflesuite.com/)
 
--   [Populus](http://populus.readthedocs.io/en/latest/)
+-   [Populus](https://populus.readthedocs.io/en/latest/)
 
 -   [Embark](https://embark.status.im/)
 

EIPS/eip-1155.md

@@ -391,7 +391,7 @@ balanceOf(baseToken + index, msg.sender); // Get balance of the Non-Fungible tok
 - [ERC-721 Non-Fungible Token Standard](https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-721.md)
 - [ERC-165 Standard Interface Detection](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md)
 - [ERC-1538 Transparent Contract Standard](https://github.com/ethereum/EIPs/issues/1538)
-- [JSON Schema](http://json-schema.org/)
+- [JSON Schema](https://json-schema.org/)
 - [RFC 2119 Key words for use in RFCs to Indicate Requirement Levels](https://www.ietf.org/rfc/rfc2119.txt)
 
 **Implementations**

EIPS/eip-1261.md

@@ -365,7 +365,7 @@ Membership Verification Token ERC1261 -- a reference implementation
 1. ERC-165 Standard Interface Detection. https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md
 1. ERC-725/735 Claim Registry https://github.com/ethereum/EIPs/blob/master/EIPS/eip-725.md
 1. ERC-173 Owned Standard. https://github.com/ethereum/EIPs/issues/173
-1. JSON Schema. http://json-schema.org/
+1. JSON Schema. https://json-schema.org/
 1. Multiaddr. https://github.com/multiformats/multiaddr
 1. RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. https://www.ietf.org/rfc/rfc2119.txt
 

EIPS/eip-1328.md

@@ -48,7 +48,7 @@ The need for this ERC stems from the discussion to move away from JSON format us
 
 ## References
 
-1.  ERC-831, http://eips.ethereum.org/EIPS/eip-831
+1.  ERC-831, https://eips.ethereum.org/EIPS/eip-831
 
 ## Copyright
 

EIPS/eip-137.md

@@ -70,10 +70,10 @@ Because the `namehash` procedure depends only on the name itself, this can be pr
 ENS names must conform to the following syntax:
 
 <pre>&lt;domain> ::= &lt;label> | &lt;domain> "." &lt;label>
-&lt;label> ::= any valid string label per [UTS46](http://unicode.org/reports/tr46/)
+&lt;label> ::= any valid string label per [UTS46](https://unicode.org/reports/tr46/)
 </pre>
 
-In short, names consist of a series of dot-separated labels. Each label must be a valid normalised label as described in [UTS46](http://unicode.org/reports/tr46/) with the options `transitional=false` and `useSTD3AsciiRules=true`. For Javascript implementations, a [library](https://www.npmjs.com/package/idna-uts46) is available that normalises and checks names.
+In short, names consist of a series of dot-separated labels. Each label must be a valid normalised label as described in [UTS46](https://unicode.org/reports/tr46/) with the options `transitional=false` and `useSTD3AsciiRules=true`. For Javascript implementations, a [library](https://www.npmjs.com/package/idna-uts46) is available that normalises and checks names.
 
 Note that while upper and lower case letters are allowed in names, the UTS46 normalisation process case-folds labels before hashing them, so two names with different case but identical spelling will produce the same namehash.
 

EIPS/eip-1444.md

@@ -106,7 +106,7 @@ function textFor(bytes32 _code) external view returns (bool _wasFound, string _t
 
 ### String Format
 
-All strings MUST be encoded as [UTF-8](http://www.ietf.org/rfc/rfc3629.txt).
+All strings MUST be encoded as [UTF-8](https://www.ietf.org/rfc/rfc3629.txt).
 
 ```solidity
 "Špeĉiäl chârãçtérs are permitted"
@@ -117,7 +117,7 @@ All strings MUST be encoded as [UTF-8](http://www.ietf.org/rfc/rfc3629.txt).
 
 ### Templates
 
-Template strings are allowed, and MUST follow the [ANSI C `printf`](http://pubs.opengroup.org/onlinepubs/009696799/utilities/printf.html) conventions.
+Template strings are allowed, and MUST follow the [ANSI C `printf`](https://pubs.opengroup.org/onlinepubs/009696799/utilities/printf.html) conventions.
 
 ```solidity
 "Satoshi's true identity is %s"
@@ -155,7 +155,7 @@ A very viable alternative is to store text off chain, with a pointer to the tran
 
 UTF-8 is the most widely used encoding at time of writing. It contains a direct embedding of ASCII, while providing characters for most natural languages, emoji, and special characters.
 
-Please see the [UTF-8 Everywhere Manifesto](http://utf8everywhere.org/) for more information.
+Please see the [UTF-8 Everywhere Manifesto](https://utf8everywhere.org/) for more information.
 
 ### When No Text is Found
 

EIPS/eip-1613.md

@@ -88,7 +88,7 @@ Glossary of terms used in the processes below:
 * `Sender` - an external address with a valid keypair but no ETH to pay for gas.
 * `Relay` - a node holding ETH in an external address, listed in RelayHub and relaying transactions from Senders to RelayHub for a fee.
 
-![Sequence Diagram](http://bit.ly/2EWWVN8)
+![Sequence Diagram](https://bit.ly/2EWWVN8)
 
 The process of registering/refreshing a `Relay`:
 

EIPS/eip-162.md

@@ -226,7 +226,7 @@ A slower release allows for extra time to identify, and address any issues which
 
 Choosing a single TLD helps to maximize network effects by focusing on one namespace.
 
-A three letter TLD is a pattern made familiar by it's common usage in internet domain names. This familiarity significantly increases the potential of the ENS to be integrated into pre-existing DNS systems, and reserved as a [special-use domain name](http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml#special-use-domain).  A recent precedent for this is the [reservation of the `.onion` domain](https://tools.ietf.org/html/rfc7686).
+A three letter TLD is a pattern made familiar by it's common usage in internet domain names. This familiarity significantly increases the potential of the ENS to be integrated into pre-existing DNS systems, and reserved as a [special-use domain name](https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml#special-use-domain).  A recent precedent for this is the [reservation of the `.onion` domain](https://tools.ietf.org/html/rfc7686).
 
 ### Holding ether as collateral
 

EIPS/eip-165.md

@@ -29,7 +29,7 @@ For some "standard interfaces" like [the ERC-20 token interface](https://github.
 
 ### How Interfaces are Identified
 
-For this standard, an *interface* is a set of [function selectors as defined by the Ethereum ABI](http://solidity.readthedocs.io/en/develop/abi-spec.html#function-selector). This a subset of [Solidity's concept of interfaces](http://solidity.readthedocs.io/en/develop/abi-spec.html) and the  `interface` keyword definition which also defines return types, mutability and events.
+For this standard, an *interface* is a set of [function selectors as defined by the Ethereum ABI](https://solidity.readthedocs.io/en/develop/abi-spec.html#function-selector). This a subset of [Solidity's concept of interfaces](https://solidity.readthedocs.io/en/develop/abi-spec.html) and the  `interface` keyword definition which also defines return types, mutability and events.
 
 We define the interface identifier as the XOR of all function selectors in the interface. This code example shows how to calculate an interface identifier:
 

EIPS/eip-190.md

@@ -88,9 +88,9 @@ Allows for packages which exclude source code or other elements which would be n
 
 Support for ERC190 is either implemented or in progress for the following:
 
-* [Truffle](http://truffleframework.com/)
-* [Populus](http://populus.readthedocs.io/en/latest/)
-* [Dapple](http://dapple.readthedocs.io/en/master/)
+* [Truffle](https://truffleframework.com/)
+* [Populus](https://populus.readthedocs.io/en/latest/)
+* [Dapple](https://dapple.readthedocs.io/en/master/)
 * [Eris PM](https://github.com/eris-ltd/eris-cli)
 * [Embark](https://github.com/iurimatias/embark-framework)
 * [Browser Solidity](https://github.com/ethereum/remix-ide/issues/386)