path: root/74/4837fb8bf51bdf90be2a9c7f0434ff12f5dde0

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A9286C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 13 May 2022 13:06:04 +0000 (UTC)
Received: by mail-pj1-x1035.google.com with SMTP id n10so8016495pjh.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <billy.tetrud@gmail.com>
Date: Fri, 13 May 2022 08:05:47 -0500
Message-ID: <CAGpPWDZskzjKeSOZ3G8Z+1kVtDiKHzzOwk=oNgvm+1MbqzNZLg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
<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

--0000000000003041a705dee456ba
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<div><br></div><div>Since there&#39;s recently=C2=
=A0been a lot more interest in discussing covenants and alternative covenan=
t proposals because of CTV, I figured I&#39;d bring up my own proposed cove=
nant opcode again while=C2=A0the urge is still fresh.=C2=A0</div><div><br><=
/div><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=
&#39;t have any plans to work on an implementation of OP_CONSTRAINDESTINATI=
ON, and I certainly wouldn&#39;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.</div><div><br></div><div>To the opcode itself, there is alread=
y plenty of exposition about it in the spec:</div><div><br></div><div><a hr=
ef=3D"https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main=
/cd/bip-constraindestination.md">https://github.com/fresheneesz/bip-efficie=
nt-bitcoin-vaults/blob/main/cd/bip-constraindestination.md</a><br></div><di=
v><br></div><div>So I wanted to discuss it from the perspective of what it =
enables, pros and cons, and key considerations:</div><div><br></div><div><b=
>OP_CONSTRAINDESTINATION alone</b></div><ul><li>Like OP_CTV</li><ul><li>Is =
fully enumerated (not open ended)</li></ul><li>Unlike OP_CTV</li><ul><li>En=
ables infinitely recursive covenants</li><li>Does not and cannot prevent ma=
lleability on its own</li></ul></ul><div></div><div>The wallet vaults that =
<a href=3D"https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob=
/main/cd/op_cdWalletVault1.md">can be created</a> using this are more flexi=
ble than ones that can be created with OP_CTV:</div><div><ul><li>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.</li><li>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</li><li>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</li></ul><div>One less-than-ideal proper=
ty shared with CTV wallet vaults:</div><div><ul><li>If the hot wallet / int=
ermediate wallet key is stolen, the attacker can steal funds after the owne=
r initiates a normal spend.</li></ul></div><div>The opcode requires some me=
chanism for fee limiting:</div></div><div><ul><li>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 <a href=3D"https://gi=
thub.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/lfc/bip-limit-f=
ee-contribution.md">OP_LIMITFEECONTRIBUTION</a>. 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&#39;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.</li></ul><div>The downsides compared to CTV:<=
/div></div><div><ul><li>Increased implementation complexity and complexity =
of the possibility space. The opcode&#39;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).</li>=
<li>txid malleability</li></ul></div><div><br></div><div><b>OP_CONSTRAINDES=
TINATION + OP_PUSHOUTPUTSTACK</b></div><div><a href=3D"https://github.com/f=
resheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.m=
d">OP_PUSHOUTPUTSTACK</a>=C2=A0is an opcode that allows a script to dynamic=
ally add local state to an output being created.</div><div><ul><li>Unlike O=
P_CTV<br></li><ul><li>Also enables infinitely recursive covenants and does =
not prevent malleability.</li><li>Can be open ended (not fully enumerated)<=
/li><li>Can produce dynamic state.</li></ul></ul></div><div>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:</div><div><ul><li>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</li></ul><div>However, th=
e complexity is substantially higher:</div></div><div><ul><li>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</li></ul><div><b>Summary</b></div></d=
iv><div><b><br></b></div><div>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&#39;t own). With <a href=3D"https://github.com/fres=
heneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md=
">one more opcode</a>, funds could be sent directly out of a wallet vault i=
n a single transaction (whereas most wallet vaults require two transactions=
 to send money out to an arbitrary destination).=C2=A0=C2=A0</div><div><br>=
</div><div>The opcodes are significantly more complex and powerful than OP_=
CTV, and also substantially less developed. However, I think they demonstra=
te a number of important considerations for covenants in the context of wal=
let vaults. Please feel free to respond or ask questions here or as a githu=
b issue.=C2=A0</div><div><br></div><div>I think wallet vaults in particular=
 are a very important mechanism to enable much more secure self-custody set=
ups without sacrificing so much usability as normal multisig wallets requir=
e. Wallet vaults could enable significantly faster growth in the rate of bi=
tcoin holders who self-custody. CTV is the only opcode that is ready, and n=
o other opcode is even being developed, let alone close to being ready. I d=
on&#39;t see APO as a good practical covenant mechanism as currently define=
d. Any &quot;next&quot; covenant opcode would likely be 4-6 years out. I be=
lieve centralized custody is a huge problem in the bitcoin ecosystem, so I =
think making it easier for people to securely self-custody their bitcoins i=
s an incredibly important area of development. I believe even *if* some oth=
er covenant opcode makes CTV completely obsolete (which it isn&#39;t at all=
 clear to me is a likely scenario), a 4-6 year head start on better self-cu=
stody mechanisms could go a long way to saving a lot of people who need bit=
coin a lot of pain (from both custodial shenanigans and self-custody mishap=
s).=C2=A0<br></div><div><br>Cheers,</div><div>BT</div><div><br></div></div>

--0000000000003041a705dee456ba--