Build updates, cont.

- Fix cross-reference issues
 - Properly comment out unused sections (coinjoin, payment processing)
 - Link correction
 - Subheading corrections
This commit is contained in:
thephez 2018-01-08 16:26:46 -05:00
parent 73df27d1b7
commit 088f104adf
16 changed files with 46 additions and 108 deletions

View file

@ -58,7 +58,6 @@ pre-build-tests-fast: check-for-non-ascii-urls check-for-wrong-filename-assignme
check-for-missing-copyright-licenses \
check-bundle \
check-for-english-in-en-dir \
check-validate-yaml \
## Post-build tests which, aggregated together, take less than 10 seconds to run on a typical PC
post-build-tests-fast: check-for-build-errors ensure-each-svg-has-a-png check-for-liquid-errors \
@ -76,7 +75,6 @@ pre-build-tests: pre-build-tests-fast
## All post-build tests, including those which might take multiple minutes
post-build-tests: post-build-tests-fast \
check-for-broken-bitcoin-core-download-links \
check-html-proofer
## All manual updates to content that should be run by a human. This
@ -244,18 +242,6 @@ manual-check-diff-sha256sums:
| uniq -u \
| sort -k2
check-for-broken-bitcoin-core-download-links:
## Ensure that the links from the Download page to the current Bitcoin
## Core binaries are correct
$S grep 'class="dl"' _site/en/download.html \
| sed 's/.*href="//; s/".*//' \
| while read url ; do \
if [ "$${url##http*}" ]; then \
curl -sI "https://bitcoin.org$$url" ; \
else \
curl -sI "$$url" ; \
fi | grep -q '200 OK' || echo "Error: Could not retrieve $$url" ; \
done | eval $(ERROR_ON_OUTPUT)
check-html-proofer:
$S bundle exec ruby _contrib/bco-htmlproof
@ -299,7 +285,3 @@ check-for-too-many-wallets-on-one-platform:
; if [ $$count -gt 14 ] \
; then echo "ERROR: too many wallets in $$platform platform. Remove one or change layout" \
; fi ; done
check-validate-yaml:
## Validate YAML files against schemas
##$S find _wallets -type f -exec bundle exec _contrib/schema-validator.rb quality-assurance/schemas/wallets.yaml {} \;

View file

@ -12,7 +12,7 @@
'`addr` messages': addr message
'`alert` message': alert message
'`alert` messages': alert message
'`amount`': pp amount
'`amount`': DO NOT AUTOCROSSREF
bitcoin QR code: URI QR code
bitcoin QR codes: URI QR code
'`bitcoin:` URI': bitcoin uri
@ -87,7 +87,7 @@ IPv6 address: DO NOT AUTOCROSSREF
IPv6 addresses: DO NOT AUTOCROSSREF
key index:
key pair:
'`label`': label
'`label`': DO NOT AUTOCROSSREF
leaf certificate:
long-term fork:
man in the middle: man-in-the-middle
@ -101,7 +101,7 @@ message payload:
'`merkleblock` message': merkleblock message
'`merkleblock` messages': merkleblock message
merge:
Merge avoidance:
Merge avoidance: DO NOT AUTOCROSSREF
micropayment channel:
micropayment channels: micropayment channel
'`mnb` message': mnb message
@ -161,16 +161,16 @@ protocol version 70013: section protocol versions
protocol version 70014: section protocol versions
public key infrastructure: pki
'`r`': r
receipt:
receipt: DO NOT AUTOCROSSREF
recurrent rebilling:
refund:
refunds: refund
refund: DO NOT AUTOCROSSREF
refunds: DO NOT AUTOCROSSREF
'`reject` message': reject message
'`reject` messages': reject message
root certificate:
RPC:
RPCs: rpc
'`script`': pp script
'`script`': DO NOT AUTOCROSSREF
secp256k1:
'`spork` message': spork message
'`spork` messages': spork message

View file

