From c1d491ed39abee1136c07857a51e4b9d18cd820b Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Sun, 11 May 2014 07:27:57 -0400 Subject: [PATCH] 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 | 19 ++++++------------- _includes/guide_mining.md | 4 ++-- _includes/guide_transactions.md | 4 ++-- 3 files changed, 10 insertions(+), 17 deletions(-) diff --git a/_includes/guide_contracts.md b/_includes/guide_contracts.md index 7c72d9e0..b0279c8c 100644 --- a/_includes/guide_contracts.md +++ b/_includes/guide_contracts.md @@ -2,19 +2,12 @@ {% autocrossref %} -By making the system hard to understand, the complexity of transactions -has so far worked against you. That changes with contracts. Contracts are +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, -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. +of dealing with unknown entities in financial transactions. 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 -placeholder byte, and a copy of the unhashed serialized redeemScript +In the input section of the script, Alice puts her signature +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 -the placeholder byte with his signature, creating the following input +both Bob and Charlie. Either one of them can complete it by adding +his signature to create the following input script: {% endautocrossref %} diff --git a/_includes/guide_mining.md b/_includes/guide_mining.md index bea9b4bc..5049a11d 100644 --- a/_includes/guide_mining.md +++ b/_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 -stays open, so miners don't need to use longpoll to ensure they receive +`getblocktemplate`, the Stratum protocol uses a two-way TCP socket directly, +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. diff --git a/_includes/guide_transactions.md b/_includes/guide_transactions.md index 9f4e4041..8a1b4eb2 100644 --- a/_includes/guide_transactions.md +++ b/_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