Bitcoin Development Mailinglist
 help / color / mirror / Atom feed
From: Lillian Wang <lilly.lezhi@gmail.com>
To: bitcoindev@googlegroups.com
Subject: [bitcoindev] Comparison of Bitcoin Covenant Proposals for Vaults
Date: Fri, 4 Sep 2026 15:01:22 -0400	[thread overview]
Message-ID: <CAPRk7czXnrB+yGV5X5UnfcXK8UBrrmSayhFPVNFvY2b6BFsTng@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2738 bytes --]

Hello list,

I am sharing a report comparing simplified Bitcoin vault constructions
using presigned transactions, CTV, APO/APOAS, TXHASH, CCV, and an
OP_CAT-based Purrfect Vault construction. Comparison factors include
partial withdrawals, withdrawal address commitment timing, flexibility for
in-transaction fee management, operational complexity, and on-chain cost.

In the basic vault constructions we considered, CTV and APOAS have fully
precomputed outputs and thus, like presigned transactions using
SIGHASH_ALL, do not support arbitrary partial withdrawals. OP_CTV
constrains the number of inputs, sequence values, and the current input
index but not the input outpoints, allowing some flexibility in choosing
fee-paying inputs. Meanwhile, APOAS omits more input information, meaning
inputs can be added more freely.

TXHASH and CCV enable vaults with greater but differing functionality.
TXHASH allows vault designers to select which transaction fields and input
or output indices to commit to. This versatility provides more support for
fee management and partial withdrawals at the cost of placing greater
responsibility on the implementer to ensure the correctness and security of
each vault. CCV can enforce how the current input’s amount is distributed
across different outputs, supporting partial withdrawals that require
remaining value to be revaulted. Additionally, CCV vaults can commit to the
withdrawal address in the unvault transaction rather than only during vault
setup. OP_CAT can support more arbitrary introspection and constraints,
depending on the construction, but the construction considered in this
report requires more complex scripts and witnesses and is thus less
practical in its current form.

Here’s the full report:
https://raw.githubusercontent.com/Skyler-Cloud/Bitcoin-Vault-Comparison/main/bitcoin-vault-comparison.pdf

I have also opened a discussion on Delving Bitcoin:
https://delvingbitcoin.org/t/comparing-bitcoin-covenant-proposals-for-vaults/2877

Hoping it will be useful for other work consolidating analyses of vault
constructions. I'd appreciate any feedback or corrections, especially with
my interpretations of the APOAS and CCV constructions, comparison
methodology, and other opcode combinations or vault properties.

Best,
Lillian Wang

-- 
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/CAPRk7czXnrB%2ByGV5X5UnfcXK8UBrrmSayhFPVNFvY2b6BFsTng%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 3327 bytes --]

                 reply	other threads:[~2026-09-07 15:46 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=CAPRk7czXnrB+yGV5X5UnfcXK8UBrrmSayhFPVNFvY2b6BFsTng@mail.gmail.com \
    --to=lilly.lezhi@gmail.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