diff options
| author | Erik Aronesty <erik@q32.com> | 2022-07-11 14:43:27 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-07-11 18:43:46 +0000 |
| commit | 73aba26c3cf0b9fcc215133b42a9a226eea8c4a6 (patch) | |
| tree | 67bbae40ea605067575b5512435a6b9b46638764 | |
| parent | 15b0fe097768024c38c122cc7e85a9f3aa2cfb0d (diff) | |
| download | pi-bitcoindev-73aba26c3cf0b9fcc215133b42a9a226eea8c4a6.tar.gz pi-bitcoindev-73aba26c3cf0b9fcc215133b42a9a226eea8c4a6.zip | |
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
| -rw-r--r-- | 72/1475311864e9fdb8f6dfe4c235c27304d06e6a | 287 |
1 files changed, 287 insertions, 0 deletions
diff --git a/72/1475311864e9fdb8f6dfe4c235c27304d06e6a b/72/1475311864e9fdb8f6dfe4c235c27304d06e6a new file mode 100644 index 000000000..b106d494a --- /dev/null +++ b/72/1475311864e9fdb8f6dfe4c235c27304d06e6a @@ -0,0 +1,287 @@ +Return-Path: <earonesty@gmail.com> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id E0303C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 11 Jul 2022 18:43:46 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id AAEBC60D73 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 11 Jul 2022 18:43:45 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org AAEBC60D73 +Authentication-Results: smtp3.osuosl.org; + dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com + header.i=@q32-com.20210112.gappssmtp.com header.a=rsa-sha256 + header.s=20210112 header.b=dsM7LtE0 +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: 0.001 +X-Spam-Level: +X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 + tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, + HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, + RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] + autolearn=no autolearn_force=no +Received: from smtp3.osuosl.org ([127.0.0.1]) + by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id uQmmN_vT2XZG + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 11 Jul 2022 18:43:41 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 381AB60F12 +Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com + [IPv6:2a00:1450:4864:20::12e]) + by smtp3.osuosl.org (Postfix) with ESMTPS id 381AB60F12 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 11 Jul 2022 18:43:41 +0000 (UTC) +Received: by mail-lf1-x12e.google.com with SMTP id n18so8458107lfq.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 11 Jul 2022 11:43:41 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=q32-com.20210112.gappssmtp.com; s=20210112; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to; + bh=4+HkiOIzPkgOzXV+aZmiivmnuv3XFlAjzTN8//+3It8=; + b=dsM7LtE0lRBWoCUbDI8iDgckiEPq9P9/y3OnZWUqLPTxXqeadGPNwbVecEbx/64kxV + dfSOPveVu4zRjvUC76wh+gp2Zz8cWRKcwNzf8jkKx6yldsz9cMhvWeoNTD7C6mb5Py5t + MzDw6bVF1P4p8j8HfQ4ZbHJM6RqDZy0t9QH4Or5wJNAK/PNN87qrtha9e9uhVanjxk17 + yEEMB0Rn/JvWiwsehxLmsrvMPWQEmMfTfLNNzNhiu70lTNnBYICihr5l4SuCPbkQgFQl + pF+ljVvapgW3vqZ0aN9pzuGs5qNk0PTBFwhCocMCrUo/e9LVAQP1ao2L8YgidccdHcGg + mrDg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to; + bh=4+HkiOIzPkgOzXV+aZmiivmnuv3XFlAjzTN8//+3It8=; + b=xNOMiuJy3GFtNmulxS0D33B/fZU87QGxmhZE7u9PmdtAY7Bd2PGwBERXugqfzY9UFn + YxhVbVq2Hn0SqVZv9nS3tldgCfW8QRrMlNM51WRt4T7NNl86cDLCiROAAJ9ujOcI3ity + lcAJF9Q7MmnTW5bkNunnHpvvU1OngnzyFjR+H0uBX3Z6TYlgzxbAPzoswcC8DPL0Z50T + Qm/tXe7q74mRlAlAKQjXdA8V5dRBoeO9J2s3/s8Lrl+9ekfvvKGlTkNAGAFzsKLd6D8v + JbVGjXs7Wv+I6+xNhkaI7hw8kzoiIoievL4SCjjlwm8CJX73zWf9kKGOrXPJUIFf11II + DETg== +X-Gm-Message-State: AJIora8omovPuT1UXC8DWRm1pp93Fx2u/s2xi/SG9VbiWP7a1ej35orH + eNO0VR/h6mx4tHg1k7Xvj8XUeV3zD8rP5eU7HM+h1l+LR5ReuqE= +X-Google-Smtp-Source: AGRyM1svaMldsMHYVxyqVIJVnwkEEkQjNyN3/aIX41Lg0P3mMGSfW/1+V2ZdO/RIhApIvmem4Td8qWS8bQHdj3wiZjA= +X-Received: by 2002:a05:6512:308b:b0:489:32f8:426c with SMTP id + z11-20020a056512308b00b0048932f8426cmr13216968lfd.270.1657565018944; Mon, 11 + Jul 2022 11:43:38 -0700 (PDT) +MIME-Version: 1.0 +References: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com> +In-Reply-To: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com> +From: Erik Aronesty <erik@q32.com> +Date: Mon, 11 Jul 2022 14:43:27 -0400 +Message-ID: <CAJowKgLXU8fFduDu5=ZQt7j585weHN5Bj_Rqs3jnPbghzV474Q@mail.gmail.com> +To: Bram Cohen <bram@chia.net>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="0000000000002578d105e38beeed" +X-Mailman-Approved-At: Mon, 11 Jul 2022 23:05:26 +0000 +Subject: Re: [bitcoin-dev] Security problems with relying on transaction + fees for security +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, 11 Jul 2022 18:43:47 -0000 + +--0000000000002578d105e38beeed +Content-Type: text/plain; charset="UTF-8" + +> If in the future Bitcoin is entirely dependent on fees for security +(scheduled very strongly) and this pattern keeps up (overwhelmingly likely) +then this is going to become a serious problem. + +We should carefully define "when" this becomes an issue. + +Suppose the reward is 1.5625 BTC. That's not very far away. Assume you +need a 12-month investment in hardware. One-year * 100% mining capacity +at that time is thus incentivised with 82125 bitcoin in losses against a +double spend. If the price remains the same as it is now, that's 1.6 +billion. Is that a sufficient security budget? + +As the rewards drop, the security of Bitcoin increasingly relies on "price +increases" and "fee pressure". Obviously "price increases" isn't something +anyone should rely on. Therefore the correct thing to address is "fee +pressure". + +> There are a few possible approaches to fixes. One would be to drag most +of east asia eastward to a later time zone thus smoothing out the day/night +cycle but that's probably unrealistic. Another would be to hard fork in +fixed rewards in perpetuity... + +There is abundant evidence that modifying on-chain utility alters fees. +There is little doubt that the lightning network has cut into the security +budget. Future privacy protocols, such as mweb, will cut in even further. + +Therefore another solution would be to simply *increase on-chain utility*, +driving up fees in response to the growth of layered transactions. + +Proposals like "payment codes" and protocols like "omni" and "omnibolt" all +use on-chain resources without needing a soft fork. Other proposals, like +covenants, may increase fee pressure more. And, of course, promoting the +use of Bitcoin & Lightning in transactions - not just "holding", helps +promote fee growth and helps maintain the security budget. + +Even if it's less fixed and predictable than tail-emissions, this approach +seems to make much more sense. + + +On Mon, Jul 11, 2022 at 2:19 PM Bram Cohen via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> If transaction fees came in at an even rate over time all at the exact +> same level then they work fine for security, acting similarly to fixed +> block rewards. Unfortunately that isn't how it works in the real world. +> There's a very well established day/night cycle with fees going to zero +> overnight and even longer gaps on weekends and holidays. If in the future +> Bitcoin is entirely dependent on fees for security (scheduled very +> strongly) and this pattern keeps up (overwhelmingly likely) then this is +> going to become a serious problem. +> +> What's likely to happen is that at first there will simply be no or very +> few blocks mined overnight. There are likely to be some, as miners at first +> turn off their mining rigs completely overnight then adopt the more +> sophisticated strategy of waiting until there are enough fees in the +> mempool to warrant attempting to make a block and only then doing it. +> Unfortunately the gaming doesn't end there. Eventually the miners with +> lower costs of operation will figure out that they can collectively reorg +> the last hour (or some time period) of the day overnight and this will be +> profitable. That's likely to cause the miners with more expensive +> operations to stop attempting mining the last hour of the day preemptively. +> +> What happens after that I'm not sure. There are a small enough number of +> miners with a quirky enough distribution of costs of operation and +> profitability that the dynamic is heavily dependent on those specifics, but +> the beginnings of a slippery slope to a mining cabal which reorgs everyone +> else out of existence and eventually 51% attacks the whole thing have +> begun. It even gets worse than that because once there's a cabal +> aggressively reorging anyone else out when they make a block other miners +> will shut down and rapidly lose the ability to quickly spin up again, so +> the threshold needed for that 51% attack will keep going down. +> +> In short, relying completely on transaction fees for security is likely to +> be a disaster. What we can say from existing experience is that having +> transaction fees be about 10% of rewards on average works well. It's enough +> to incentivize collecting fees but not so much that it makes incentives get +> all weird. 90% transaction fees is probably very bad. 50% works but runs +> the risk of spikes getting too high. +> +> There are a few possible approaches to fixes. One would be to drag most of +> east asia eastward to a later time zone thus smoothing out the day/night +> cycle but that's probably unrealistic. Another would be to hard fork in +> fixed rewards in perpetuity, which is slightly less unrealistic but still +> extremely problematic. +> +> Much more actionable are measures which smooth out fees over time. Having +> wallets opportunistically collect their dust during times of low +> transaction fees would help and would save users on fees. Also making UX +> which clarifies when things are likely to take a day or week but that it's +> reliable would be a reasonable thing to do, but users unfortunately are +> very averse to transactions taking a while. +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--0000000000002578d105e38beeed +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">> If in the future Bitcoin is entirely dependent on fee= +s for security (scheduled very strongly) and this pattern keeps up (overwhe= +lmingly likely) then this is going to become a serious problem.<div><br>We = +should carefully define "when" this becomes an issue.=C2=A0 =C2= +=A0=C2=A0<br><br>Suppose the reward is=C2=A01.5625 BTC.=C2=A0 =C2=A0That= +9;s not very far away.=C2=A0 =C2=A0Assume you need a 12-month investment in= + hardware.=C2=A0 =C2=A0One-year * 100% mining capacity at that time is thus= + incentivised with 82125 bitcoin in losses against a double spend.=C2=A0 = +=C2=A0If the price remains the same as it is now, that's 1.6 billion.= +=C2=A0 Is that a sufficient security budget?<br><br>As the rewards drop, th= +e security of Bitcoin increasingly relies on "price increases" an= +d "fee pressure".=C2=A0 Obviously "price increases" isn= +'t something anyone should rely on.=C2=A0 =C2=A0Therefore the correct t= +hing to address is "fee pressure".</div><div><br><div>> There = +are a few possible approaches to fixes. One would be to drag most of east a= +sia eastward to a later time zone thus smoothing out the day/night cycle bu= +t that's probably unrealistic. Another would be to hard fork in fixed r= +ewards in perpetuity...</div><div><br> + +There is abundant=C2=A0evidence that modifying on-chain utility alters fees= +.=C2=A0 There is little doubt that the lightning network has cut into the s= +ecurity budget.=C2=A0 Future privacy protocols, such as mweb, will cut in e= +ven further.=C2=A0 <br><br>Therefore another solution would be to simply *i= +ncrease on-chain utility*, driving up fees in response to the growth of lay= +ered transactions.=C2=A0 =C2=A0<br><br>Proposals like "payment codes&q= +uot; and protocols like "omni" and "omnibolt" all use o= +n-chain resources without needing a soft fork.=C2=A0 =C2=A0Other proposals,= + like covenants, may increase fee pressure more.=C2=A0 =C2=A0And, of course= +, promoting the use of Bitcoin & Lightning in transactions - not just &= +quot;holding", helps promote fee growth and helps maintain the securit= +y budget.<br></div><div><br>Even if it's less fixed and=C2=A0predictabl= +e than tail-emissions, this approach seems to make much more sense.<br></di= +v></div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr= +" class=3D"gmail_attr">On Mon, Jul 11, 2022 at 2:19 PM Bram Cohen via bitco= +in-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin= +-dev@lists.linuxfoundation.org</a>> 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"><div dir=3D"ltr">If transaction fees came in = +at an even rate over time all at the exact same level then they work fine f= +or security, acting similarly to fixed block rewards. Unfortunately that is= +n't how it works in the real world. There's a very well established= + day/night cycle with fees going to zero overnight and even longer gaps on = +weekends and holidays. If in the future Bitcoin is entirely dependent on fe= +es for security (scheduled very strongly) and this pattern keeps up (overwh= +elmingly likely) then this is going to become a serious problem.<div><br></= +div><div>What's likely to happen is that at first there will simply be = +no or very few blocks mined overnight. There are likely to be some, as mine= +rs at first turn off their mining rigs completely overnight then adopt the = +more sophisticated strategy of waiting until there are enough fees in the m= +empool to warrant attempting to make a block and only then doing it. Unfort= +unately the gaming doesn't end there. Eventually the miners with lower = +costs of operation will figure out that they can collectively reorg the las= +t hour (or some time period) of the day overnight and this will be profitab= +le. That's likely to cause the miners with more expensive operations to= + stop attempting mining the last hour of the day preemptively.=C2=A0</div><= +div><br></div><div>What happens after that I'm not sure. There are a sm= +all enough number of miners with a quirky enough distribution of costs of o= +peration and profitability that the dynamic is heavily dependent on those s= +pecifics, but the beginnings of a slippery slope to a mining cabal which re= +orgs everyone else out of existence and eventually 51% attacks the whole th= +ing have begun. It even gets worse than that because once there's a cab= +al aggressively reorging anyone else out when they make a block other miner= +s will shut down and rapidly lose the ability to quickly spin up again, so = +the threshold needed for that 51% attack will keep going down.</div><div><b= +r></div><div>In short, relying completely on transaction fees for security = +is likely to be a disaster. What we can say from existing experience is tha= +t having transaction fees be about 10% of rewards on average works well. It= +'s enough to incentivize collecting fees but not so much that it makes = +incentives get all weird. 90% transaction fees is probably very bad. 50% wo= +rks but runs the risk of spikes getting too high.</div><div><br></div><div>= +There are a few possible approaches to fixes. One would be to drag most of = +east asia eastward to a later time zone thus smoothing out the day/night cy= +cle but that's probably unrealistic. Another would be to hard fork in f= +ixed rewards in perpetuity, which is slightly less unrealistic but still ex= +tremely problematic.=C2=A0</div><div><br></div><div>Much more actionable ar= +e measures which smooth out fees over time. Having wallets opportunisticall= +y collect their dust during times of low transaction fees would help and wo= +uld save users on fees. Also making UX which clarifies when things are like= +ly to take a day or week but that it's reliable would be a reasonable t= +hing to do, but users unfortunately are very averse to transactions taking = +a while.</div></div> +_______________________________________________<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> + +--0000000000002578d105e38beeed-- + |