path: root/34/89becc27443b9f7f65d967b53a188200502acc

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7E01DC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 25 Jul 2021 19:49:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 65B27832FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 25 Jul 2021 19:49:59 +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: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id hoDKSgJdb6QF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 25 Jul 2021 19:49:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [IPv6:2a00:1450:4864:20::533])
 by smtp1.osuosl.org (Postfix) with ESMTPS id D410A832BF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 25 Jul 2021 19:49:57 +0000 (UTC)
Received: by mail-ed1-x533.google.com with SMTP id l6so5785898edc.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 25 Jul 2021 12:49:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=Fwye+HfizgPQ//idm9zbCJVsfzjqTKpVfWUcdwm1kCA=;
 b=lcPbMABLgpAANkeCQSE+/0rKx213ezVLvXK+pcQW9ZoZ9DNwBk1LhsqIVqALi8DSjK
 e6vks58rvf+iAv5/T9h9we4plAqys4Lw/XxWVZTyI+J34QdqhnmYUxXqy+i08EJ44k52
 ryv+nbfc+oG8+uP3h7Z1RiZenyoC6IESA0bAH/5X15IiAYr+ldv1avPAdC/xH4hGccEz
 Dp4J0ANDpKpwntFKlKcS7ClfYmMl8gwI8NigYYuVD7zfgKm/v4ubclsfBaFIgw4q9usG
 IUvNWKBo4sMZd0+Y6OLjzaTEw1EZOQ7yEHKMp5kQ1xt7/Lb6RbhBVUEEcPY8Q5affkGo
 n2Ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=Fwye+HfizgPQ//idm9zbCJVsfzjqTKpVfWUcdwm1kCA=;
 b=Iqir5f/GE2dbAletA0nebK7N48mwD68D7AyfOQk647MX/kmcfl9MhmNnh6AwGKfXq6
 wlf8P7R8eOM2+o5grU3kB64Iwfcdink+I9DlxG3ueO3t9sPKRemKxyLrJwFWnWWas9pf
 FpxoEt7uTQkBSSeRynUyt1iJdwxW9kFsosIQjxqID0XTLpcXcBQVDCESgcjQYcwBH6xt
 gftlRSlBwcgmRZ7lHMbOjG9D2Zt4TkRlVGZVKqjJZwkohG38/1OZrDhktHYr4x+gxHBT
 NYSJ+SQ2XZxRfMKXKWx7Fzn0MHMk0bhfSCgDAtM+rbT2/XJ2uh7w6CNV7cBszzyFU/H4
 Cgmw==
X-Gm-Message-State: AOAM532yUQ44bLIEK9L5iMK7SFESy+E4SsMWPT5qe5LwDENNrDaj7fiA
 hr2pz7tnvQcmxFflCzWmfe/KiDsX5Tiemze0WPBNCeLHqg7YzQ==
X-Google-Smtp-Source: ABdhPJwrJPNmnn8vhU83WHc+vdXK9iHc2tMFxebL8HOawT/kMtcIolp5OYrpLnUdwqGiWSN8YTY/QadxyWwXC4EHdZ4=
X-Received: by 2002:aa7:c810:: with SMTP id a16mr8977397edt.338.1627242595729; 
 Sun, 25 Jul 2021 12:49:55 -0700 (PDT)
MIME-Version: 1.0
References: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
 <20210725053803.fnmd6etv3f7x3u3p@ganymede>
In-Reply-To: <20210725053803.fnmd6etv3f7x3u3p@ganymede>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sun, 25 Jul 2021 12:49:38 -0700
Message-ID: <CAGpPWDZ8EWd7kGV5pFZadQM1kqETrTK2zybsGF1hW9fx2oZb7w@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000e1c3ac05c7f7f06a"
X-Mailman-Approved-At: Sun, 25 Jul 2021 20:44:12 +0000
Subject: Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION
 (an alternative to OP_CTV)
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: Sun, 25 Jul 2021 19:49:59 -0000

--000000000000e1c3ac05c7f7f06a
Content-Type: text/plain; charset="UTF-8"

Thanks for taking a look at the proposal David. I appreciate it.

> I don't think we want full nodes to have to store the feerate for every
transaction in a 3,000 block window

That's a good point. It would probably be just as good to find the median
fee-rate for each block and store that, then calculate the average of those
stored per-block median numbers. Do you think that would be sufficiently
cheap to store?

