Migrate external links to md syntax

content/concepts/complex-payment-types/payment-channels.md

@@ -4,7 +4,7 @@ Payment Channels are an advanced feature for sending "asynchronous" XRP payments
 
 The XRP for a payment channel is set aside for a given time period. The sender creates _Claims_ against the channel, which the recipient verifies without sending an XRP Ledger transaction or waiting for a new ledger version to be approved by [consensus](consensus.html). (This is an _asychronous_ process because it happens separate from the usual pattern of getting transactions approved by consensus.) At any time, the recipient can _redeem_ a Claim to receive an amount of XRP authorized by that Claim. Settling a Claim like this uses a standard XRP Ledger transaction, as part of the usual consensus process. This single transaction can encompass any number of transactions guaranteed by smaller Claims.
 
-Because Claims can be verified individually but settled in bulk later, payment channels make it possible to conduct transactions at a rate only limited by the participants' ability to create and verify the digital signatures of those Claims. This limit is primarily based the speed of the participants' hardware and the complexity of the signature algorithms. For maximum speed, use Ed25519 signatures, which are faster than the XRP Ledger's default secp256k1 ECSDA signatures. Research has <a href="https://ed25519.cr.yp.to/ed25519-20110926.pdf">demonstrated the ability to create over Ed25519 100,000 signatures per second and to verify over 70,000 per second <i class="fa fa-external-link" aria-hidden="true"></i></a> on commodity hardware in 2011.
+Because Claims can be verified individually but settled in bulk later, payment channels make it possible to conduct transactions at a rate only limited by the participants' ability to create and verify the digital signatures of those Claims. This limit is primarily based the speed of the participants' hardware and the complexity of the signature algorithms. For maximum speed, use Ed25519 signatures, which are faster than the XRP Ledger's default secp256k1 ECSDA signatures. Research has [demonstrated the ability to create over Ed25519 100,000 signatures per second and to verify over 70,000 per second](https://ed25519.cr.yp.to/ed25519-20110926.pdf) on commodity hardware in 2011.
 
 
 ## Why Use Payment Channels

content/concepts/introduction/technical-faq.md

@@ -7,7 +7,7 @@
 
 Validators determine if transactions meet protocol requirements, and are therefore “valid.” The service validators uniquely provide is grouping transactions into ordered units, agreeing on one such ordering specifically to prevent double spending.
 
-See [Consensus](consensus.html) and the <a href="https://ripple.com/insights/ripple-labs-tech-talk-consensus-within-the-ripple-protocol/" target="_blank">Ripple Labs Tech Talk: Understanding Consensus <i class="fa fa-external-link" aria-hidden="true"></i></a><!--#{ fix md highlighting_ #}--> for more information about the consensus process.
+See [Consensus](consensus.html) and the [Ripple Labs Tech Talk: Understanding Consensus](https://ripple.com/insights/ripple-labs-tech-talk-consensus-within-the-ripple-protocol/) for more information about the consensus process.
 
 
 #### How much does it cost to run a validator?
@@ -82,7 +82,7 @@ Ripple controls who has access to modify official versions of the `rippled` serv
 
 #### Does Ripple offer a secure method to download their software?
 
-`rippled` source code is available at <a href="https://github.com/ripple/rippled" target="_blank">https://github.com/ripple/rippled <i class="fa fa-external-link" aria-hidden="true"></i></a><!--#{ fix md highlighting_ #}-->, where the tip of the master, release and develop branches always contains a version-setting commit signed by a `rippled` developer. The XRP Ledger also offers prebuilt RPM packages for CentOS, RedHat Enterprise Linux, Fedora and Ubuntu. Those packages are digitally signed by Ripple so that they are tamper-evident and their authenticity can be verified. Lastly, release bulletins are made available over a secure website, and include the commit ID of the repository, as well as the md5sum of the RPM packages that are published.
+`rippled` source code is available at <https://github.com/ripple/rippled>, where the tip of the `master`, `release` and `develop` branches always contains a version-setting commit signed by a `rippled` developer. The XRP Ledger also offers prebuilt RPM packages for CentOS, RedHat Enterprise Linux, Fedora and Ubuntu. Those packages are digitally signed by Ripple so that they are tamper-evident and their authenticity can be verified. Lastly, release bulletins are made available over a secure website, and include the commit ID of the repository, as well as the md5sum of the RPM packages that are published.
 
 
 #### Does Ripple distinguish between the codebase for validation and the one for user software?
@@ -92,8 +92,8 @@ Yes. Client software for the XRP Ledger, including ripple-lib, has a different c
 
 ## See Also
 
-- <a href="https://github.com/ripple/rippled" target="_blank">`rippled` codebase <i class="fa fa-external-link" aria-hidden="true"></i></a><!--#{ fix md highlighting_ #}-->
+- [`rippled` codebase](https://github.com/ripple/rippled)
 - User software codebase:
-      - <a href="https://github.com/ripple/ripple-lib" target="_blank">ripple-lib <i class="fa fa-external-link" aria-hidden="true"></i></a><!--#{ fix md highlighting_ #}-->
-      - <a href="https://github.com/ripple/ripplecharts-frontend" target="_blank">ripplecharts-frontend <i class="fa fa-external-link" aria-hidden="true"></i></a><!--#{ fix md highlighting_ #}-->
-- <a href="https://github.com/ripple/" target="_blank">Ripple GitHub Organization <i class="fa fa-external-link" aria-hidden="true"></i></a><!--#{ fix md highlighting_ #}-->
+      - [ripple-lib](https://github.com/ripple/ripple-lib)
+      - [ripplecharts-frontend](https://github.com/ripple/ripplecharts-frontend)
+- [Ripple GitHub Organization](https://github.com/ripple/)

content/concepts/payment-system-basics/transaction-basics/transaction-basics.md

@@ -47,7 +47,7 @@ Sending a transaction to the XRP Ledger involves several steps:
 1. Create an [unsigned transaction in JSON format](#example-unsigned-transaction).
 2. Use one or more signatures to [authorize the transaction](#authorizing-transactions).
 3. Submit a transaction to a `rippled` server. If the transaction is properly formed, the server provisionally applies the transaction to its current version of the ledger and relays the transaction to other members of the peer-to-peer network.
-4. The [consensus process](https://ripple.com/build/ripple-ledger-consensus-process/) determines which provisional transactions get included in the next validated ledger.
+4. The [consensus process](consensus.html) determines which provisional transactions get included in the next validated ledger.
 5. The `rippled` servers apply those transactions to the previous ledger in a canonical order and share their results.
 6. If enough [trusted validators](rippled-server-modes.html#reasons-to-run-a-validator) created the exact same ledger, that ledger is declared _validated_ and the [results of the transactions](transaction-results.html) in that ledger are immutable.