fix blog post links

Author: redsh4de

src/content/blog/en/2017-12-11-A-note-on-fees.md

@@ -15,7 +15,7 @@ Let's start by comparing Monero's per kB fees to the per kB fees of other (hybri
 - **Dash:** ~$0.07
 - **Monero:** ~$0.24
 
-As you can see, the per kB fee of Monero is fairly low. However, due to the high transaction size, the absolute default fee (in $ terms) is quite high. Note that the transaction size is this big due to Monero's inherent default privacy, i.e., the range proofs, which mask the amount values, make up ~12 kB of a single transaction. RingCT, however, was absolutely necessary to strengthen the privacy of the network. More specifically, there were a lot of privacy "leaks" when Monero didn't mask amounts yet. Fortunately, [Bulletproofs](/2017/12/07/Monero-Compatible-Bulletproofs.html) will reduce transaction sizes by at least 80%.
+As you can see, the per kB fee of Monero is fairly low. However, due to the high transaction size, the absolute default fee (in $ terms) is quite high. Note that the transaction size is this big due to Monero's inherent default privacy, i.e., the range proofs, which mask the amount values, make up ~12 kB of a single transaction. RingCT, however, was absolutely necessary to strengthen the privacy of the network. More specifically, there were a lot of privacy "leaks" when Monero didn't mask amounts yet. Fortunately, [Bulletproofs](/blog/2017/12/07/Monero-Compatible-Bulletproofs/) will reduce transaction sizes by at least 80%.
 
 ---
 
@@ -115,7 +115,7 @@ In conclusion, whilst fees are currently too high, they, most likely, won't be a
 
 2. A more in depth analysis (by ArticMine) of the penalty function can be found [here](https://bitcointalk.org/index.php?topic=753252.msg13591241#msg13591241).
 
-3. The penalty function in the original [CryptoNote whitepaper](cryptonote.org/whitepaper.pdf) is somewhat different. More information can be found [here](https://monero.stackexchange.com/questions/1067/block-reward-penalties-and-dynamic-block-size).
+3. The penalty function in the original [CryptoNote whitepaper](https://cryptonote.org/whitepaper.pdf) is somewhat different. More information can be found [here](https://monero.stackexchange.com/questions/1067/block-reward-penalties-and-dynamic-block-size).
 
 4. Code details and the actual implementation of the dynamic block size algorithm can be found [here](https://github.com/monero-project/monero/blob/master/src/cryptonote_basic/cryptonote_basic_impl.cpp).
 

src/content/blog/en/2018-03-29-response-to-an-empirical-analysis-of-traceability.md

@@ -7,7 +7,7 @@ author: Justin Ehrenhofer (SamsungGalaxyPlayer, sgp)
 
 ### Preface
 
-On March 17, 2018, several researchers published the [second version](https://arxiv.org/pdf/1704.04299.pdf) of "An Empirical Analysis of Traceability in the Monero Blockchain." I previously authored a response to the [initial version](https://arxiv.org/pdf/1704.04299v1.pdf) with the help of many other community members [here](/2017/04/19/an-unofficial-response-to-an-empirical-analysis-of-linkability.html). The researchers have changed the paper in a significant enough way that it warrants a separate response.
+On March 17, 2018, several researchers published the [second version](https://arxiv.org/pdf/1704.04299.pdf) of "An Empirical Analysis of Traceability in the Monero Blockchain." I previously authored a response to the [initial version](https://arxiv.org/pdf/1704.04299v1.pdf) with the help of many other community members [here](/blog/2017/04/19/an-unofficial-response-to-an-empirical-analysis-of-linkability/). The researchers have changed the paper in a significant enough way that it warrants a separate response.
 
 The Monero contributors and community at large always appreciate research done on Monero's technology. They heavily encourage constructive criticism of all cryptocurrencies. The Monero project recommends future research into several findings of the paper, which are mentioned later in this post.
 
@@ -29,7 +29,7 @@ This research paper includes several findings, some of which are completely new,
 
 5. In September 2017, RingCT was made mandatory for all transactions.
 
-6. The paper looked into the impact of mining activity as recommended in the [previous response](/2017/04/19/an-unofficial-response-to-an-empirical-analysis-of-linkability.html). Figure 8 shows the proportion of network hashrate associated for specific pools with transparent mined blocks and payouts. This proportion peaked around 40% in April 2017, with most periods below 30%. Figure 9 shows the proportion of pool-related transactions was approximately 95% through all of 2015, and it was approximately 30% in April 2017. The proportion is likely too insignificant to make a meaningful impact on most transactions after January 2017. More importantly, however, the paper looked at the proportion of transactions, not the proportion of visible outputs, meaning any comparison is indirect. However, it is possible that transactions made during several days of low transaction volume until September 2017 could reach a meaningful threshold. The potential risk was further mitigated in September when the minimum ringsize was increased to 5.
+6. The paper looked into the impact of mining activity as recommended in the [previous response](/blog/2017/04/19/an-unofficial-response-to-an-empirical-analysis-of-linkability/). Figure 8 shows the proportion of network hashrate associated for specific pools with transparent mined blocks and payouts. This proportion peaked around 40% in April 2017, with most periods below 30%. Figure 9 shows the proportion of pool-related transactions was approximately 95% through all of 2015, and it was approximately 30% in April 2017. The proportion is likely too insignificant to make a meaningful impact on most transactions after January 2017. More importantly, however, the paper looked at the proportion of transactions, not the proportion of visible outputs, meaning any comparison is indirect. However, it is possible that transactions made during several days of low transaction volume until September 2017 could reach a meaningful threshold. The potential risk was further mitigated in September when the minimum ringsize was increased to 5.
 
 7. The paper set a bound for daily Monero transaction volume on AlphaBay between $0 and $60,000 in early 2017, with a maximum of up to 10% of all AlphaBay transaction volume and up to 25% of all Monero transaction volume. AlphaBay was a darknet website that accepted Bitcoin and Monero before it was seized and shut down in July 2017. The Monero project condemns illicit use of Monero.
 

src/content/blog/en/2018-09-26-Introducing-the-Monero-Malware-Response-Workgroup-Website.md

@@ -8,7 +8,7 @@ Monero is a powerful tool that prioritizes privacy, security, decentralization,
 
 While the clear majority of users take advantage of these features for good, some attackers use Monero to earn money from machines without users' consent. They may run miners on webpages that activate without a user's consent. They may infect machines or hide it in other packages and run mining software. They may infect machines, encrypt the local files, and demand a ransom payment in Monero.
 
-The Monero community condemns this malicious, non-consensual use of equipment to mine. Unfortunately, the Monero network itself benefits by having a wide set of stakeholders mine, since the network's security is afforded through a distributed set of users. While restricting mining to specialized equipment largely eliminates malicious mining, it doesn't eliminate ransomware, and it introduces security compromises that [the Monero community is not comfortable with](/2018/02/11/PoW-change-and-key-reuse.html). Monero contributors build the best tool possible; they should not make it less secure even if it means the accessible system provides easier access to criminals too. However, the Monero community does not want to sit idly by as victims struggle to understand the impact of mining and ransomware. Most of these victims have no idea what mining and Monero are.
+The Monero community condemns this malicious, non-consensual use of equipment to mine. Unfortunately, the Monero network itself benefits by having a wide set of stakeholders mine, since the network's security is afforded through a distributed set of users. While restricting mining to specialized equipment largely eliminates malicious mining, it doesn't eliminate ransomware, and it introduces security compromises that [the Monero community is not comfortable with](/blog/2018/02/11/PoW-change-and-key-reuse/). Monero contributors build the best tool possible; they should not make it less secure even if it means the accessible system provides easier access to criminals too. However, the Monero community does not want to sit idly by as victims struggle to understand the impact of mining and ransomware. Most of these victims have no idea what mining and Monero are.
 
 [We created a set of resources](https://mrw.getmonero.org) that explain the basics of Monero and mining. We also have resources explaining and helping stop/remove unwanted in-browser mining, system mining, and ransomware. The website is purposefully approachable to absolute newcomers so that anyone can understand, though it offers actionable information that novices and experts alike can follow. It's our mission to resolve an unfortunate situation as well as possible.
 

src/content/blog/en/2018-12-17-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-12-17.md

@@ -233,7 +233,7 @@ author: el00ruobuob / surae
 **\<suraeNoether>** would they be do-able together or would it be one or the other only?  
 **\<kayront>** DLSAG = ?  
 **\<sarang>** You could probably do a separate return subaddress per output address  
-**\<sarang>** MRL-0008: https://ww.getmonero.org/resources/research-lab/  
+**\<sarang>** MRL-0008: https://www.getmonero.org/resources/research-lab/  
 **\<ilyaAldanov>** If you ask me, I came up with many more use cases for return addresses.  
 **\<sarang>** I definitely see the usefulness  
 **\<suraeNoether>** DLSAG = dual-output linkable spontaneous anonymous group signatures  

src/content/blog/en/2019-02-12-2018-year-in-review.md

@@ -10,9 +10,9 @@ author: dEBRUYNE, needmoney90
 
 Despite the tremendous amount of progress the community and protocol experienced, as always, there were inevitable unforseen setbacks. The response to these obstacles is a critical part of any development cycle, as is the disclosure of how they were handled. Here is a short overview of the largest obstacles faced in the development of Monero in 2018:
 
-First, in the beginning of the year, ASICs were detected on the network. The hashrate rose dramatically, until it was estimated that 80-90% of the network was specialized hardware, posing a significant danger to the security of the network. Monero's social covenant includes egalitarian mining, and the community pushed for [a modification to the proof-of-work algorithm](/2018/02/11/PoW-change-and-key-reuse.html) which could not run on the ASIC hardware. The PoW modification was implemented in the scheduled April 2018 protocol upgrade, and successfully managed to boot existing ASICs off the network. A second PoW modification was implemented in the scheduled protocol upgrade of October as a precaution and deterrent.
+First, in the beginning of the year, ASICs were detected on the network. The hashrate rose dramatically, until it was estimated that 80-90% of the network was specialized hardware, posing a significant danger to the security of the network. Monero's social covenant includes egalitarian mining, and the community pushed for [a modification to the proof-of-work algorithm](/blog/2018/02/11/PoW-change-and-key-reuse/) which could not run on the ASIC hardware. The PoW modification was implemented in the scheduled April 2018 protocol upgrade, and successfully managed to boot existing ASICs off the network. A second PoW modification was implemented in the scheduled protocol upgrade of October as a precaution and deterrent.
 
-Second, two critical vulnerabilities were discovered in the client. The [the multiple counting bug](/2018/09/05/a-post-mortum-of-the-multiple-counting-bug-2018-09-05.html) would have allowed an attacker to create a transaction in which the transaction public key was included multiple times, causing the client to erroneously return that more funds were received than were sent. By utilizing this particular bug, an attacker would have been able to steal funds from organizations in the Monero ecosystem. Fortunately, the bug was confined to the accounting functionality of the wallet software, and so the protocol and coin supply were not affected. The [burning bug](https://ww.getmonero.org/2018/09/25/a-post-mortum-of-the-burning-bug.html) caused the software to not display a warning when burned outputs were received, allowing an attacker to burn funds of any recipient who allowed withdrawals following deposits. If exploited, it would have allowed a determined attacker to burn the funds of an organization's wallet, while only costing themselves transaction fees. Similarly to the multiple counting bug, this bug also did not affect the protocol, and would not have allowed an attacker to alter the supply. Both bugs were dealt with swiftly and professionally by the developers, following the [vulnerability response process](https://github.com/monero-project/meta/blob/master/VULNERABILITY_RESPONSE_PROCESS.md). It's imperative, however, that we learn from these events and seek improvements that could significantly mitigate the impact of similar bugs in the future.
+Second, two critical vulnerabilities were discovered in the client. The [the multiple counting bug](/blog/2018/09/05/a-post-mortum-of-the-multiple-counting-bug-2018-09-05/) would have allowed an attacker to create a transaction in which the transaction public key was included multiple times, causing the client to erroneously return that more funds were received than were sent. By utilizing this particular bug, an attacker would have been able to steal funds from organizations in the Monero ecosystem. Fortunately, the bug was confined to the accounting functionality of the wallet software, and so the protocol and coin supply were not affected. The [burning bug](/blog/2018/09/25/a-post-mortum-of-the-burning-bug/) caused the software to not display a warning when burned outputs were received, allowing an attacker to burn funds of any recipient who allowed withdrawals following deposits. If exploited, it would have allowed a determined attacker to burn the funds of an organization's wallet, while only costing themselves transaction fees. Similarly to the multiple counting bug, this bug also did not affect the protocol, and would not have allowed an attacker to alter the supply. Both bugs were dealt with swiftly and professionally by the developers, following the [vulnerability response process](https://github.com/monero-project/meta/blob/master/VULNERABILITY_RESPONSE_PROCESS.md). It's imperative, however, that we learn from these events and seek improvements that could significantly mitigate the impact of similar bugs in the future.
 
 A third obstacle involved Monero forks (such as Monero Original and Monero Classic) retaining the transaction output (TXO) set, jeopardizing the privacy of Monero users. For example, if Alice spends her output on the Monero Classic chain with ring A, B, C, D, E (where A is the real input) and thereafter spends the same output on the Monero chain with ring A, F, G, H, I (where, again, A is the real input), an observer could reasonably infer (by analyzing both chains) that A was the input being spent, i.e., the real input. Now, if another user used Alice's output A as a decoy output, their privacy was weakened, as the output was, due to Alice's behavior, rendered obsolete as decoy. Fortunately, the Monero developers added several mitigations (for example, a user now has an option to reuse their ring), rendering aforementioned analysis mostly obsolete. In addition, the user can utilize a special tool which ensures no provably spent outputs (e.g. Alice's output in previous example) are used as decoy outputs. This significantly reduced the impact of key image reusage, for example, in the event of a Monero user claiming their Monero Classic. Subsequent research by Justin Ehrenhofer confirmed their effectiveness.
 

src/content/blog/en/2019-11-12-monero-0.15-released.md

@@ -8,7 +8,7 @@ image: ../assets/2019-11-12-monero-0.15-released/CarbonChamaeleon.png
 
 ### Overview
 
-This is the **v0.15.0 release of the Monero software**. This major release, announced in an [earlier post](/2019/10/01/announcement-release-0-15.html), is due to the November 30th network upgrade. Users, merchants and exchanges should update to the latest Monero software before that date. The binaries for the GUI wallet are forthcoming, we will make another announcement as soon as they are released.
+This is the **v0.15.0 release of the Monero software**. This major release, announced in an [earlier post](/blog/2019/10/01/announcement-release-0-15/), is due to the November 30th network upgrade. Users, merchants and exchanges should update to the latest Monero software before that date. The binaries for the GUI wallet are forthcoming, we will make another announcement as soon as they are released.
 
 Some of the major changes introduced with this release are:
 
@@ -20,7 +20,7 @@ Some of the major changes introduced with this release are:
 - **Optional Tor/I2P** transaction relay for privacy (block relay being done on clearnet)
 - **New gen_ssl_cert tool** to generate SSL certificates suitable for Monero usage
 - **IPv6** support
-- **Removed Long Payment IDs** (see the [deprecation announcement](/2019/06/04/Long-Payment-ID-Deprecation.html))
+- **Removed Long Payment IDs** (see the [deprecation announcement](/blog/2019/06/04/Long-Payment-ID-Deprecation/))
 
 The complete list of features and changes is on GitHub: [github.com/monero-project/monero/releases/tag/v0.15.0.0](https://github.com/monero-project/monero/releases/tag/v0.15.0.0).
 

src/content/blog/en/2019-11-19-warning-compromised-binaries.md

@@ -9,7 +9,7 @@ Yesterday [a GitHub issue about mismatching hashes coming from this website](htt
 
 It's strongly recommended to anyone who downloaded the CLI wallet from this website between Monday 18th 2:30 AM UTC and 4:30 PM UTC, to check the hashes of their binaries. If they don't match the official ones, delete the files and download them again. <b>Do not run the compromised binaries for any reason</b>.
 
-We have two guides available to help users check the authenticity of their binaries: <a href="{{site.baseurl}}/resources/user-guides/verification-windows-beginner.html">Verify binaries on Windows (beginner)</a> and <a href="{{site.baseurl}}/resources/user-guides/verification-allos-advanced.html">Verify binaries on Linux, Mac, or Windows command line (advanced)</a>. Signed hashes can be found here: https://getmonero.org/downloads/hashes.txt.
+We have two guides available to help users check the authenticity of their binaries: <a href="/resources/user-guides/verification-windows-beginner.html">Verify binaries on Windows (beginner)</a> and <a href="/resources/user-guides/verification-allos-advanced.html">Verify binaries on Linux, Mac, or Windows command line (advanced)</a>. Signed hashes can be found here: https://getmonero.org/downloads/hashes.txt.
 
 The situation is being investigated and updates will be provided soon.
 

src/content/blog/en/2019-11-24-monero-0.15.0.1-GUI-CLI-released.md

@@ -59,7 +59,7 @@ You can also compile it from source by yourself. See the [instructions on GitHub
 
 ## Verify Hashes
 
-If you would like to verify that you have downloaded the correct file, check the following SHA256 hashes using these guides: [Verify binaries on Windows (beginner)]({{site.baseurl}}/resources/user-guides/verification-windows-beginner.html) and [Verify binaries on Linux, Mac, or Windows command line (advanced)]({{site.baseurl}}/resources/user-guides/verification-allos-advanced.html)
+If you would like to verify that you have downloaded the correct file, check the following SHA256 hashes using these guides: [Verify binaries on Windows (beginner)](/resources/user-guides/verification-windows-beginner.html) and [Verify binaries on Linux, Mac, or Windows command line (advanced)](/resources/user-guides/verification-allos-advanced.html)
 
 ### GUI: