From ebe2ac3ce64b1e115d8a3f6a6dfa680c4f14dc83 Mon Sep 17 00:00:00 2001
From: Jean Do <117163651+jdlcdl@users.noreply.github.com>
Date: Wed, 1 Jan 2025 15:03:59 -0400
Subject: [PATCH 1/3] Update mint-005.md

Changes reflect my understanding of the rest of this document's statements, tables, miniscript policy and output descriptor.
---
 mint-005.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/mint-005.md b/mint-005.md
index 9882d5e..9ddaa6d 100644
--- a/mint-005.md
+++ b/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.
 
@@ -231,4 +231,4 @@ Transaction](https://mempool.space/signet/tx/bc75e9c7bd62168134a6283a56c2a0bf3c8
 Signed by: $RK_1$, $RK_2$
 
 [Reference Testnet
-Transaction](https://mempool.space/signet/tx/1d35568360a3a11309c77c893142a0c0cf58ed9cfce981c5492c66fb795f1872)
\ No newline at end of file
+Transaction](https://mempool.space/signet/tx/1d35568360a3a11309c77c893142a0c0cf58ed9cfce981c5492c66fb795f1872)

From 397a983b436d275dac9452f2bc2ada1a8c13af79 Mon Sep 17 00:00:00 2001
From: Jean Do <jean.dominique.lecomte.delisle@protonmail.me>
Date: Tue, 7 Jan 2025 18:24:05 -0400
Subject: [PATCH 2/3] commented out sample txs. Todo: find replacements

---
 mint-005.md | 21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/mint-005.md b/mint-005.md
index 9ddaa6d..e16667a 100644
--- a/mint-005.md
+++ b/mint-005.md
@@ -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
+[Reference Signet
 Transaction](https://mempool.space/signet/tx/1d35568360a3a11309c77c893142a0c0cf58ed9cfce981c5492c66fb795f1872)
+-->

From 86367c6ded57c0f231736cb03b435d83fa4b24cf Mon Sep 17 00:00:00 2001
From: Jean Do <jean.dominique.lecomte.delisle@protonmail.me>
Date: Thu, 9 Jan 2025 12:27:42 -0400
Subject: [PATCH 3/3] commented Source Policy: until "sln:" vs "snl:"
 understood

---
 mint-005.md | 50 ++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 46 insertions(+), 4 deletions(-)

diff --git a/mint-005.md b/mint-005.md
index e16667a..d819543 100644
--- a/mint-005.md
+++ b/mint-005.md
@@ -207,8 +207,50 @@ For this example, the `smallest_epoch_timestamp` is: 1672531200 (Jan 1 2023, mid
 - MINT-005 Output Descriptor:
 <code>wsh(andor(multi(2,$PAK_1$,$PAK_2$,$PAK_3$),or_i(and_v(v:pkh($SAK$),after(`between_epoch_timestamp`)),thresh(2,pk($PK_1$),s:pk($PK_2$),s:pk($PK_3$),snl:after(`smallest_epoch_timestamp`))),and_v(v:thresh(2,pkh($RK_1$),a:pkh($RK_2$),a:pkh($RK_3$)),after(`larget_epoch_timestamp`))))</code>
 
+<!--
+The following source-policy does not appear to perfectly compile to the Miniscript as in the MINT-005 Output Descriptor above.
+
+When compiling a very similar source policy at https://bitcoin.sipa.be/miniscript/, the resulting Miniscript 'identities' prefixing "after(smallest_epoch_timestamp)` become "sln:" instead of "snl:".
+
+Assertion to confirm: This plays no meaningful logical difference in the meaning of this mint (other than different bitcoin scripts and therefore different addresses between the two versions)!?!?
+
+...still, if it's possible to have another source-policy that perfectly compiles to the exact Miniscript descriptor, I'm interested in learning what that source policy was.
+
+Analyzing the "sln:" version of similar Miniscript shows:
+```
+s: or_i
+    false
+    n: after(smallest_epoch_timestamp)
+```
+whereas the "snl:" version of the MINT-005 Output Descriptor above shows:
+```
+s: n: or_i
+    false
+    after(smallest_epoch_timestamp)
+```
+
+The resulting bitcoin script structure changes as well.
+
+At the bottom, starting with the last `else` leg, the "sln:" version is:
+```
+    OP_ELSE
+      <smallest_epoch_timestamp> OP_CHECKLOCKTIMEVERIFY OP_0NOTEQUAL
+    OP_ENDIF
+    OP_ADD 2 OP_EQUAL
+```
+whereas the "snl:" version is:
+```
+    OP_ELSE
+      <smallest_epoch_timestamp> OP_CHECKLOCKTIMEVERIFY
+    OP_ENDIF
+    OP_0NOTEQUAL OP_ADD 2 OP_EQUAL
+```
+
+For a future commit: If there is another source policy that perfectly compiles to the same Miniscript as the descriptor, to update below.
+
 - Source Policy (FOR REFERENCE PURPOSES ONLY):
 <code>"or(99@and(thresh(2,pk($PAK_1$),pk($PAK_2$),pk($PAK_3$)),or(99@thresh(2,pk($PK_1$),pk($PK_2$),pk($PK_3$),after(`smallest_epoch_timestamp`)),and(pk($SAK$),after(`between_epoch_timestamp`)))),and(thresh(2,pk($RK_1$),pk($RK_2$),pk($RK_3)),after(`largest_epoch_timestamp`)))"</code>
+-->
 
 ## Layer 1 Example Spend
 
@@ -217,13 +259,13 @@ Signed by: $PK_1$, $PK_2$, $PAK_1$, $PAK_2$
 <!--
 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.
+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 (largest is smallest).
 
-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.
+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 the Secondary Agent to work with the 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.
+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 already 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.
+I suspect that rob1ham may have much better sample transactions, perhaps even on mainnet, that would better represent this great work.  For a future commit, better sample transactions and updating the epoch_timestamps above to match them.
 
 
 [Reference Signet