wiki commit

2020-11-04 13:23:02 -05:00
parent 7cb8fa7a00
commit f1fb956302
46 changed files with 611 additions and 350 deletions
@@ -1,11 +1,5 @@
 # Bitcoin Cash Specification Repository
-This repository contains markdown documentation that specifies the Bitcoin Cash cryptocurrency protocol.
+This repository contains markdown documentation that specifies the Bitcoin Cash cryptocurrency protocol.  However, this repository should not be directly used for normal browsing because this document uses some markdown extensions.
 However, this repository should not be directly used for normal browsing because this document uses some markdown extensions.
 Instead, read this documentation at one of the following places:
 - [reference.cash](http://reference.cash)
 - [documentation.cash](http://documentation.cash)
 - [bitcoinprotocol.cash](http://bitcoinprotocol.cash)
 Instead, read this documentation at [reference.cash](http://reference.cash)
@@ -0,0 +1 @@
 test C
@@ -0,0 +1 @@
 edit 1
@@ -0,0 +1,31 @@
 <div class="cwikmeta">
 {
 "title":"Glossary",
 "related":["/glossary/UTXO","/glossary/UTXO__set"]
 }
 </div>
 ## [A](#A)
 ## [B](#B)
 [Block](/glossary/block)
 ## [C](#C)
 [Constraint Script](/glossary/constraint__script)
 ## [H](#H)
 [Hash Identifier](/glossary/hash__identifier)
 ## [O](#O)
 [Outpoint](/glossary/outpoint)
 [Output Script](/glossary/output__script)
 ## [P](#P)
 [P2PKH](/glossary/p2pkh)
 [P2SH](/glossary/p2sh)
 ## [R](#R)
 [Redeem Script](/glossary/redeem__script)
 ## [T](#T)
 [Transaction](/glossary/transaction)
 ## [U](#U)
 [UTXO](/glossary/utxo)
 [UTXO set](/glossary/utxo__set)
@@ -0,0 +1,8 @@
 <div class="cwikmeta">
 {
 "title":"Block",
 "related":[]
 } </div>
 A block is a group of (transactions)[/glossary/transaction] that have been committed to the blockchain.
@@ -0,0 +1,10 @@
 <div class="cwikmeta">
 {
 "title":"Constraint Script",
 "related":["/glossary/output__script","/glossary/redeem__script","/glossary/input__script"]
 }
 </div>
 Bitcoins are not sent to addresses, they are actually encumbered by a program (generally called a script, which is a term for a short, simple program that typically focuses on one thing).  Spending transactions supply input parameters (in the form of an input script) to this constraint script.  If the constraint script returns success, the coins are able to be spent.  Otherwise the transaction is invalid.
 The term "constraint script" refers generally to any script that adds spending constraints.  In Bitcoin, there are actually two different scripts that can do this -- the [output script](/glossary/output__script) and the [redeem script](/glossary/redeem__script).
@@ -0,0 +1,11 @@
 A hash identifier is sequence of bytes derived from some source data that forms a probabilistically globally unique identifier that can be used to reference the source data.
 Hash identifiers are calculated by running a cryptographically secure hash function on the source data.  Due to the properties of cryptographic hash functions, it is theoretically very hard (and in practice, impossible given current or future processing power) to find 2 different pieces of source data that form the same hash identifier in a reasonable time frame.  
 This allows hash identifiers to be used in multiple applications, most importantly:
 - As a global "pointer" or "reference" to a piece of source data
 - As a "fingerprint" that identifies source data.
 - As a "commitment" that allows an entity to prove it knows some data at this time, without revealing that data until a later time. 
 In Bitcoin, hash identifiers (sometimes just called a "hash" for short) are generally calculated using a double sha256 algorithm: SHA256(SHA256(source data)), resulting an a 32 byte hash identifier.  However, when a smaller hash is desirable and Wagner's Birthday attack cannot be deployed, bitcoin sometimes uses RIPEMD(SHA256(source data)) which results in a 20 byte hash identifier.  Notably, this is used in standard ([P2PKH](/glossary/p2pkh)) bitcoin addresses.
@@ -0,0 +1 @@
 see [outpoint](/glossary/outpoint)
@@ -0,0 +1,4 @@
 <!-- TITLE: P2PKH -->
 <!-- SUBTITLE: Pay to Public Key Hash (script) -->
 A P2PKH script is the most common [constraint script](/glossary/constraint_script).
@@ -0,0 +1,12 @@
 <!-- TITLE: P2SH -->
 <!-- SUBTITLE: Pay To Script Hash (script) -->
 Pay to script hash is a special payment destination that consists of two [constraint scripts](/glossary/constraint__script).  The first is the output script which must follow a specific form that is recognised by bitcoin software.  This output script requires a parameter which is actually another constraint script, called the [redeem script](/glossary/redeem_script).  To spend a P2SH output, the input script therefore supplies the redeem script and additional data as stack parameters.  The bitcoin software verifies that the redeem script's hash matches that in the output script, and then executes the redeem script (which uses the additional data pushed by the input script).  Since the redeem script stack item is executed without any explicit instruction to do so, the P2SH script form breaks the original [script execution model](script/execution__model).
 ## Comparison with P2PKH
 The P2SH form places all interesting constraints in the redeem script, whereas previously these constraints were placed in the output script.  It is arguably better to place constraints in the redeem script for several reasons:
 1. Simple Addresses: P2SH allows the receiver to have funds sent to any constraint script, by providing the sender with an address.  Previously, a new address form had to be created for every new script type, or in theory the entire constraint script could be sent from receiver to sender (no protocol to do this has been specced or implemented).
 2. Information Containment:  In the original model, the sender places constraints on the receiver's __next__ spend.  But what the receiver does with the money next is and should be irrelevant to the sender, except in special circumstances.  In those circumstances, P2SH still works -- the receiver and sender can agree on the redeem script beforehand. 
 3. Space Efficiency: P2SH defers providing the redeem script until it is used, replacing it with a 20 byte hash.  For non-trivial scripts, this will make the [UTXO set](/glossary/UTXO__set) smaller.
 4. Privacy: P2SH does not reveal the script contents until it is spent.  One drawback of this is that it is not possible to determine whether certain instructions are in use or not.  This makes retirement of opcodes impossible.  However, its also possible for people to create transactions and not commit them to the blockchain, so the viability of opcode retirement is questionable anyway.
@@ -0,0 +1,3 @@
 <!-- TITLE: Redeem Script -->
 The redeem script is a constraint script that is used in the P2SH payment mode.  The redeem script is provided by the spender's input script, however, it is chosen by the original spender.  This is possible because the output script constrains the redeem script's hash to match a specific value.  In P2SH this is the only constraint allowed by the output script, so the redeem script must implement all other constraints (such as signature checking).
@@ -0,0 +1,4 @@
 <!-- TITLE: Transaction -->
 <!-- SUBTITLE: means of transfer -->
 A transaction is how transfers are made in the blockchain.  It comprises of a set of input [UTXOs](/glossary/UTXO) which will be spent to a set of output [UTXOs](/glossary/UTXO).  The blockchain mining and full node software ensures that every transaction follows the blockchain's rules before admitting the transaction into a block.  Verification of a transaction ensures that the input UTXOs have not already been spent, that quantity of input coins is greater than or equal to the quantity of output coins (any extra is given to the miner as a transaction fee), and that the transaction satisifies all spending constraints specified by the UTXO's constraint scripts.
@@ -0,0 +1,4 @@
 <!-- TITLE: UTXO -->
 <!-- SUBTITLE: Unspent Transaction Output -->
 An unspent transaction output, also called a "coin", is a record in the blockchain of money that can be spent (used as an input in a new transaction).  It is essentially a positive balance in the blockchain ledger, and contains a quantity and a spending constraint script.
@@ -1,21 +1,21 @@
 # Bitcoin Cash Protocol
-### About
+**About**
 [Style Guide](/style-guide) — [Contributors](/contributors) — [Target Audience](/target-audience) — [Project History](/project-history)
 ### Basics
-[Blockchain Basics](/protocol/blockchain) — [Protocol Hashing Algorithms](/protocol/blockchain/hash) — Memory Pool
+[Blockchain basics](/protocol/blockchain) — [Protocol hashing algorithms](/protocol/blockchain/hash) — Memory Pool
 ### Transactions
-[Bitcoin Transaction](/protocol/blockchain/transaction) — [Unlocking Script](/protocol/blockchain/transaction/unlocking-script) — [Locking Script](/protocol/blockchain/transaction/locking-script) — [Transaction Signing](/protocol/blockchain/transaction/transaction-signing)
+[Bitcoin Transaction](/protocol/blockchain/transaction) — [Unlocking Script](/protocol/blockchain/transaction/unlocking-script)— [Locking Script](/protocol/blockchain/transaction/locking-script)
 ### Blocks
-[Bitcoin Blocks](/protocol/blockchain/block) —
+[Bitcoin blocks](/protocol/blockchain/block) —
-[Block Header](/protocol/blockchain/block/block-header) — [Merkle Tree](/protocol/blockchain/block/merkle-tree) — [Transaction Ordering](/protocol/blockchain/block/transaction-ordering)
+[Block header](/protocol/blockchain/block/block-header) — [Merkle Tree](/protocol/blockchain/block/merkle-tree) — [Transaction Ordering](/protocol/blockchain/block/transaction-ordering)
 ### Script (Bitcoin transaction language)
-[Script](/protocol/blockchain/script) — [Operation Codes (opcodes)](/protocol/blockchain/script#operation-codes-opcodes)
+[Script](/protocol/blockchain/script) — [Operation codes (opcodes)](/protocol/blockchain/script#operation-codes-opcodes)
 ### Transaction validation
 [Transaction Validation](/protocol/blockchain/transaction-validation) —
@@ -25,35 +25,35 @@
 [Proof of Work](/protocol/blockchain/proof-of-work) — [Difficulty Adjustment Algorithm](/protocol/blockchain/proof-of-work/difficulty-adjustment-algorithm) — [Mining](/protocol/blockchain/proof-of-work/mining) — Stratum Protocol — Mining Pools
 ### Addresses
-Pay To Public Key (P2PK) — Pay To Public Key Hash (P2PKH) — Pay To Script Hash (P2SH) — [Base58Check encoding (legacy)](/protocol/blockchain/encoding/base58check) — [Cashaddr Encoding](/protocol/blockchain/encoding/cashaddr)
+Pay To Public Key (P2PK) — Pay To Public Key Hash (P2PKH) — Pay To Script Hash (P2SH) — [Base58Check encoding (legacy)](/protocol/blockchain/encoding/base58check) — [Cashaddr encoding](/protocol/blockchain/encoding/cashaddr)
 ### Cryptography
-Secp256k1 — Public Key — Private Key — ECDSA Signatures — Schnorr Signatures — [Multisignature (M-of-N multisig)](/protocol/blockchain/cryptography/multisignature)
+Secp256k1 — Public Key — Private Key — ECDSA signatures — Schnorr signatures — [Multisignature (M-of-N multisig)](/protocol/blockchain/cryptography/multisignature.md)
 ### Network upgrades
-[Bip-16](/protocol/forks/bip-0016) — [Bip-34](/protocol/forks/bip-0034) — [Bip-37](/protocol/forks/bip-0037) — [Bip-64](/protocol/forks/bip-0064) — [Bip-65](/protocol/forks/bip-0065) — [Bip-66](/protocol/forks/bip-0066) — [Bip-68](/protocol/forks/bip-0068) — [Bip-112](/protocol/forks/bip-0112) — [Bip-113](/protocol/forks/bip-0113) — [Bip-157](/protocol/forks/bip-0157) — [Bip-158](/protocol/forks/bip-0158) — [Bip-159](/protocol/forks/bip-0159) — [BCH-UAHF (BUIP-55)](/protocol/forks/bch-uahf) — [HF-20171113](/protocol/forks/hf-20171113) — HF-20180515 — HF-20181115 — HF-20190515 — HF-20191115
+[Bip-16](/protocol/forks/bip-0016) — [Bip-34](/protocol/forks/bip-0034) — [Bip-37](/protocol/forks/bip-0037) — [Bip-64](/protocol/forks/bip-0064) — [Bip-65](/protocol/forks/bip-0065) — [Bip-66](/protocol/forks/bip-0066) — [Bip-68](/protocol/forks/bip-0068) — [Bip-112](/protocol/forks/bip-0112) — [Bip-113](/protocol/forks/bip-0113) — [Bip-157](/protocol/forks/bip-0157) — [Bip-158](/protocol/forks/bip-0158) — [Bip-159](/protocol/forks/bip-0159) — BCH-UAHF (BUIP-55) — [HF-20171113](/protocol/forks/hf-20171113) — HF-20180515 — HF-20181115 — HF-20190515 — HF-20191115
 ### Network protocol
 [Network Messages](/protocol/network/messages) — [Handshake](/protocol/network/node-handshake)
-#### Announcement messages
+**Announcement messages**
-[filteradd](/protocol/network/messages/filteradd) — [filterclear](/protocol/network/messages/filterclear) — [filterload](/protocol/network/messages/filterload) — [inv](/protocol/network/messages/inv)
+[filteradd](/protocol/network/messages/filteradd.md) — [filterclear](/protocol/network/messages/filterclear.md) — [filterload](/protocol/network/messages/filterload.md) — [inv](/protocol/network/messages/inv.md)
-#### Request messages
+**Request messages**
-[feefilter](/protocol/network/messages/feefilter) — [getaddr](/protocol/network/messages/getaddr) — [getblocks](/protocol/network/messages/getblocks) — [getdata](/protocol/network/messages/getdata) — [getheaders](/protocol/network/messages/getheaders) — [ping](/protocol/network/messages/ping) —
+feefilter — getaddr — [getblocks](/protocol/network/messages/getblocks.md) — [getdata](/protocol/network/messages/getdata.md) — [getheaders](/protocol/network/messages/getheaders.md) — [ping](/protocol/network/messages/ping.md) —
-[sendheaders](/protocol/network/messages/sendheaders) — [version](/protocol/network/messages/version)
+sendheaders — [version](/protocol/network/messages/version.md)
-#### Response messages
+**Response messages**
-[addr](/protocol/network/messages/addr) — [block](/protocol/network/messages/block) — [headers](/protocol/network/messages/headers) — [notfound](/protocol/network/messages/notfound) — [merkleblock](/protocol/network/messages/merkleblock) — [pong](/protocol/network/messages/pong) —
+[addr](/protocol/network/messages/addr.md) — block — headers — notfound — [merkleblock](/protocol/network/messages/merkleblock.md) — [pong](/protocol/network/messages/pong.md) —
-[reject](/protocol/network/messages/reject) — [tx](/protocol/network/messages/tx) — [verack](/protocol/network/messages/verack)
+[reject](/protocol/network/messages/reject.md) — tx — [verack](/protocol/network/messages/verack.md)
-#### Other messages (extensions)
+**Other messages (extensions)**
-sendcmpct — get_xthin — xthinblock — thinblock — get_xblocktx — xblocktx — [xupdate](/protocol/network/messages/xupdate) — [xversion](/protocol/network/messages/xversion) — [xverack](/protocol/network/messages/xverack)
+sendcmpct — get_xthin — xthinblock — thinblock — get_xblocktx — xblocktx —[xverack](/protocol/p2p/xverack.md) — [xversion](/protocol/p2p/xversion.md)
 ### Simple Payment Verification (SPV)
 [Bloom Filters](/objects/bloom__filter)
@@ -0,0 +1,116 @@
 <div class="cwikmeta">
 {
 "title":"P2P Protocol",
 "related":[]
 } </div>
 The Bitcoin P2P protocol is comprised of messages over TCP.  These messages are serialized using a custom format.  Unlike RPC protocols, messages do not necessarily have a reply and there is no way to unambiguously connect a sent message to a reply, although many communications are often request/response pairs.   High performance full node software may handle incoming messages in parallel, so it is not appropriate to assume a message reply order.  Messages that cannot be fulfilled are sometimes dropped with no reply, and sometimes replied to via a REJECT message.
 These legacy design decisions can make the protocol difficult to implement on the client side, but are generally needed when a robust implementation communicates with untrusted/uncooperative partners.  A good strategy is to wait for any message that provides the required data, with a timeout, and then separately issue the request in a retry loop to multiple peers.  If a timeout occurs, return to higher level software which should re-assess whether the data is still needed, since in nodes in the network may have converged to a competing block or transaction, and therefore not be serving the data you are requesting (nodes only serve data on the most-difficult chain, even if they have some data pertaining to lower-difficulty splits).
 ## Serialization Format
 Bitcoin uses a custom serialization format that is generally little-endian.
 ## Message Envelope
 The following table describes the message header:
 | network identifier | command | size | checksum | contents |
 |-------------|--------------|-------------|----------------|------------|
 | 0: 4 bytes | 4: 12 bytes | 16: 4 bytes | 20: 4 bytes | 24: size bytes |
 |*BCH*:E3,E1,F3,E8<br>*BTC*:F9,BE,B4,D9<br>*tBCH*:F4,E5,F3,F4<BR>*tBTC*:0B,11,09,07 | ascii null extended | little endian uint32 | little endian uint32 | depends on command
 ### Network Identifier
 The network identifier is used to separate blockchains and test networks.  This reduces unnecessary load on peers, allowing them to rapidly ban nodes rather then forcing the peer to do a blockchain analysis before banning.  
 Unfortunately, the BCH and BSV blockchains use the same network identifier.
 ### Command
 The command is the exact lowercase bytes in the titles of each subsection in the Message Types section below followed by zeros -- e.g. the INV message's command is literally the 12 bytes: 'i','n',v',0,0,0,0,0,0,0,0,0.  This is not a "C" string.  If a command was exactly 12 bytes, there would be no null terminator!
 ### Size
 Size is the size of the contents field in bytes, not the size of the entire message.
 ### Checksum
 This field is a message checksum.  The checksum is calculated by first computing the double SHA256 of the *contents* portion of the message.  The first 4 bytes of this hash is the checksum. See [C++ generate](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.7.0.0/src/net.cpp#L3179), [python verify](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/eb264e627e231f7219e60eef41b4e37cc52d6d9d/qa/rpc-tests/test_framework/mininode.py#L409), [python generate](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/eb264e627e231f7219e60eef41b4e37cc52d6d9d/qa/rpc-tests/test_framework/mininode.py#L449).
 Since TCP has message integrity checksums, and a peer can cause another node to waste processing power validating bad checksums, it is not recommended that nodes verify this checksum.  That is, this field should be considered obsolete.
 However, senders should calculate and fill this checksum field to be compatible with all software, unless the [XVERSION](/protocol/p2p/xversion.md) message is used to tell peers that this checksum will not be verified (currently supported by *Bitcoin Unlimited*).  In this case the field **SHOULD** be set to 0 (but not enforced as 0 on the receiver's side).  This may allow a future reuse of this field.
 ### Contents
 The contents of messages are described in the next section.
 ## Message Contents
 ### Announcements (unsolicited messages with no response)
 #### [FILTERADD](/protocol/p2p/filteradd)
 *Add a single item into an existing filter*
 #### [FILTERCLEAR](/protocol/p2p/filterclear)
 *Remove an existing filter*
 #### [FILTERLOAD](/protocol/p2p/filterload)
 *Inserts a transaction and merkle block filter into the peer*
 #### [INV](protocol/p2p/inv)
 *Notifies peers about the existence of some information (generally a block or transaction)*
 #### [XUPDATE](/protocol/p2p/xupdate)
 *Communicates a change in peer capabilities*
 ### Requests
 #### [GETBLOCKS](/protocol/p2p/getblocks)
 *Requests block hash identifiers*
 #### [GETDATA](/protocol/p2p/getdata)
 *Requests information (generally previously announced via an INV) from a peer*
 #### [GETHEADERS](/protocol/p2p/getheaders)
 *Requests block headers from a peer*
 #### [PING](/protocol/p2p/ping)
 *Keep-alive*
 #### [VERSION](/protocol/p2p/version)
 *Describes peer capabilities*
 #### [XVERSION](/protocol/p2p/xversion)
 *Describes peer capabilities in an extensible manner*
 *Currently supported by Bitcoin Unlimited only*
 #### Responses
 Note that some of these "response" messages can also be sent without solicitation (i.e. without a request).
 #### [ADDR](/protocol/p2p/addr)
 *Provides a peer with the addresses of other peers*
 #### BLOCK, THINBLOCK, XTHINBLOCK, GRAPHENEBLOCK, CMPCTBLOCK
 *Provides a block*
 #### [HEADERS](/protocol/p2p/headers)
 *Provides a set of block headers (unsolicited or GETHEADERS response)*
 #### [MERKLEBLOCK](protocol/p2p/merkleblock)
 *Provides a provable subset of a block's transactions, as filtered by FILTERADD*
 #### [PONG](/protocol/p2p/pong)
 *Reply to a ping message*
 #### [REJECT](/protocol/p2p/reject)
 *General response by well-behaved clients if a message cannot be handled*
 #### [TX](/protocol/p2p/tx)
 *Transaction object*
 #### [VERACK](/protocol/p2p/verack)
 *Respond to a [version](/protocol/p2p/version) message*
 #### [XVERACK](/protocol/p2p/xverack)
 *Respond to an [xversion](/protocol/p2p/xversion) message*
@@ -22,7 +22,7 @@ Sibling blocks can happen if a block is created with sufficient work before the
 Sibling blocks are incompatible with one another, and eventually one will become orphaned.
 The [genesis block](/protocol/blockchain#genesis-block) is the first block in a chain, and has a block height of `0` (as its distance to the genesis block is zero).
-As of [BIP-34](/protocol/forks/bip-0034), the `block height` is included within the [coinbase transaction](/protocol/blockchain/block#coinbase-transaction).
+As of [BIP-0034](/blockchain/forks/bip-34), the `block height` is included within the [coinbase transaction](/protocol/blockchain/block#coinbase-transaction).
 ## Work
@@ -40,9 +40,3 @@ This requirement was added with version 2 blocks as a part of [BIP-34](/protocol
 Each coinbase transaction may only have one transaction input.
 Each coinbase transaction's unlocking script must be less than or equal to 100 bytes.
 ## Block Size
 The maximum block size for blocks is 32MB (32 * 1000 * 1000 bytes).
 The maximum number of transactions within a block is a function of this limit divided by the minimum transaction size, of 100 bytes.
 Other rules limit the number of transactions that may be within a block, including the number of signature operations ("sigops") within a block.
@@ -5,6 +5,7 @@ This specification does not explain what hashes are, nor the details of the spec
 Instead, this page will focus on which hashing algorithms are used, where they are used, and why they are used there.
 ## SHA-256
 [SHA-256](https://en.wikipedia.org/wiki/SHA-2) is widely used throughout the Bitcoin Cash protocol to identify blocks and transactions along with a variety of purposes in transaction scripts.
 The most notable uses of SHA-256 are:
@@ -24,16 +25,14 @@ Since [BIP-34](/protocol/forks/bip-0034), the block height is now required to be
 		 - `D5D27987D2A3DFC724E359870C6644B40E497BDC0589A033220FE15429D88599`
 		 - `E3BF3D07D4B0375638D5F1DB5255FE07BA2C4CB067CD81B84EE974B6585FB468`
 In contrast to many other protocols, Bitcoin Cash sometimes treats block and transaction hashes as a number, for example when comparing with block difficulty during block validation or mining.
 In these situations, the output byte array of the hashing algorithm is interpreted as a 256 bit number in little-endian format, particularly when transmitted over the network.
 This is the opposite of standard protocol design, so it may be simpler to think of hashes as byte arrays that occasionally are turned into little-endian numbers, than as numbers with a lot of display/encoding caveats.
 ## RIPEMD-160
 [RIPEMD-160](https://en.wikipedia.org/wiki/RIPEMD) is used in Bitcoin Cash scripts to create short, quasi-anonymous representations of payees for transactions.
 Since its brevity is also a potential liability for the anonymity it provides (since shorter hashes generally provide less collision-resistance), it is used in conjunction with SHA-256 when generating an address from a public key.
 That is, `(public key) -> SHA-256 -> RIPEMD-160 -> (address)`.
 This SHA-256 then RIPEMD-160 process has its own operation for ease-of-use, [OP_HASH160](/protocol/blockchain/script/op-codes/op-hash160).
- ## Murmur
+ 
 ## Murmur
 [MurmurHash](https://en.wikipedia.org/wiki/MurmurHash) is used in Bitcoin to support [Bloom filters](https://en.wikipedia.org/wiki/Bloom_filter).
 The specific version used is the MurmurHash version 3 (32-bit), with the first hash initialized to `(numberOfHashesRequired * 0xFBA4C795L + nonce)` where `nonce` is a randomly chosen 32-bit unsigned integer.
@@ -22,25 +22,14 @@ For more details on how the target is calculated, see [Difficulty Adjustment Alg
 ## Difficulty
-Though the term difficulty is often used colloquially to refer generally to the changes to the target as blocks are mined, it can also refer specifically to the integer value of one target divided by another.
+Though the term difficulty is often used colloquially to refer generally to the changes to the target as blocks are mined, it can also refer specifically to the integer value of one target divided by another.  Generally, the numerator is a base target, e.g. the [genesis block](/protocol/blockchain#genesis-block) target, while the denominator is the target of the block whose "difficulty" is to be calculated.  This results in two benefits relative to using targets directly:
 Generally, the numerator is a base target, e.g. the [genesis block](/protocol/blockchain#genesis-block) target, while the denominator is the target of the block whose "difficulty" is to be calculated.
 This results in two benefits relative to using targets directly:
 - **More Intuitive:** Higher numbers mean the block required more hashing power to mine, while lower number mean less hashing power was required.  Increased difficulty is easier to understand than decreased target, even though these means the same thing.
 - **More Manageable:** The difficulty calculation produces much more human-readable numbers than trying to interpret targets as an integer directory.
 ## Chainwork
-Chainwork is a representation of the work performed through a block's entire history.
+Chainwork is a representation of the work performed through a block's entire history.  It is calculated using the difficulties of each of the blocks in the chain.  The work for a single block is calculated as <code>2<sup>256</sup> / (target + 1)</code>, or equivalently in 256-bit two's-complement arithmetic, <code>(~target / (target + 1)) + 1</code>, where `~` is the bitwise NOT operation.  The chainwork for a block is the sum of its work with the work of all the blocks preceeding it.  As such, when a new block is mined, its chainwork is simply its work plus the chainwork of the block before it.
 It is the [expected](https://en.wikipedia.org/wiki/Expected_value) number of hashes required to re-solve every block in the chain.
 It is calculated using the difficulties of each of the blocks in the chain.
 The work for a single block is calculated as <code>2<sup>256</sup> / (target + 1)</code>, or equivalently in 256-bit two's-complement arithmetic, <code>(~target / (target + 1)) + 1</code>, where `~` is the bitwise NOT operation.
 The chainwork for a block is the sum of its work with the work of all the blocks preceeding it.
 As such, when a new block is mined, its chainwork is simply its work plus the chainwork of the block before it.
 This algorithm implies that summing chainwork makes sense.
 More formally, the expected number of hashes to solve one block candidate with work `W` is equal to the expected number of hashes to solve `N` block candidates with work `W/N`.
 This, and that chainwork is the expected number of hashes, is proved [here](/protocol/blockchain/chainwork-proof).
 ## Extra Nonce
@@ -6,8 +6,7 @@ Primarily, the `nonce` field is modified and can take any of its 2<sup>32</sup>
 Then, as needed, the merkle root is changed by modifying the [coinbase message](/protocol/blockchain/block#coinbase-transaction) to include an [extra nonce](/protocol/blockchain/proof-of-work#extra-nonce).
 In addition, the block timestamp is also updated occasionally to ensure that it remains reasonably current.
-As the two nonces are rapidly and systematically changed, and the resulting block hash rapidly changes to seemingly random values each time, there is an increasing likelihood that one of the hashes will be below the specified target.
+As the two nonces are rapidly and systematically changed, and the resulting block hash rapidly changes to seemingly random values each time, there is an increasing likelihood that one of the hashes will be below the specified target.  Once such a hash is found, the block is then broadcast to the network in hopes that no one else found a suitable block in the passing time.
 Once such a hash is found, the block is then broadcast to the network in hopes that no one else found a suitable block in the passing time.
 ## Types of Mining
@@ -15,5 +14,4 @@ Due to the various incentives for mining blocks, miners have employed a variety
 - **CPU Mining:** This was the initial approach, simply running the mining algorithm on a computer's processor, ideally multi-threaded so that for a CPU with N-cores (or [threads](https://en.wikipedia.org/wiki/Simultaneous_multithreading)), N candidate blocks could be hashed at a time, improving the throughput.
 - **[GPU](https://en.wikipedia.org/wiki/Graphics_processing_unit) Mining:** Since GPUs are particularly well-suited to parallel-processing, the use of GPUs allowed for significantly increased hashing power and, for a time, heavily increased the demand for high-end graphics cards.
- - **[ASIC](https://en.wikipedia.org/wiki/Application-specific_integrated_circuit) Mining:** Ultimately, purpose-built devices were created to perform mining as fast as physically possible.
+ - **[ASIC](https://en.wikipedia.org/wiki/Application-specific_integrated_circuit) Mining:** Ultimately, purpose-built devices were created to perform mining as fast as physically possible.  These devices rapidly consume power and produce a considerable amount of heat and the people that run then often seek out the lowest available power prices and invest in cooling solutions that keep their mining devices (often just referred to as "miners") running at peek performance.
 These devices rapidly consume power and produce a considerable amount of heat and the people that run then often seek out the lowest available power prices and invest in cooling solutions that keep their mining devices (often just referred to as "miners") running at peek performance.
@@ -84,13 +84,13 @@ Op codes marked with **(do not use)** are disallowed and will make a transaction
 | OP_TOALTSTACK   | 107   | 0x6b | x1                  | (alt) x1               | Puts the input onto the top of the alt stack. Removes it from the main stack. |
 | OP_FROMALTSTACK | 108   | 0x6c | (alt) x1            | x1                     | Puts the input onto the top of the main stack. Removes it from the alt stack. |
 | OP_IFDUP        | 115   | 0x73 | x                   | x / x x                | If the top stack value is not 0, duplicate it. |
-| OP_DEPTH        | 116   | 0x74 | Nothing             | &lt;stack size&gt;           | Puts the number of stack items onto the stack. |
+| OP_DEPTH        | 116   | 0x74 | Nothing             | <stack size>           | Puts the number of stack items onto the stack. |
 | OP_DROP         | 117   | 0x75 | x                   | Nothing                | Removes the top stack item.           |
 | OP_DUP          | 118   | 0x76 | x                   | x x                    | Duplicates the top stack item.        |
 | OP_NIP          | 119   | 0x77 | x1 x2               | x2                     | Removes the second-to-top stack item. |
 | OP_OVER         | 120   | 0x78 | x1 x2               | x1 x2 x1               | Copies the second-to-top stack item to the top. |
-| OP_PICK         | 121   | 0x79 | xn ... x2 x1 x0 n | xn ... x2 x1 x0 xn     | The item *n* back in the stack is copied to the top. |
+| OP_PICK         | 121   | 0x79 | xn ... x2 x1 x0 <n> | xn ... x2 x1 x0 xn     | The item *n* back in the stack is copied to the top. |
-| OP_ROLL         | 122   | 0x7a | xn ... x2 x1 x0 n | x(n-1) ... x2 x1 x0 xn | The item *n* back in the stack is moved to the top. |
+| OP_ROLL         | 122   | 0x7a | xn ... x2 x1 x0 <n> | x(n-1) ... x2 x1 x0 xn | The item *n* back in the stack is moved to the top. |
 | OP_ROT          | 123   | 0x7b | x1 x2 x3	           | x2 x3 x1	              | The top three items on the stack are rotated to the left. |
 | OP_SWAP         | 124   | 0x7c | x1 x2	              | x2 x1                  | The top two items on the stack are swapped. |
 | OP_TUCK         | 125   | 0x7d | x1 x2	              | x2 x1 x2	              | The item at the top of the stack is copied and inserted below the second-to-top item. |
@@ -110,7 +110,6 @@ Op codes marked with **(do not use)** are disallowed and will make a transaction
 |OP_NUM2BIN |128    |0x80|a b           |out     |Converts numeric value *a* into byte sequence of length *b*. Known as OP_LEFT before 2018-05-15.       |
 |OP_BIN2NUM |129    |0x81|x             |out     |Converts byte sequence *x* into a numeric value. Known as OP_RIGHT before 2018-05-15. |
 |OP_SIZE    |130    |0x82|x          |x size     |Pushes the string length of the top element of the stack (without popping it). |
 |OP_REVERSEBYTES |188 |0xbc |x |out     |Reverses the order of the bytes in byte sequence *x* so that the first byte is now its last byte, the second is now its second-to-last, and so forth. Enabled in [HF-20200515](/protocol/forks/hf-20200515). |
 ### Bitwise logic
@@ -167,17 +166,17 @@ Op codes marked with **(do not use)** are disallowed and will make a transaction
 | OP_CODESEPARATOR	      | 171  | 0xab | Nothing        | Nothing | Makes `OP_CHECK(MULTI)SIG(VERIFY)` use the subset of the script of everything after the most recently-executed OP_CODESEPARATOR when computing the sighash. | 
 | OP_CHECKSIG	           | 172  | 0xac | sig pubkey	    | true / false     | The last byte (=sighash type) of the signature is removed. The sighash for this input is calculated based on the sighash type. The truncated signature used by OP_CHECKSIG must be a valid ECDSA or Schnorr signature for this hash and public key. If it is valid, 1 is returned, if it is empty, 0 is returned, otherwise the operation fails. |
 | OP_CHECKSIGVERIFY      | 173  | 0xad | sig pubkey	    | Nothing / *fail* | Same as OP_CHECKSIG, but OP_VERIFY is executed afterward. |
-| OP_CHECKMULTISIG	      | 174  | 0xae | dummy sig1 sig2 ... &lt;#-of-sigs&gt; pub1 pub2 ... &lt;#-of-pubkeys&gt; | true / false | Signatures are checked against public keys. Signatures must be placed in the unlocking script using the same order as their corresponding public keys were placed in the locking script or redeem script. If all signatures are valid, 1 is returned, 0 otherwise. All elements are removed from the stack. For more information on the execution of this opcode, see [Multisignature](/protocol/blockchain/cryptography/multisignature). |
+| OP_CHECKMULTISIG	      | 174  | 0xae | dummy sig1 sig2 ... <# of sigs> pub1 pub2 ... <# of pubkeys> | true / false | Signatures are checked against public keys. Signatures must be placed in the unlocking script using the same order as their corresponding public keys were placed in the locking script or redeem script. If all signatures are valid, 1 is returned, 0 otherwise. All elements are removed from the stack. For more information on the execution of this opcode, see [Multisignature](/protocol/blockchain/cryptography/multisignature). |
-| OP_CHECKMULTISIGVERIFY | 175  | 0xaf | dummy sig1 sig2 ... &lt;#-of-sigs&gt; pub1 pub2 ... &lt;#-of-pubkeys&gt; | Nothing / *fail*  | Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward. |
+| OP_CHECKMULTISIGVERIFY | 175  | 0xaf | dummy sig1 sig2 ... <# of sigs> pub1 pub2 ... <# of pubkeys> | Nothing / *fail*  | Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward. |
 | OP_CHECKDATASIG        | 186  | 0xba | sig msg pubkey | true / false | Check if signature is valid for message and a public key. [See spec](/protocol/forks/op_checkdatasig) |
-| OP_CHECKDATASIGVERIFY | 187  | 0xbb | sig msg pubkey | nothing / *fail* | Same as OP_CHECKDATASIG, but runs OP_VERIFY afterward. |
+| OP_CHECKDATASIGVERIFY | 187  | 0xbb | sig msg pubkey | nothing / *fail* | Same as OP_CHECKDATASIG, but runs OP_VERIFY afterward. |
 ### Locktime
 | Word                   | Value   | Hex       | Input |Output     | Description                                     |
 | ---------------------- | ------- | --------- | ----- | --------- | ----------------------------------------------- |
-| OP_CHECKLOCKTIMEVERIFY | 177     | 0xb1      | x     |x / *fail* | Marks transaction as invalid if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed. Transaction is also invalid if 1. the stack is empty; or 2. the top stack item is negative; or 3. the top stack item is greater than or equal to 500000000 while the transaction's nLockTime field is less than 500000000, or vice versa; or 4. the input's nSequence field is equal to 0xffffffff. The precise semantics are described in [BIP65](/protocol/forks/bip-0065). |
+| OP_CHECKLOCKTIMEVERIFY | 177     | 0xb1      | x     |x / *fail* | Marks transaction as invalid if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed. Transaction is also invalid if 1. the stack is empty; or 2. the top stack item is negative; or 3. the top stack item is greater than or equal to 500000000 while the transaction's nLockTime field is less than 500000000, or vice versa; or 4. the input's nSequence field is equal to 0xffffffff. The precise semantics are described in BIP65. |
-| OP_CHECKSEQUENCEVERIFY | 178     | 0xb2      | x     |x / *fail* |  Marks transaction as invalid if the relative lock time of the input (enforced by BIP68 with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in [BIP112](/protocol/forks/bip-0112). |
+| OP_CHECKSEQUENCEVERIFY | 178     | 0xb2      | x     |x / *fail* |  Marks transaction as invalid if the relative lock time of the input (enforced by BIP68 with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in BIP112. |
 ### Reserved
@@ -188,7 +187,7 @@ Op codes marked with **(do not use)** are disallowed and will make a transaction
 ### Uncategorized
-Please help improve this article by categorizing and describing the following op codes.
+Please help improve this article by catigorizing and describing the following up codes.
 | Hex  | Word |
 | ---- | ---- |
@@ -198,6 +197,7 @@ Please help improve this article by categorizing and describing the following op
 | 0x66 | OP_VERNOTIF **(do not use)** |
 | 0x89 | OP_RESERVED1 **(do not use)** |
 | 0x8A | OP_RESERVED2 **(do not use)** |
 | 0xBC | OP_REVERSEBYTES **(disabled)** |
 | 0xBD - 0xFF | Unused **(disabled)** |
 ### Node-Specific Behavior
@@ -25,4 +25,3 @@ Furthermore, this coinbase's output is not considered an unspent transaction out
 Coinbases may only have one transaction input.
 All coinbase unlocking script must be less than or equal to 100 bytes in size.
@@ -15,10 +15,10 @@ Verification of a transaction ensures that:
 |--|--|--|--|
 | version | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The version of the transaction format.  Currently `0x02000000`. |
 | input count | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of inputs in the transaction. |
-| transaction inputs | variable | `input_count` [transaction inputs](#transaction-inputs) | Each of the transaction's inputs serialized in order. |
+| transaction inputs | variable | `input count` [transaction inputs](#transaction-inputs) | Each of the transaction's inputs serialized in order. |
 | output count | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of output in the transaction. |
-| transaction outputs | variable | `output_count` [transaction outputs](#transaction-outputs) | Each of the transaction's outputs serialized in order. |
+| transaction outputs | variable | `output count` [transaction outputs](#transaction-outputs) | Each of the transaction's outputs serialized in order. |
-| lock-time | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The block height or timestamp after which this transaction is allowed to be included in a block.  If less than `500,000,000`, this is interpreted as a block height.  If equal or greater than `500,000,000`, this is interpreted as a unix timestamp in seconds. Ignored if all of the transaction input sequence numbers are `0xFFFFFFFF`.<br/><br/>Note that at 10 minutes per block, it will take over 9,500 years to reach block height 500,000,000.  Also note that when Bitcoin was created the unix timestamp was well over 1,000,000,000.<br/><br/>Additionally, since [BIP-113](/protocol/forks/bip-0113), when the lock-time is intepreted as a time, it is compared to the [median-time-past](#median-time-past) of a block, not it's timestamp. |
+| lock-time | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The block height or timestamp after which this transaction is allowed to be included in a block.  If less than `500,000,000`, this is interpreted as a block height.  If more than `500,000,000`, this is interpreted as a unix timestamp in seconds.  Ignored if all of the transaction input sequence numbers are `0xFFFFFFFF`.<br/><br/>Note that at 10 minutes per block, it will take over 9,500 years to reach block height 500,000,000.  Also note that when Bitcoin was created the unix timestamp was well over 1,000,000,000.<br/><br/>Additionally, since [BIP-113](/protocol/forks/bip-0113), when the lock-time is intepreted as a time, it is compared to the [median-time-past](#median-time-past) of a block, not it's timestamp. |
 ### Median-Time-Past
@@ -74,7 +74,7 @@ A Transaction Output that is being spent by a Transaction Input is often referre
 | Field | Length | Format | Description |
 |--|--|--|--|
 | value | 8 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The number of satoshis to be transferred. |
-| locking script length | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the locking script in bytes. |
+| locking script length | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the unlocking script in bytes. |
 | locking script | variable | bytes<sup>[(BE)](/protocol/misc/endian/big)</sup> | The contents of the locking script. |
 ## Transaction Fee
@@ -1,130 +1,65 @@
 # Transaction Signing
-# Transaction Signatures
+Generally, every input of a [transaction](/protocol/blockchain/transaction) require one or more signature. The signatures enforce (sign) what the transaction looks like and make it impossible for a third party to temper with without invalidating the transaction. 
-Transaction signatures are central to how [Bitcoin Cash transactions](/protocol/blockchain/transaction) are generally secured, preventing people other than the intended recipient of funds from spending them.  Bitcoin Cash signatures are created using [asymmetric cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography) and involve generating a [hash](/protocol/blockchain/hash) of the transaction and performing a signature operation using the sender's private key.  Anyone with the corresponding public key can then verify the validity of the signature.  As described in [Standard Scripts](/protocol/blockchain/transaction/locking-script#standard-scripts), the [OP_CHECKSIG and related operations](/protocol/blockchain/script#cryptography) are used to validate signatures included in the unlocking script of a future transaction input.
+This applies to any input whose previous output [locking script](/protocol/blockchain/transaction/locking-script) includes one of the following [operation codes](/protocol/blockchain/script#operation-codes-opcodes): `OP_CHECKSIG`, `OP_CHECKSIGVERIFY`, `OP_CHECKMULTISIG`, `OP_CHECKMULTISIGVERIFY`. In scripts using these opcodes, *signatures* are checked against *public keys* and the transaction signature (as described below).
-However, there are a number of issues with signing a transaction that must be addressed:
+The `OP_CHECKSIG` and `OP_CHECKSIGVERIFY` opcodes require a sigle signature which is checked against a single public key:
-  1. Transactions are identified by hashes of the full contents of the transaction
+```
-  2. The signatures are a part of the transaction data
+<sig> <pubkey> CHECKSIG(VERIFY)
-  3. The signatures are created from a hash of the transaction's data
+```
-Points (1) and (2) mean that if the signature is changed, the transaction's hash will change.  Points (2) and (3) mean that the data that the signature hash preimage (i.e. the data that is hashed and signed) must not be the full transaction data. In addition, because signatures relate only to a single input to a transaction (i.e. spending an unspent transaction output or UTXO) the may be multiple signatures in a transaction potentially created by different private keys, or even different people.
+For `OP_CHECKMULTISIG` and `OP_CHECKMULTISIGVERIFY` behavior, see [Multisignature spec](/protocol/blockchain/cryptography/multisignature).
-As a consequence of these factors, signatures have more parameters than may be immediately obvious, and the details of how signatures are generated can be, and have been, changed in a number of ways.  These parameters are encoded in the [Hash Type](#hash-type).
+## Transaction Digest Algorithm (Preimage Format) 
 In addition, as a part of [BCH-UAHF](/protocol/forks/bch-uahf) (activated in block 478,559), the transaction signed format changed from the legacy [Bitcoin (BTC) method](#btc-signatures) to the [Bitcoin Cash (BCH) Signatures](#bch-signatures).  In both cases, there is a signature preimage format (input) and a signature format (output).
 ### Hash Type
 Parameters that change the way a signature hash is generated are encoded in the hash type field.
 This field (which is always included in the preimage), is contained in 4 bytes.
 The two least significant bits have the following collective meaning:
 | Value | Meaning |
 |--|--|
 | `0x01` | `SIGHASH_ALL`.  This is the default and indicates that all outputs are included in the signature preimage. |
 | `0x02` | `SIGHASH_NONE`.  Indicates that no outputs are included in the signature preimage. |
 | `0x03` | `SIGHASH_SINGLE`.  Indicates that only the output with the same index as the input the signature is being generated for will be included in the signature preimage. |
 In conjunction with the above values, the higher-order bits act as a bitmask with the following meaning:
 | Bit | Meaning |
 |--|--|
 | `0x00000040` | `SIGHASH_FORKID`.  If set, indicates that this signature is for a Bitcoin Cash transaction.  Required following BCH-UAHF, to prevent transactions from being valid on both the BTC and BCH chains. |
 | `0x00000080` | `SIGHASH_ANYONECANPAY`.  Indicates that only information about the input the signature is for will be included, allowing other inputs to be added without impacting the signature for the current input. |
 Combining these, there are 6 valid signature hash types in Bitcoin Cash.  Only the least significant byte (LSB) is shown in binary, since the rest of the bits are zero.
 | Signature hash type                                      | Value (hex) | LSB (bin)   |  Description                                                          |
 | -------------------------------------------------------- | ----------- | ----------- | --------------------------------------------------------------------- |
 | SIGHASH_ALL \| SIGHASH_FORKID                            | 0x00000041  | 0b01000001  | Signature applies to all inputs and outputs.                          |
 | SIGHASH_NONE \| SIGHASH_FORKID                           | 0x00000042  | 0b01000010  | Signature applies to all inputs and none of the outputs.              |
 | SIGHASH_SINGLE \| SIGHASH_FORKID                         | 0x00000043  | 0b01000011  | Signature applies to all inputs and the output with the same index.   |
 | SIGHASH_ALL \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID    | 0x000000C1  | 0b11000001  | Signature applies to its own input and all outputs.                   |
 | SIGHASH_NONE \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID   | 0x000000C2  | 0b11000010  | Signature applies to its own input and none of the outputs.           |
 | SIGHASH_SINGLE \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID | 0x000000C3  | 0b11000011  | Signature applies to its own input and the output with the same index.|
 ## BCH Signatures
 In Bitcoin Cash, transaction signature uses the transaction digest algorithm described in [BIP143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki), in order to minimize redundant data hashing in verification and to cover the input value by the signature.
-### Preimage Format
+Since it is impossible to sign signatures themselves, it is necessary to have a *preimage* which represents the transaction without signatures. Therefore, a preimage must be built for any input which requires a transaction signature.
-| Field | Length | Format | Description |
+The preimage consists of the following elements:
 |--|--|--|--|
 | transaction version | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The value of transaction's version field. |
 | previous outputs hash | 32 bytes | hash<sup>[(BE)](/protocol/misc/endian/big)</sup> | A double SHA-256 hash of the set of previous outputs spent by the inputs of the transaction.  See [Previous Outputs](#previous-outputs-hash) for the hash preimage format.<br/><br/>If hash type is "ANYONE CAN PAY" then this is all `0x00` bytes.  |
 | sequence numbers hash | 32 bytes | hash<sup>[(BE)](/protocol/misc/endian/big)</sup> | A double SHA-256 hash of the set of sequence numbers of the inputs of the transaction.  See [Sequence Numbers](#sequence-numbers-hash) for the hash preimage format.<br/><br/>If hash type is "ANYONE CAN PAY" then this is all `0x00` bytes.  |
 | previous output hash | 32 bytes | hash<sup>[(LE)](/protocol/misc/endian/little)</sup> | The transaction ID of the previous output being spent. |
 | previous output index | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The index of the output to be spent. |
 | modified locking script length | variable | [variable length integer](/protocol/format/variable-length-integer) | The number of bytes for `modified_locking_script`. |
 | modified locking script | `modified_locking_script_length` bytes | bytes<sup>[(BE)](/protocol/misc/endian/big)</sup> | The subset of the locking script used for signing.  See [Modified Locking Script](#modified-locking-script) |
 | previous output value | 8 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The value of the transaction output being spent. |
 | input sequence number | 8 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The sequence number of the input this signature is for. |
 | transaction outputs hash | 32 bytes | hash<sup>[(BE)](/protocol/misc/endian/big)</sup> | A double SHA-256 hash of the outputs of the transaction.  See [Transaction Outputs](#transaction-outputs-hash) for the hash preimage format.  |
 | transaction lock time | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The lock time of the transaction. |
 | hash type | 4 bytes | [Hash Type](#hash-type)<sup>[(LE)](/protocol/misc/endian/little)</sup> | Flags indicating the rules for how this signature was generated. |
-#### Previous Outputs Hash
+| Field                               | Length   | Format                                                               | Description                                                 |
 | ----------------------------------- | -------- | -------------------------------------------------------------------- | ----------------------------------------------------------- |
 | version                             | 4 bytes  | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup>      | The version of the transaction format. Currently `1` or `2`. |
 | previous outputs hash               | 32 bytes | hash<sup>[(BE)](/protocol/misc/endian/big)</sup>                     | The double SHA256 of the serialization of **all** input outpoints (txids + indexes) of the transaction. If the `SIGHASH_ANYONECANPAY` flag is set, it is `0x00...00`. |
 | sequences hash                      | 32 bytes | hash<sup>[(BE)](/protocol/misc/endian/big)</sup>                     | The double SHA256 of the serialization of **all** input sequences of the transaction. If `SIGHASH_ANYONECANPAY`, `SIGHASH_SINGLE` or `SIGHASH_NONE` is used, this field is `0x00...00`. |
 | previous output transaction id      | 32 bytes | hash<sup>[(LE)](/protocol/misc/endian/big)</sup>                     | The identifier of the transaction containing the previous output, i.e., the output spent by this input. |
 | previous output index               | 4 bytes  | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup>      | The index of the previous output inside the transaction.    |
 | previous output locking script size | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the previous locking script in bytes.           |
 | previous output locking script      | variable | bytes<sup>[(BE)](/protocol/misc/endian/big)</sup>                    | The locking script of the output spent by this input. If the previous output is a P2SH output, then this field must be the redeem script. |
 | previous output value               | 8 bytes  | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup>      | The value in satoshis of the output spent by this input.    |
 | sequence number                     | 4 bytes  | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup>      | The sequence number of this input.                          |
 | outputs hash                        | 32 bytes | hash<sup>[(BE)](/protocol/misc/endian/big)</sup>                     | The double SHA256 of the serialization of **all** output values and locking scripts (including size) of the transaction. If `SIGHASH_SINGLE` is used: if this input index is smaller than the number of outputs, this field is the double SHA256 of the output value and locking script of the same index as the input; otherwise it is `0x00...00`. If `SIGHASH_NONE` is used, this field is `0x00...00`. |
 | locktime                            | 4 bytes  | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup>      | The locktime of the transaction.                            |
 | signature hash type                 | 4 bytes  | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup>      | The signature hash type used to sign this input. See description below.  |
-The double-SHA256-hash of the following data is used.
+The signing algorithm (whether it is ECDSA or Schnorr algorithm) is applied to **the double SHA256 hash of this preimage**.
-For each transaction input in the transaction, append the following information:
+## Signature Hash Type
-| Field | Length | Format | Description |
+A signature (ECDSA or Schnorr) is ALWAYS followed by the signature hash type used to sign the input. Signature hash type indicates which part of the transaction is hashed to be signed.
 |--|--|--|--|
 | previous transaction hash | 32 bytes | bytes<sup>[(LE)](/protocol/misc/endian/little)</sup> | The hash of the transaction that generated the output to be spent. |
 | output index | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The index of the output to be spent from the specified transaction. |
-#### Sequence Numbers Hash
+Version and locktime are always signed. All inputs are included unless the `SIGHASH_ANYONECANPAY` flag is set.
-The double-SHA256-hash of the following data is used.
+The signature hash flags are:
-For each transaction input in the transaction, append the following information:
+| Flag                 | Value (hex) | Value (bin) |  Description                             |
 | -------------------- | ----------- | ----------- | ---------------------------------------- |
 | SIGHASH_ALL          | 0x01        | 0b00000001  | Sign all outputs.                        |
 | SIGHASH_NONE         | 0x02        | 0b00000010  | Sign none of the outputs.                |
 | SIGHASH_SINGLE       | 0x03        | 0b00000011  | Sign only the ouput with the same index. |
 | SIGHASH_ANYONECANPAY | 0x80        | 0b10000000  | Sign only its own input.                 |
 | SIGHASH_FORKID       | 0x40        | 0b01000000  | Bitcoin Cash modifier flag.              |
-| Field | Length | Format | Description |
+Signature hash flags are combined using the bitwise OR operator (`|`) in order to get the **signature hash type** of the input. There are 6 valid signature hash types in Bitcoin Cash:
 |--|--|--|--|
 | sequence number | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The sequence number field of the transaction input. |
 #### Modified Locking Script
 The locking script included in the signature preimage is, first, dependent on the type of locking script included in the previous output.  For non-[P2SH](/protocol/blockchain/transaction/locking-script#pay-to-script-hash-p2sh) outputs, the locking script itself is used.  However, for P2SH outputs, the redeem script is used instead.
 Second, the selected script (locking script or redeem script) is modified as follows.
 * Find the [`OP_CODESEPARATOR`](/protocol/blockchain/script#cryptography) operation in the script preceding the expected [signature-verification operation](/protocol/blockchain/script#cryptography) (e.g. `OP_CHECKSIG`).
 * Remove all operations before this point.
 * Remove any remaining `OP_CODESEPARATOR` operations.
 The resulting script is what is included in the signature preimage.
 #### Transaction Outputs Hash
 If the hash type is `SIGHASH_NONE` then the hash should be all `0x00` bytes.
 If hash type is `SIGHASH_SINGLE` then only the output with the same index as the input being signed is included.
 If no such output exists (i.e. there are fewer outputs than the index of the input to be signed), this is again all `0x00` bytes.
 Otherwise, all outputs of the transaction should be signed (i.e. `SIGHASH_ALL`).
 For each transaction output to be signed (per the hash mode), append the following information:
 | Field | Length | Format | Description |
 |--|--|--|--|
 | value | 8 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The number of satoshis to be transferred. |
 | locking script length | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the locking script in bytes. |
 | locking script | variable | bytes<sup>[(BE)](/protocol/misc/endian/big)</sup> | The contents of the locking script. |
 ### Signature Format
 ## BTC Signatures
 ### Preimage Format
 ### Signature Format
 | Signature hash type                                      | Value (hex) | Value (bin) |  Description                                                          |
 | -------------------------------------------------------- | ----------- | ----------- | --------------------------------------------------------------------- |
 | SIGHASH_ALL \| SIGHASH_FORKID                            | 0x41        | 0b01000001  | Signature applies to all inputs and outputs.                          |
 | SIGHASH_NONE \| SIGHASH_FORKID                           | 0x42        | 0b01000010  | Signature applies to all inputs and none of the outputs.              |
 | SIGHASH_SINGLE \| SIGHASH_FORKID                         | 0x43        | 0b01000011  | Signature applies to all inputs and the output with the same index.   |
 | SIGHASH_ALL \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID    | 0xc1        | 0b11000001  | Signature applies to its own input and all outputs.                   |
 | SIGHASH_NONE \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID   | 0xc2        | 0b11000010  | Signature applies to its own input and none of the outputs.           |
 | SIGHASH_SINGLE \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID | 0xc3        | 0b11000011  | Signature applies to its own input and the output with the same index.|
@@ -5,4 +5,4 @@ This is accomplished by first executing the unlocking script and then executing
 If this execution triggers no failures and leaves a single non-zero (TRUE) value on the stack, the UTXO has been successfully unlocked.
 One way to look at this is that the unlocking script provides an initial state that acts as an inverse to the previously published locking script.
-For more information about how script execution works, see [Script](/protocol/blockchain/script).  For information on how signatures (which typically go in the unlocking script) are generated, see [Transaction Signatures](/protocol/blockchain/transaction/signatures).
+For more information about how script execution works, see [Script](/protocol/blockchain/script).
@@ -1,18 +1,11 @@
 # P2P Network Message
-The Bitcoin Cash Peer-to-Peer (P2P) Network protocol is a binary protocol used by Full Nodes and [SPV](/protocol/simple-payment-verification) Nodes, transmitted over TCP/IP.
+The Bitcoin Cash Peer-to-Peer (P2P) Network protocol is a binary protocol used by Full Nodes and [SPV](/protocol/simple-payment-verification) Nodes, transmitted via TCP.
-Individual nodes on the Bitcoin Cash network connect and create a mesh network where each node is indirectly connected to many others via just a couple of hops.
+The P2P network is similar to a gossip network, where nodes listen for messages and then relays that message to its other peers if it believes that message's content is valid.
 In the original Satoshi implementation of the P2P protocol the design of INV and getdata have been used for propagating transaction data using the rules of the gossip protocol values: forwarding validated transactions to a few peer-nodes who send it to others until the entire network has the transaction.
 This emergent behavior of the P2P layer allows fast propagation without undue strain on any individual node.
-The P2P protocol is designed around messages.
+P2P network messages do not necessarily have a reply and there is no way to unambiguously connect a sent message to a reply, although many communications are often request/response pairs.
-Each message is separate and self-contained.
+Nodes may handle incoming messages in parallel, so a message reply order cannot be assumed.
-Nodes should be tolerant of message-types they do not understand.
+Messages that cannot be fulfilled are sometimes dropped with no reply, and sometimes replied to via a `reject` message.  
 It is best to simply ignore those.
 Generally speaking, each message is an event that the node can choose to respond to.
 Events can be notifications of new data (transactions/blocks/etc), requests for such data to be sent, or the sending of the data itself.
 In some specific cases a message can indicate the rejection of another message, though this is optional and should not be relied upon.
 These design decisions were made with consideration to communication with untrusted/uncooperative partners.
@@ -23,24 +16,24 @@ These design decisions were made with consideration to communication with untrus
 The P2P network has a variety of message types.
 All P2P messages follow a binary format with the following structure:
 | Field | Length | Format | Description |
 |--|--|--|--|
 | net magic | 4 bytes | byte array<sup>[(BE)](/protocol/misc/endian/big)</sup> | See [net magic](#net-magic). |
 | command string | 12 bytes | string<sup>[(BE)](/protocol/misc/endian/big)</sup> | See [command string](#command-string).
 | payload byte count | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The size of the payload.  The total max size of any message is `268,435,456` bytes (256 MiB), and the header for a message is always 24 bytes, therefore the max value of the payload byte count is `268,435,432` bytes, while the min value is zero (indicating no additional payload). |
 | payload checksum | 4 bytes | byte array<sup>[(BE)](/protocol/misc/endian/big)</sup> | The message checksum is the first 4 bytes of a double-sha256 hash of the payload. |
 | payload | variable | message-specific | See [message types](#message-types) for links to message-specific page, which describe the payload for each message. |
-See [Example Message](#example-message) for a concrete example of this with a message that does not contain an extended payload.
+| Field | Length | Format |
 |--|--|--|
 | net magic | 4 bytes | byte array<sup>[(BE)](/protocol/misc/endian/big)</sup> |
 | command string | 12 bytes | string<sup>[(BE)](/protocol/misc/endian/big)</sup> |
 | payload byte count | 4 bytes | integer<sup>[(LE)](/protocol/misc/endian/little)</sup> |
 | payload checksum | 4 bytes | byte array<sup>[(BE)](/protocol/misc/endian/big)</sup> |
 | payload | variable |  |
 ### Net Magic
 The network identifier is used to separate blockchains and test networks.
 This reduces unnecessary load on peers, allowing them to rapidly ban nodes rather then forcing the peer to do a blockchain analysis before banning or disconnecting.
-For Bitcoin Cash main net, the `net magic` field is always `0xE3E1F3E8` (the ASCII string, "cash", with each byte's highest bit set).
+For Bitcoin Cash main net, the `net magic` field is always `E3E1F3E8`.
 Any message received that does not begin with the `net magic` is invalid.
 The `net magic` is designed to be unlikely to occur in normal data--the characters are rarely used upper ASCII, are not valid as UTF-8, and produce a large 32-bit integer with any alignment.
 `E3E1F3E8` is the ASCII string, "cash", with each byte's highest bit set.
 ### Command String
@@ -50,43 +43,45 @@ Commands that are shorter than 12 bytes are right-padded with null bytes (`0x00`
 The command string is used to determine the type of message being transmitted.
 Messages with an unrecognized `command string` are ignored by most implementations but may result in a ban by implementations that diverge from the Satoshi-client defacto standard.
-### Message Types
+The following messages are considered standard by all node implementations.
 #### Announcements
-| Command String | Synopsis |
+| Command String | Synopsis | Supported Implementations
-| -- | -- |
+| -- | -- | -- |
-| [filteradd](/protocol/network/messages/filteradd) | *Adds a single item into an installed filter* |
+| [filteradd](/protocol/p2p/filteradd) | *Adds a single item into an installed filter* | all
-| [filterclear](/protocol/network/messages/filterclear) | *Removes an installed filter* |
+| [filterclear](/protocol/p2p/filterclear) | *Removes an installed filter* | all
-| [filterload](/protocol/network/messages/filterload) | *Inserts a transaction and merkle block filter into the peer* |
+| [filterload](/protocol/p2p/filterload) | *Inserts a transaction and merkle block filter into the peer* | all
-| [inv](/protocol/network/messages/inv) | *Notifies peers about the existence of some information (generally a block or transaction)* |
+| [inv](/protocol/p2p/inv) | *Notifies peers about the existence of some information (generally a block or transaction)* | all
  | [xupdate](/protocol/p2p/xupdate)  | *Communicates a change in peer capabilities* | BCHUnlimited
 #### Requests
-| Command String | Synopsis |
+| Command String | Synopsis | Supported Implementations
-| -- | -- |
+| -- | -- | -- |
-| [feefilter](/protocol/network/messages/feefilter) | *Requests that transactions without sufficient fees are not relayed* |
+| feefilter |  |
-| [getaddr](/protocol/network/messages/getaddr) | *Requests a list of active peers* |
+| getaddr |  |
-| [getblocks](/protocol/network/messages/getblocks) | *Requests block hash identifiers* |
+| [getblocks](/protocol/p2p/getblocks) | *Requests block hash identifiers* | all |
-| [getdata](/protocol/network/messages/getdata) | *Requests information from a peer* |
+| [getdata](/protocol/p2p/getdata) | *Requests information from a peer* | all |
-| [getheaders](/protocol/network/messages/getheaders) | *Requests block headers from a peer*  |
+| [getheaders](/protocol/p2p/getheaders) | *Requests block headers from a peer*  | all |
-| [ping](/protocol/network/messages/ping) | *Requests a confirmation (pong) that the peer is still active* |
+| ping | [Ping](/protocol/network/messages/ping) | all |
-| [sendheaders](/protocol/network/messages/sendheaders) | *Requests that new blocks are sent as headers instead of hashes* |
+| sendheaders |  |
-| [version](/protocol/network/messages/version) | *Describes peer capabilities* |
+| [version](/protocol/network/messages/version) | *Describes peer capabilities* | all
 | [xversion](/protocol/p2p/xversion) | *Describes peer capabilities in an extensible manner* | BCHUnlimited
 #### Responses
-| Command String | Synopsis |
+| Command String | Synopsis | Supported Implementations
-| -- | -- |
+| -- | -- | -- |
-| [addr](/protocol/network/messages/addr) | *Provides a peer with the addresses of other peers* |
+| [addr](/protocol/p2p/addr) | *Provides a peer with the addresses of other peers* | all
-| [block](/protocol/network/messages/block) | *Provides the contents of a block* |
+| block |  |
-| [headers](/protocol/network/messages/headers) | *Provides a set of block headers (unsolicited or GETHEADERS response)* |
+| [headers](/protocol/p2p/headers) | *Provides a set of block headers (unsolicited or GETHEADERS response)* | all |
-| [notfound](/protocol/network/messages/notfound) | *Indicates that a requested resource could not be relayed* |
+| notfound |  |
-| [merkleblock](/protocol/network/messages/merkleblock) | *Provides a provable subset of a block's transactions, as filtered by FILTERADD* |
+|  [merkleblock](protocol/p2p/merkleblock) | *Provides a provable subset of a block's transactions, as filtered by FILTERADD*  | all |
-| [pong](/protocol/network/messages/pong) | *Reply to a ping message* |
+| [Pong](/protocol/network/messages/pong) | *Reply to a ping message* | all |
-| [reject](/protocol/network/messages/reject) | *Response by well-behaved clients if a message cannot be handled* |
+| [reject](/protocol/p2p/reject) | *Response by well-behaved clients if a message cannot be handled*  | all
-| [tx](/protocol/network/messages/tx) | *Provides a transaction* |
+| [TX](/protocol/p2p/tx) | *Provide a transaction* | all
-| [verack](/protocol/network/messages/verack) | *Response to a [version](/protocol/network/messages/version) message* |
+| [verack](/protocol/network/messages/verack) | *Respond to an [xversion](/protocol/p2p/xversion) message* | all
-#### Other Message Types (Extensions)
+The following messages are well known, but not implemented by all node implementations.
 | Command String | Synopsis | Supported Implementations
 | -- | -- | -- |
@@ -97,24 +92,22 @@ Messages with an unrecognized `command string` are ignored by most implementatio
 | thinblock |  |  |
 | xblocktx |  |  |
 | xthinblock |  |  |
 | [xupdate](/protocol/network/messages/xupdate)  | *Communicates a change in peer capabilities* | BCHUnlimited
 | [xversion](/protocol/network/messages/xversion) | *Describes peer capabilities in an extensible manner* | BCHUnlimited
 | [xverack](/protocol/network/messages/xverack) | *Response to an [xversion](/protocol/network/messages/xversion) message* | BCHUnlimited
-## Example message
+### Payload Byte Count
-The below segments, when concatenated in order, create a sample [verack](/protocol/network/messages/verack) message.
+The payload byte count is the size of the payload, encoded as a [little-endian](/protocol/misc/endian/little) 4-byte integer.
 The total max size of any message is `268,435,456` bytes (256 MiB), and the header for a message is always 24 bytes, therefore the max value of the payload byte count is `268,435,432` bytes.
 The payload byte count may be zero, but must not be negative.
-| Label | Sample Value (Hexadecimal Representation) |
+### Payload Checksum
 |-------|------|
 | Net Magic<sup>[(BE)](/protocol/misc/endian/little)</sup> | `E3E1F3E8` |
 | Command String ("verack")<sup>[(BE)](/protocol/misc/endian/big)</sup> | `76657261636B000000000000` |
 | Payload Byte Count<sup>[(LE)](/protocol/misc/endian/little)</sup> | `00000000` |
 | Payload Checksum<sup>[(LE)](/protocol/misc/endian/little)</sup> |  `5DF6E0E2` |
-Below is the full, concatenated sample message (in hexadecimal):
+The message checksum is the first 4 bytes of a double-sha256 hash of the payload.
 The checksum is transmitted as a byte array, and is encoded as [big-endian](/protocol/misc/endian/big).
-`E3E1F3E876657261636B000000000000000000005DF6E0E2`
+
 ### Payload
 The message payload is defined by the message type.
 # Node Specific Behavior
@@ -3,14 +3,27 @@
 "related":["/protocol","/protocol/network/messages/getaddr"]
 }</div>
-# Response: Addresses ("addr")
+# Response: Addr ("addr")
-Provide information about other prospective P2P protocol peers.  Peers SHOULD not send this message unsolicited (see [getaddr](/protocol/network/messages/getaddr)), and nodes that receive an unsolicited addr message MUST ignore it.  This behavior helps prevent eclipse and partitioning attacks by not allowing an attacker to aggressively seed peer connection tables with its own nodes.
+Provide information about other prospective P2P protocol peers.  Peers SHOULD not send this message unsolicited, and nodes that receive an unsolicited ADDR message MUST ignore it.  This behavior helps prevent eclipse and partitioning attacks by not allowing an attacker to aggressively seed peer connection tables with its own nodes.
 ## Message Format
 | Field | Length | Format | Description |
 |--|--|--|--|
-| peer count | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of peers whose connection information is being sent in this message. |
+| vector length N | variable | [compact int](/protocol/p2p/compact__int.md) | The following fields are repeated N times |
-| peer network addresses | `peer_count` * 30 | `peer_count` [network addresses](/protocol/formats/network-address) | The peer information for each of the peers being transmitted. |
+| time 0 | 4 bytes | unsigned int<sup>[(LE)](/protocol/misc/endian/little)</sup> | last known alive time |
 | services 0 | 8 bytes | unsigned int<sup>[(LE)](/protocol/misc/endian/little)</sup> bit field | the services this node supports |
 | IP address 0 | 16 bytes | bytes | connect using this IP address
 | port 0 | 2 bytes | unsigned integer<sup>[(BE)](/protocol/misc/endian/little)</sup> | connect using this IP port 
 | ... |
 | time N, etc
 *services* is a bit field describing supported functionality, that is also used in the [version](/protocol/p2p/version) message.  See [services field](/protocol/p2p/services__field) for bit definitions.
 *time* is a 4 byte unsigned little-endian integer denoting the last time in epoch seconds that this node was known to be "live".
 *IP address* is the IPv4 or IPv6 address of the prospective node.
 *port* is the IP port of the prospective node, serialized as an unsigned 2 byte big-endian value.
@@ -9,9 +9,8 @@ Add an entry into the installed bloom filter.
 ## Message Format
-| Field | Length | Format | Description |
+| compact int | N bytes | 
-|--|--|--|--|
+|-------------|---------|
-| data length | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the piece of the data to be added to the bloom filter. |
+|[vector](/protocol/p2p/vector) size N of| data
 | data | `data_length` bytes | bytes | The raw data of the object to the be added. |
 *data* is inserted into the bloom filter, exactly as if the [insert](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/eb264e627e231f7219e60eef41b4e37cc52d6d9d/src/bloom.cpp#L116) operation had been called locally before sending the filter.
@@ -9,7 +9,7 @@ Inserts a transaction and merkle block filter into the peer, overwriting any exi
 ### Effect on Transactions
-This message installs a bloom filter into the peer.  Subsequent [inv](/protocol/network/messages/inv) and [merkleblock](/protocol/network/messages/merkleblock) messages only provide transactions that in match this bloom filter in some manner.  The following items in a transaction are checked against the bloom filter:
+This message installs a bloom filter into the peer.  Subsequent INV notifications and MERKLEBLOCK messages only provide transactions that in match this bloom filter in some manner.  The following items in a transaction are checked against the bloom filter:
 - The transaction hash
 - Each data field in every [output script](/glossary/output__script.md) in the transaction
@@ -22,17 +22,16 @@ See [CBloomFilter::MatchAndInsertOutputs](https://github.com/BitcoinUnlimited/Bi
 ### Effect on Merkle Blocks
-If a [filtered block](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.7.0.0/src/protocol.h#L483) is requested via an inventory message, the installed bloom filter is used to choose which transactions are included in the response using the same matching algorithm as described above for transaction inventories.
+If a [filtered block](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.7.0.0/src/protocol.h#L483) is requested via in [INV](/protocol/network/messages/inv.md) message, the installed bloom filter is used to choose which transactions are included in the response using the same matching algorithm as described above for transaction INVs.
 ## Message Format
 | Field | Length | Format | Description |  
 |--|--|--|--|
-| bloom filter size | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the bloom filter to be used. |
+| [vector](/protocol/p2p/vector.md) of bytes | up to 36000 bytes | bit vector | bloom filter data |
-| bloom filter data | variable | `bloom_filter_size` bytes | Raw bloom filter data (up to 36,000 bytes). |
+| num hash funcs | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | number of hash functions used when generating this filter (max 50) |
-| number of hash functions | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The number of hash functions used when generating this filter (max 50). |
+| tweak | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | arbitrary number that uniquifies this bloom filter |
-| tweak | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | Arbitrary number that helps randomize this bloom filter. |
+flags | 1 byte | bit field | bloom filter flags
 | flags | 1 byte | bit field | See [bloom filter flags](#bloom-filter-flags). |
 ### Bloom Filter Flags
@@ -5,15 +5,28 @@
 # Request: Get Data (“getdata”)
-Requests information (generally previously announced via an [inv](/protocol/network/messages/inv) message) from a peer.
+Requests information (generally previously announced via an INV) from a peer.
-As such, a getdata request carries the same general format as an inventory message and is used to request any items that the node was previously unaware.
+
 A GETDATA request is a [vector](/protocol/p2p/vector.md) of INV-formatted data.
 ## Message Format
 | Field | Length | Format | Description |
 |--|--|--|--|
-| inventory count | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of inventory items being requested in this message. |
+| vector length N | variable | compact int | number of items |
-| inventory items | `inventory_count` * 36 bytes | `inventory_count` [inventory items](/protocol/network/messages/inv#inventory-item-format) | The set of inventory items being requested. |
+| item 0 type | 4 bytes | unsigned int<sup>[(LE)](/protocol/misc/endian/little)</sup> | type of the requested object |
 | item 0 hash | 32 bytes | bytes | hash of the requested object |
 | ... | | | |
 | item N-1 type |
 | item N-1 hash 
 ### Type
 The type of the desired object. See [INV](/protocol/network/messages/inv.md) for specific values
 ### Hash
 The [hash identifier](glossary/hash__identifier) of the desired object.
 ## Server Implementations 
@@ -3,24 +3,15 @@
 "related":["/protocol","/protocol/p2p/getheaders"]
 }</div>
-# Response: Headers ("headers")
+*Provides a contiguous set of block headers*  
-Provides a contiguous set of block headers.
+## HEADERS Message Format
-## Message Format
+|Size in bytes|Description|Data type|
-
+|-------------|-----------|---------|
-| Field | Length | Format | Description |
+|1+           | Number of headers | varint|
-|--|--|--|--|
+|(81 + (1+)) * count  |[Block headers](/protocol/blockchain/block/block-header/) and number of txs in the block|Blockheader + varint|
 | block header count | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of block headers in this message. |
 | block headers | variable | `block_header_count` [block headers with transaction count](#block-header-with-transaction-count-format) | The set of block headers being transmitted, with the block's transaction count. |
 No more than 2000 block headers may be sent at one time. Block headers in this array MUST be sequential, ordered by height and without range gaps.
-#### Block Header With Transaction Count Format
+The number of txs in header is **DEPRECATED** and should be ignored. Nodes are allowed to send 0 regardless of the actual number of transactions in the block.
 | Field | Length | Format | Description |
 |--|--|--|--|
 | block header | 80 bytes | [block header](/protocol/blockchain/block/block-header#block-header-format) | The contents of the block's header. |
 | transaction count* | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of transactions contained within the block with the preceding header. |
 \* The transaction count above is **DEPRECATED** and should be ignored. Nodes are allowed to send 0 regardless of the actual number of transactions in the block.
@@ -3,31 +3,18 @@
 "related":["/protocol","/protocol/network/messages/getdata.md","/protocol/network/messages/filterload.md","/protocol/network/messages/filterclear.md"]
 }</div>
-# Announcement: Inventory ("inv")
+*Notifies peers about the existence of some information (block or transaction)*
 Based on selected services in the [VERSION](/protocol/network/messages/version.md) message, INV messages may not be sent.
-Notifies peers about the existence of some information (block or transaction).
+If a bloom filter has been sent to this node via [FILTERLOAD](/protocol/network/messages/filterload.md), transaction INVs will only be sent if they match the bloom filter.
-Based on selected services in the [version](/protocol/network/messages/version) message, inventory messages may not be sent.
+| compact int | 4 bytes | 32 bytes |... | 4 bytes | 32 bytes |
 |----------|---------|----------|---|---------|----------| 
 |[vector](/protocol/p2p/vector.md) size N of|   type 1  |   hash 1  | | type N | hash N
-If a bloom filter has been sent to this node via [filterload](/protocol/network/messages/filterload), a transaction inventory will only be sent for transactions that match the bloom filter.
+NOTE: Since a block header is a relatively small data structure, and block propagation speed is an important network metric, a peer may send HEADER messages in place of INV messages when a block arrives.
-## Message Format
+##### Type
 | Field | Length | Format | Description |
 |--|--|--|--|
 | inventory count | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of inventory items in this message. |
 | inventory items | `inventory_count` * 36 bytes | `inventory_count` [inventory items](#inventory-item-format) | The set of inventory items being transmitted. |
 NOTE: Since a block header is a relatively small data structure, and block propagation speed is an important network metric, a peer may send [headers](/protocol/network/messages/headers) messages in place of inventory messages when a block arrives.  This behavior can be requested using the [sendheaders](/protocol/network/messages/sendheaders) message.
 #### Inventory Item Format
 | Field | Length | Format | Description |
 |--|--|--|--|
 | type | 4 bytes | [inventory type](#inventory-types)<sup>[(LE)](/protocol/misc/endian/little)</sup> | Indicates what the following hash represents. |
 | item hash | 32 bytes | bytes<sup>[(LE)](/protocol/misc/endian/little)</sup> | The [hash](/protocol/blockchain/hash) that identifies the item. |
 #### Inventory Types
 The type of the object that is available.
 | Type | Value|
@@ -40,3 +27,6 @@ The type of the object that is available.
 |   6  |  Graphene Block (Bitcoin Unlimited)
 Implementations: [C++](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/eb264e627e231f7219e60eef41b4e37cc52d6d9d/src/protocol.h#L477)
 ##### Hash
 The [hash identifier](/glossary/hash__identifier.md) of the available object.
@@ -5,26 +5,14 @@
 # Response: Merkle Block ("merkleblock")
-Provides a block header and partial merkle proof tree to show that the selected transaction [hashes](/protocol/blockchain/hash) exist in the block.
+*Provides a block header and partial merkle proof tree to show that selected transaction ids exist in the block.*  
-Transactions are selected by honest servers if they match the bloom filter installed by the client.  However, note that servers can omit transactions and this cannot be detected except by receiving a merkleblock message from an honest server.
+Transactions are selected by honest servers if they match the bloom filter installed by the client.  However, note that servers can omit transactions and this cannot be detected except by receiving a MERKLEBLOCK message from an honest server.
-All selected transactions are subsequently sent as separate [tx](/protocol/network/messages/tx) messages.  Due to multi-threading on the server, clients should not assume that these transaction messages directly follow the merkleblock message.
+All selected transactions are subsequently sent as separate TX messages.  Due to multi-threading on the server, clients should not assume that these TX messages directly follow the MERKLEBLOCK message.
 ## Message Format
-| Field | Length | Format | Description |
+| ... | 4 bytes |  ... | ...|
-|--|--|--|--|
+|----|---------------|-----------|------------|
-| block header | 80 bytes | [block header](/protocol/blockchain/block/block-header#block-header-format) | The header of the block. |
+|  [block header](/protocol/blockchain/block/block-header.md)| # tx in block | [vector](/protocol/p2p/vector) of 32 byte hashes | [vector](/protocol/p2p/vector) of bytes that define the merkle block traversal
 | transaction count | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The number of transactions in the block. |
 | filtered transaction count | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of transactions matching the client's bloom filter. |
 | transaction hashes | `transaction_count` * 32 bytes | bytes<sup>[(LE)](/protocol/misc/endian/little)</sup> | The hashes of the full set of transactions in the block, in the the order they appear in the block (i.e. depth-first order with respect to the merkle tree). |
 | flag byte count | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of flags bytes to follow. |
 | flag bits | `flag_count` bytes | bytes | Flag bits, collected into bytes (zero-padded to a full byte as necessary) indicating inclusion information with respect to traversal of the partial merkle tree of matches.  See [partial merkle tree flag bits](#partial-merkle-tree-flag-bits). |
 #### Partial Merkle Tree Flag Bits
 The partial merkle tree flag bits effectively create a variable-width bitfield, indicating which transaction hashes from the block the merkleblock message pertains to actually matched the client's bloom filter.
 If you picture the merkle tree root at the top, the flag bits represent a top-down yes/no approach to whether the a given branch (or leaf node) of the tree includes any matching transactions.
 For full details, see [BIP-37: Partial Merkle Branch Format](/protocol/forks/bip-0037#partial-merkle-branch-format).
@@ -3,29 +3,29 @@
 "related":["/protocol"]
 }</div>
-# Response: Reject ("reject")
+*Notifies peer that a message is invalid*
 Notifies peer that a received message is invalid.
-## Message Format
+| [compact int](/protocol/p2p/compact__int.md) N (max 12) | N bytes | 1 byte | [compact int](/protocol/p2p/compact__int.md) M (max 111) | M bytes | 
 |----------------|---------|-------------|---------------|---------| 
 | command length | command | error code  | reason length | reason string |
-| Field | Length | Format | Description |
+*command length* and *command* form a [vector](/protocol/p2p/vector.md) of bytes that identify the type of the problem message.  These bytes (less padded nulls) match the *command* field in the protocol [message envelope](/protocol.md).
 |--|--|--|--|
 | rejected message type | variable | [variable length string](/protocol/formats/variable-length-string) | The [command string](/protocol/network/messages#command-string) of the message that is being rejected (e.g. "tx"). |
 | rejection code | 1 byte | [rejection code](#rejection-codes) | A code indicating why the message was rejected. |
 | rejection reason* | variable | [variable length string](/protocol/formats/variable-length-string) | A description of why the message was rejected. |
- \* *rejection reason* is a string providing a human language explanation of the reason the message was rejected.  This string is subject to change so client software **SHOULD NOT** use it programmatically.
+*reason length* and *reason string* form a [vector](/protocol/p2p/vector.md) of bytes that is a string providing a human language explanation of the reason the message was rejected.  This string is subject to change so client software **SHOULD NOT** use it programatically.
-#### Rejection Codes
+*error code* provides a succinct machine-interpretable reason why the message was rejected.
-|    Name    | Value | Response To |  Description |
+### Reject Error Codes
 |    Name    | Value | Response To |  Description
 |-------------|-------|---------------|-----------|
-| REJECT_MALFORMED | 0x01 | any | Message cannot be deserialized. |
+| REJECT_MALFORMED | 0x01 | any | message cannot be deserialized |
-| REJECT_INVALID | 0x10 | BLOCK, TX, FILTERSIZEXTHIN | Block or transaction is invalid, or xthin filter size is too small | 
+| REJECT_INVALID | 0x10 | BLOCK, TX, FILTERSIZEXTHIN | block or transaction is invalid, or xthin filter size is too small | 
 | REJECT_OBSOLETE | 0x11 | VERSION | This node no longer supports your client protocol version |
 | REJECT_DUPLICATE | 0x12 | unused | |
-| REJECT_NONSTANDARD | 0x40 | TX | Transaction is [non-standard](/protocol/blockchain/transaction-validation/network-level-validation-rules#standard-transactions), or not final as per [BIP68](/protocol/forks/bip-0068). |
+| REJECT_NONSTANDARD | 0x40 | TX | Transaction is [non-standard](/standard__transactions.md), or [not final](/final__transactions.md) as per BIP68 |
-| REJECT_DUST  | 0x41 | TX | Transaction has an output that is too small. |
+| REJECT_DUST  | 0x41 | TX | Transaction has an output that is too small |
-| REJECT_INSUFFICIENTFEE | 0x42 | TX | Transaction does not pay enough in fees to be relayed. |
+| REJECT_INSUFFICIENTFEE | 0x42 | TX | Transaction does not pay enough to be relayed |
 | REJECT_CHECKPOINT | 0x43 | unused | |
 | REJECT_WAITING | 0x44 | TX | This transaction is [not final](/final__transactions.md) |
@@ -1,4 +1,4 @@
-# Handshake: Version Acknowledgement ("verack")
+# Handshake: Acknowledge ("verack")
 The `verack` message is sent in reply to a [version](/protocol/network/messages/version) message.
 Sending a `verack` in response to a `version` message indicates to the remote that its connection and version has been accepted.
@@ -7,6 +7,16 @@ There is no version negotiation functionality between nodes; therefore if the no
 This `verack` message consists of only a message header; the command string is "verack".
-## Message Format
+## Example Serialized Data
-This message has no contents.
+Net Magic<sup>[(BE)](/protocol/misc/endian/little)</sup>
 `E3E1F3E8`
 Command String ("verack")<sup>[(BE)](/protocol/misc/endian/big)</sup>
 `76657261636B000000000000`
 Payload Byte Count<sup>[(LE)](/protocol/misc/endian/little)</sup>
 `00000000`
 Payload Checksum<sup>[(LE)](/protocol/network/messages/message-checksum)</sup>
 `5DF6E0E2`
@@ -1,7 +1,7 @@
 # Handshake: Version (“version”)
-The version message is a part of the node connection [handshake](/protocol/network/node-handshake) and indicates various connection settings, networking information, and the services provided by the sending node (see Services Bitfield [below](#services-bitfield)).
+The version message is a part of the node connection [handshake](/protocol/network/node-handshake) and indicates various connection settings, networking information, and the services provided by the sending node (see Services Bitmask [below](#services-bitmask)).
 The node connection is not considered established until both nodes have sent and received both a `version` and [verack](/protocol/network/messages/verack) message.
@@ -10,7 +10,7 @@ The node connection is not considered established until both nodes have sent and
 | Field | Length | Format | Description |
 |--|--|--|--|
 | version number | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The version number supported by the sending node. |
-| services | 8 bytes | bitfield<sup>[(LE)](/protocol/misc/endian/little)</sup> | An indication of the services supported by the sending node.  See Services Bitfield section below. |
+| services | 8 bytes | bitmask<sup>[(LE)](/protocol/misc/endian/little)</sup> | An indication of the services supported by the sending node.  See Services Bitmask section below. |
 | timestamp | 8 bytes | unix timestamp<sup>[(LE)](/protocol/misc/endian/little)</sup> | The time the message was generated on the sending node. |
 | remote address | 26 bytes | [network address](/protocol/formats/network-address) | The network address of the remote node.  <p>_NOTE: this does not contain the timestamp normally included with network addresses._</p> |
 | local address | 26 bytes | [network address](/protocol/formats/network-address) | The network address of the sending node. <p>_NOTE: this does not contain the timestamp normally included with network addresses._</p> |
@@ -30,11 +30,11 @@ Modern Nodes ignore extra data after the `relay flag`.
 The most recent version of the network protocol is `70015`.
 The `version` value often correlates to new behavior, parsing formats, and available services; for more details review the network protocol's [version history](/history/protocol-version).
-Nodes should use `version` and the `services` bitfield to determine if the node should accept the incoming connection.
+Nodes should use `version` and the `services` bitmask to determine if the node should accept the incoming connection.
 Related: [node connection handshake](/protocol/network/node-handshake).
-## Services Bitfield
+## Services Bitmask
 The services field is an 8 byte little-endian-serialized bitfield that described peer capabilities.
 The following capabilities are defined, by bit position:
@@ -0,0 +1,5 @@
 The block header appears in several P2P messages.  It's serialization format is as follows:
 | 4 bytes | 32 bytes | 32 bytes | 4 bytes | 4 bytes | 4 bytes
 |----|---------------|-----------|------------|---------|------
 | version |  hash of previous block  |  hash of merkle root  |  block time in epoch seconds  |  difficulty in "bits" format  |  nonce
@@ -0,0 +1,20 @@
 A "compact int" is serialized as follows:
 *If the number < 253, store it in 1 byte
 *If the number fits in 16 bits: store a 1 byte value 253, and the 2 byte little-endian number.
 |    0   |     1   |    2    | 
 |--------|---------|---------|
 |  0xfd  | val&255 | val>>8  |
 * If the number fits in 32 bits (but not 8 or 16): store a 1 byte value 254, and the 4 byte little-endian number
 |   0    |    1    |    2    |     3   |    4    | 
 |--------|---------|---------|---------|---------|
 |  0xfe  | val&255 | (val>>8)&255  | (val>>16)&255 | (val>>24)&255 |
 * If the number fits in 64 bits (but not 8, 16, or 32): store a 1 byte value 255 and the 8 byte little-endian number
 |    0   |    1    |    2    |     3   |     4   |    5    |   6      |     7   |    8    |
 |--------|---------|---------|---------|---------|---------|---------|---------|--------|
 |  0xff  | val&255 | val>>8  | val>>16 | val>>24 | val>>32 | val>>40  | val>>48 | val>>56 |
@@ -0,0 +1,40 @@
 The services field is an 8 byte little-endian-serialized bitfield that described peer capabilities.  The following capabilities are defined, by bit position:
 * 0: NODE_NETWORK
 	The node is capable of serving the complete block chain. It is currently set by all full nodes, and is unset by SPV clients or other peers that just want network services but don't provide them.
 * 1: NODE_GETUTXO
 	 The node is capable of responding to the getutxo protocol request.  See [BIP 64](https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki) for details on how this is implemented.  *Supported by Bitcoin XT only*
 * 2: NODE_BLOOM 
 	The node is capable and willing to handle bloom-filtered connections.
 * 3: NODE_WITNESS
 	Indicates that a node can be asked for blocks and transactions including witness data.  
 	*Bitcoin Cash nodes do not have witness data so this flag should be ignored on receipt and set to 0 when sent*
 * 4: NODE_XTHIN 
 	The node supports Xtreme Thinblocks
 	*Supported by Bitcoin Unlimited only*
 * 5: NODE_BITCOIN_CASH 
 	The node supports the BCH chain.  This is intended to be just a temporary service bit until the BTC/BCH fork actually happens.
 * 6: NODE_GRAPHENE
 	The node supports Graphene blocks.  If this is turned off then the node will not service graphene requests nor make graphene requests.
 	*Supported by Bitcoin Unlimited only*
 * 7: NODE_WEAKBLOCKS
 	The node supports Storm weak block (currently no node supports these in production, so this is a placeholder).
 * 8: NODE_CF 
 	Indicates the node is capable of serving compact block filters to SPV clients, AKA the "Neutrino" protocol ([BIP157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki), and [BIP158](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki)).
 * 9: NODE_NETWORK_LIMITED 
 	This means the same as NODE_NETWORK with the limitation of only serving a small subset of the blockchain.  See [BIP159](https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki) for details on how this is implemented.
 * 24-31: Experimental 
 	These bits are reserved for temporary experiments. Just pick a bit that isn't getting used, or one not being used much, and notify the community. Remember that service bits are just unauthenticated advertisements, so your code must be robust against collisions and other cases where nodes may be advertising a service they do not actually support.
@@ -0,0 +1,6 @@
 Vectors (and arrays, lists, maps, etc) are serialized by first serializing the number of elements and then serializing each element.  The number of elements is serialized in [compact int](/protocol/p2p/compact__int) format.
 | vector element count | object #0 | object #1 | ... | object #count-1 |
 |-------------|--------------|-------------|----------------|------------|
 | [compact int](/protocol/p2p/compact__int) | object specific serialization | ... | ... | ... |
 |
@@ -0,0 +1,18 @@
 <div class="cwikmeta">{
 "title":"XUPDATE",
 "related":["/protocol","/protocol/p2p/xversion" ,"/protocol/p2p/xversionkeys"]
 }</div>
 *Notifies peers about an XVERSION configuration value update*
 This message notifies a peer about changes to protocol parameters.  It follows the same format as [XVERSION](/protocol/p2p/xversion.md) protocol parameters.  Implementations **SHOULD** only send changed parameters, rather than every parameter.   Note that some XVERSION parameters are not changeable and therefore will be ignored if they appear in this message.  
 See the [XVERSION](/protocol/p2p/xversion.md) message for detailed information about each parameter.
 | compact int | compact int | variable bytes |... | compact int | 32 bytes |
 |----------|---------|----------|---|---------|----------|
 |[vector](/protocol/p2p/vector) size N of|   key 1  | [vector](/protocol/p2p/vector) of bytes  | | key N | [vector](/protocol/p2p/vector) of bytes
 ### Support
 Supported by: **Bitcoin Unlimited**
@@ -0,0 +1,11 @@
 <div class="cwikmeta">{
 "title":"XVERACK",
 "related":["/protocol","/protocol/p2p/xversion","/protocol/p2p/xupdate"]
 }</div>
 *Notifies peers that an XVERSION message was received*.
 This message has no *contents*.
 ### Support
 Supported by: **Bitcoin Unlimited**
@@ -0,0 +1,27 @@
 <div class="cwikmeta">{
 "title":"XVERSION",
 "related":["/protocol","/protocol/p2p/xupdate","/protocol/p2p/xversionkeys"]
 }</div>
 *Notifies peers about a protocol configuration value*
 This message notifies a peer about extended protocol parameters.  This message MAY be sent during connection initialization.  If sent, it MUST be sent immediately subsequent to the receipt of the [VERACK](/protocol/p2p/verack.md) message, and before other non-initialization messages are sent.
 | compact int | compact int | variable bytes |... | compact int | variable bytes |
 |----------|---------|----------|---|---------|----------|
 |[vector](/protocol/p2p/vector) size N of|   key 1  | value 1 [vector](/protocol/p2p/vector) of bytes  | | key N | value N [vector](/protocol/p2p/vector) of bytes
 The *value* is a vector of bytes.  These bytes can be an object that is itself serialized, but **MUST** exist within the vector "envelope" so that implementations that do not recognize a field can skip it.   The serialization format of the bytes inside the "envelope" is defined by the creator of the key, however, Bitcoin P2P network serialization is recommended since it is also used to encode/decode all the messages of this protocol.
 See [XVERSION specification](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.7.0.0/doc/xversionmessage.md) for additional details.
 ### XVERSION Fields
 XVERSION field identifiers are 32 bits and split into a 16 bit prefix and 16 bit suffix.  Each development group is assigned a prefix so that new identifiers do not accidentally conflict.  Once a field identifier is created by group A, it should be used by other software both to receive that information from A and to present that information to other software.  Therefore, group A **MUST NOT** change the syntax or semantics of a field once defined.  To change a field, create a new identifier and deprecate (by no longer using the original identifier).
 #### Prefix and Suffix Assignments
 See [xversionkeys](/protocol/p2p/xversionkeys.md) for a full list of assigned prefixes and field definitions.
 ### Support
 Supported by: **Bitcoin Unlimited**
@@ -0,0 +1,24 @@
 <div class="cwikmeta">{
 "title":"XVERSIONKEYS",
 "related":["/protocol","/protocol/p2p/xversion","/protocol/p2p/xupdate"]
 }</div>
 ### Prefix Assignments
 |    Group                | Value |
 |-------------------------|-------|
 | Reserved for versioning |   0   |
 | Bitcoin Cash Node       |   1   |
 | Bitcoin Unlimited       |   2   |
 #### Field Assignments
 See [xversionkeys.dat](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.7.0.0/src/xversionkeys.dat) for the most up-to-date field definitions defined by the BitcoinUnlimited full node.
 Note that:
 * *u64c* refers to a [compact int](/protocol/p2p/compact__int.md) serialization of an unsigned 64-bit value.
 * *Changeable* fields MAY be changed during the course of a connection via the [XUPDATE](/protocol/p2p/xupdate) message.
 ### Support
 Supported by: **Bitcoin Unlimited**
@@ -64,7 +64,7 @@ When creating pages, consider which part of the protocol the content you wish to
 As a convention, URL components (i.e. directories and pages) should contain only lower-case letters, numbers, and hyphens.
 Full words, separated by hyphens, are preferred over abbreviations, acronyms, or the use of punctuation or spaces.
-For example, the page for the <code>version</code> message exists at [<code>/protocol/network/messages/version</code>](/protocol/network/messages/version).
+For example, the page for the <code>version</code> message exists at <code>[/protocol/network/messages/version](/protocol/network/messages/version)</code>.
 A page relating to SLP (Simple Ledger Protocol) may exist at a path like <code>/protocol/simple-ledger-protocol/[page-name]</code>.
 Once you have created the page, consider which existing pages should link to the new page and add links as appropriate.
		`@@ -0,0 +1,3 @@`
							`<!-- TITLE: Redeem Script -->`

							`The redeem script is a constraint script that is used in the P2SH payment mode. The redeem script is provided by the spender's input script, however, it is chosen by the original spender. This is possible because the output script constrains the redeem script's hash to match a specific value. In P2SH this is the only constraint allowed by the output script, so the redeem script must implement all other constraints (such as signature checking).`
`@@ -25,4 +25,3 @@ Furthermore, this coinbase's output is not considered an unspent transaction out`
	`Coinbases may only have one transaction input.`	`Coinbases may only have one transaction input.`

	`All coinbase unlocking script must be less than or equal to 100 bytes in size.`	`All coinbase unlocking script must be less than or equal to 100 bytes in size.`