@ -88,7 +88,7 @@ format:
| → <br>`result` | *any* | Required<br>(exactly 1) | The RPC output<!--noref--> whose type varies by call. Has value `null` if an error occurred.
| → <br>`error` | null/object | Required<br>(exactly 1) | An object describing the error if one occurred, otherwise `null`.
| → → <br>`code` | number (int) | Required<br>(exactly 1) | The error code returned by the RPC function call. See [rpcprotocol.h][] for a full list of error codes and their meanings.
| → → <br>`message` | string | Required<br>(exactly 1) | A text description of the error. May be an empty string ("").
| → → <br>`message<!--noref-->` | string | Required<br>(exactly 1) | A text description of the error. May be an empty string ("").
| → <br>`id` | string | Required<br>(exactly 1) | The value of `id` provided with the request. Has value `null` if the `id` field was omitted in the request.
{:.ntpd}

View file

@ -240,6 +240,7 @@ MATCH FAILURE: Index 0x6 not set in 1010110111110000
{% endautocrossref %}
### Bloom Filter Script
<!-- no subhead-links here -->
<!-- Shell script to run previous examples -->
Complete Python script demonstrating the

View file

@ -129,6 +129,7 @@ second) and clear the shell variable.
{% endautocrossref %}
##### Simple Spending Script
{% include helpers/subhead-links.md %}
<!-- Shell script to run previous example -->
Shell script to run the previous example:

View file

