From: Luke Carriere <luke@lukecarriere.com>
To: bitcoindev@googlegroups.com
Subject: [bitcoindev]
Date: Mon, 5 Oct 2026 20:16:14 -0500 [thread overview]
Message-ID: <CAFYm+Pe8_a568_=GtHhHMVZUF8j8JSS_eYJEaTSbJnOn-dkCHw@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]
Hi bitcoin,
I'd like feedback on a draft that standardizes the policy a co-signer
enforces, not the co-signer itself.
A co-signer that signs only when a predicate holds is a known way to
emulate covenants today. Towns described the multisig version of this in
2021. Recent work (Halseth's blinded co-signers, Chain Code
Delegation, predicate blind signatures, bonded co-signers) and products
such as Liquidium and Lendasat each define their own policy.
A wallet built for one cannot use a co-signer or oracle built for another.
The draft is one policy format for that. It covers open verification,
blinded verification, and enclave verification, and conditions taken
from the transaction or from external attestations. Co-signers must accept
DLC oracle attestations, so existing oracles can be evidence
sources unchanged. Anything script can enforce is required to be in script.
Every policy keeps a spending path that needs no co-signer.
Draft BIP:
https://github.com/lukecarriere/bip-cosigner-spending-policies/blob/main/bip-cosigner-spending-policies.md
I want to know whether this is the right layer to standardize, and comments
on the open questions in the draft:
- canonical JSON or TLV for the policy serialization
- whether blinded verification can be specified from existing blinded
MuSig2 and predicate blind signatures, or should wait
- whether the statement attestation format belongs here or in the DLC
specifications
- whether the output expression language is the right size
- whether the fallback path must be timelocked, so it cannot bypass
the co-signers early
Thank you my brothers,
Luke Carriere
luke@lukecarriere.com
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAFYm%2BPe8_a568_%3DGtHhHMVZUF8j8JSS_eYJEaTSbJnOn-dkCHw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 3384 bytes --]
reply other threads:[~2026-10-06 2:32 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFYm+Pe8_a568_=GtHhHMVZUF8j8JSS_eYJEaTSbJnOn-dkCHw@mail.gmail.com' \
--to=luke@lukecarriere.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox