Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Corrections for mint-005.md (still incomplete) #15

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

Corrections for mint-005.md (still incomplete) #15

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
ebe2ac3
Update mint-005.md
jdlcdl Jan 1, 2025
397a983
commented out sample txs. Todo: find replacements
Jan 7, 2025
86367c6
commented Source Policy: until "sln:" vs "snl:" understood
Jan 9, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 63 additions & 8 deletions mint-005.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down Expand Up @@ -207,28 +207,83 @@ 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

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 (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 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 already been available.

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
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)
-->