> Miners can include many small high-fee pay-to-self transactions in their
blocks to raise the median feerate

Definitely a reasonable thing to consider. One point I want to make about
that tho is that the opcode only limits how much of a particular output can
be put towards the transaction fee - for the vast majority of transactions
using this opcode, a lower fee would be used and the limit would be
irrelevant (and therefore raising the median fee rate would not affect
those transactions). The point of limiting the fee is to limit an
attacker's ability to grief a victim by sending all their funds as
transaction fee. So the only situations where miners would gain something
from raising the fee rate is for griefing situations, which should be so
rare as to be completely insignificant to miners. If griefing is not rare,
something else is pretty broken.

> I think this fee mechanism is redundant

See above, but to break down that situation a bit further, these are the
two situations I can think of:

   1. The opcode limits user/group A to send the output to user/group B
   2. The opcode limits user A to send from one address they own to another
   address they own.

In case 1, user/group A could be the attacker that attempts to direct as
much of the outputs as possible towards the fee (instead of the agreed upon
recipient user/group B). In case 2, the attacker would be someone that
steals a key from the user (eg in the case the attacker gets access to 1
key of the wallet vault keys) and attempts to grief them by making a
transaction with the highest possible fee. In both these scenarios, the fee
limit helps limit the amount of damage these attackers could do to their
victim. Without a fee limit, these attack vectors could spend up to the
full output amount as fee, which could be very damaging.

> A mutual spend clause

Have you considered the use case of wallet vaults? I designed this opcode
primarily with wallet vaults in mind. In such a case there is a "mutual
spend clause" of a kind - but all the keys may be owned by a single
individual. One of the keys would be kept close at hand, and other keys
would be kept in more secure and more difficult-to-access places (like a
safe in a remote location). While the key-spend-path would be cheapest on
chain, traveling to get the key itself might often be more expensive than
using the script spend-path (because it takes time and effort to travel to
those locations and access the keys). It might be informative to take a
look at these wallet vault scripts
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/op_cdWalletVault1.md>
that
could use this opcode or the larger vision
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/README.md>
I have for wallet vaults (which involves 2 other new opcodes). There are
certainly also multi-user multisig use cases for OP_CD that have similar
properties to this single-user use case.

> A fee override that allows paying additional fees .. through attaching an
additional input or through CPFP

I definitely agree those are desirable mechanisms. To reiterate what I said
above, the fee limitation is there to limit griefing attack vectors that
spend an unreasonable amount of a particular output towards the fee.
Spending *other* outputs (via either of those mechanisms) towards a
transaction's fee is perfectly acceptable and doesn't undermine the purpose
of the fee limitation.

At its core, the limitation is there because the miner is another
destination that the output's funds can be sent to, and while it wouldn't
be wise to prevent an output from being spent as fee at all (because then
the output is unspendable on its own, or with any other similarly
constrained outputs), if OP_CD allowed spending the entire output as a fee
then it wouldn't be successful in constraining the destination to the
listed addresses.

Do you see my points here, or do you still think the limitation is
redundant?

Thanks,
BT




