Update mint-005.md

mint-005.md

@@ -6,11 +6,11 @@
 
 To provide a custody arrangement in which an owner of bitcoin (Principal) is able to secure bitcoin by working with an Agent. Unlike existing collaborative custody models up to this point, **where bitcoin keys WITHIN a multisig threshold are shared between Principals and agents**, a joint custody model by default requires a threshold of keys by both the Agent & Principal for movement of funds.
 
-This introduces a concept of "Negative Control" where, by default, funds are not able to be moved unless both the Principal and Agent sign the transaction.
+This introduces a concept of "Negative Control" where, by default, funds are not able to be moved unless both the Principal and Primary Agent sign the transaction.
 
-In the event the Principal loses access to all of their keys, a secondary agent is available to work with the Primary Agent such that funds can be recovered after a set period of time.
+In the unlikely event the Principal has lost 2 of their 3 keys, a timelock enabled threshold allows only 1 of 3 keys from the Principal to be signed with the Primary Agent.
 
-In the unlikely event the Primary Agent has lost 2 of their 3 keys, a timelock enabled threshold allows  only 1 of 3 keys from the Primary Agent to be signed with the secondary agent.
+In the event the Principal loses access to all of their keys, a secondary agent is available to work with the Primary Agent such that funds can be recovered after a set period of time.
 
 Finally, in the event the Principal no longer wishes to work with the agent, say after a contract expires, the custody defers to a set of recovery keys, which can be held either by the Principal, or their own delegated managers of the recovery keys. As a result, when enough time has passed, the Principal is able to move bitcoin unilaterally without having the Agent sign key material.
 
@@ -214,21 +214,34 @@ For this example, the `smallest_epoch_timestamp` is: 1672531200 (Jan 1 2023, mid
 
 Signed by: $PK_1$, $PK_2$, $PAK_1$, $PAK_2$
 
-[Reference Testnet
+<!--
+The following transactions do not represent this mint and are inconsistent with the rest of this document:
+
+1 of 3 epochs are incorrect. For each of the sample transactions below, the little-endian 4byte values pushed before each op_cltv do not match the values above for smallest_, between_ and largest_ epoch_timestamps.  Instead they are for (Jan 1 '23, Jan 15 '23', and Dec 15 '22) respectively.
+
+As noted above, they're also out of order, which alters everything. The epoch for recovery Keys falls between the epoch relaxing Principal to 1-of-3 and the epoch allowing Secondary Agent to work with Primary Agent's 2-of-3.
+
+On a minor note: if looking only at the inputs for these 4 sample transactions, it appears that the wallet was funded months after the last epoch, so for each of the sample spends, all of the satisfiable spending conditions would have been available.
+
+I suspect that rob1ham may have much better sample transactions, perhaps even on mainnet, that would be better represent this great work.  For a future commit, better sample transactions and updating the timestamps to above to match them.
+
+
+[Reference Signet
 Transaction](https://mempool.space/signet/tx/2836d6af6b5c4bb01e926391f64771fb333193676040b24d4236ba0bb89a7008)
 
 ## Layer 2 Example Spend
 Signed by: $PK_1$, $PK_2$, $SAK$
 
-[Reference Testnet
+[Reference Signet
 Transaction](https://mempool.space/signet/tx/36aa3dfd0c7b4f4d8c7924c411e240920e4b4d36950ca59f68098b77162ae54d)
 
 ## Layer 3 Example Spend
-[Reference Testnet
+[Reference Signet
 Transaction](https://mempool.space/signet/tx/bc75e9c7bd62168134a6283a56c2a0bf3c872cc6703d9566f1851309d5ef7465)
 
 ## Layer 4 Example Spend
 Signed by: $RK_1$, $RK_2$
 
-[Reference Testnet
-Transaction](https://mempool.space/signet/tx/1d35568360a3a11309c77c893142a0c0cf58ed9cfce981c5492c66fb795f1872)
+[Reference Signet
+Transaction](https://mempool.space/signet/tx/1d35568360a3a11309c77c893142a0c0cf58ed9cfce981c5492c66fb795f1872)
+-->