Updates Based On Feedback From Mailing List

* Remove the QR Code error corrections subsection.

* Remove the non-example Payment Protocol text from developer examples.

* Update reference links and autocrossrefs to reflect above deletions

* Fix CSS padding problems reported by @saivann

* Remove all HTML comments from autocrossref text to allow easy checking
  for broken link definitions: find _site -name '*.html' | xargs grep '\]\['

* Add PNG versions of guide and example SVG icons.  (optipng run)

_autocrossref.yaml

@@ -124,14 +124,11 @@ p2sh multisig:
 parent chain code:
 parent private key:
 parent public key:
-Payment message: pp payment
 payment protocol:
 "payment protocol's": payment protocol
-PaymentACK:
 PaymentDetails:
 PaymentRequest:
 PaymentRequests: paymentrequest
-'`payment_url`': pp payment url
 peer:
 peers: peer
 peer-to-peer network: network
@@ -157,7 +154,6 @@ recurrent rebilling:
 redeemScript:
 refund: 
 refunds: refund
-'`refund_to`': pp refund to
 root certificate:
 root seed:
 RPCs: rpc

_includes/example_payment_processing.md

@@ -1,27 +1,6 @@
 ## Payment Processing
 
-### QR Code Error Correction
-
-{% autocrossref %}
-
-![Bitcoin QR Codes](/img/dev/en-qr-code.svg)
-
-QR encoders offer four possible levels of error correction: 
-
-1. Low: corrects up to 7% damage
-
-2. Medium: corrects up to 15% damage but results in approximately 8%
-   larger images over low-level damage correction.
-
-3. Quartile: corrects corrects up to 25% damage but results in
-   approximately 20% larger images over low-level damage correction.
-
-4. High: corrects up to 30% damage but results in approximately 26%
-   larger images over low-level damage correction.
-
-{% endautocrossref %}
-
-#### Payment Protocol
+### Payment Protocol
 
 {% autocrossref %}
 
@@ -44,7 +23,7 @@ served with the [MIME][] type `application/bitcoin-paymentrequest`<!--noref-->.
 
 {% endautocrossref %}
 
-##### PaymentRequest & PaymentDetails
+#### PaymentRequest & PaymentDetails
 
 {% autocrossref %}
 
@@ -70,7 +49,7 @@ programming languages. You will also need a copy of the PaymentRequest
 
 {% endautocrossref %}
 
-###### Initialization Code
+##### Initialization Code
 
 {% autocrossref %}
 
@@ -101,7 +80,7 @@ functions created by `protoc`.
 
 {% endautocrossref %}
 
-###### Configuration Code
+##### Configuration Code
 
 {% autocrossref %}
 
@@ -251,7 +230,7 @@ later.
 
 {% endautocrossref %}
 
-###### Code Variables
+##### Code Variables
 
 {% autocrossref %}
 
@@ -354,7 +333,7 @@ payment as part of a cryptographically-proven receipt.
 
 {% endautocrossref %}
 
-###### Derivable Data
+##### Derivable Data
 
 {% autocrossref %}
 
@@ -440,7 +419,7 @@ same hashing formula we specified in `pki_type` (sha256 in this case)
 
 {% endautocrossref %}
 
-###### Output Code
+##### Output Code
 
 {% autocrossref %}
 
