path: root/be/e2d8142d375ea74cf4d8dafde0de1411e04260

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 28E0EC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 26 Jul 2021 20:18:54 +0000 (UTC)
Received: by mail-ej1-x631.google.com with SMTP id e19so18308443ejs.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
 <20210725053803.fnmd6etv3f7x3u3p@ganymede>
 <CAGpPWDZ8EWd7kGV5pFZadQM1kqETrTK2zybsGF1hW9fx2oZb7w@mail.gmail.com>
 <20210726000553.tetqypkqj34lcztt@ganymede>
 <SN7PR18MB3981DC1CD23B90367045995FD2E89@SN7PR18MB3981.namprd18.prod.outlook.com>
In-Reply-To: <SN7PR18MB3981DC1CD23B90367045995FD2E89@SN7PR18MB3981.namprd18.prod.outlook.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Mon, 26 Jul 2021 13:18:35 -0700
Message-ID: <CAGpPWDbW8y+ZMBqog72A0H9C3azZ+9sjnRZBvnCKG3NtaHSpxA@mail.gmail.com>
To: Randy Fox <mrkingfoxx@hotmail.com>
Content-Type: multipart/alternative; boundary="0000000000003c1c3a05c80c769d"
X-Mailman-Approved-At: Mon, 26 Jul 2021 20:31:08 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: 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 <mrkingfoxx@hotmail.com> wrote:

> Agree.
>
>
> Sent from Yahoo Mail for iPhone
> <https://overview.mail.yahoo.com/?.src=iOS>
>
> 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

<div dir=3D"ltr">&gt;=C2=A0

it&#39;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<div><br></div><div>That=
&#39;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:</div><div><br></div><div>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</div><d=
iv><br></div><div>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.<br></div><div><br></div><div>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</div><div>=
<br></div><div>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</div><div><br></div><div>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.</div><div><br></div><div>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&#39;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.</d=
iv><div><br></div><div><div>&gt; 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</div><div><br></div><div>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</div></div><div><br></div><div>&gt; The alter=
native is to never allow OP_CD to spend any of the UTXOs it encumbers to fe=
es<br></div><div><br></div><div>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&#39;t have access to external outputs to=
 contribute to the fee).=C2=A0<br></div><div><br></div><div>In any case, I&=
#39;ve updated my proposal with some of the things we&#39;ve discussed. Tha=
nks!</div><div><br></div><div>@Randy What are you agreeing=C2=A0with?<br></=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Mon, Jul 26, 2021 at 5:59 AM Randy Fox &lt;<a href=3D"mailto:mrkingf=
oxx@hotmail.com">mrkingfoxx@hotmail.com</a>&gt; wrote:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">
<div>
Agree.<br><br><br><a href=3D"https://overview.mail.yahoo.com/?.src=3DiOS" t=
arget=3D"_blank">Sent from Yahoo Mail for iPhone</a><br><br><p style=3D"fon=
t-size:15px;color:rgb(113,95,250);padding-top:15px;margin-top:0px">On Sunda=
y, July 25, 2021, 7:07 PM, David A. Harding via bitcoin-dev &lt;<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.linuxfoundation.org</a>&gt; wrote:</p><blockquote>On Sun, Jul 25, 20=
21 at 12:49:38PM -0700, Billy Tetrud wrote:<br clear=3D"none">&gt; find the=
 median fee-rate for each block and store that, then calculate<br clear=3D"=
none">&gt; the average of those stored per-block median numbers. <br clear=
=3D"none"><br clear=3D"none">One datapoint per block seems fine to me and i=
t works much nicer with<br clear=3D"none">pruned nodes.<br clear=3D"none"><=
br clear=3D"none">&gt; So the only situations where miners would gain somet=
hing<br clear=3D"none">&gt; from raising the fee rate is for griefing situa=
tions, which should be so<br clear=3D"none">&gt; rare as to be completely i=
nsignificant to miners. <br clear=3D"none"><br clear=3D"none">I don&#39;t b=
elieve the problem scope can be reduced this way.=C2=A0 Although we<br clea=
r=3D"none">we often look at miners as separate from users, it&#39;s importa=
nt to<br clear=3D"none">remember that every miner is also a user of Bitcoin=
 and ever user of<br clear=3D"none">Bitcoin may also someday be a miner.=C2=
=A0 Users may also employ miners<br clear=3D"none">directly via out-of-band=
 payments.<br clear=3D"none"><br clear=3D"none">In your usecase of vaults, =
we can imagine Bob is attempting to store<br clear=3D"none">100,000 BTC.=C2=
=A0 He designs his vault to allow spending on fees up to 10x<br clear=3D"no=
ne">the 3,000 block median fee.=C2=A0 Mallory steals Bob&#39;s encumbered s=
pending<br clear=3D"none">key.=C2=A0 Mallory could immediately go to a mine=
r and offer them a 50/50<br clear=3D"none">split on the 10x fees over the m=
edian (~10,000 sat?), or Mallory could<br clear=3D"none">take a bit more ti=
me and work with a cartel of miners to raise the<br clear=3D"none">median o=
ver a period of three weeks (3k blocks) to 10,000<br clear=3D"none">BTC/tra=
nsaction, allowing them to take all of Bob&#39;s coins in fees.<br clear=3D=
"none"><br clear=3D"none">&gt; if OP_CD allowed spending the entire output =
as a fee then it wouldn&#39;t<br clear=3D"none">&gt; be successful in const=
raining the destination to the listed addresses.<br clear=3D"none"><br clea=
r=3D"none">The alternative is to never allow OP_CD to spend any of the UTXO=
s it<br clear=3D"none">encumbers to fees, requiring all fees be paid via an=
other mechanism.<br clear=3D"none">Since satisfactory designs are going to =
provide those other mechanisms<br clear=3D"none">anyway, it seems to me tha=
t there&#39;s no need for OP_CD to manage fees.<br clear=3D"none">That said=
, I don&#39;t have a real strong opinion here.<div id=3D"gmail-m_-437161199=
535481575yqtfd45875"><br clear=3D"none"><br clear=3D"none">-Dave<br clear=
=3D"none"></div><div id=3D"gmail-m_-437161199535481575yqtfd52243">_________=
______________________________________<br clear=3D"none">bitcoin-dev mailin=
g list<br clear=3D"none"><a shape=3D"rect" href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.o=
rg</a><br clear=3D"none"><a shape=3D"rect" href=3D"https://lists.linuxfound=
ation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev</a><br clear=3D"none"></div><=
blockquote></blockquote></blockquote>
</div></blockquote></div>

--0000000000003c1c3a05c80c769d--