Small Changes To Devel Doc Based On Comments By @luke-jr & @mikehearn

_includes/guide_transactions.md:

* DOS expanded to "denial of service" to improve readability and avoid
  conflation with Disk Operating System. Change based on feedback from
  @luke-jr. Thanks!

_includes/guide_mining.md:

* Dropped assertion that `getblocktemplate` can't reuse an established
  socket. Change based on feedback from @luke-jr. Thanks!

_includes/guide_contracts.md:

* Dropped opening sentences to Contracts section, which were a holdover
  from when contracts was a subsection of Transactions. New opening
  sentence is now similar to the summary sentences which open all other
  sections. Change based on feedback from @mikehearn. Thanks!

* Deleted USA-centric example from second paragraph and merged remaining
  parts of the first two paragraphs into a single opening paragraph with
  no example. Change based on feedback from @mikehearn. Thanks!

* Removed mention of placeholder byte from multisig example. Change
  based on feedback from @mikehearn. Thanks!

_includes/guide_contracts.md

@@ -2,19 +2,12 @@
 
 {% 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
 agreements.
-
 Bitcoin contracts can often be crafted to minimize dependency on outside
 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
 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
 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
-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:
 
 {% endautocrossref %}

_includes/guide_mining.md

@@ -187,8 +187,8 @@ Merkle root field.
 
 Unlike `getblocktemplate`, miners using Stratum cannot inspect or add
 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
 peer-to-peer network.
 

_includes/guide_transactions.md

@@ -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
 transaction signers from using the method described above to cancel a
 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
 multiple signers to agree to update a transaction; when they finished
 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 %}
 
 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
 contains the signature, which can't sign itself, allowing attackers to
 make non-functional modifications to a transaction without rendering it