From: Billy Tetrud <billy.tetrud@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Soliciting more discussion for OP_CONSTRAINDESTINATION (a covenant opcode)
Date: Fri, 13 May 2022 08:05:47 -0500 [thread overview]
Message-ID: <CAGpPWDZskzjKeSOZ3G8Z+1kVtDiKHzzOwk=oNgvm+1MbqzNZLg@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 7024 bytes --]
Hi all,
Since there's recently been a lot more interest in discussing covenants and
alternative covenant proposals because of CTV, I figured I'd bring up my
own proposed covenant opcode again while the urge is still fresh.
To be clear upfront, this opcode has a spec, but nothing else. No tests. No
implementation. No signet. No tooling. While this is a serious proposal
that I think has a lot of benefits over any other covenant opcode proposal,
I am not suggesting that this should supplant CTV. I also don't have any
plans to work on an implementation of OP_CONSTRAINDESTINATION, and I
certainly wouldn't without more interest and an equal partner on a project
like this. I think CTV is a quite useful opcode that is simple and
incremental. OP_CD on the other hand is significantly more powerful, which
would be likely to lead to even more contention than what CTV has had.
To the opcode itself, there is already plenty of exposition about it in the
spec:
https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md
So I wanted to discuss it from the perspective of what it enables, pros and
cons, and key considerations:
*OP_CONSTRAINDESTINATION alone*
- Like OP_CTV
- Is fully enumerated (not open ended)
- Unlike OP_CTV
- Enables infinitely recursive covenants
- Does not and cannot prevent malleability on its own
The wallet vaults that can be created
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/op_cdWalletVault1.md>
using this are more flexible than ones that can be created with OP_CTV:
- Spends from a wallet vault can spend arbitrary amounts, and send the
rest back to a change address, just like a normal transaction.
- Arbitrary amounts of coins can be sent directly to any of the
addresses involved in the wallet vault without any risk of loss of funds.
- Anchor outputs are not (necessarily) necessary for fee bumping. A user
can have the option of creating a transaction that includes other inputs
that can contribute to the fee. Those inputs can also send to other
outputs, allowing one to basically attach an anchor output at
transaction-creation-time if they think they want it for CPFP fee bumping.
One less-than-ideal property shared with CTV wallet vaults:
- If the hot wallet / intermediate wallet key is stolen, the attacker
can steal funds after the owner initiates a normal spend.
The opcode requires some mechanism for fee limiting:
- As currently specified, an attacker who gets access to the hot key can
fee-grief the owner of the vault by spending all the coins as fees. The
proposed solution to this is to add an addition opcode to limit the fees,
called OP_LIMITFEECONTRIBUTION
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/lfc/bip-limit-fee-contribution.md>.
Another solution would be to require 100% of the output values go to the
destinations passed to OP_CONSTRAINDESTINATION, and rely on CPFP on an
anchor output to pay the fees, which seems less than ideal. A third
solution would be to include sponsor transactions alongside the opcode and
rely on those instead of CPFP. While I think sponsor transactions would be
very useful, always relying on an external wallet to pay the fees is IMO
not super great since it allows for inconvenient scenarios if all your
money is in this secure vault, in which case you simply wouldn't be able to
get it out without either first acquiring more bitcoin in a hotter wallet,
or doing a full recovery transaction with all your wallet vault keys.
The downsides compared to CTV:
- Increased implementation complexity and complexity of the possibility
space. The opcode's main purpose of ensuring that only certain addresses
are sent to might be simpler than CTV, but the aspect of counting output
values pushes it into more complex territory. And when you consider the
solutions to fee-griefing, that adds additional implementation and
possibility-space complexity (depending on how its done).
- txid malleability
*OP_CONSTRAINDESTINATION + OP_PUSHOUTPUTSTACK*
OP_PUSHOUTPUTSTACK
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md>
is
an opcode that allows a script to dynamically add local state to an output
being created.
- Unlike OP_CTV
- Also enables infinitely recursive covenants and does not prevent
malleability.
- Can be open ended (not fully enumerated)
- Can produce dynamic state.
The wallet vaults that can be created with this combination of opcodes is a
bit better than ones with just OP_CD on its own:
- Even if the hot wallet key is stolen, the attacker cannot steal funds
without compromising all the seeds that make up the wallet vault.
However, the complexity is substantially higher:
- Being able to push dynamic state onto transactions substantially
increases the possibility space of covenant chains. There may be
significant consequences of this that no one has thought of yet.
*Summary*
These opcodes would allow the creation of wallet vaults that could be
intuitively used in almost the same way that a standard wallet can be used,
including mixing in arbitrary inputs and outputs (including ones you don't
own). With one more opcode
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md>,
funds could be sent directly out of a wallet vault in a single transaction
(whereas most wallet vaults require two transactions to send money out to
an arbitrary destination).
The opcodes are significantly more complex and powerful than OP_CTV, and
also substantially less developed. However, I think they demonstrate a
number of important considerations for covenants in the context of wallet
vaults. Please feel free to respond or ask questions here or as a github
issue.
I think wallet vaults in particular are a very important mechanism to
enable much more secure self-custody setups without sacrificing so much
usability as normal multisig wallets require. Wallet vaults could enable
significantly faster growth in the rate of bitcoin holders who
self-custody. CTV is the only opcode that is ready, and no other opcode is
even being developed, let alone close to being ready. I don't see APO as a
good practical covenant mechanism as currently defined. Any "next" covenant
opcode would likely be 4-6 years out. I believe centralized custody is a
huge problem in the bitcoin ecosystem, so I think making it easier for
people to securely self-custody their bitcoins is an incredibly important
area of development. I believe even *if* some other covenant opcode makes
CTV completely obsolete (which it isn't at all clear to me is a likely
scenario), a 4-6 year head start on better self-custody mechanisms could go
a long way to saving a lot of people who need bitcoin a lot of pain (from
both custodial shenanigans and self-custody mishaps).
Cheers,
BT
[-- Attachment #2: Type: text/html, Size: 7791 bytes --]
reply other threads:[~2022-05-13 13:06 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='CAGpPWDZskzjKeSOZ3G8Z+1kVtDiKHzzOwk=oNgvm+1MbqzNZLg@mail.gmail.com' \
--to=billy.tetrud@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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