From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7E01DC000E for ; 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 ; 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 ; 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 ; Sun, 25 Jul 2021 19:49:57 +0000 (UTC) Received: by mail-ed1-x533.google.com with SMTP id l6so5785898edc.5 for ; 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: <20210725053803.fnmd6etv3f7x3u3p@ganymede> In-Reply-To: <20210725053803.fnmd6etv3f7x3u3p@ganymede> From: Billy Tetrud Date: Sun, 25 Jul 2021 12:49:38 -0700 Message-ID: To: "David A. Harding" , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 that could use this opcode or the larger vision 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
Thanks for taking a look at the proposal David. I apprecia= te 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 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?

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

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'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.
=
> I think this fee mechanism is redundant

<= /div>
See above, but to break down that situation a bit further, t= hese are the two situations I can think of:
  1. The opcode li= mits user/group A to send the output to user/group B
  2. The opcode lim= its user A to send from one address they own to another address they own.= =C2=A0
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

> A mutual spend clause
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 = "mutual spend clause" 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 these wallet vault scripts=C2=A0that could use this opcode or the larger vision 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.






On Sat, Jul 24, 2021 at 10:39 PM David A. Harding via bitco= in-dev <bitcoin= -dev@lists.linuxfoundation.org> wrote:
On Tue, Jul 20, 2021 at 10:56:10PM -0700, Bil= ly Tetrud via bitcoin-dev wrote:
> This involves [...] constraining the amount of the fee that output is<= br> > allowed to contribute to.=C2=A0 [...] fee is specified relative to rec= ent
> 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<= br> > most recent windowLength blocks. The maxFeeContribution is defined as<= br> > 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 fo= r
every transaction in a 3,000 block window (~2.5 million txes, assuming
all segwit).=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 For any case where<= br> this opcode will be used, you'll want to have two things:

=C2=A0 =C2=A0 1. A mutual spend clause (e.g. a multisignature taproot keypa= th
=C2=A0 =C2=A0 =C2=A0 =C2=A0spend) where all parties agree on a spend of the= output and so
=C2=A0 =C2=A0 =C2=A0 =C2=A0can set an appropriate feerate at that time.=C2= =A0 You want this
=C2=A0 =C2=A0 =C2=A0 =C2=A0because it'll be the most efficient way to s= pend.

=C2=A0 =C2=A0 2. A fee override that allows paying additional fees beyond w= hat
=C2=A0 =C2=A0 =C2=A0 =C2=A0OP_CONSTRAINDESTINATION allows, either through a= ttaching an
=C2=A0 =C2=A0 =C2=A0 =C2=A0additional input or through CPFP.=C2=A0 You want= this because you
=C2=A0 =C2=A0 =C2=A0 =C2=A0will know more about feerate conditions at spend= time than you
=C2=A0 =C2=A0 =C2=A0 =C2=A0did 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<= br> caught my attention.)

-Dave
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000e1c3ac05c7f7f06a--