From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 02CD9C002D for ; Mon, 11 Jul 2022 18:39:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id C24C4826AA for ; Mon, 11 Jul 2022 18:39:18 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C24C4826AA Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=JorIdWoA X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.852 X-Spam-Level: X-Spam-Status: No, score=0.852 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 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 65WBLOns7MNw for ; Mon, 11 Jul 2022 18:39:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6E7EA82640 Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) by smtp1.osuosl.org (Postfix) with ESMTPS id 6E7EA82640 for ; Mon, 11 Jul 2022 18:39:14 +0000 (UTC) Received: by mail-lj1-x22e.google.com with SMTP id o12so4646781ljc.3 for ; Mon, 11 Jul 2022 11:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6CA0tH1ajRBIXnhF/lo5BaszZiUowby4BC79IVH3VOs=; b=JorIdWoAwdMopSUrTj3IwtDwWsyiEm2N87fiVGmOaqCPvT67cWgaOc/gAC14DSwhEI ro6e/VgvC96S2bcQUJnQXBOPFdLhLtSCs5kxxfqh4pBY3tARR01owLktmJgJ2KiloQ3E pDV29VQL1ArKJQkyvHIv/dDABD9MMCBPF4Z2QaaZa9OqKaSL7p7DjZs5egLzzdPPWIKo V5yJP/9E0TXydF/xS/Zzq4T1IpUPr2A/Vm1tyEmnFz/8JkRaf7mx8gYqh8fhasf+hahH fWsWF+ZCQ0DLclm+R2dZb7Lq/WTEUAUpS6xpUuQD60E0nXj4o2o/8Pg1p+DeuVVQ0G+X YVvw== 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=6CA0tH1ajRBIXnhF/lo5BaszZiUowby4BC79IVH3VOs=; b=AEEBxwJdcZ4WYfw1gRJ0BQl4qbpN/6TvLZZ3D1b7d3QGLbAvOsQAH9pIuTPvsByHp5 hu1tlwVe87n3ZIqxecZEG/9D8oIPFSHcSVZObBOfd9loqew4vucUxRbVdXLyKy4vzR7Q nJ2aeJC3GwoZM5AwUXHW0VpI+u9IZIQy3mANauso+z5VWqfp2rVSatgMR0tROkMcwYSn sfiWBS5ETQ8xj8CSkb+GFKm2k92XYaFW0pDDnAS3lU5aXwnbDAlr6bYjJzwoJAs8rcIU 25qKSV/sQbtMJZFFUngNKuBtMvsKeQJmPnbrFozVLDAkLKFpT3bu68au75YxT41OTJCU oj5w== X-Gm-Message-State: AJIora8ZfrQE9kYop57Hi1SNBf4kg45ubXVUernzAILqx6NF44MQ7Xhp fSccFz07GeyOeMMHgBq1hoJcT9ZBd3ZUT6NQLAs= X-Google-Smtp-Source: AGRyM1tsx7CkpW9lfFC72wD42/2b3QeBGQQKN16y6Tcia+cblCjvfwgZBC31MjPBrNgk1pWLjDCPO/zuL9m64ZG7SMo= X-Received: by 2002:a05:651c:211f:b0:25a:86c4:bfe4 with SMTP id a31-20020a05651c211f00b0025a86c4bfe4mr11042100ljq.531.1657564752193; Mon, 11 Jul 2022 11:39:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: micaroni@gmail.com Date: Mon, 11 Jul 2022 15:38:34 -0300 Message-ID: To: Bram Cohen , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000003f30ec05e38bde5f" X-Mailman-Approved-At: Mon, 11 Jul 2022 23:06:55 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2022 18:39:19 -0000 --0000000000003f30ec05e38bde5f Content-Type: text/plain; charset="UTF-8" The expectation is that in a few years a space in the block will be very competitive / expensive and be used only as a bridge for second layers or big transactions. Who would have thought in 2017 that one day we would be worried about cheap rates! Anyway, it seems like a good point and I suggest giving this issue some name for easy and later reference. On Mon, Jul 11, 2022 at 3:20 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 > --0000000000003f30ec05e38bde5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The expec= tation is that in a few years a space in the block will be very competitive= / expensive and be used only as a bridge for second layers or= big transactions. Who would have thou= ght in 2017 that one day we would be worried about cheap rates!

Anyway, it seems like a good point and I suggest= giving this issue some name for easy and later reference.


On Mon, Jul 11,= 2022 at 3:20 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 e= xact 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 ze= ro overnight and even longer gaps on weekends and holidays. If in the futur= e Bitcoin is entirely dependent on fees for security (scheduled very strong= ly) and this pattern keeps up (overwhelmingly likely) then this is going to= become a serious problem.

What's likely to happen i= s 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 the= re. Eventually the miners with lower costs of operation will figure out tha= t they can collectively reorg the last hour (or some time period) of the da= y overnight and this will be profitable. That's likely to cause the min= ers with more expensive operations to stop attempting mining the last hour = of the day preemptively.=C2=A0

What happens after = that I'm not sure. There are a small enough number of miners with a qui= rky enough distribution of costs of operation and profitability that the dy= namic is heavily dependent on those specifics, but the beginnings of a slip= pery slope to a mining cabal which reorgs everyone else out of existence an= d eventually 51% attacks the whole thing have begun. It even gets worse tha= n that because once there's a cabal aggressively reorging anyone else o= ut 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% atta= ck will keep going down.

In short, relying complet= ely on transaction fees for security is likely to be a disaster. What we ca= n say from existing experience is that having transaction fees be about 10%= of rewards on average works well. It's enough to incentivize collectin= g fees but not so much that it makes incentives get all weird. 90% transact= ion fees is probably very bad. 50% works but runs the risk of spikes gettin= g too high.

There are a few possible approaches to= fixes. One would be to drag most of east asia eastward to a later time zon= e thus smoothing out the day/night cycle but that's probably unrealisti= c. Another would be to hard fork in fixed rewards in perpetuity, which is s= lightly less unrealistic but still extremely problematic.=C2=A0
<= br>
Much more actionable are measures which smooth out fees over = time. Having wallets opportunistically collect their dust during times of l= ow 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&#= 39;s reliable would be a reasonable thing to do, but users unfortunately ar= e very averse to transactions taking a while.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000003f30ec05e38bde5f--