From 61f0931b758b4a2397885b412a18f29385930058 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Fri, 6 Jun 2014 18:46:32 -0400 Subject: [PATCH] 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 | 4 - _includes/example_payment_processing.md | 134 ++---------------------- _includes/guide_payment_processing.md | 4 +- _includes/references.md | 6 +- _less/screen.less | 5 +- _plugins/autocrossref.rb | 2 +- img/compass-rose.png | Bin 0 -> 1555 bytes img/hash.png | Bin 0 -> 915 bytes 8 files changed, 14 insertions(+), 141 deletions(-) create mode 100644 img/compass-rose.png create mode 100644 img/hash.png diff --git a/_autocrossref.yaml b/_autocrossref.yaml index 627812fd..bdd65bc9 100644 --- a/_autocrossref.yaml +++ b/_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 diff --git a/_includes/example_payment_processing.md b/_includes/example_payment_processing.md index 906ebe1c..57d786aa 100644 --- a/_includes/example_payment_processing.md +++ b/_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`. {% 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. - - - -* [`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 %} diff --git a/_includes/guide_payment_processing.md b/_includes/guide_payment_processing.md index 4c427044..4d1c6cad 100644 --- a/_includes/guide_payment_processing.md +++ b/_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. diff --git a/_includes/references.md b/_includes/references.md index 5f893744..57f895f8 100644 --- a/_includes/references.md +++ b/_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 diff --git a/_less/screen.less b/_less/screen.less index 63846c75..b76d3aab 100644 --- a/_less/screen.less +++ b/_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; } diff --git a/_plugins/autocrossref.rb b/_plugins/autocrossref.rb index f479ec8e..4e4a653c 100644 --- a/_plugins/autocrossref.rb +++ b/_plugins/autocrossref.rb @@ -73,7 +73,7 @@ require 'yaml' (?!\w) ## Don't match inside words /xmi, "[\\&][#{term[1]}]{:.auto-link}") } - output.gsub!('','') ## Remove all comments + output.gsub!(//m,'') ## Remove all HTML comments output end diff --git a/img/compass-rose.png b/img/compass-rose.png new file mode 100644 index 0000000000000000000000000000000000000000..e13494a9c45d2c25f537066930b81a0e5b78f482 GIT binary patch literal 1555 zcmeAS@N?(olHy`uVBq!ia0vp^1|ZDA3?vioaBc-s%*9TgAsieWw;%dH0CG7CJR*yM z%CCbkqm#z$3ZS55iEBhjaDG}zd16s2LwR|*US?i)adKios$PCk`s{Z$QVa}?I|F<| zT>t<74^⪼NjsRL!*R*1TI~2a&ow&u!`&J>qEqijg65N*xTD9bJ5s-etr-UQ&UqQ zBQi1)NG2vGqA7!Lv$C=v3}7G%2??pIs{^@pb#*|prKJT(IyyQ6NuZ5=eSJX2^5x5c zq^PKeah<@7}+E|LN1G&!0bk|Ni~&-@m|Et4X;DGNrvF$S;_I zk%^gwm5rT)lZTgIKu}0nL{v;nTtZSxT1Hl0QCUS*OKfAZ|v^X4sFxMb8~^5xsNZ@+r=1_<81ef$2yhc92gef#m_$Irii|NZmNH+u$5pO&63jv*e$r%rnt zFXSk2oL$sdS=2E2iiwCkgQL%4_RCwY%xe}oddb8?Zc4)?9oDyuiJy&Hes|xlzH!@j zLBFAXUU^>K{nYZZeD;PC1n5JztmK0_EoE0^#)m+d9Tl3eJ#RW=jx8R z=Tg!OlBEi-O}!d=+WG6P>?P-n9@PY$Pg<|kZ0PX0i_iY{oKqr)I=Uwud~-L+`gKbE zp$^XA{ztd?1nnqBw$-a2h6mVZyjWd* z^jD+X<1VKckC`T1(7t%HI@$GCpI@fzq_c{QC(dgB;#?sg^fLQx%F{(_yBYR7ezmx9 zkjZbBcFwI8EJwD4@Ee?a@!I!*(Bw=`i+M?3E>z5AI=t#HgZ?CjI?t)~yYhPH-sE4; z*2KcWcxU0y{C7%w_i?{TWG$Y=u(D2La}Y!6v0vtbjOWbG=A^jXGu*Wj7E50~{jf0V|4Z>(XE#sQk#VgtK73};+r0WY7ymyLaDF1h z*x#%d<@x$fm5J_4|4N<(vJ)-(a?h;3eCo}XvP;rFi_S0K!?9rR=8%lct~{BaEV`=} zC)WL+J)LpO&G>H_U#_m=5AI^{yc)R3VQOz>wYY*ygTjHsVXBv|gg#?#a@T86WvVDt zyBDXrP&%Y^<@7Id$+kYS-VRkl5{nkL&tz|$zvD>EQ56NPXUj8vmE1zFpD|d>eq%yI zY2`bmi+Lfc4khzXRn0ixd0@^Pvvu1<<5MiQ@_sn8G-fI%V~2Kl>fu#|YnCkQ*k%<41TqZ&D1Q)VX>hS>f2i#a%-0N_u6{1-oD!MP)K~!jg)tbLfR8bJde*>#f5dTCXCL|^b8UYp12QbmZ*2>0c zW#Kc}7z^LPN6_BH+Q!lbK_y#=A^yW?B++PrB96uGCd;{J_s*Gnc9Ac+1>fe|bG|z> z_spF|RFxbMkuhK?pr5Gfb%XXkaJ7w6;Iyi)muYKByX=m6U@YL?8?_e#?V4rt00YJa zESQgQ&&xz2G7LRQNYU@pQf8gyqUX2ODX(OyR2C$M7Bor`e&H6S7*z+^zbP}RQ% zxhwTr$Q6NEK%AQhBe1TjZ>;&|Usu(#b0dl>2Ew}t zwv%)M*zeFqk=uYJg}lb2$eBW4Rn;;FilttE4T#7na5SL31q`<4FA8r2syqfm?W(GN zbMC`!z?J_Za*Re7nxyN7ZLNfe3;=fwx+@Xxl8A(_mLVo0+z}DETcTT1)ko1!f+N1h z&bQ04>p`zti5i1=V~zj-002ovPDHLkV1f(^khA~* literal 0 HcmV?d00001