Merge remote-tracking branch 'BitcoinUnlimited/master' into master

home.md

@@ -8,7 +8,7 @@
 [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 Signatures](/protocol/blockchain/transaction/signatures)
+[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)
 
 ### Blocks
 [Bitcoin Blocks](/protocol/blockchain/block) —

protocol/blockchain/chainwork-proof.md

@@ -0,0 +1,106 @@
+# Chainwork Proof
+
+The idea of chainwork is intrinsic to blockchains.  Nodes switch to the chain tip with the most cumulative "work" to help preserve the blockchain assumption that the majority of the miners on a chain are honest.  Chainwork is calculated by summing the "work" done in each block in the chain.  
+
+Is summing work a valid operation?
+
+More formally, *is 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?*
+
+## Warm-up
+
+For every block candidate, a target (specified in a nonstandard floating point form in the block header as 'nBits') is calculated.  Any hash less than this target solves the block.  Under the random oracle model (that is, assuming that cryptographic hash functions produce unpredictable output), this is equivalent to rolling a $2^{256}$ sided die with any number less than or equal to the target resulting in a "win".  The probability of this is:
+
+$$
+P(target) = (target + 1)/2^{256}       \tag1
+$$
+
+*We add one to target because the number range of target is from 0 to $2^{256}-1$, rather than 1 to $2^{256}$.*
+
+Equation 1 is about the target, but we sum work.   We need the relationship between work and target which is defined in the code as follows:
+
+$$
+work = 2^{256}/ (target + 1)
+$$
+
+or, solving for target:
+
+$$
+T(work) = (2^{256}/work) -1   \tag2
+$$
+
+Finally we need an equation from general statistics.  The expected number of trials before a success for such a random variable is given by (see [wikipedia](https://en.wikipedia.org/wiki/Geometric_distribution#Properties)):
+
+$$
+E(probability\_of\_success) = 1/probability\_of\_success    \tag3
+$$
+
+'Trials' in our case are individual attempts to solve a block.  So if the expected number of trials of two different processes are the same then we can say those two processes would take the same amount of work (on average).
+
+## Proof
+
+Recall our question "*is 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?*"
+
+With the above definitions this can be expressed in mathematical notation:
+
+$$
+E(P(T(work))) \stackrel{?}{=} n * E(P(T(work/n)))    \tag4
+$$
+
+With all of our preparation, this proof is easy.  But I'll go through each step to make it convenient to read along.  
+
+First we'll replace the functions with their defintions on the left side **to prove that what the blockchain community calls "work" is the expected number of hashes**.
+
+$$
+E(P(T(work))) = E(P((2^{256}/work) -1))
+$$
+
+$$
+ = E(((2^{256}/work) -1 + 1)/2^{256})
+$$
+
+$$
+ = E((2^{256}/work)/2^{256})
+$$
+
+$$
+ = E(1/work)
+$$
+
+$$  
+ = work
+$$
+
+
+Second we'll do the same on the right side and simplify to prove that the result is the same:
+
+First, substitute the definition of T() (eqn 2):
+
+$$  
+n * E(P(T(work/n))) = n * E(P((n*2^{256}/work) -1)
+$$
+
+Next, substitute the definition of P() (eqn 1):
+
+$$
+ = n * E( ((n*2^{256}/work))/2^{256})
+$$
+
+Third, substitute the defintion of E() (eqn 3):
+
+$$
+= \dfrac{n}{\frac{(n*2^{256}/work )}{2^{256}}}
+$$
+
+Finally, simplify:
+
+$$
+= \dfrac{n*2^{256}} {(n*2^{256}/work)}
+$$
+
+$$
+= \dfrac{n*2^{256}*work} {n*2^{256}}
+$$
+
+$$
+= work
+$$

protocol/blockchain/proof-of-work.md

@@ -22,14 +22,25 @@ 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.  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:
+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:
 
  - **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.  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.
+Chainwork is a representation of the work performed through a block's entire history.
+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
 
@@ -40,4 +51,4 @@ As a result, there was a need for additional data to be varied.
 The only other parameter of the block header that a miner has any power over is the merkle root.
 In order to change the merkle root, the transactions in the block would need to be changed.
 But since the [coinbase transaction](/protocol/blockchain/block#coinbase-transaction) is already created by the miner of the block, and updating its hash would allow for efficient re-calculation of the merkle root, putting this "extra nonce" in the coinbase transaction was the logical conclusion.
-Ultimately, the extra nonce is included as a part of the coinbase message, usually following the block height that is required to be first.
+Ultimately, the extra nonce is included as a part of the coinbase message, usually following the block height that is required to be first.

protocol/blockchain/transaction/transaction-signing.md

@@ -34,41 +34,56 @@ In conjunction with the above values, the higher-order bits act as a bitmask wit
 | `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. |
 
-For example, a hash type of `0x000000C2`, would indicate a signature generated for a Bitcoin Cash transaction with an anyone-can-pay, no-outputs-included preimage.
+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
 
-| Field | Length | Format | Description |  
+| Field | Length | Format | Description |
 |--|--|--|--|
 | 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 | bytes<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.  |
+| 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 | bytes<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.  |
+| 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 | bytes<sup>[(LE)](/protocol/misc/endian/little)</sup> | The transaction ID of the previous output being spent. |
+| 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 | bytes<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 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
 
+The double-SHA256-hash of the following data is used.
+
 For each transaction input in the transaction, append the following information:
 
-| Field | Length | Format | Description |  
+| Field | Length | Format | Description |
 |--|--|--|--|
 | 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
 
+The double-SHA256-hash of the following data is used.
+
 For each transaction input in the transaction, append the following information:
 
-| Field | Length | Format | Description |  
+| Field | Length | Format | Description |
 |--|--|--|--|
 | sequence number | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The sequence number field of the transaction input. |