diff --git a/doc/abc/replay-protected-sighash.md b/doc/abc/replay-protected-sighash.md
index 19dce6c968..a8de78558f 100644
--- a/doc/abc/replay-protected-sighash.md
+++ b/doc/abc/replay-protected-sighash.md
@@ -1,197 +1,205 @@
 # BUIP-HF Digest for replay protected signature verification across hard forks
 
-Version 1.1, 2017-06-14
+Version 1.2, 2017-07-16
 
 ## Abstract
 
 This document describes proposed requirements and design for a reusable signing mechanism ensuring replay protection in the event of a hard fork. It provides a way for users to create transactions which are invalid on forks lacking support for the mechanism and a fork-specific ID.
 
 The proposed digest algorithm is adapted from BIP143[[1]](#bip143) as it minimizes redundant data hashing in verification, covers the input value by the signature and is already implemented in a wide variety of applications[[2]](#bip143Motivation).
 
-The proposed digest algorithm is used when the `SIGHASH_FORKID` bit is set in the signature's sighash type. The verification of signatures which do not set this is bit is not affected.
+The proposed digest algorithm is used when the `SIGHASH_FORKID` bit is set in the signature's sighash type. The verification of signatures which do not set this bit is not affected.
 
 ## Specification
 
 ### Activation
 
 The proposed digest algorithm is only used when the `SIGHASH_FORKID` bit in the signature sighash's type is set. It is defined as follows:
 
 ````cpp
   // ...
   SIGHASH_SINGLE = 3,
   SIGHASH_FORKID = 0x40,
   SIGHASH_ANYONECANPAY = 0x80,
   // ...
 ````
 
 In presence of the `SIGHASH_FORKID` flag in the signature's sighash type, the proposed algorithm is used.
 
 Signatures using `SIGHASH_FORKID` must be rejected before [UAHF](https://github.com/Bitcoin-UAHF/spec/blob/master/uahf-technical-spec.md) is activated.
 
 In order to ensure proper activation, the reference implementation uses the `SCRIPT_ENABLE_SIGHASH_FORKID` flag when executing `EvalScript` .
 
 ### Digest algorithm
 
 The proposed digest algorithm computes the double SHA256 of the serialization of:
 1. nVersion of the transaction (4-byte little endian)
 2. hashPrevouts (32-byte hash)
 3. hashSequence (32-byte hash)
 4. outpoint (32-byte hash + 4-byte little endian)
 5. scriptCode of the input (serialized as scripts inside CTxOuts)
 6. value of the output spent by this input (8-byte little endian)
 7. nSequence of the input (4-byte little endian)
 8. hashOutputs (32-byte hash)
 9. nLocktime of the transaction (4-byte little endian)
 10. sighash type of the signature (4-byte little endian)
 
 Items 1, 4, 7 and 9 have the same meaning as in the original algorithm[[3]](#OP_CHECKSIG).
 
 #### hashPrevouts
 
 * If the `ANYONECANPAY` flag is not set, `hashPrevouts` is the double SHA256 of the serialization of all input outpoints;
 * Otherwise, `hashPrevouts` is a `uint256` of `0x0000......0000`.
 
 #### hashSequence
 
 * If none of the `ANYONECANPAY`, `SINGLE`, `NONE` sighash type is set, `hashSequence` is the double SHA256 of the serialization of `nSequence` of all inputs;
 * Otherwise, `hashSequence` is a `uint256` of `0x0000......0000`.
 
 #### scriptCode
 
 In this section, we call `script` the script being currently executed. This means `redeemScript` in case of P2SH, or the `scriptPubKey` in the general case.
 
 * If the `script` does not contain any `OP_CODESEPARATOR`, the `scriptCode` is the `script` serialized as scripts inside `CTxOut`.
 * If the `script` contains any `OP_CODESEPARATOR`, the `scriptCode` is the `script` but removing everything up to and including the last executed `OP_CODESEPARATOR` before the signature checking opcode being executed, serialized as scripts inside `CTxOut`.
 
 Notes:
 1. Contrary to the original algorithm, this one does not use `FindAndDelete` to remove the signature from the script.
 2. Because of 1, it is not possible to create a valid signature within `redeemScript` or `scriptPubkey` as the signature would be part of the digest. This enforces that the signature is in `sigScript` .
-3. In case an opcode that requires signature checking is present in `sigScript`, `script` is effectively `sigScript`. However, for reason similar to 2. , it is not possible to provide a valid signature in that case.
+3. In case an opcode that requires signature checking is present in `sigScript`, `script` is effectively `sigScript`. However, for reason similar to 2, it is not possible to provide a valid signature in that case.
 
 #### value
 
 The 8-byte value of the amount of bitcoin spent in this input.
 
 #### hashOutputs
 
 * If the sighash type is neither `SINGLE` nor `NONE`, `hashOutputs` is the double SHA256 of the serialization of all output amount (8-byte little endian) with `scriptPubKey` (serialized as scripts inside CTxOuts);
 * If sighash type is `SINGLE` and the input index is smaller than the number of outputs, `hashOutputs` is the double SHA256 of the output amount with `scriptPubKey` of the same index as the input;
 * Otherwise, `hashOutputs` is a `uint256` of `0x0000......0000`.
 
 Notes:
 1. In the [original algorithm][3], a `uint256` of `0x0000......0001` is committed if the input index for a `SINGLE` signature is greater than or equal to the number of outputs. In this BIP a `0x0000......0000` is committed, without changing the semantics.
 
 #### sighash type
 
 The sighash type is altered to include a 24-bit *fork id* in its most significant bits.
 
 ````cpp
   ss << ((GetForkID() << 8) | nHashType);
 ````
 
 This ensure that the proposed digest algorithm will generate different results on forks using different *fork ids*.
 
 ## Implementation
 
 Addition to `SignatureHash` :
 
 ````cpp
   if (nHashType & SIGHASH_FORKID) {
     uint256 hashPrevouts;
     uint256 hashSequence;
     uint256 hashOutputs;
 
     if (!(nHashType & SIGHASH_ANYONECANPAY)) {
       hashPrevouts = GetPrevoutHash(txTo);
     }
 
     if (!(nHashType & SIGHASH_ANYONECANPAY) &&
         (nHashType & 0x1f) != SIGHASH_SINGLE &&
         (nHashType & 0x1f) != SIGHASH_NONE) {
       hashSequence = GetSequenceHash(txTo);
     }
 
     if ((nHashType & 0x1f) != SIGHASH_SINGLE &&
         (nHashType & 0x1f) != SIGHASH_NONE) {
       hashOutputs = GetOutputsHash(txTo);
     } else if ((nHashType & 0x1f) == SIGHASH_SINGLE &&
                nIn < txTo.vout.size()) {
       CHashWriter ss(SER_GETHASH, 0);
       ss << txTo.vout[nIn];
       hashOutputs = ss.GetHash();
     }
 
     CHashWriter ss(SER_GETHASH, 0);
     // Version
     ss << txTo.nVersion;
     // Input prevouts/nSequence (none/all, depending on flags)
     ss << hashPrevouts;
     ss << hashSequence;
     // The input being signed (replacing the scriptSig with scriptCode +
     // amount). The prevout may already be contained in hashPrevout, and the
     // nSequence may already be contain in hashSequence.
     ss << txTo.vin[nIn].prevout;
     ss << static_cast<const CScriptBase &>(scriptCode);
     ss << amount;
     ss << txTo.vin[nIn].nSequence;
     // Outputs (none/one/all, depending on flags)
     ss << hashOutputs;
     // Locktime
     ss << txTo.nLockTime;
     // Sighash type
     ss << ((GetForkId() << 8) | nHashType);
     return ss.GetHash();
   }
 ````
 
 Computation of midstates:
 
 ````cpp
 uint256 GetPrevoutHash(const CTransaction &txTo) {
   CHashWriter ss(SER_GETHASH, 0);
   for (unsigned int n = 0; n < txTo.vin.size(); n++) {
     ss << txTo.vin[n].prevout;
   }
 
   return ss.GetHash();
 }
 
 uint256 GetSequenceHash(const CTransaction &txTo) {
   CHashWriter ss(SER_GETHASH, 0);
   for (unsigned int n = 0; n < txTo.vin.size(); n++) {
     ss << txTo.vin[n].nSequence;
   }
 
   return ss.GetHash();
 }
 
 uint256 GetOutputsHash(const CTransaction &txTo) {
   CHashWriter ss(SER_GETHASH, 0);
   for (unsigned int n = 0; n < txTo.vout.size(); n++) {
     ss << txTo.vout[n];
   }
 
   return ss.GetHash();
 }
 ````
 
 Gating code:
 
 ````cpp
   uint32_t nHashType = GetHashType(vchSig);
   if (nHashType & SIGHASH_FORKID) {
     if (!(flags & SCRIPT_ENABLE_SIGHASH_FORKID))
       return set_error(serror, SCRIPT_ERR_ILLEGAL_FORKID);
   } else {
     // Drop the signature in scripts when SIGHASH_FORKID is not used.
     scriptCode.FindAndDelete(CScript(vchSig));
   }
 ````
 
+## Note
+
+In the UAHF, a `fork id` of 0 is used (see [[4]](#uahfspec) REQ-6-2 NOTE 4), i.e.
+the GetForkID() function returns zero.
+In that case the code can be simplified to omit the function.
+
 ## References
 
 <a name="bip143">[1]</a> https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki
 
 <a name="bip143Motivation">[2]</a> https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Motivation
 
 <a name="OP_CHECKSIG">[3]</a> https://en.bitcoin.it/wiki/OP_CHECKSIG
+
+<a name="uahfspec">[4]</a> https://github.com/Bitcoin-UAHF/spec/blob/master/uahf-technical-spec.md
diff --git a/doc/abc/uahf-technical-spec.md b/doc/abc/uahf-technical-spec.md
index 62a41910a8..d775a35b0a 100644
--- a/doc/abc/uahf-technical-spec.md
+++ b/doc/abc/uahf-technical-spec.md
@@ -1,225 +1,244 @@
 # UAHF Technical Specification
 
-Version 1.2, 2017-06-14
+Version 1.4, 2017-07-16
 
 
 ## Introduction
 
 This document describes proposed requirements for a block size Hard Fork (HF).
 
 BUIP 55 specified a block height fork. This UAHF specification is
 inspired by the idea of a flag day, but changed to a time-based fork due
 to miner requests. It should be possible to change easily to a height-based
 fork - the sense of the requirements would largely stay the same.
 
 
 ## Definitions
 
 MTP: the "median time past" value of a block, calculated from the
 nTime values of its past up to 11 ancestors, as obtained by the
 GetMedianTimePast(block.parent) call.
 
 "activation time": once the MTP of the chain tip is equal to or greater
 than this time, the next block must be a valid fork block. The fork block
 and subsequent blocks built on it must satisfy the new consensus rules.
 
 "fork block": the first block built on top of a chain tip whose MTP is
 greater than or equal to the activation time.
 
 "fork EB": the user-specified value that EB shall be set to at
 activation time. EB can be adjusted post-activation by the user.
 
 "fork MG": the user-specified value that MG shall be set to at activation
 time. It must be > 1MB. The user can adjust MG to any value once the
 fork has occurred (not limited to > 1MB after the fork).
 
 "Large block" means a block satisfying 1,000,000 bytes < block
 size <= EB, where EB is as adjusted by REQ-4-1 and a regular block
 is a block up to 1,000,000 bytes in size.
 
 "Core rules" means all blocks <= 1,000,000 bytes (Base block size).
 
 "Extended BU tx/sigops rules" means the existing additional consensus rules (1) and
 (2) below, as formalized by BUIP040 [1] and used by the Bitcoin Unlimited
 client's excessive checks for blocks larger than 1MB, extended with rule
 (3) below:
 1. maximum sigops per block is calculated based on the actual size of
 a block using
 max_block_sigops = 20000 * ceil((max(blocksize, 1000000) / 1000000))
 2. maximum allowed size of a single transaction is 1,000,000 bytes (1MB)
 3. maximum allowed number of sigops for a single transaction is 20k .
 
 NOTE 1: In plain English, the maximum allowed sigops per block is
 20K sigops per the size of the block, rounded up to nearest integer in MB.
 i.e. 20K if <= 1MB, 40K for the blocks > 1MB and up to 2MB, etc.
 
 
 ## Requirements
 
 ### REQ-1 (fork by default)
 
 The client (with UAHF implementation) shall default to activating
 a hard fork with new consensus rules as specified by the remaining
 requirements.
 
 RATIONALE: It is better to make the HF active by default in a
 special HF release version. Users have to download a version capable
 of HF anyway, it is more convenient for them if the default does not
 require them to make additional configuration.
 
 NOTE 1: It will be possible to disable the fork behavior (see
 REQ-DISABLE)
 
 
 ### REQ-2 (configurable activation time)
 
 The client shall allow a "activation time" to be configured by the user,
 with a default value of 1501590000 (epoch time corresponding to Tue
 1 Aug 2017 12:20:00 UTC)
 
 RATIONALE: Make it configurable to adapt easily to UASF activation
 time changes.
 
 NOTE 1: Configuring a "activation time" value of zero (0) shall disable
 any UAHF hard fork special rules (see REQ-DISABLE)
 
 
 ### REQ-3 (fork block must be > 1MB)
 
 The client shall enforce a block size larger than 1,000,000 bytes
 for the fork block.
 
 RATIONALE: This enforces the hard fork from the original 1MB
 chain and prevents a re-organization of the forked chain to
 the original chain.
 
 
 ### REQ-4-1 (require "fork EB" configured to at least 8MB at startup)
 
 If UAHF is not disabled (see REQ-DISABLE), the client shall enforce
 that the "fork EB" is configured to at least 8,000,000 (bytes) by raising
 an error during startup requesting the user to ensure adequate configuration.
 
 RATIONALE: Users need to be able to run with their usual EB prior to the
 fork (e.g. some are running EB1 currently). The fork code needs to adjust
 this EB automatically to a > 1MB value. 8MB is chosen as a minimum since
 miners have indicated in the past that they would be willing to support
 such a size, and the current network is capable of handling it.
 
 
 ### REQ-4-2 (require user to specify suitable *new* MG at startup)
 
 If UAHF is not disabled (see REQ-DISABLE), the client shall require
 the user to specify a "fork MG" (mining generation size) greater than
 1,000,000 bytes.
 
 RATIONALE: This ensures a suitable MG is set at the activation time so
 that a mining node would produce a fork block compatible with REQ-3.
 It also forces the user (miner) to decide on what size blocks they want to
 produce immediately after the fork.
 
 NOTE 1: The DEFAULT_MAX_GENERATED_BLOCK_SIZE in the released client needs
 to remain 1,000,000 bytes so that the client will not generate invalid
 blocks before the fork activates. At activation time, however, the "fork MG"
 specified by the user (default: 2MB) will take effect.
 
 
 ### REQ-5 (max tx / max block sigops rules for blocks > 1 MB)
 
 Blocks larger than 1,000,000 shall be subject to "Extended BU tx/sigops rules"
 as follows:
 
 1. maximum sigops per block shall be calculated based on the actual size of
 a block using
 `max_block_sigops = 20000 * ceil((max(blocksize_bytes, 1000000) / 1000000))`
 
 2. maximum allowed size of a single transaction shall be 1,000,000 bytes
 
 NOTE 1: Blocks up to and including 1,000,000 bytes in size shall be subject
 to existing pre-fork Bitcoin consensus rules.
 
 NOTE 2: Transactions exceeding 100,000 bytes (100KB) shall remain
 non-standard after the activation time, meaning they will not be relayed.
 
 NOTE 3: BU treats both rules (1) and (2) as falling under the Emergent
 Consensus rules (AD). Other clients may choose to implement them as
 firm rules at their own risk.
 
 
 ### REQ-6-1 (disallow special OP_RETURN-marked transactions with sunset clause)
 
 Once the fork has activated, transactions containing an OP_RETURN output
-with a specific magic data value shall be considered invalid until
+with a specific magic data value of
+
+    Bitcoin: A Peer-to-Peer Electronic Cash System
+
+(46 characters, including the single spaces separating the words, and
+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)
 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
 for block 530,001 and onwards.
 
 
 ### REQ-6-2 (opt-in signature shift via hash type)
 
 Once the fork has activated, a transaction shall not be deemed invalid 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
 
 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).
 
 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 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 3: 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).
+
 
 ### REQ-6-3 (use adapted BIP143 hash algorithm for protected transactions)
 
 Once the fork has activated, any transaction that has bit 6 set in its
 hash type shall have its signature hash computed using a minimally revised
 form of the transaction digest algorithm specified in BIP143.
 
 RATIONALE: see Motivation section of BIP143 [2].
 
 NOTE 1: refer to [3] for the specificaton of the revised transaction
 digest based on BIP143. Revisions were made to account for non-Segwit
 deployment.
 
 
+### 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
+before the tip, the proof of work target is increased by a quarter, or 25%,
+which corresponds to a difficulty reduction of 20% .
+
+RATIONALE: The hashrate supporting the chain is dependent on market price and
+hard to predict. In order to make sure the chain remains viable no matter what
+difficulty needs to adjust down in case of abrupt hashrate drop.
+
 ### REQ-DISABLE (disable fork by setting fork time to 0)
 
 If the activation time is configured to 0, the client shall not enforce
 the new consensus rules of UAHF, including the activation of the fork,
 the size constraint at a certain time, and the enforcing of EB/AD
 constraints at startup.
 
 RATIONALE: To make it possible to use such a release as a compatible
 client with legacy chain / i.e. to decide to not follow the HF on one's
 node / make a decision at late stage without needing to change client.
 
 
 ## References
 
 [1] https://bitco.in/forum/threads/buip040-passed-emergent-consensus-parameters-and-defaults-for-large-1mb-blocks.1643/
 
 [2] https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Motivation
 
 [3] [Digest for replay protected signature verification accross hard forks](replay-protected-sighash.md)
 
 [4] https://github.com/Bitcoin-UAHF/spec/blob/master/uahf-test-plan.md
 
 
 END