Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id CA979C002D for ; Mon, 11 Jul 2022 20:35:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 955BA410C3 for ; Mon, 11 Jul 2022 20:35:16 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 955BA410C3 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=blockstream-com.20210112.gappssmtp.com header.i=@blockstream-com.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=axPrBwEo X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbKwWoGko4jc for ; Mon, 11 Jul 2022 20:35:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 2119C410C2 Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) by smtp4.osuosl.org (Postfix) with ESMTPS id 2119C410C2 for ; Mon, 11 Jul 2022 20:35:14 +0000 (UTC) Received: by mail-qt1-x834.google.com with SMTP id ck6so7964616qtb.7 for ; Mon, 11 Jul 2022 13:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=RqouIluR7rsUJwQEJ+zPJUxGnVGvwgKZyCbJ9MO2J+8=; b=axPrBwEoUiGVbd2ImZVbTN3ktN2YnVMFHxRKQhuY2Y5bvfx8xCJdR3Q6Ohhsef6YwA nvdZMG8Fclq17VdrhaLKdY2N5J6L/kDhhynm06DdglDrqFoB7NTfzJ39jutdXvw/iG3y AxNPkzE3Q36aGDZdkMcERQu1RKCA5ndbmMk/3IZbRNL3nZdTN4K4vpwUuT2/IN6v3dJh BPyW6btnoAu7dLC80HrqbrV8yUI3hhmLXNk1WTdl84B6QEvp+UfKxyT1gwzRSuaeSeLu ewEaSI62a7befKVBMxrhXcCxWEzkaTzRSKJtRhPddp8rdlJjyiVk8Hf+yQ+0ui+Q28+v j0ZA== 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=RqouIluR7rsUJwQEJ+zPJUxGnVGvwgKZyCbJ9MO2J+8=; b=S9VIrMVV60XFR9596GHpxT8uOLZNwRyeD/Uki3cTrLzK57Jh1XtIRwwErLR5Dh6gSa 2G5+pojMiIXKm9ns/lDM1i47cPdhsDsUTEC0Ana8LtO6QzwzT6i0HdsGKde8Ev4RDL8g bZM3DuIdmsQXvBxBjnTJcK44j5xIVxa4wxxtM6NdUh/rqhDlsEO+65UKc9CgEp0m3W4Z egHW3pa5dKScJSA+hLAPnkaFv7Yy1aFbbDaEyCnmm5eIlEXByBFzTQBpfhB+0Uwdmi4K fJt6y3vicS3Po9/MNUZrPvQl/Afzb3vtCIvPmZ4ONWjznSPxrmwc5J12M/WxatXEvSYw qINQ== X-Gm-Message-State: AJIora/eFRbrlWhGWQUcnshsIG6OjmcjOFzLW406fkovwUNzIItanIen 5TOce9tGzsUOvFjwv/sSbzR2EaCg+M8rVrzvGuWkQDES9R4= X-Google-Smtp-Source: AGRyM1tcTioEH7bDIXJk3xJQmBq3ucc4fYQRWI0DjocsheqFBN76fuxKSuNz4y4ikcbGpKxsd2ehdOTisxMweJv203M= X-Received: by 2002:a05:622a:389:b0:31d:3d5e:6317 with SMTP id j9-20020a05622a038900b0031d3d5e6317mr15288239qtx.268.1657571713737; Mon, 11 Jul 2022 13:35:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Russell O'Connor" Date: Mon, 11 Jul 2022 16:35:02 -0400 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000002ffc2605e38d7de2" 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 20:35:16 -0000 --0000000000002ffc2605e38d7de2 Content-Type: text/plain; charset="UTF-8" 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. > Miners will learn to create anyone-can-spend outputs to bribe other miners to build on their block rather than reorg it. (Due to the coinbase maturity, this will require some amount of floating capital.) --0000000000002ffc2605e38d7de2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 11, 2022 at 2:19 PM Bram Cohen via bitcoin-dev <bitcoin-dev@lists.linux= foundation.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, act= ing similarly to fixed block rewards. Unfortunately that isn't how it w= orks 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 hol= idays. 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= 9;s likely to happen is that at first there will simply be no or very few b= locks mined overnight. There are likely to be some, as miners at first turn= off their mining rigs completely overnight then adopt the more sophisticat= ed strategy of waiting until there are enough fees in the mempool to warran= t attempting to make a block and only then doing it. Unfortunately the gami= ng doesn't end there. Eventually the miners with lower costs of operati= on 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 l= ikely to cause the miners 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.

Miners will learn to create anyone-can-spend outputs to b= ribe other miners to build on their block rather than reorg it.=C2=A0 (Due = to the coinbase maturity, this will require some amount of floating capital= .)
--0000000000002ffc2605e38d7de2--