@ -207,8 +207,9 @@ all under an Apache license.
-->
{% endautocrossref %}
<!-- Obsolesced by PrivateSend
{% comment %}<!-- Obsolesced by PrivateSend
### CoinJoin
{% include helpers/subhead-links.md %}
{% autocrossref %}
@ -290,4 +291,7 @@ saving each one of them a tiny amount of duffs.
CoinJoin is [CoinMux](http://coinmux.com/), available under the Apache
license.
-->
{% endautocrossref %}
{% endcomment %}

View file

@ -28,7 +28,6 @@ economy.
### InstantSend
{% include helpers/subhead-links.md %}
{% autocrossref %}
@ -62,7 +61,6 @@ There are a number of limitations on InstantSend transactions:
### PrivateSend
{% include helpers/subhead-links.md %}
{% autocrossref %}
@ -90,7 +88,6 @@ reference this [Official Documentation PrivateSend page](https://dashpay.atlassi
### Masternode Payment
{% include helpers/subhead-links.md %}
{% autocrossref %}
@ -115,7 +112,6 @@ treated as misbehaving and have its ban score increased.
{% endautocrossref %}
### Masternode Sync
{% include helpers/subhead-links.md %}
{% autocrossref %}
@ -129,6 +125,7 @@ several conditions that initiate a start/restart the sync process:
* Issuing a `mnsync reset` RPC command
#### Initial Masternode<!--noref--> Sync
{% include helpers/subhead-links.md %}
This diagram shows the order in which P2P messages are sent to perform
masternode synchronization initially after startup.
@ -176,6 +173,7 @@ are used in both `ssc` messages and the `mnsync` RPC.
#### Ongoing Masternode<!--noref--> Sync
{% include helpers/subhead-links.md %}
Once a masternode completes an initial full sync, continuing synchronization is
maintained by the exchange of P2P messages with other nodes. This diagram shows
@ -219,6 +217,7 @@ network. Unsynchronized peers may send `govsync` messages to request governance
sync.
#### Masternode<!--noref--> Sync Schedule
{% include helpers/subhead-links.md %}
The following tables detail the timing of various functions used to keep the
masternodes in sync with each other. This information is derived from
@ -242,12 +241,12 @@ The following actions only run when the masternode sync is past `MASTERNODE_SYNC
{% endautocrossref %}
### Governance
{% include helpers/subhead-links.md %}
{% autocrossref %}
#### Synchronization
{% include helpers/subhead-links.md %}
Dash Core synchronizes the governance system via the Masternode network as the
last stage of the Masternode sync process (following the sync of sporks, the
@ -309,6 +308,7 @@ Once the syncing node receives the counts and inventories, it may request any
| | ← | `govobjvote` message | (If requested) Governance object vote
#### Sentinel<!--noref-->
{% include helpers/subhead-links.md %}
[Sentinel](https://github.com/dashpay/sentinel<!--noref-->/) is a Python application that connects to a masternode's local dashd
instance to run as an autonomous agent for persisting, processing, and automating
@ -323,11 +323,15 @@ governance sync, ping, governance object pruning, and superblock management.
The governance object data is stored in a SQLite database.
##### Sentinel<!--noref--> Sync
{% include helpers/subhead-links.md %}
Sentinel issues a `gobject list` RPC command and updates its database with the
results returned from dashd. When objects are removed from the network, they are
purged from the Sentinel database.
##### Sentinel<!--noref--> Ping
{% include helpers/subhead-links.md %}
In Dash Core 12.2, use of the `watchdog` governance object type was replaced
by integrating sentinel information into the masternode ping (`mnp` message)
via [Pull Request #1491](https://github.com/dashpay/dash/pull/1491).
@ -335,13 +339,17 @@ Sentinel calls the `sentinelping` RPC which updates the masternode info to
prevent it from entering a `MASTERNODE_WATCHDOG_EXPIRED` state.
##### Sentinel<!--noref--> Prune
{% include helpers/subhead-links.md %}
Sentinel 1.1.0 introduced proposal pruning which automatically votes to delete
expired proposals following approximately half of a superblock cycle. This delay
period ensures that proposals are not deleted prematurely. Prior to this,
proposals remained in memory unless a sufficient number of masternodes manually
voted to delete them.
##### Sentinel<!--noref--> Superblock
##### Sentinel<!--noref--> Superblock<!--noref-->
{% include helpers/subhead-links.md %}
Sentinel manages superblock creation, voting, and submission to dashd for
network propagation.
@ -349,7 +357,6 @@ network propagation.
### Quorum Selection
{% include helpers/subhead-links.md %}
{% autocrossref %}

View file

@ -14,8 +14,8 @@ Core, either from [source][core git] or from a [pre-compiled executable][core ex
Questions about Dash development are best asked in one of the
[Dash development communities][dev communities].
Errors or suggestions related to
documentation on {Dash.org} can be [submitted as an issue][docs issue]
or posted to the [bitcoin-documentation mailing list][].
documentation on [dash-docs.github.io](https://dash-docs.github.io) can be
[submitted as an issue][docs issue].
In the following documentation, some strings have been shortened or wrapped: "[...]"
indicates extra data was removed, and lines ending in a single backslash "\\"

View file

@ -118,7 +118,7 @@ connection to a specific node by IP address. See the `-help` text for
details.
**Resources:** [Dash Seeder][], the program run by several of the
seeds used by Dash Core. The Dash Core [DNS SeedPolicy][]. The hardcoded list
seeds used by Dash Core. The Dash Core [DNS Seed Policy][]. The hardcoded list
of IP addresses used by Dash Core is generated using the [makeseeds script][].
{% endautocrossref %}

View file

@ -661,8 +661,7 @@ added in sequence until all of the available space is filled.
As of Dash Core 0.12.2.x, a [minimum fee][/en/glossary/minimum-relay-fee]{:#term-minimum-fee}{:.term}(1,000 duffs following [DIP1][] activation) is required to
broadcast a non-priority transaction across the network. Any transaction paying
only the minimum fee should be prepared to wait a long time before there's
enough spare space in a block to include it. Please see the [verifying payment section][section verifying payment]
for why this could be important.
enough spare space in a block to include it.
Since each transaction spends Unspent Transaction Outputs (UTXOs) and
because a UTXO can only be spent once, the full value of the included
@ -727,8 +726,8 @@ described below, with more general attacks hypothesized).
So, for both privacy and security, we encourage you to build your
applications to avoid public key reuse and, when possible, to discourage
users from reusing addresses. If your application needs to provide a
fixed URI to which payments should be sent, please see the
[`dash:` URI section][bitcoin URI subsection] below.
fixed URI to which payments should be sent, please use `dash:` URIs as defined
by [BIP21](https://github.com/QuantumExplorer/bips/blob/master/bip-0021.mediawiki#general-format).
{% endautocrossref %}

View file

@ -244,8 +244,7 @@ design these minimalist wallets:
Neither method adds a significant amount of overhead, especially if a
database is used anyway to associate each incoming payment with a
separate public key for payment tracking. See the [Payment
Processing][devguide payment processing] section for details.
separate public key for payment tracking.
{% endautocrossref %}

View file

@ -16,7 +16,8 @@ Core, either from [source][core git] or from a [pre-compiled executable][core ex
Questions about Dash development are best asked in one of the
[Dash development communities][dev communities].
Errors or suggestions related to
documentation on dash-docs.github.io can be [submitted as an issue][docs issue].
documentation on [dash-docs.github.io](https://dash-docs.github.io) can be
[submitted as an issue][docs issue].
In the following documentation, some strings have been shortened or wrapped: "[...]"
indicates extra data was removed, and lines ending in a single backslash "\\"

View file

@ -167,7 +167,7 @@ The currently-available type identifiers are:
| 15 | [`MSG_MASTERNODE_PING`][msg_masternode_ping]{:#term-msg_masternode_ping}{:.term} | The hash is a Masternode Ping.
| 16 | [`MSG_DSTX`][msg_dstx]{:#term-msg_dstx}{:.term} | The hash is Private Send (Dark Send) Broadcast TX.
| 17 | [`MSG_GOVERNANCE_OBJECT`][msg_governance_object]{:#term-msg_governance_object}{:.term} | The hash is a Governance Object.
| 18 | [`MSG_GOVERNANCE_OBJECT_VOTE`][msg_governance_object_vote]{:#term-msg_governance_object}{:.term} | The hash is a Governance Object Vote.
| 18 | [`MSG_GOVERNANCE_OBJECT_VOTE`][msg_governance_object_vote]{:#term-msg_governance_object_vote}{:.term} | The hash is a Governance Object Vote.
| 19 | [`MSG_MASTERNODE_VERIFY`][msg_masternode_verify]{:#term-msg_masternode_verify}{:.term} | The hash is a Masternode Verify.
Type identifier zero and type identifiers greater than nineteen are reserved

View file

@ -4,19 +4,10 @@ http://opensource.org/licenses/MIT.
{% endcomment %}
{% comment %}<!-- Terms; must have tooltip description in "quotes"; alphabetical order -->{% endcomment %}
[bitcoin URI]: /en/developer-guide#term-bitcoin-uri "A URI which allows receivers to encode payment details so spenders don't have to manually enter addresses and other details"
[certificate chain]: /en/developer-examples#term-certificate-chain "A chain of certificates connecting a individual's leaf certificate to the certificate authority's root certificate"
[coinbase block height]: /en/developer-reference#term-coinbase-block-height "The current block's height encoded into the first bytes of the coinbase field"
[data-pushing opcode]: https://en.bitcoin.it/wiki/Script#Constants "Any opcode from 0x01 to 0x4e which pushes data on to the script evaluation stack"
[fiat]: /en/developer-guide#term-fiat "National currencies such as the dollar or euro"
[intermediate certificate]: /en/developer-examples#term-intermediate-certificate "A intermediate certificate authority certificate which helps connect a leaf (receiver) certificate to a root certificate authority"
[key index]: /en/developer-guide#term-key-index "An index number used in the HD wallet formula to generate child keys from a parent key"
[key pair]: /en/developer-guide#term-key-pair "A private key and its derived public key"
[label]: /en/developer-guide#term-label "The label parameter of a bitcoin: URI which provides the spender with the receiver's name (unauthenticated)"
[leaf certificate]: /en/developer-examples#term-leaf-certificate "The end-node in a certificate chain; in the payment protocol, it is the certificate belonging to the receiver of satoshis"
[merge]: /en/developer-guide#term-merge "Spending, in the same transaction, multiple outputs which can be traced back to different previous spenders, leaking information about how many satoshis you control"
[merge avoidance]: /en/developer-guide#term-merge-avoidance "A strategy for selecting which outputs to spend that avoids merging outputs with different histories that could leak private information"
[message]: /en/developer-guide#term-message "A parameter of bitcoin: URIs which allows the receiver to optionally specify a message to the spender"
<!-- Inventory Messages -->
[msg_tx]: /en/developer-reference#term-msg_tx "The TXID data type identifier of an inventory on the P2P network"
[msg_block]: /en/developer-reference#term-msg_block "The block header hash data type identifier of an inventory on the P2P network"
@ -49,26 +40,9 @@ http://opensource.org/licenses/MIT.
[op_return]: /en/developer-reference#term-op-return "Operation which terminates the script in failure"
[op_verify]: /en/developer-reference#term-op-verify "Operation which terminates the script if the entry below it on the stack is non-true (zero)"
[output index]: /en/developer-guide#term-output-index "The sequentially-numbered index of outputs in a single transaction starting from 0"
[PaymentDetails]: /en/developer-examples#term-paymentdetails "The PaymentDetails of the payment protocol which allows the receiver to specify the payment details to the spender"
[PaymentRequest]: /en/developer-examples#term-paymentrequest "The PaymentRequest of the payment protocol which contains and allows signing of the PaymentDetails"
[PaymentRequests]: /en/developer-examples#term-paymentrequest "The PaymentRequest of the payment protocol which contains and allows signing of the PaymentDetails"
[PKI]: /en/developer-examples#term-pki "Public Key Infrastructure; usually meant to indicate the X.509 certificate system used for HTTP Secure (https)."
[point function]: /en/developer-guide#term-point-function "The ECDSA function used to create a public key from a private key"
[pp amount]: /en/developer-examples#term-pp-amount "Part of the Output part of the PaymentDetails part of a payment protocol where receivers can specify the amount of satoshis they want paid to a particular pubkey script"
[pp expires]: /en/developer-examples#term-pp-expires "The expires field of a PaymentDetails where the receiver tells the spender when the PaymentDetails expires"
[pp memo]: /en/developer-examples#term-pp-memo "The memo fields of PaymentDetails, Payment, and PaymentACK which allow spenders and receivers to send each other memos"
[pp merchant data]: /en/developer-examples#term-pp-merchant-data "The merchant_data part of PaymentDetails and Payment which allows the receiver to send arbitrary data to the spender in PaymentDetails and receive it back in Payments"
[pp PKI data]: /en/developer-examples#term-pp-pki-data "The pki_data field of a PaymentRequest which provides details such as certificates necessary to validate the request"
[pp pki type]: /en/developer-examples#term-pp-pki-type "The PKI field of a PaymentRequest which tells spenders how to validate this request as being from a specific recipient"
[pp script]: /en/developer-examples#term-pp-script "The script field of a PaymentDetails where the receiver tells the spender what pubkey scripts to pay"
[previous block header hash]: /en/developer-reference#term-previous-block-header-hash "A field in the block header which contains the SHA256(SHA256()) hash of the previous block's header"
[proper money handling]: /en/developer-reference#term-proper-money-handling "Bitcoin amounts need to be correctly processed without introducing rounding errors that could cause monetary loss"
[r]: /en/developer-guide#term-r-parameter "The payment request parameter in a bitcoin: URI"
[receipt]: /en/developer-guide#term-receipt "A cryptographically-verifiable receipt created using parts of a payment request and a confirmed transaction"
[recurrent rebilling]: /en/developer-guide#rebilling-recurring-payments "Billing a spender on a regular schedule"
[refund]: /en/developer-guide#issuing-refunds "A transaction which refunds some or all satoshis received in a previous transaction"
[root certificate]: /en/developer-examples#term-root-certificate "A certificate belonging to a certificate authority (CA)"
[ssl signature]: /en/developer-examples#term-ssl-signature "Signatures created and recognized by major SSL implementations such as OpenSSL"
[standard block relay]: /en/developer-guide#term-standard-block-relay "The regular block relay method: announcing a block with an inv message and waiting for a response"
[transaction]: /en/developer-guide#transactions "A transaction spending satoshis"
[transaction version number]: /en/developer-guide#term-transaction-version-number "A version number prefixed to transactions to allow upgrading""
@ -77,9 +51,7 @@ http://opensource.org/licenses/MIT.
[unique addresses]: /en/developer-guide#term-unique-address "Address which are only used once to protect privacy and increase security"
[unlocked wallet]: /en/developer-reference#walletpassphrase "An encrypted wallet that has been unlocked with the walletpassphrase RPC"
[unsolicited block push]: /en/developer-guide#term-unsolicited-block-push "When a miner sends a block message without sending an inv message first"
[URI QR Code]: /en/developer-guide#term-uri-qr-code "A QR code containing a bitcoin: URI"
[v2 block]: /en/developer-reference#term-v2-block "The current version of Bitcoin blocks"
[verified payments]: /en/developer-guide#verifying-payment "Payments which the receiver believes won't be double spent"
[wallet support]: /en/developer-reference#term-wallet-support "A Dash Core ./configure option that enables (default) or disables the wallet"
{% comment %}<!-- RPCs; alphabetical order -->{% endcomment %}
@ -240,7 +212,7 @@ http://opensource.org/licenses/MIT.
[dssu message]: /en/developer-reference#dssu "A P2P network message providing a mixing pool status update"
[dsq message]: /en/developer-reference#dsq "A P2P network message sent to indicate the queue is ready and the user is expected to send the entry inputs to start mixing"
[dstx message]: /en/developer-reference#dstx "A P2P network message sent by masternodes to broadcast subsidized transactions without fees (provides security in mixing)"
[feefilter message]: /en/developer-reference#feefilter "The P2P network message which requests the receiving peer not relay any transactions below the specified fee rate"
{% comment %}<!-- Fee Filter not currently implemented in Dash Core. [feefilter message]: /en/developer-reference#feefilter "The P2P network message which requests the receiving peer not relay any transactions below the specified fee rate" -->{% endcomment %}
[filteradd message]: /en/developer-reference#filteradd "A P2P protocol message used to add a data element to an existing bloom filter."
[filterclear message]: /en/developer-reference#filterclear "A P2P protocol message used to remove an existing bloom filter."
[filterload message]: /en/developer-reference#filterclear "A P2P protocol message used to send a filter to a remote peer, requesting that they only send transactions which match the filter."
@ -275,34 +247,8 @@ http://opensource.org/licenses/MIT.
[version message]: /en/developer-reference#version "A P2P network message sent at the begining of a connection to allow protocol version negotiation"
{% comment %}<!-- Other internal site links; alphabetical order -->{% endcomment %}
[bandwidth sharing guide]: /en/full-node
[bcc contribute]: /en/bitcoin-core/contribute/
[bcc contribute code]: /{{page.lang}}/{% translate development url %}
[bcc contribute documentation]: /en/bitcoin-core/contribute/documentation
[bcc contribute issues]: /en/bitcoin-core/contribute/issues
[bcc contribute support]: /en/bitcoin-core/contribute/support
[bcc contribute translations]: /en/bitcoin-core/contribute/translations
[bcc decentralized peer discovery]: /en/bitcoin-core/features/privacy#decentralized-peer-discovery
[bcc documentation]: /en/bitcoin-core/help#documentation
[bcc download]: /en/download
[bcc features]: /en/bitcoin-core/features/
[bcc forums]: /en/bitcoin-core/help#forums
[bcc help]: /en/bitcoin-core/help
[bcc live help]: /en/bitcoin-core/help#live
[bcc main]: /en/bitcoin-core/
[bcc network support]: /en/bitcoin-core/features/network-support
[bcc privacy]: /en/bitcoin-core/features/privacy
[bcc privacy data leaking]: /en/bitcoin-core/features/privacy#perfect-privacy-for-received-transactions
[bcc requirements]: /en/bitcoin-core/features/requirements
[bcc user interface]: /en/bitcoin-core/features/user-interface
[bcc user interface lightweight]: /en/bitcoin-core/features/user-interface#lightweight
[bcc validation]: /en/bitcoin-core/features/validation
[bcc validation decentralization]: /en/bitcoin-core/features/validation#help-protect-decentralization
[bcc validation do you validate]: /en/bitcoin-core/features/validation#do-you-validate
[bcc validation protection]: /en/bitcoin-core/features/validation#how-validation-protects-your-bitcoins
[bcc version history]: /en/version-history
[bitcoin URI subsection]: /en/developer-guide#bitcoin-uri
[dashd initial setup]: /en/developer-examples
[bitcoinpdf]: https://bitcoin.org/en/bitcoin-paper
[choose your wallet]: https://www.dash.org/wallets/
@ -311,17 +257,14 @@ http://opensource.org/licenses/MIT.
[dev communities]: https://www.dash.org/community/
[developer documentation]: /en/developer-documentation
[devex complex raw transaction]: /en/developer-examples#complex-raw-transaction
[devex payment protocol]: /en/developer-examples#payment-protocol
[devexamples]: /en/developer-examples
[devguide]: /en/developer-guide
[devguide avoiding key reuse]: /en/developer-guide#avoiding-key-reuse
[devguide hardened keys]: /en/developer-guide#hardened-keys
[devguide payment processing]: /en/developer-guide#payment-processing
[devguide wallets]: /en/developer-guide#wallets
[devref]: /en/developer-reference
[devref wallets]: /en/developer-reference#wallets
[locktime parsing rules]: /en/developer-guide#locktime_parsing_rules
[Merge Avoidance subsection]: /en/developer-guide#merge-avoidance
[micropayment channel]: /en/developer-guide#term-micropayment-channel
[not a specification]: /en/developer-reference#not-a-specification
[raw transaction format]: /en/developer-reference#raw-transaction-format
@ -344,12 +287,9 @@ http://opensource.org/licenses/MIT.
[section rpc quick reference]: /en/developer-reference#rpc-quick-reference
[section serialized blocks]: /en/developer-reference#serialized-blocks
[section simple raw transaction]: /en/developer-examples#simple-raw-transaction
[section verifying payment]: /en/developer-guide#verifying-payment
[secure your wallet]: /en/secure-your-wallet
[signature script modification warning]: /en/developer-reference#signature_script_modification_warning
[v0.8 chain fork]: /en/alert/2013-03-11-chain-fork
[Verification subsection]: /en/developer-guide#verifying-payment
[X509Certificates]: /en/developer-examples#term-x509certificates
{% comment %}<!-- Official reference documents (BIPs should not use zero padding:
BIP32 not BIP0032); alphabetical order -->{% endcomment %}

View file

@ -47,7 +47,9 @@ end_of_page: |
{% include devdoc/example_p2p_networking.md %}
<!-- Services like Blockcyper are more likely to be used by most than building a ground-up payment system
{% include devdoc/example_payment_processing.md %}
{% comment %}
{% include devdoc/example_payment_processing.md %}
{% endcomment %}
-->
{% include references.md %}

View file

@ -62,7 +62,9 @@ of the following file. -->
{% include devdoc/guide_mining.md %}
<!-- Services like Blockcyper are more likely to be used by most than building a ground-up payment system
include devdoc/guide_payment_processing.md
{% comment %}
include devdoc/guide_payment_processing.md
{% endcomment %}
-->
{% include references.md %}