Merge pull request #394 from harding/docsupdate1

Small Changes To Devel Doc Based On Comments
This commit is contained in:
David A. Harding 2014-05-11 14:18:03 -04:00
commit 0db9d5a544
3 changed files with 14 additions and 21 deletions

View file

@ -2,19 +2,12 @@
{% autocrossref %} {% autocrossref %}
By making the system hard to understand, the complexity of transactions Contracts are
has so far worked against you. That changes with contracts. Contracts are
transactions which use the decentralized Bitcoin system to enforce financial transactions which use the decentralized Bitcoin system to enforce financial
agreements. agreements.
Bitcoin contracts can often be crafted to minimize dependency on outside Bitcoin contracts can often be crafted to minimize dependency on outside
agents, such as the court system, which significantly decreases the risk agents, such as the court system, which significantly decreases the risk
of dealing with unknown entities in financial transactions. For example, of dealing with unknown entities in financial transactions.
Alice and Bob might only know each other casually over the Internet;
they would never open a checking account together---one of them could
pass bad checks, leaving the other on the hook. But with Bitcoin
contracts, they can nearly eliminate the risk from their relationship
and start a business even though they hardly know each other.
The following subsections will describe a variety of Bitcoin contracts The following subsections will describe a variety of Bitcoin contracts
already in use. Because contracts deal with real people, not just already in use. Because contracts deal with real people, not just
@ -85,11 +78,11 @@ so she creates and signs a transaction with two outputs, one that spends 60%
of the satoshis to Bob's public key and one that spends the remaining of the satoshis to Bob's public key and one that spends the remaining
40% to Charlie's public key. 40% to Charlie's public key.
In the input section of the script, Alice puts her signature, a 0x00 In the input section of the script, Alice puts her signature
placeholder byte, and a copy of the unhashed serialized redeemScript and a copy of the unhashed serialized redeemScript
that Bob created. She gives a copy of the incomplete transaction to that Bob created. She gives a copy of the incomplete transaction to
both Bob and Charlie. Either one of them can complete it by replacing both Bob and Charlie. Either one of them can complete it by adding
the placeholder byte with his signature, creating the following input his signature to create the following input
script: script:
{% endautocrossref %} {% endautocrossref %}

View file

@ -187,8 +187,8 @@ Merkle root field.
Unlike `getblocktemplate`, miners using Stratum cannot inspect or add Unlike `getblocktemplate`, miners using Stratum cannot inspect or add
transactions to the block they're currently mining. Also unlike transactions to the block they're currently mining. Also unlike
`getblocktemplate`, the Stratum protocol uses a two-way TCP socket which `getblocktemplate`, the Stratum protocol uses a two-way TCP socket directly,
stays open, so miners don't need to use longpoll to ensure they receive so miners don't need to use HTTP longpoll to ensure they receive
immediate updates from mining pools when a new block is broadcast to the immediate updates from mining pools when a new block is broadcast to the
peer-to-peer network. peer-to-peer network.

View file

@ -340,10 +340,10 @@ scriptSig: OP_0 <sig> <sig> <redeemscript>
**Pubkey** **Pubkey**
[Pubkey][]{:#term-pubkey}{:.term} scripts are a simplified form of the P2PH script; theyre used in all [Pubkey][]{:#term-pubkey}{:.term} scripts are a simplified form of the P2PH script,
coinbase transactions, but they arent as convenient but they arent as
or secure as P2PH, so they generally secure as P2PH, so they generally
arent used elsewhere. arent used in new transactions anymore.
{% endautocrossref %} {% endautocrossref %}
@ -503,7 +503,7 @@ transaction should be made a few hours before the time lock expires.
Previous versions of Bitcoin Core provided a feature which prevented Previous versions of Bitcoin Core provided a feature which prevented
transaction signers from using the method described above to cancel a transaction signers from using the method described above to cancel a
time-locked transaction, but a necessary part of this feature was time-locked transaction, but a necessary part of this feature was
disabled to prevent DOS attacks. A legacy of this system are four-byte disabled to prevent denial of service attacks. A legacy of this system are four-byte
[sequence numbers][sequence number]{:#term-sequence-number}{:.term} in every input. Sequence numbers were meant to allow [sequence numbers][sequence number]{:#term-sequence-number}{:.term} in every input. Sequence numbers were meant to allow
multiple signers to agree to update a transaction; when they finished multiple signers to agree to update a transaction; when they finished
updating the transaction, they could agree to set every input's updating the transaction, they could agree to set every input's
@ -615,7 +615,7 @@ fixed URI to which payments should be sent, please see the
{% autocrossref %} {% autocrossref %}
None of Bitcoin's signature hash types protect the scriptSig, leaving None of Bitcoin's signature hash types protect the scriptSig, leaving
the door open for a limited DOS attack called [transaction the door open for a limited denial of service attack called [transaction
malleability][]{:.term}{:#term-transaction-malleability}. The scriptSig malleability][]{:.term}{:#term-transaction-malleability}. The scriptSig
contains the signature, which can't sign itself, allowing attackers to contains the signature, which can't sign itself, allowing attackers to
make non-functional modifications to a transaction without rendering it make non-functional modifications to a transaction without rendering it