Cleans up simple _devdocs Markdown files

looterz · Aug 16, 2017 · 4329375 · 4329375
1 parent 4b74aca
commit 4329375
Show file tree

Hide file tree

Showing 19 changed files with 0 additions and 860 deletions.
diff --git a/_devdocs/examples/intro.md b/_devdocs/examples/intro.md
@@ -4,8 +4,6 @@ http://opensource.org/licenses/MIT.
 {% endcomment %}
 {% assign filename="_includes/devdoc/example_intro.md" %}
 
-{% autocrossref %}
-
 The following guide aims to provide examples to help you start
 building Bitcoin-based applications. To make the best use of this document,
 you may want to install the current version of Bitcoin Core, either from
@@ -66,4 +64,3 @@ are continued below. If you hover your mouse over a paragraph, cross-reference
 links will be shown in blue.  If you hover over a cross-reference link, a brief
 definition of the term will be displayed in a tooltip.
 
-{% endautocrossref %}
diff --git a/_devdocs/examples/p2p_networking.md b/_devdocs/examples/p2p_networking.md
@@ -5,12 +5,8 @@ http://opensource.org/licenses/MIT.
 {% assign filename="_includes/devdoc/example_p2p_networking.md" %}
 
 ## P2P Network
-{% include helpers/subhead-links.md %}
 
 ### Creating A Bloom Filter
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 In this section, we'll use variable names that correspond to the field
 names in the [`filterload` message documentation][filterload message].
@@ -160,12 +156,7 @@ b50f ....... Filter: 1010 1101 1111 0000
 00 ......... nFlags: BLOOM_UPDATE_NONE
 {% endhighlight %}
 
-{% endautocrossref %}
-
 ### Evaluating A Bloom Filter
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 Using a bloom filter to find matching data is nearly identical to
 constructing a bloom filter---except that at each step we check to see
@@ -235,12 +226,7 @@ match failure:
 MATCH FAILURE: Index 0x6 not set in 1010110111110000
 {% endhighlight %}
 
-{% endautocrossref %}
-
 ### Retrieving A MerkleBlock
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 For the `merkleblock` message documentation on the reference page, an
 actual merkle block was retrieved from the network and manually
@@ -351,12 +337,7 @@ python get-merkle.py | nc localhost 8333 | hd
 
 Part of the response is shown in the section below.
 
-{% endautocrossref %}
-
 ### Parsing A MerkleBlock
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 In the section above, we retrieved a merkle block from the network; now
 we will parse it. Most of the block header has been omitted. For
@@ -453,4 +434,3 @@ The final steps would be to ensure the computed computed merkle root
 is identical to the merkle root in the header and check the other steps
 of the parsing checklist in the `merkleblock` message section.
 
-{% endautocrossref %}
diff --git a/_devdocs/examples/payment_processing.md b/_devdocs/examples/payment_processing.md
@@ -5,18 +5,12 @@ http://opensource.org/licenses/MIT.
 {% assign filename="_includes/devdoc/example_payment_processing.md" %}
 
 ## Payment Processing
-{% include helpers/subhead-links.md %}
 
 ### Payment Protocol
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 To request payment using the payment protocol, you use an extended (but
 backwards-compatible) `bitcoin:` URI.  For example:
 
-{% endautocrossref %}
-
 ~~~
 bitcoin:mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN\
 ?amount=0.10\
@@ -25,8 +19,6 @@ bitcoin:mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN\
 &r=https://example.com/pay.php/invoice%3Dda39a3ee
 ~~~
 
-{% autocrossref %}
-
 The browser, QR code reader, or other program processing the URI opens
 the spender's Bitcoin wallet program on the URI. If the wallet program is
 aware of the payment protocol, it accesses the URL specified in the `r`
@@ -36,12 +28,7 @@ served with the [MIME][] type `application/bitcoin-paymentrequest`<!--noref-->.
 **Resource:** Gavin Andresen's [Payment Request Generator][] generates
 custom example URIs and payment requests for use with testnet.
 
