From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 28E0EC000E for ; Mon, 26 Jul 2021 20:18:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 040DE4045B for ; Mon, 26 Jul 2021 20:18:56 +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 MwzHBEzSzM6O for ; Mon, 26 Jul 2021 20:18:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by smtp4.osuosl.org (Postfix) with ESMTPS id 3C67D40449 for ; Mon, 26 Jul 2021 20:18:54 +0000 (UTC) Received: by mail-ej1-x631.google.com with SMTP id e19so18308443ejs.9 for ; Mon, 26 Jul 2021 13:18:54 -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 :cc; bh=PxCNPUE/UzLk1j5qU0tQRcVSCqDxFym2b8BM0A0Z+6M=; b=dL+13eLVQ4Oa4gtctSreMy4Di68fzpFsOKusCk85XyhtbRHen0DySqpPG+4/cmZ43D 3yocAKXsLELtSfy4I3F6HiIqTNkLwRe28YAwonQ623+UnNbgYupC91zJLENKQIVko569 VDbV3z99UE2YQ5uJokvwSl64kryCR+/s7yis1vPjJBIsDFY2yUJGgripFpAXya5YImmR NMXPzNESgn8bueEBFlI5gWwAWlGqobi7OYf3LKbuuGWK53zxyWdbPFkknY6E1hphMEpa 8RzftqC9nAaxvGqHmyVC90LJv7efDo/rdHZzeWrUi0Ok8bAX/Wp9CcXQSxRCU2D5pxuN Psrw== 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:cc; bh=PxCNPUE/UzLk1j5qU0tQRcVSCqDxFym2b8BM0A0Z+6M=; b=fCp9qIPOMgIiutpDPR2YdeniB5ZQGoTVi9AVPX0gbAN9ytMsY28Uz0u5P68h7FN5Kq ASZIiVLLLyusgNRwi2R3FT42kqPWLieZszHgRiprE9lVyIhuyMU7zgD73RtQXFiMCKVr kCLaIfExnGmxh8E6hVIwIN7P7NEjDdlvvMOTrrK3k5yWEb1vGbOvytRyAKXRSbtfW9Sc 4IUBDkqMUyD+/gIwH1FuQp/e8vwwiQxAPWuYBs3VQ0f9TLrhW0q5/9fF1ild42LKaBJL 2fH1bTsouRiW09XipQZh1wZG82QY+/hngmOGVv6a3znvjmCfAUB+svbK1kd30Gdrh09F MnVQ== X-Gm-Message-State: AOAM531dDCmBSC9df+qV6YxKEJY48YiwOmnb7O0teL2AYerCN3fQm15r QEa3TOU9URDXlsRe1bAwKx1A/uSzw0Y15KwGraQ= X-Google-Smtp-Source: ABdhPJyobTD4gOHMuV7w8P8c5nzOYWFUn/ArIn1VtvaDE00LaQ+BKu63JiKw1+8yiZzZoWucK4qr0NF4MlHGZVMz1nA= X-Received: by 2002:a17:906:4d94:: with SMTP id s20mr7614751eju.152.1627330732365; Mon, 26 Jul 2021 13:18:52 -0700 (PDT) MIME-Version: 1.0 References: <20210725053803.fnmd6etv3f7x3u3p@ganymede> <20210726000553.tetqypkqj34lcztt@ganymede> In-Reply-To: From: Billy Tetrud Date: Mon, 26 Jul 2021 13:18:35 -0700 Message-ID: To: Randy Fox Content-Type: multipart/alternative; boundary="0000000000003c1c3a05c80c769d" X-Mailman-Approved-At: Mon, 26 Jul 2021 20:31:08 +0000 Cc: Bitcoin Protocol Discussion 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: Mon, 26 Jul 2021 20:18:56 -0000 --0000000000003c1c3a05c80c769d Content-Type: text/plain; charset="UTF-8" > it's important to remember that every miner is also a user of Bitcoin and ever user of Bitcoin may also someday be a miner That's certainly true. One good quantification for how much of a problem this could be is to calculate the cost of the attack vs the damage done in the attack. So let me try to estimate that: Miners could collectively shift the fee rate up by sending payments to themselves, like you said. However, each one represents an opportunity cost of a low-value transaction. Given a bell curve distribution of transaction fee-rates, filling 15% of each block with these self-pay transactions could raise the median fee rate by about 1/4 of a standard deviation, or something probably around a 5% increase in median fee rate. This would lose miners approximately 5% of the fees for the blocks they did this for. So in order to do 1-to-1 damage (which would have them break even on the attack), there would have to be enough of these transactions to fill up maybe 1% of 3000 blocks (if we assume these transactions will generally have 10 times the fee-rate of the displaced low-value transactions). That would be on the order of hundreds of thousands of transactions. A shorter sample window would be easier to abuse this way, but even still likely at least hundreds of transactions would be needed to make up the difference. Manipulating fees this way has diminishing returns, meaning that filling a smaller percent of a block with high-fee self-payment transactions would lead to a greater increase in the median fee rate per amount of fees lost. Something interesting about this attack is that a successful attack would make the next attack easier, because mining these transactions from stolen keys would also help raise the median fee-rate a bit (tho only a fraction of the self-pay transactions that would still be necessary for the next round of attacks). And the above is a situation with 100% dishonest miners. With fewer dishonest miners, say 25%, the attack would have a much lower ROI. For the wallet vault use case, this is still a security improvement over a normal wallet, since in a normal wallet, a stolen key means all your funds can be stolen, but in an OP_CD wallet vault the attackers are still limited in how much can be stolen via the fee, stealing via the fee requires paying miners a cut to receive back some of the fee, and stealing extra (via raising the median fee rate) has a real cost placed on the miners. For multi-party scenarios, I think the fee limit might be slightly less effective. Eg in contracts where some money is promised to be sent to another person's address (e.g. congestion controlled payments), if a miner controls the sending address that miner can simply send the maximum fee to gain more money directly. The limit is still partially effective, but its definitely worth noting that malicious miners can abuse the fee limit mechanism. I would think manipulating the median fee rate is just as difficult in this scenario tho. > pay-to-self transactions .. puts them at increased risk of fee sniping from other miners, which may incentivize fee-raisers to centralize their mining This is an interesting point I forgot to respond to from your first email. I think even without the threat of fee-sniping, fee raisers would want to cartelize because coordinating the timing of attacks would reduce their collective costs. Tho fee-sniping would increase this pressure, I agree. It seems like cartels like this would have to get near the range of being able to 51% attack to really be effective tho. > The alternative is to never allow OP_CD to spend any of the UTXOs it encumbers to fees I agree that functionally this would work ok. However, both other mechanisms (gathering keys for a multisig spend or CPFP / adding other inputs) are likely to often be more expensive than letting the UTXO contribute to the fee directly. Also, it would complicate usability of these outputs, sometimes even making them unspendable by the user directly (in the case they don't have access to external outputs to contribute to the fee). In any case, I've updated my proposal with some of the things we've discussed. Thanks! @Randy What are you agreeing with? On Mon, Jul 26, 2021 at 5:59 AM Randy Fox wrote: > Agree. > > > Sent from Yahoo Mail for iPhone > > > On Sunday, July 25, 2021, 7:07 PM, David A. Harding via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Sun, Jul 25, 2021 at 12:49:38PM -0700, Billy Tetrud wrote: > > find the median fee-rate for each block and store that, then calculate > > the average of those stored per-block median numbers. > > One datapoint per block seems fine to me and it works much nicer with > pruned nodes. > > > 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. > > I don't believe the problem scope can be reduced this way. Although we > we often look at miners as separate from users, it's important to > remember that every miner is also a user of Bitcoin and ever user of > Bitcoin may also someday be a miner. Users may also employ miners > directly via out-of-band payments. > > In your usecase of vaults, we can imagine Bob is attempting to store > 100,000 BTC. He designs his vault to allow spending on fees up to 10x > the 3,000 block median fee. Mallory steals Bob's encumbered spending > key. Mallory could immediately go to a miner and offer them a 50/50 > split on the 10x fees over the median (~10,000 sat?), or Mallory could > take a bit more time and work with a cartel of miners to raise the > median over a period of three weeks (3k blocks) to 10,000 > BTC/transaction, allowing them to take all of Bob's coins in fees. > > > 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. > > The alternative is to never allow OP_CD to spend any of the UTXOs it > encumbers to fees, requiring all fees be paid via another mechanism. > Since satisfactory designs are going to provide those other mechanisms > anyway, it seems to me that there's no need for OP_CD to manage fees. > That said, I don't have a real strong opinion here. > > > -Dave > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --0000000000003c1c3a05c80c769d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0 it's important to remember that every miner is also a user of Bitcoin a= nd ever user of Bitcoin may also someday be a miner