On Sat, Jul 24, 2021 at 10:39 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, Jul 20, 2021 at 10:56:10PM -0700, Billy Tetrud via bitcoin-dev
> wrote:
> > This involves [...] constraining the amount of the fee that output is
> > allowed to contribute to.  [...] fee is specified relative to recent
> > median fee rates - details in the proposal).
>
> Here are the relevant details:
>
> > The medianFeeRate is defined as the median fee rate per vbyte for the
> > most recent windowLength blocks. The maxFeeContribution is defined as
> > medianFeeRate * 2^feeFactor of the fee. Note that this is a limitation
> > on the fee, not on the fee-rate. If feeFactor is -1,
> > maxFeeContribution is 0.
>
> First, I don't think we want full nodes to have to store the feerate for
> every transaction in a 3,000 block window (~2.5 million txes, assuming
> all segwit).  I'm sure you could tweak this proposal to require a much
> smaller dataset.
>
> Second, I think this requires careful consideration of how it might
> affect the incentives for miners.  Miners can include many small high-fee
> pay-to-self transactions in their blocks to raise the median feerate,
> but this puts them at increased risk of fee sniping from other miners,
> which may incentivize fee-raisers to centralize their mining, which is
> ultimately bad.  I'm not sure that's a huge concern with this proposal,
> but I think it and other incentive problems require consideration.
>
> Finally, I think this fee mechanism is redundant.  For any case where
> this opcode will be used, you'll want to have two things:
>
>     1. A mutual spend clause (e.g. a multisignature taproot keypath
>        spend) where all parties agree on a spend of the output and so
>        can set an appropriate feerate at that time.  You want this
>        because it'll be the most efficient way to spend.
>
>     2. A fee override that allows paying additional fees beyond what
>        OP_CONSTRAINDESTINATION allows, either through attaching an
>        additional input or through CPFP.  You want this because you
>        will know more about feerate conditions at spend time than you
>        did when you created the receiving script.
>
> If you have the ability to choose feerates through the above mechanisms,
> you don't need a constrained feerate mechanism that might be
> manipulable by miners.
>
> (I haven't looked closely at the rest of your proposal; the above just
> caught my attention.)
>
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Thanks for taking a look at the proposal David. I apprecia=
te it.<div><br></div><div>&gt; I don&#39;t think we want full nodes to have=
 to store the feerate for every transaction in a 3,000 block window</div><d=
iv><br></div><div>That&#39;s a good point. It would probably be just as goo=
d to find the median fee-rate for each block and store that,=C2=A0then calc=
ulate the average of those stored per-block median numbers. Do you think th=
at would be sufficiently cheap to store?</div><div><br></div><div>&gt; Mine=
rs can include many small high-fee pay-to-self transactions in their blocks=
 to raise the median feerate</div><div><br></div><div>Definitely a reasonab=
le thing to consider. One point I want to make about that tho is that the o=
pcode only limits how much of a particular output can be put towards the tr=
ansaction fee - for the vast majority of transactions using this opcode, a =
lower fee would be used and the limit would be irrelevant (and therefore ra=
ising the median fee rate would not affect those transactions). The point o=
f limiting the=C2=A0fee is to limit an attacker&#39;s ability to grief a vi=
ctim by sending all their funds as transaction fee. So the only situations =
where miners would gain something from raising the fee rate is for griefing=
 situations, which should be so rare as to be completely insignificant to m=
iners. If griefing is not rare, something else is pretty broken.</div><div>=
<br></div><div>&gt; I think this fee mechanism is redundant</div><div><br><=
/div><div><div>See above, but to break down that situation a bit further, t=
hese are the two situations I can think of:</div><div><ol><li>The opcode li=
mits user/group A to send the output to user/group B</li><li>The opcode lim=
its user A to send from one address they own to another address they own.=
=C2=A0</li></ol></div><div>In case 1, user/group A could be the attacker th=
at attempts to direct as much of the outputs as possible towards the fee (i=
nstead of the agreed upon recipient user/group B). In case 2, the attacker =
would be someone that steals a key from the user (eg in the case the attack=
er gets access to 1 key of the wallet vault keys) and attempts to grief the=
m by=C2=A0making a transaction with the highest possible fee. In both these=
 scenarios, the fee limit helps limit the amount of damage these attackers =
could do to their victim. Without a fee limit, these attack vectors could s=
pend up to the full output amount as fee, which could be very damaging.=C2=
=A0</div></div><div><br></div><div>&gt; A mutual spend clause</div><div><br=
></div><div>Have you considered the use case of wallet vaults? I designed t=
his opcode primarily with wallet vaults in mind. In such a case there is a =
&quot;mutual spend clause&quot; of a kind - but all the keys may be owned b=
y a single individual. One of the keys would be kept close at hand, and oth=
er keys would be kept in more secure and more difficult-to-access places (l=
ike a safe in a remote location). While the key-spend-path would be cheapes=
t on chain, traveling to get the key itself might often be more expensive=
=C2=A0than using the script spend-path (because it takes time and effort to=
 travel to those locations and access the keys). It might be informative to=
 take a look at <a href=3D"https://github.com/fresheneesz/bip-efficient-bit=