@@ -471,102 +450,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 %}
-
-##### Payment
-
-{% autocrossref %}
-
-If the spender declines to pay, the wallet program will not send any
-further messages to the receiver's server unless the spender clicks
-another URI pointing to that server.  If the spender does decide to pay,
-the wallet program will create at least one transaction paying each of
-the outputs in the PaymentDetails section. The wallet may broadcast
-the transaction or transactions, as Bitcoin Core 0.9 does, but it
-doesn't need to.
-
-Whether or not it broadcasts the transaction or transactions, the wallet
-program composes a reply to the PaymentRequest; the reply is called the
-Payment. [Payment][pp payment]{:#term-pp-payment}{:.term} contains four fields:
-
-* `merchant_data`: (optional) an exact copy of the
-  `merchant_data` from the PaymentDetails. This is
-  optional in the case that the PaymentDetails doesn't provide
-  `merchant_data`. Receivers should be aware that malicious spenders can
-  modify the merchant data before sending it back, so receivers may wish to
-  cryptographically sign it before giving it to the spender and then
-  validate it before relying on it.
-
-* [`transactions`][pp transactions]{:#term-pp-transactions}{:.term}: (required) one or more signed transactions which pay the outputs
-  specified in the PaymentDetails.
-
-<!-- BIP70 implies that refund_to is required (i.e. "one or more..."),
-but Mike Hearn implied on bitcoin-devel that it's optional (i.e. "wallets have
-to either never submit refund data, or always submit it"). 
-I'll use the BIP70 version here until I hear differently. -harding -->
-
-* [`refund_to`][pp refund to]{:#term-pp-refund-to}{:.term}: (required) one or more output scripts to which the
-  receiver can send a partial or complete refund. As of this writing, a
-  proposal is gaining traction to expire refund output scripts after a
-  certain amount of time (not defined yet) so spenders don't need to
-  worry about receiving refunds to addresses they no longer monitor.
-
-* `memo`: (optional) a plain UTF-8 text memo sent to the receiver. It
-  should not contain HTML or any other markup. Spenders should not depend
-  on receivers reading their memos.
-
-The Payment is sent to the [`payment_url`][pp payment
-url]{:#term-pp-payment-url}{:.term} provided in the PaymentDetails.
-The URL should be a HTTPS address to prevent a man-in-the-middle attack
-from modifying the spender's `refund_to` output scripts. When sending the
-Payment, the wallet program must set the following HTTP client headers:
-
-{% endautocrossref %}
-
-~~~
-Content-Type: application/bitcoin-payment
-Accept: application/bitcoin-paymentack
-~~~
-
-##### PaymentACK
-
-{% autocrossref %}
-
-The receiver's CGI program at the `payment_url` receives the Payment message and
-decodes it using its Protocol Buffers code. The `transactions` are
-checked to see if they pay the output scripts the receiver requested in
-PaymentDetails and are then broadcast to the network (unless the network
-already has them).
-
-The CGI program checks the `merchant_data` parameter if necessary and issues
-a [PaymentACK][]{:#term-paymentack}{:.term} (acknowledgment) with the following HTTP headers:
-
-{% endautocrossref %}
-
-~~~
-Content-Type: application/bitcoin-paymentack
-Content-Transfer-Encoding: binary
-~~~
-
-{% autocrossref %}
-
-Then it sends another Protocol-Buffers-encoded message with one or two
-fields:
-
-* `payment`: (required) A copy of the the entire Payment message (in
-  serialized form) which is being acknowledged.
-
-* `memo`: (optional) A plain UTF-8 text memo displayed to the spender
-  informing them about the status of their payment.  It should not
-  contain HTML or any other markup.  Receivers should not depend on
-  spenders reading their memos.
-
-The PaymentACK does not mean that the payment is final; it just means
-that everything seems to be correct. The payment is final once the
-payment transactions are block-chain confirmed to the receiver's
-satisfaction.
-
-However, the spender's wallet program should indicate to the spender that
-the payment was accepted for processing so the spender can direct his or
-her attention elsewhere.
-
-{% endautocrossref %}

_includes/guide_payment_processing.md

@@ -221,8 +221,8 @@ images, or in videos. Most mobile Bitcoin wallet apps, and some desktop
 wallets, support scanning QR codes to pre-fill their payment screens.
 
 The figure below shows the same `bitcoin:` URI code encoded as four
-different [Bitcoin QR codes][URI QR code]{:#term-uri-qr-code}{:.term} at different error correction levels (described
-in the Developer Examples [QR Codes subsection][devex qr codes]). The QR code can include the `label` and `message`
+different [Bitcoin QR codes][URI QR code]{:#term-uri-qr-code}{:.term} at four
+different error correction levels. The QR code can include the `label` and `message`
 parameters---and any other optional parameters---but they were
 omitted here to keep the QR code small and easy to scan with unsteady
 or low-resolution mobile cameras.

_includes/references.md

@@ -89,7 +89,6 @@
 [parent private key]: /en/developer-guide#term-parent-private-key "A private key which has created child private keys"
 [parent public key]: /en/developer-guide#term-parent-public-key "A public key corresponding to a parent private key which has child private keys"
 [payment protocol]: /en/developer-guide#term-payment-protocol "The protocol defined in BIP70 which lets spenders get signed payment details from receivers"
-[PaymentACK]: /en/developer-examples#term-paymentack "The PaymentACK of the payment protocol which allows the receiver to indicate to the spender that the payment is being processed"
 [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"
@@ -106,13 +105,9 @@
 [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 Payment]: /en/developer-examples#term-pp-payment "The Payment message of the PaymentProtocol which allows the spender to send payment details to the receiver"
 [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 refund to]: /en/developer-examples#term-pp-refund-to "The refund_to field of a Payment where the spender tells the receiver what outputs to send refunds to"
 [pp script]: /en/developer-examples#term-pp-script "The script field of a PaymentDetails where the receiver tells the spender what output scripts to pay"
-[pp transactions]: /en/developer-examples#term-pp-transactions "The transactions field of a Payment where the spender provides copies of signed transactions to the receiver"
-[pp payment url]: /en/developer-examples#term-pp-payment-url "The payment_url of the PaymentDetails which allows the receiver to specify where the sender should post payment"
 [proof of work]: /en/developer-guide#term-proof-of-work "Proof that computationally-difficult work was performed which helps secure blocks against modification, protecting transaction history"
 [Pubkey]: /en/developer-guide#term-pubkey "A standard output script which specifies the full public key to match a signature; used in coinbase transactions"
 [r]: /en/developer-guide#term-r-parameter "The payment request parameter in a bitcoin: URI" 
@@ -180,6 +175,7 @@
 [core paymentrequest.proto]: https://github.com/bitcoin/bitcoin/blob/master/src/qt/paymentrequest.proto
 [core script.h]: https://github.com/bitcoin/bitcoin/blob/master/src/script.h
 [DER]: https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One
+[devex payment protocol]: /en/developer-examples#payment-protocol
 [devguide]: /en/developer-guide
 [devguide wallets]: /en/developer-guide#wallets
 [devref wallets]: /en/developer-reference#wallets

_less/screen.less

@@ -787,12 +787,13 @@ table td,table th{
 	background-color:#f5f5f5;
 	border:1px solid #ccc;
 	overflow-y:auto;
-	padding-bottom: 17px;
+	padding-bottom: 34px;
 }
 
 .toccontent .multicode pre {
 	border: 0px none;
-	padding: 0px;
+	padding-top: 0px;
+	padding-bottom: 0px;
 	overflow-y: visible;
 	margin-bottom: -17px;
 }

_plugins/autocrossref.rb

@@ -73,7 +73,7 @@ require 'yaml'
             (?!\w)  ## Don't match inside words
           /xmi, "[\\&][#{term[1]}]{:.auto-link}")
       }
-      output.gsub!('<!--noref-->','')  ## Remove all <!--noref--> comments
+      output.gsub!(/<!--.*?-->/m,'')  ## Remove all HTML comments
 
       output
     end