That= 's certainly true. One good quantification for how much of a problem th= is could be is to calculate the cost of the attack vs the damage done in th= e attack. So let me try to estimate that:

Miners c= ould collectively shift the fee rate up by sending payments to themselves, = like you said. However, each one represents=C2=A0an opportunity=C2=A0cost o= f a low-value transaction. Given a bell curve distribution of transaction f= ee-rates, filling 15% of each block with these self-pay transactions could = raise the median fee rate by about 1/4 of a standard deviation,=C2=A0or som= ething probably around a 5% increase in median fee rate. This would lose mi= ners approximately 5% of the fees for the blocks they did this for. So in o= rder to do 1-to-1 damage (which would have them break even on the attack), = there would have to be enough of these transactions to fill up maybe 1% of = 3000 blocks (if we assume these transactions will generally have 10 times t= he fee-rate of the displaced low-value transactions). That would be on the = order of hundreds of thousands of transactions. A shorter sample window=C2= =A0would be easier to abuse this way, but even still likely at least hundre= ds of transactions would be needed to make up the difference.=C2=A0

Manipulating fees this way has diminishing returns, meani= ng that filling a smaller percent of a block with high-fee self-payment tra= nsactions would lead to a greater increase in the median fee rate per amoun= t of fees lost.

Something interesting about th= is attack is that a successful attack would make the next attack easier, be= cause mining these transactions from stolen keys would also help raise the = median fee-rate a bit (tho only a fraction of the self-pay transactions tha= t would still be necessary for the next round of attacks).=C2=A0
=
And the above is a situation with 100% dishonest miners. Wit= h fewer dishonest miners, say 25%, the attack would have a much lower ROI.= =C2=A0