coin-vaults/blob/main/cd/op_cdWalletVault1.md">these wallet vault scripts</=
a>=C2=A0that could use this opcode or the <a href=3D"https://github.com/fre=
sheneesz/bip-efficient-bitcoin-vaults/blob/main/README.md">larger vision</a=
> I have for wallet vaults (which involves 2 other new opcodes). There are =
certainly also multi-user multisig use cases for OP_CD that have similar pr=
operties to this single-user use case.</div><div><br></div><div>&gt; A fee =
override that allows paying additional fees .. through attaching an additio=
nal input or through CPFP</div><div><br><div>I definitely agree those are d=
esirable mechanisms. To reiterate what I said above, the fee limitation is =
there to limit griefing attack vectors that spend an unreasonable amount of=
 a particular output towards the fee. Spending *other* outputs (via either =
of those mechanisms) towards a transaction&#39;s fee is perfectly acceptabl=
e and doesn&#39;t undermine the purpose of the fee limitation.=C2=A0</div><=
div><br></div><div>At its core, the limitation is there because the miner i=
s another destination that the output&#39;s funds can be sent to, and while=
 it wouldn&#39;t be wise to prevent an output from being spent as fee at al=
l (because then the output is unspendable on its own, or with any other sim=
ilarly constrained outputs), if OP_CD allowed spending the entire output as=
 a fee then it wouldn&#39;t be successful in constraining the destination t=
o the listed addresses.=C2=A0</div><div><br></div><div>Do you see my points=
 here, or do you still think the limitation is redundant?<br></div><div><br=
></div><div>Thanks,</div><div>BT</div><div><br></div><div><br><div><br></di=
v></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Sat, Jul 24, 2021 at 10:39 PM David A. Harding via bitco=
in-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">On Tue, Jul 20, 2021 at 10:56:10PM -0700, Bil=
ly Tetrud via bitcoin-dev wrote:<br>
&gt; This involves [...] constraining the amount of the fee that output is<=
br>
&gt; allowed to contribute to.=C2=A0 [...] fee is specified relative to rec=
ent<br>
&gt; median fee rates - details in the proposal).<br>
<br>
Here are the relevant details:<br>
<br>
&gt; The medianFeeRate is defined as the median fee rate per vbyte for the<=
br>
&gt; most recent windowLength blocks. The maxFeeContribution is defined as<=
br>
&gt; medianFeeRate * 2^feeFactor of the fee. Note that this is a limitation=
<br>
&gt; on the fee, not on the fee-rate. If feeFactor is -1,<br>
&gt; maxFeeContribution is 0.<br>
<br>
First, I don&#39;t think we want full nodes to have to store the feerate fo=
r<br>
every transaction in a 3,000 block window (~2.5 million txes, assuming<br>
all segwit).=C2=A0 I&#39;m sure you could tweak this proposal to require a =
much<br>
smaller dataset.<br>
<br>
Second, I think this requires careful consideration of how it might<br>
affect the incentives for miners.=C2=A0 Miners can include many small high-=
fee<br>
pay-to-self transactions in their blocks to raise the median feerate,<br>
but this puts them at increased risk of fee sniping from other miners,<br>
which may incentivize fee-raisers to centralize their mining, which is<br>
ultimately bad.=C2=A0 I&#39;m not sure that&#39;s a huge concern with this =
proposal,<br>
but I think it and other incentive problems require consideration.<br>
<br>
Finally, I think this fee mechanism is redundant.=C2=A0 For any case where<=
br>
this opcode will be used, you&#39;ll want to have two things:<br>
<br>
=C2=A0 =C2=A0 1. A mutual spend clause (e.g. a multisignature taproot keypa=
th<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0spend) where all parties agree on a spend of the=
 output and so<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0can set an appropriate feerate at that time.=C2=
=A0 You want this<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0because it&#39;ll be the most efficient way to s=
pend.<br>
<br>
=C2=A0 =C2=A0 2. A fee override that allows paying additional fees beyond w=
hat<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0OP_CONSTRAINDESTINATION allows, either through a=
ttaching an<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0additional input or through CPFP.=C2=A0 You want=
 this because you<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0will know more about feerate conditions at spend=
 time than you<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0did when you created the receiving script.<br>
<br>
If you have the ability to choose feerates through the above mechanisms,<br=
>
you don&#39;t need a constrained feerate mechanism that might be<br>
manipulable by miners.<br>
<br>
(I haven&#39;t looked closely at the rest of your proposal; the above just<=
br>
caught my attention.)<br>
<br>
-Dave<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000e1c3ac05c7f7f06a--