From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id A9286C002D for ; Fri, 13 May 2022 13:06:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id A444C408B3 for ; Fri, 13 May 2022 13:06:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSEV274LQfmG for ; Fri, 13 May 2022 13:06:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by smtp4.osuosl.org (Postfix) with ESMTPS id 8FAF8408A7 for ; Fri, 13 May 2022 13:06:04 +0000 (UTC) Received: by mail-pj1-x1035.google.com with SMTP id n10so8016495pjh.5 for ; Fri, 13 May 2022 06:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=HlVntcSfqmzk0bGm+v9zIui6xlJA2CJW4/zKLA4nkLg=; b=Hb5wL3uMRejMRMHOGxEzYZMSP7xYL0AHw1HGIMvg+jJiaT4/qcFLNMr605JrjJ4c0a SDIQCarG0uxewTDv1pCtCuquk9mQLizJGuro+G3WuygxkIPK5BiEVaYXDhRiqC/mCvwO vhajTdynAJv5G3ChGEKurUioxIZBJ2BxnaEPLl9kJ4bMAoMaA4TxLUuyJnhYOKH4YgIb HbigSNEH24KPZgaJ/QhYW3brgGgPgEOImlgsq6Ejvn1hYyPf343X/Z44Mtw7YXs7pp65 bEU2FVb6f87yL86n2zwayX6gS0kYuN81AijqEKjHnTbyGIAWwAYSDg8LIdU86VNS7umY Us7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HlVntcSfqmzk0bGm+v9zIui6xlJA2CJW4/zKLA4nkLg=; b=EROIrvQ37Ts7t+noLHVUllCIp7fWDGs7SrLkw6CrRFoAOPf5ziu54U3OiU3wz4HA1k u3MprjytG4xQR+R8G1aViItcU9PRuvKQf1tKNR3dnmavYqopwh5IUK6+ceP2zWe+o0Xw JheT9APpSB9g6a8KSiIKZzs781aI5mPRf409d7MtkvNXDigpawxafmLqfbq7VTR3oTCl z8WeF+PRJfBzlYAriqlEyD/xwv/YDNdmMiTClHr+WLwRVqbHTiI7V/UksuSTQX4aDu2r 84nw90i9uQ2EgpaFewAuXvK8VWb69Ok5hM2Bbuk2jIqE0dWv1lZZJi24Yb9MpFUJSw0w Etrw== X-Gm-Message-State: AOAM533od7dGmzBi6HYF8/RTJcfuB1B8k+KjrfG5ORDngChPY5g2H5qt SNO/HxvBQkJdh++7xwjOmr0WNlKb1bROHa7pIKFzIVAD10M= X-Google-Smtp-Source: ABdhPJxTh6LdD8DisbEFLKcPT005/19vNenLzmEEwoZ7+8UlcHAF5B5IVykPNSHOrVrUOYqzD1vcjpe+cWQQ+RSOxzw= X-Received: by 2002:a17:90a:930b:b0:1d5:684b:8e13 with SMTP id p11-20020a17090a930b00b001d5684b8e13mr4839747pjo.153.1652447163464; Fri, 13 May 2022 06:06:03 -0700 (PDT) MIME-Version: 1.0 From: Billy Tetrud Date: Fri, 13 May 2022 08:05:47 -0500 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000003041a705dee456ba" X-Mailman-Approved-At: Fri, 13 May 2022 13:11:45 +0000 Subject: [bitcoin-dev] Soliciting more discussion for OP_CONSTRAINDESTINATION (a covenant opcode) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2022 13:06:08 -0000 --0000000000003041a705dee456ba Content-Type: text/plain; charset="UTF-8" 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 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 . 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 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 , 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 --0000000000003041a705dee456ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Since there's recently=C2= =A0been a lot more interest in discussing covenants and alternative covenan= t proposals because of CTV, I figured I'd bring up my own proposed cove= nant opcode again while=C2=A0the urge is still fresh.=C2=A0

<= /div>
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 p= roposal that I think has a lot of benefits over any other covenant opcode p= roposal, I am not suggesting that this should supplant CTV.=C2=A0I also don= 't have any plans to work on an implementation of OP_CONSTRAINDESTINATI= ON, and I certainly wouldn't without more interest and an equal partner= on a project like this.=C2=A0=C2=A0I think CTV is a quite useful opcode th= at 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 alread= y plenty of exposition about it in the spec:


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
    • En= ables infinitely recursive covenants
    • Does not and cannot prevent ma= lleability on its own
The wallet vaults that = can be created using this are more flexi= ble than ones that can be created with OP_CTV:
  • Spends fro= m a wallet vault can spend arbitrary amounts, and send the rest back to a c= hange 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.=C2=A0
  • Anchor outputs are n= ot (necessarily) necessary for fee bumping. A user can have the option of c= reating a transaction that includes other inputs that can contribute to the= fee. Those inputs can also send to other outputs, allowing one to basicall= y attach an anchor output at transaction-creation-time if they think they w= ant it for CPFP fee bumping.=C2=A0
One less-than-ideal proper= ty shared with CTV wallet vaults:
  • If the hot wallet / int= ermediate wallet key is stolen, the attacker can steal funds after the owne= r initiates a normal spend.
The opcode requires some me= chanism for fee limiting:
  • As currently specified, a= n attacker who gets access to the hot key can fee-grief=C2=A0the owner of t= he vault by spending all the coins as fees. The proposed solution to this i= s to add an addition opcode to limit the fees, called OP_LIMITFEECONTRIBUTION. Another solution would be = to require 100% of the output values go to the destinations passed to OP_CO= NSTRAINDESTINATION, and rely on CPFP on an anchor output to pay the fees, w= hich seems less than ideal. A third solution would be to include sponsor tr= ansactions alongside the opcode and rely on those instead of CPFP. While I = think sponsor transactions would be very useful, always relying on an exter= nal wallet to pay the fees is IMO not super great since it allows for incon= venient 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 acquirin= g more bitcoin in a hotter wallet, or doing a full recovery transaction wit= h all your wallet vault keys.
The downsides compared to CTV:<= /div>
  • Increased implementation complexity and complexity = of the possibility space. The opcode's=C2=A0main purpose of ensuring th= at only certain addresses are sent to might be simpler than CTV, but the as= pect of counting output values pushes it into more complex territory. And w= hen you consider the solutions to fee-griefing, that adds additional implem= entation and possibility-space complexity (depending on how its done).
    • =
  • txid malleability

OP_CONSTRAINDES= TINATION + OP_PUSHOUTPUTSTACK
OP_PUSHOUTPUTSTACK=C2=A0is an opcode that allows a script to dynamic= ally add local state to an output being created.
  • Unlike O= P_CTV
    • Also enables infinitely recursive covenants and does = not prevent malleability.
    • Can be open ended (not fully enumerated)<= /li>
    • Can produce dynamic state.
The wallet vaul= ts that can be created with this combination of opcodes is a bit better tha= n ones with just OP_CD on its own:
  • Even if the hot wallet= key is stolen, the attacker cannot steal funds without compromising all th= e seeds that=C2=A0make up the wallet vault.=C2=A0
However, th= e complexity is substantially higher:
  • Being able to= push dynamic state onto transactions substantially increases the possibili= ty space of covenant chains. There may be significant consequences of this = that no one has thought of yet.=C2=A0
Summary

These opcodes would allow the creation of wal= let vaults that could be intuitively used in almost the same way that a sta= ndard wallet can be used, including mixing in arbitrary inputs and outputs = (including ones you don't own). With