For the wallet vault use case, this is stil= l a security improvement over a normal wallet, since in a normal wallet, a = stolen key means all your funds can be stolen, but in an OP_CD wallet vault= the attackers are still limited in how much can be stolen via the fee, ste= aling via the fee requires paying miners a cut to receive back some of the = fee, and stealing extra=C2=A0 (via raising the median fee rate) has a real = cost placed on the miners.

For multi-party scenari= os, I think the=C2=A0fee limit might be slightly less effective. Eg in cont= racts where some money is promised to be sent to another person's addre= ss (e.g. congestion controlled payments), if a miner controls the sending a= ddress that miner can simply send the maximum fee to gain more money direct= ly. The limit is still partially effective, but its definitely worth noting= that malicious miners can abuse the fee limit mechanism. I would think man= ipulating the median fee rate is just as difficult in this scenario tho.

> pay-to-self transactions .. puts them at i= ncreased risk of fee sniping from other miners, which may incentivize fee-r= aisers to centralize their mining

This is an inter= esting point I forgot to respond to from your first email. I think even wit= hout the threat of fee-sniping, fee raisers would want to cartelize because= coordinating the timing of attacks would reduce their collective costs. Th= o fee-sniping would increase this pressure, I agree. It seems like cartels = like this would have to get near the range of being able to 51% attack to r= eally be effective tho.=C2=A0

> The alter= native is to never allow OP_CD to spend any of the UTXOs it encumbers to fe= es

I agree that functionally this would work o= k. However, both other mechanisms (gathering keys for a multisig spend or C= PFP / adding other inputs) are likely to often be more expensive than letti= ng the UTXO contribute to the=C2=A0fee directly. Also, it would complicate = usability of these outputs, sometimes even making them unspendable by the u= ser directly (in the case they don't have access to external outputs to= contribute to the fee).=C2=A0

In any case, I&= #39;ve updated my proposal with some of the things we've discussed. Tha= nks!

@Randy What are you agreeing=C2=A0with?

On Mon, Jul 26, 2021 at 5:59 AM Randy Fox <mrkingfoxx@hotmail.com> wrote:
Agree.


Sent from Yahoo Mail for iPhone

On Sunda= y, July 25, 2021, 7:07 PM, David A. Harding via bitcoin-dev <bitcoin-dev= @lists.linuxfoundation.org> wrote:

On Sun, Jul 25, 20= 21 at 12:49:38PM -0700, Billy Tetrud wrote:
> find the= median fee-rate for each block and store that, then calculate
> the average of those stored per-block median numbers.

One datapoint per block seems fine to me and i= t works much nicer with
pruned nodes.
<= br clear=3D"none">> So the only situations where miners would gain somet= hing
> from raising the fee rate is for griefing situa= tions, which should be so
> rare as to be completely i= nsignificant to miners.

I don't b= elieve the problem scope can be reduced this way.=C2=A0 Although we
we often look at miners as separate from users, it's importa= nt to
remember that every miner is also a user of Bitcoin= and ever user of
Bitcoin may also someday be a miner.=C2= =A0 Users may also employ miners
directly via out-of-band= payments.

In your usecase of vaults, = we can imagine Bob is attempting to store
100,000 BTC.=C2= =A0 He designs his vault to allow spending on fees up to 10x
the 3,000 block median fee.=C2=A0 Mallory steals Bob's encumbered s= pending
key.=C2=A0 Mallory could immediately go to a mine= r and offer them a 50/50
split on the 10x fees over the m= edian (~10,000 sat?), or Mallory could
take a bit more ti= me and work with a cartel of miners to raise the
median o= ver a period of three weeks (3k blocks) to 10,000
BTC/tra= nsaction, allowing them to take all of Bob's coins in fees.

> if OP_CD allowed spending the entire output = as a fee then it wouldn't
> be successful in const= raining the destination to the listed addresses.

The alternative is to never allow OP_CD to spend any of the UTXO= s it
encumbers to fees, requiring all fees be paid via an= other mechanism.
Since satisfactory designs are going to = provide those other mechanisms
anyway, it seems to me tha= t there's no need for OP_CD to manage fees.
That said= , I don't have a real strong opinion here.


-Dave
_________= ______________________________________
bitcoin-dev mailin= g list
bitcoin-dev@lists.linuxfoundation.o= rg
https://lists.lin= uxfoundation.org/mailman/listinfo/bitcoin-dev
<= blockquote>
--0000000000003c1c3a05c80c769d--