Make protected transactions mandatory on UAHF chain (and enforce SCRI…

…PT_VERIFY_STRICTENC) (#17)

* Make protected transactions mandatory on UAHF chain (and enforce SCRIPT_VERIFY_STRICTENC)

This enforces the use of SIGHASH_FORKID and SCRIPT_VERIFY_STRICTENC on
by UAHF-compatible clients once the fork has activated.

It makes the OP_RETURN protection obsolete, but it is not removed in order
to avoid a hard fork change w.r.t. existing deployments.

The strengthening of replay protections is a feature requested by miners
and exchanges to protect Bitcoin users from accidental loss and theft of
their Bitcoin Cash.

* Reword REQ-6-2 (as per deadalnix review comment)

Reworded positively and in bullet style similar to original

* Reword REQ-6-4

Thanks to Tom Zander for pointing out that its confusing.
Unfortunately, the specification situation around SCRIPT_VERIFY_STRICTENC
is also not such that we can point at a clear specification here.

Implementors should consider the code as reference for the moment.

uahf-technical-spec.md

@@ -1,6 +1,6 @@
 # UAHF Technical Specification
 
-Version 1.5, 2017-07-22
+Version 1.6, 2017-07-24
 
 
 ## Introduction
@@ -156,43 +156,54 @@ Once the fork has activated, transactions consisting exclusively of a single OP_
 without any terminating null character) shall be considered invalid until
 block 530,000 inclusive.
 
-RATIONALE: To give users on the legacy chain (or other fork chains)
+RATIONALE: (DEPRECATED - see NOTE 2) To give users on the legacy chain (or other fork chains)
 an opt-in way to exclude their transactions from processing on the UAHF
 fork chain. The sunset clause block height is calculated as approximately
 1 year after currently planned UASF activation time (Aug 1 2017 00:00:00 GMT),
 rounded down to a human friendly number.
 
-NOTE: Transactions with such OP_RETURNs shall be considered valid again
+NOTE 1: Transactions with such OP_RETURNs shall be considered valid again
 for block 530,001 and onwards.
 
+NOTE 2: With the changes in v1.6 of this specification, mandatory use
+of SIGHASH_FORKID replay protection on UAHF chain makes the use of this
+opt-out protection unnecessary. Clients should nevertheless implement this
+requirement, as removing it would constitute a hard fork vis-a-vis the
+existing network. The sunset clause in this requirement will take care
+of its expiry by itself.
 
-### REQ-6-2 (opt-in signature shift via hash type)
 
-Once the fork has activated, a transaction shall not be deemed invalid if
+### REQ-6-2 (mandatory signature shift via hash type)
+
+Once the fork has activated, a transaction shall be deemed valid only if
 the following are true in combination:
-- the nHashType has bit 6 set (mask 0x40)
-- adding a magic 'fork id' value to the nHashType before the hash is
-  calculated allows a successful signature verification as per REQ-6-3
+- its nHashType has bit 6 set (SIGHASH_FORKID, mask 0x40)
+- a magic 'fork id' value is added to the nHashType before the hash is
+  calculated (see note 4)
+- it is digested using the new algorithm described in REQ-6-3
 
-RATIONALE: To give users on the UAHF chain an opt-in way to encumber
-replay of their transactions to the legacy chain (and other forks which may
-consider such transactions invalid).
+RATIONALE: To provide strong protection against replay of existing
+transactions on the UAHF chain, only transactions signed with the new
+hash algorithm and having SIGHASH_FORKID set will be accepted, by consensus.
 
-NOTE 1: It is possible for other hard forks to defeat this protection by
-implementing a compatible signature check that accepts transactions
-signed in this special way. However, this does require a counter hard fork.
+NOTE 1: It is possible for other hard forks to allow SIGHASH_FORKID-protected
+transactions on their chain by implementing a compatible signature.
+However, this does require a counter hard fork by legacy chains.
 
-NOTE 2: The client shall still accept transactions whose signatures
-verify according to pre-fork rules, subject to the additional OP_RETURN
-constraint introduced by REQ-6-1.
+NOTE 2: (DEPRECATED) ~~The client shall still accept transactions whose signatures~~
+~~verify according to pre-fork rules, subject to the additional OP_RETURN~~
+~~constraint introduced by REQ-6-1.~~
 
-NOTE 3: If bit 6 is not set, only the unmodified nHashType will be used
-to compute the hash and verify the signature.
+NOTE 3: (DEPRECATED) ~~If bit 6 is not set, only the unmodified nHashType will be used~~
+~~to compute the hash and verify the signature.~~
 
 NOTE 4: The magic 'fork id' value used by UAHF-compatible clients is zero.
 This means that the change in hash when bit 6 is set is effected only by
 the adapted signing algorithm (see REQ-6-3).
 
+NOTE 5: See also REQ-6-4 which introduces a requirement for use of
+SCRIPT_VERIFY_STRICTENC.
+
 
 ### REQ-6-3 (use adapted BIP143 hash algorithm for protected transactions)
 
@@ -207,6 +218,19 @@ digest based on BIP143. Revisions were made to account for non-Segwit
 deployment.
 
 
+### REQ-6-4 (mandatory use of SCRIPT_VERIFY_STRICTENC)
+
+Once the fork has activated, transactions shall be validated with
+SCRIPT_VERIFY_STRICTENC flag set.
+
+RATIONALE: Use of SCRIPT_VERIFY_STRICTENC also ensures that the
+nHashType is validated properly.
+
+NOTE: As SCRIPT_VERIFY_STRICTENC is not clearly defined by BIP,
+implementations seeking to be compliant should consult the Bitcoin C++
+source code to emulate the checks enforced by this flag.
+
+
 ### REQ-7 Difficulty adjustement in case of hashrate drop
 
 In case the MTP of the tip of the chain is 12h or more after the MTP 6 block