Fix various typos or naming inconsistencies

This commit is contained in:
Saivann 2014-06-08 23:17:04 -04:00
parent abf8ac25d6
commit 0cb0a999f6
3 changed files with 19 additions and 19 deletions

View file

@ -12,7 +12,7 @@ bitcoin:mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN\
?amount=0.10\
&label=Example+Merchant\
&message=Order+of+flowers+%26+chocolates\
&r=http://example.com/pay.php/invoice%3Dda39a3ee
&r=https://example.com/pay.php/invoice%3Dda39a3ee
~~~
The browser, QR code reader, or other program processing the URI opens

View file

@ -89,7 +89,7 @@ Verify that we now have 50 bitcoins available to spend.
Bitcoin Core provides several RPCs which handle all the details of
spending, including creating change outputs and paying appropriate fees.
Even advanced users should use these RPCs whenever possible to decrease
the chance that satoshis will be lost to mistakes.
the chance that satoshis will be lost by mistake.
{% highlight bash %}
> bitcoin-cli -regtest getnewaddress
@ -400,7 +400,7 @@ variables.
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
the two inputs belonged to different people who agreed to create a
transaction together (such as a Coinjoin transaction).
transaction together (such as a CoinJoin transaction).
<div markdown="1" class="multicode">
{% highlight bash %}

View file

@ -293,7 +293,7 @@ Protocol is typically used.
Charlie, the client, is shopping on a website run by Bob, the
businessman. Charlie adds a few items to his shopping cart and clicks
the Checkout With Bitcoin button.
the "Checkout With Bitcoin" button.
Bob's server automatically adds the following information to its
invoice database:
@ -316,21 +316,21 @@ a `bitcoin:` URI for Charlie to click to pay.
Charlie clicks on the `bitcoin:` URI in his browser. His browser's URI
handler sends the URI to his wallet program. The wallet is aware of the
Payment Protocol, so it parses the `r` parameter and sends an HTTP GET
to that URL looking for a Payment Request.
to that URL looking for a payment request.
The Payment Request may include private information, such as Charlie's
The PaymentRequest message may include private information, such as Charlie's
mailing address, but the wallet must be able to access it without using prior
authentication, such as HTTP cookies, so a publicly-accessible HTTPS URL
with a guess-resistant part is typically used. The
unique public key created for the Payment Request can be used to create
a unique identifier. This is why, in the example URI above, the Payment
Request URL contains the P2PKH address:
unique public key created for the payment request can be used to create
a unique identifier. This is why, in the example URI above, the PaymentRequest
URL contains the P2PKH address:
`https://example.com/pay/mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN`
After receiving the HTTP GET to the URL above, the Payment
Request-generating CGI program on Bob's webserver takes the
unique identifier from the URL and looks up the corresponding details in
the database. It then creates a Payment Details message with the
the database. It then creates a PaymentDetails message with the
following information:
* The amount of the order in satoshis and the output script to be paid.
@ -339,26 +339,26 @@ following information:
he's paying for. It may also include Charlie's mailing address so he can
double-check it.
* The time the Payment Details message was created plus the time
* The time the PaymentDetails message was created plus the time
it expires.
* A URL to which Charlie's wallet should send its completed transaction.
That Payment Details message is put inside a Payment Request message.
The Payment Request lets Bob's server sign the entire Request with the
That PaymentDetails message is put inside a PaymentRequest message.
The payment request lets Bob's server sign the entire Request with the
server's X.509 SSL certificate. (The Payment Protocol has been designed
to allow other signing methods in the future.) Bob's server sends the
Payment Request to Charlie's wallet in the reply to the HTTP GET.
payment request to Charlie's wallet in the reply to the HTTP GET.
![Bitcoin Core Showing Validated Payment Request](/img/dev/en-btcc-payment-request.png)
Charlie's wallet receives the Payment Request, checks its signature, and
then displays the details from the Payment Details to Charlie. Charlie
Charlie's wallet receives the payment request, checks its signature, and
then displays the details from the PaymentDetails message to Charlie. Charlie
agrees to pay, so the wallet constructs a payment to the output script
Bob's server provided. Unlike a traditional Bitcoin payment, Charlie's
wallet doesn't necessarily automatically broadcast this payment to the
network. Instead, the wallet constructs a Payment message and sends it to
the URL provided in the Payment Details message as an HTTP POST. Among
the URL provided in the PaymentDetails message as an HTTP POST. Among
other things, the Payment message contains:
* The signed transaction in which Charlie pays Bob.
@ -384,11 +384,11 @@ After Bob's server verifies from the block chain that Charlie's
transaction has been suitably confirmed, it authorizes shipping
Charlie's order.
In the case of a dispute, Charlie can generate a cryptgraphically-proven
In the case of a dispute, Charlie can generate a cryptographically-proven
[receipt][]{:#term-receipt}{:.term} out of the various signed or
otherwise-proven information.
* The Payment Details message signed by Bob's webserver proves Charlie
* The PaymentDetails message signed by Bob's webserver proves Charlie
received an invoice to pay a specified output script for a specified
number of satoshis for goods specified in the memo field.