Templates 000,001,002 Submission

[RandyMcMillan]

No description provided.

[RandyMcMillan]

squashed #2 PR @apoelstra request.

[RandyMcMillan]

added linter to this PR:

https://github.com/bitcoincore-dev/miniscript-templates/actions/runs/7292315752/job/19873043982

turn on actions to use.

[RandyMcMillan]

ab8f15b: applied spelling and markdown changes the linter detected.

Ought to be ready for review.

Thanks for the feedback so far! @apoelstra @Rob1Ham

[apoelstra]

ab8f15b looks great! I have only a couple nits.

[apoelstra]

In ab8f15b:

I'm not sure where this should go, but somewhere in this doc we should say that the first timelock should be less than the second. This doesn't matter at all semantically but it's good to tighten the spec wherever we can, and it'd be potentially confusing to have the timelocks in an arbitrary order.

[RandyMcMillan]

#11 (comment)

[RandyMcMillan]

I have been using the term "Cascading Timelocks" in some of my own template proposals.
We are on the same page with this!

[RandyMcMillan]

I introduce the terminology "Cascading TimeLock" and give a short explanation on why TimeLocks should be sequential.

[apoelstra]

ACK cf0b6bf

[apoelstra]

This looks great! Thanks for all your iteration!

[benma]

Hi

Nice effort, being able to abstract policies/Miniscripts from users and still give them access to its power is very much needed.

Let me know if I should open an issue instead, I was not sure if I should comment here on the approved PR or open an issue.

provide a common MiniScript policy.

A policy can be compiled to many different Miniscripts that encode the same semantics, and the output of the policy compliation can change between compilers and even between compiler versions.

Hardware wallets generally work at the Miniscript/descriptor level and don't compile policies.

It would help if you could describe how Miniscript templates should work with hardware wallets in more detail. Ideally the hardware wallet user sees a high level description of the semantics based on these templates, but then the templates can't be policies (only), as the compiled Miniscript/descriptor could unexpectedly change.

Another point where guidance would help is with backups: the user needs to have a valid backup of the full descriptor to be able to restore, and at the same time not trust their computer to display the correct information.

Did you already brainstorm solutions to these?

[apoelstra]

Hi @benma. Great question, and I think @Rob1Ham is better positioned than me to answer it.

For my part: in rust-miniscript we have a lift function which takes an arbitrary miniscript and drops the specific combinators to obtain a policy. We recommend users use this to compare Miniscripts for semantic equivalence. So the idea is that two Miniscripts that differ only in e.g. their choice of or constructions will be considered "the same" and if they matched a MINT in this repo, could be displayed to the user as that MINT.

This is potentially dangerous because it will show users policies that are "the same" even if they actually produce different addresses.

If we want to canonize this strategy then you're right that we need a document explaining (a) how wallets are supposed to manage things and present to users, and (b) a specification for this "lift"ing procedure. (It's super simple: you can do it textually by dropping all the letters before : or after _ in a combinator name.)

An alternate strategy would be to run every policy in these documents through the compiler to get an actual Miniscript (I think for these three MINTs there is actually only one possible sensible compilation, so this is an easy case) (where "sensible" means, like, not chaining a tons of ls and us on each other for no reason).

[RandyMcMillan]

I did notice this while working on this documentation.

[RandyMcMillan]

I have additional tooling which is ommited from this PR. I recommend limiting the scope of this PR (to keep things moving) and creating an issue.

[Rob1Ham]

Great points @benma.

Given the variation of policies that can result in effectively the same spending policies, but different script construction and therefore resulting in different addresses, it probably is best to default to an Output Descriptor post compilation.

Especially for the interoperation with Hardware Wallets, we want to have an explicit predetermined way that a given MINT would align with hardware wallets, and not have to have hardware wallet firmware/software wallet versions whenever the compiler comes out with new versions.

My ultimate goal with this project is to have a repository of known and validated application of miniscript templates which enable a synergy between users, hardware wallet signers, and software wallet developers. We remove uncertainty and opportunities for user error by deciding on a specific output descriptor for everyone to align on.

Around backups: In theory, if you knew an output descriptor followed a particular MINT, you'd be able to have some kind of compression on the data to be stored, but up to now that hasn't been discussed. One could store the XPUBs, and timelock details and have sufficient information to recover a wallet, but it isn't something I've explicitly put thought into beyond just storing the entire descriptor, happy to brainstorm ways to optimize this @benma!

[benma]

I converted this into an issue at #12 as requested. Let's continue there, thanks!

[RandyMcMillan]

follow up PR planned

use UTC not GMT

https://github.com/bitcoincore-dev/miniscript-templates/tree/1705598723/bc705a4/cf0b6bf-use-UTC