-{% endautocrossref %}
-
 #### PaymentRequest & PaymentDetails
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 The [PaymentRequest][]{:#term-paymentrequest}{:.term} is created with data structures built using
 Google's Protocol Buffers. BIP70 describes these data
@@ -63,12 +50,7 @@ protocol buffer compilers are available for a variety of
 programming languages. You will also need a copy of the PaymentRequest
 [Protocol Buffer description][core paymentrequest.proto] from the Bitcoin Core source code.
 
-{% endautocrossref %}
-
 ##### Initialization Code
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 With the Python code generated by `protoc`, we can start our simple
 CGI program.
@@ -95,12 +77,7 @@ The startup code above is quite simple, requiring nothing but the epoch
 functions from the OpenSSL library, and the data structures and
 functions created by `protoc`.
 
-{% endautocrossref %}
-
 ##### Configuration Code
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 Next, we'll set configuration settings which will typically only change
 when the receiver wants to do something differently. The code pushes a
@@ -246,12 +223,7 @@ The private SSL key will not be transmitted with your request. We're
 only loading it into memory here so we can use it to sign the request
 later.
 
-{% endautocrossref %}
-
 ##### Code Variables
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 Now let's look at the variables your CGI program will likely set for
 each payment.
@@ -350,12 +322,7 @@ given over to storing the certificate chain. As will be described in a
 later subsection, the `memo` field can be used by the spender after
 payment as part of a cryptographically-proven receipt.
 
-{% endautocrossref %}
-
 ##### Derivable Data
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 Next, let's look at some information your CGI program can
 automatically derive.
@@ -437,12 +404,7 @@ signing the completed and serialized PaymentRequest. We'll use the
 private key we stored in memory in the configuration section and the
 same hashing formula we specified in `pki_type` (sha256 in this case) 
 
-{% endautocrossref %}
-
 ##### Output Code
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 Now that we have PaymentRequest all filled out, we can serialize it and
 send it along with the HTTP headers, as shown in the code below.
@@ -470,4 +432,3 @@ created by the program above appears in the GUI from Bitcoin Core 0.9.
 
 ![Bitcoin Core Showing Validated Payment Request](/img/dev/en-btcc-payment-request.png)
 
-{% endautocrossref %}
diff --git a/_devdocs/examples/testing.md b/_devdocs/examples/testing.md
@@ -5,19 +5,11 @@ http://opensource.org/licenses/MIT.
 {% assign filename="_includes/devdoc/example_testing.md" %}
 
 ## Testing Applications
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 Bitcoin Core provides testing tools designed to let developers
 test their applications with reduced risks and limitations.
 
-{% endautocrossref %}
-
 ### Testnet
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 When run with no arguments, all Bitcoin Core programs default to Bitcoin's main
 network ([mainnet][/en/glossary/mainnet]{:#term-mainnet}{:.term}). However, for development,
@@ -32,12 +24,7 @@ free satoshis for testing, use [Piotr Piasecki's testnet faucet][].
 Testnet is a public resource provided for free by members of the
 community, so please don't abuse it.
 
-{% endautocrossref %}
-
 ### Regtest Mode
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 For situations
 where interaction with random peers and blocks is unnecessary or
@@ -50,19 +37,13 @@ Many developers consider regtest mode the preferred way to develop new
 applications. The following example will let you create a regtest
 environment after you first [configure bitcoind][bitcoind initial setup].
 
-{% endautocrossref %}
-
 {% highlight bash %}
 > bitcoind -regtest -daemon
 Bitcoin server starting
 {% endhighlight %}
 
-{% autocrossref %}
-
 Start `bitcoind` in regtest mode to create a private block chain.
 
-{% endautocrossref %}
-
 ~~~
 ## Bitcoin Core 0.10.1 and earlier
 bitcoin-cli -regtest setgenerate true 101
@@ -71,8 +52,6 @@ bitcoin-cli -regtest setgenerate true 101
 bitcoin-cli -regtest generate 101
 ~~~
 
-{% autocrossref %}
-
 Generate 101 blocks using a special RPC
 which is only available in regtest mode. This takes less than a second on
 a generic PC. Because this is a new block chain using Bitcoin's default
@@ -82,15 +61,11 @@ However, a block must have 100 confirmations before that reward can be
 spent, so we generate 101 blocks to get access to the coinbase
 transaction from block #1.
 
-{% endautocrossref %}
-
 {% highlight bash %}
 bitcoin-cli -regtest getbalance
 50.00000000
 {% endhighlight %}
 
-{% autocrossref %}
-
 Verify that we now have 50 bitcoins available to spend.
 
 You can now use Bitcoin Core RPCs prefixed with `bitcoin-cli -regtest`<!--noref-->.
@@ -102,4 +77,3 @@ start a new regtest. (See the [Developer Examples Introduction][devexamples] for
 configuration directory locations on various operating systems. Always back up
 mainnet wallets before performing dangerous operations such as deleting.)
 
-{% endautocrossref %}
diff --git a/_devdocs/examples/transactions.md b/_devdocs/examples/transactions.md
@@ -5,12 +5,8 @@ http://opensource.org/licenses/MIT.
 {% assign filename="_includes/devdoc/example_transactions.md" %}
 
 ## Transactions
-{% include helpers/subhead-links.md %}
 
 ### Transaction Tutorial
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 Creating transactions is something most Bitcoin applications do.
 This section describes how to use Bitcoin Core's RPC interface to
@@ -25,17 +21,7 @@ In order to use this tutorial, you will need to setup [Bitcoin Core][core execut
 and create a regression test mode environment with 50 BTC in your test
 wallet.
 
-{% endautocrossref %}
-
-
-
-
-
-
 #### Simple Spending
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 Bitcoin Core provides several RPCs which handle all the details of
 spending, including creating change outputs and paying appropriate fees.
@@ -127,17 +113,7 @@ list of UTXOs.
 Create a new block to confirm the transaction above (takes less than a
 second) and clear the shell variable.
 
-{% endautocrossref %}
-
-
-
-
-
-
 #### Simple Raw Transaction
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 The raw transaction RPCs allow users to create custom transactions and
 delay broadcasting those transactions. However, mistakes made in raw
@@ -252,7 +228,6 @@ would be a whopping 40 bitcoins. See the Complex Raw Transaction
 subsection below for how to create a transaction with multiple outputs so you
 can send the change back to yourself.
 
-
 <div markdown="1" class="multicode">
 {% highlight bash %}
 > bitcoin-cli -regtest decoderawtransaction $RAW_TX
@@ -353,16 +328,7 @@ connected to other peers because we started in regtest mode.
 Generate a block to confirm the transaction and clear our shell
 variables.
 
-{% endautocrossref %}
-
-
-
-
-
 #### Complex Raw Transaction
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 In this example, we'll create a transaction with two inputs and two
 outputs.  We'll sign each of the inputs separately, as might happen if
@@ -511,7 +477,6 @@ e8677d2cc74df51f738285013c260000000000ffffffff02f028d6dc01000000\
 Create the raw transaction using `createrawtransaction` much the same as
 before, except now we have two inputs and two outputs.
 
-
 <div markdown="1" class="multicode">
 {% highlight bash %}
 > bitcoin-cli -regtest signrawtransaction $RAW_TX '[]' '''
@@ -607,16 +572,7 @@ not going to send this transaction to the connected node with
 Signing subsection below how to spend a transaction which is not yet in
 the block chain or memory pool.
 
-{% endautocrossref %}
-
-
-
-
-
 #### Offline Signing
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 We will now spend the transaction created in the Complex Raw Transaction
 subsection above without sending it to the local node first. This is the
@@ -745,7 +701,6 @@ variable.
 {% endhighlight %}
 </div>
 
-
 Decode the signed raw transaction so we can get its txid. Also, choose a
 specific one of its UTXOs to spend and save that UTXO's output index number
 (vout) and hex pubkey script (scriptPubKey) into shell variables.
@@ -906,17 +861,7 @@ are part of the local node's memory pool.
 
 Remove old shell variables. 
 
-{% endautocrossref %}
-
-
-
-
-
-
 #### P2SH Multisig
-{% include helpers/subhead-links.md %}
-
-{% autocrossref %}
 
 In this subsection, we will create a P2SH multisig address, spend
 satoshis to it, and then spend those satoshis from it to another
@@ -1276,4 +1221,3 @@ complete.
 We send the transaction spending the P2SH multisig output to the local
 node, which accepts it.
 
-{% endautocrossref %}