joshua/dash-docs
1
0
Fork 0
mirror of https://github.com/seigler/dash-docs synced 2025-07-27 17:56:16 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Fix various typos or naming inconsistencies

Browse source
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
Download patch file Download diff file Expand all files Collapse all files

2
_includes/example_payment_processing.md
View file

@ -12,7 +12,7 @@ bitcoin:mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN\
?amount=0.10\ ?amount=0.10\
&label=Example+Merchant\ &label=Example+Merchant\
&message=Order+of+flowers+%26+chocolates\ &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 The browser, QR code reader, or other program processing the URI opens

4
_includes/example_transactions.md
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 Bitcoin Core provides several RPCs which handle all the details of
spending, including creating change outputs and paying appropriate fees. spending, including creating change outputs and paying appropriate fees.
Even advanced users should use these RPCs whenever possible to decrease 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 %} {% highlight bash %}
> bitcoin-cli -regtest getnewaddress > bitcoin-cli -regtest getnewaddress
@ -400,7 +400,7 @@ variables.
In this example, we'll create a transaction with two inputs and two 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 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 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"> <div markdown="1" class="multicode">
{% highlight bash %} {% highlight bash %}

22
_includes/guide_payment_processing.md
View file

@ -293,7 +293,7 @@ Protocol is typically used.
Charlie, the client, is shopping on a website run by Bob, the Charlie, the client, is shopping on a website run by Bob, the
businessman. Charlie adds a few items to his shopping cart and clicks 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 Bob's server automatically adds the following information to its
invoice database: invoice database:
@ -316,15 +316,15 @@ a `bitcoin:` URI for Charlie to click to pay.
Charlie clicks on the `bitcoin:` URI in his browser. His browser's URI 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 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 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 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 authentication, such as HTTP cookies, so a publicly-accessible HTTPS URL
with a guess-resistant part is typically used. The with a guess-resistant part is typically used. The
unique public key created for the Payment Request can be used to create 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 a unique identifier. This is why, in the example URI above, the PaymentRequest
Request URL contains the P2PKH address: URL contains the P2PKH address:
`https://example.com/pay/mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN` `https://example.com/pay/mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN`
After receiving the HTTP GET to the URL above, the Payment After receiving the HTTP GET to the URL above, the Payment
@ -345,15 +345,15 @@ following information:
* A URL to which Charlie's wallet should send its completed transaction. * A URL to which Charlie's wallet should send its completed transaction.
That PaymentDetails message is put inside a PaymentRequest message. That PaymentDetails message is put inside a PaymentRequest message.
The Payment Request lets Bob's server sign the entire Request with the 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 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 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) ![Bitcoin Core Showing Validated Payment Request](/img/dev/en-btcc-payment-request.png)
Charlie's wallet receives the Payment Request, checks its signature, and Charlie's wallet receives the payment request, checks its signature, and
then displays the details from the Payment Details to Charlie. Charlie then displays the details from the PaymentDetails message to Charlie. Charlie
agrees to pay, so the wallet constructs a payment to the output script agrees to pay, so the wallet constructs a payment to the output script
Bob's server provided. Unlike a traditional Bitcoin payment, Charlie's Bob's server provided. Unlike a traditional Bitcoin payment, Charlie's
wallet doesn't necessarily automatically broadcast this payment to the wallet doesn't necessarily automatically broadcast this payment to the
@ -384,7 +384,7 @@ After Bob's server verifies from the block chain that Charlie's
transaction has been suitably confirmed, it authorizes shipping transaction has been suitably confirmed, it authorizes shipping
Charlie's order. 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 [receipt][]{:#term-receipt}{:.term} out of the various signed or
otherwise-proven information. otherwise-proven information.