diff options
| author | Bram Cohen <bram@chia.net> | 2022-07-11 19:47:43 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-07-12 02:47:57 +0000 |
| commit | 90350f99e7b08caee21eeb92521dddba6fd7a4b7 (patch) | |
| tree | 9da61f028c61803191bbfc6e463abbe914755edb | |
| parent | 9eeca4947a73ecaacab671ad1c6df408d1bf2536 (diff) | |
| download | pi-bitcoindev-90350f99e7b08caee21eeb92521dddba6fd7a4b7.tar.gz pi-bitcoindev-90350f99e7b08caee21eeb92521dddba6fd7a4b7.zip | |
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
| -rw-r--r-- | af/8beebce2a72cd8588003baa9489f7c28a19073 | 149 |
1 files changed, 149 insertions, 0 deletions
diff --git a/af/8beebce2a72cd8588003baa9489f7c28a19073 b/af/8beebce2a72cd8588003baa9489f7c28a19073 new file mode 100644 index 000000000..4051fe5fb --- /dev/null +++ b/af/8beebce2a72cd8588003baa9489f7c28a19073 @@ -0,0 +1,149 @@ +Return-Path: <bram@chia.net> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 9F8C4C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 12 Jul 2022 02:47:57 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 736564184E + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 12 Jul 2022 02:47:57 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 736564184E +Authentication-Results: smtp4.osuosl.org; + dkim=pass (2048-bit key) header.d=chia.net header.i=@chia.net + header.a=rsa-sha256 header.s=google header.b=LhchIjKR +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.099 +X-Spam-Level: +X-Spam-Status: No, score=-2.099 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, 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 ljOXxmcVfbyd + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 12 Jul 2022 02:47:56 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org DB9274181F +Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com + [IPv6:2607:f8b0:4864:20::1134]) + by smtp4.osuosl.org (Postfix) with ESMTPS id DB9274181F + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 12 Jul 2022 02:47:55 +0000 (UTC) +Received: by mail-yw1-x1134.google.com with SMTP id + 00721157ae682-31caffa4a45so67966617b3.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 11 Jul 2022 19:47:55 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chia.net; s=google; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=QkqBNjFHC5gjLBdMmqmaYCLlP92hsxqGwTQkPY0qVj0=; + b=LhchIjKRzSkwZ8MDwDPNcTfYUTvbB9juzFIEEoX6BRGloDJ0QnS4V+lJJGUpKWl9S3 + fWRxUyyhBe76MqG8nKBr7BBrUL6NBcioy2l2Bki8JNlTw9py2BqtbX0FKReyCEQ5iwWV + ddbJ6dRljuewigZIkHGIg0nTFYLLKSGDGOyHGKkiK6KtWn1rMZDWYyh2lZlBW2hhLngZ + JMkoGRqCK6nxqX1i1bxWwCdOGwUFM2cxX5XRSItvEiuWGj0HYq42CoFgqnH/CJnKem8m + 4iLMdVV8L7Gv8y6YtxLgmBoiwdJDeop1g2vSNtBlb5eqo53EqlQYD+1gY6m8H/DmAJK7 + hrAg== +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:cc; + bh=QkqBNjFHC5gjLBdMmqmaYCLlP92hsxqGwTQkPY0qVj0=; + b=X3jqNbeqHykzK5Fg0I4PDI3lpeMWSWqZj1n0zEq+i5pG1Ngv/FMMwmIiRfl2rRVvga + XdGqENeR6s7yUp3J9qDmt284W95wKkyy50vgQi9awHT9piHRZD7cIIilFrADS4P1M3Ak + f6Trjx+pVqp2LbQLRTpjvKb7YCTjrCmkHTEakfsq7Pk2oSUR40+LiG6U9fi1mzBnUDdV + Tiz+UpuO8ZBTDyhALm9r+m+KlImaQxi6wC92cr2B/tAxsjNFw+M2fzjX1Wi77+OO3bxX + 7AlYfA30+GM5g3S0R6VObgsLtsonChs+jl5uZeg7By2sZfe9FztP6zTeK7WCF5JSS4d3 + TyQQ== +X-Gm-Message-State: AJIora95Zs4rPxeprVnjUJU6HOFTmiEkJ4K+wYmUpkazDMtfjs0cWqCx + QJYo4RVpTFZzNLjVylEOTZL/6/B32xQ7/3oGe1IXdA== +X-Google-Smtp-Source: AGRyM1tsusTFEVI2sBGbSAlNd7Kf3QENRchVpmuf+l6WS4iJMRUCuzOxDSaAQwd0+C56lCoOF90wM3mu0ajgIbn6U6w= +X-Received: by 2002:a81:9b02:0:b0:31c:9ae4:99ec with SMTP id + s2-20020a819b02000000b0031c9ae499ecmr22793786ywg.495.1657594074760; Mon, 11 + Jul 2022 19:47:54 -0700 (PDT) +MIME-Version: 1.0 +References: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com> + <Ysyb4T/36oXeAH+z@petertodd.org> +In-Reply-To: <Ysyb4T/36oXeAH+z@petertodd.org> +From: Bram Cohen <bram@chia.net> +Date: Mon, 11 Jul 2022 19:47:43 -0700 +Message-ID: <CAHUJnBA+gb0AnGDRB9iA99R6=L0Y5DffB7aE2x+9dU9vyOoXmw@mail.gmail.com> +To: Peter Todd <pete@petertodd.org> +Content-Type: multipart/alternative; boundary="000000000000021ea305e392b212" +X-Mailman-Approved-At: Tue, 12 Jul 2022 09:49:17 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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: Tue, 12 Jul 2022 02:47:57 -0000 + +--000000000000021ea305e392b212 +Content-Type: text/plain; charset="UTF-8" + +On Mon, Jul 11, 2022 at 2:53 PM Peter Todd <pete@petertodd.org> wrote: + +> +> The only type of fee-smoothing scheme that is feasible is to smooth an +> entirely +> separate category of fees that are made mandatory. For example, you could +> achieve the economic impact of inflation by having a fixed value*time +> based fee +> that goes to timelocked anyone-can-spend outputs in the coinbase to push +> the +> fee forward to other miners. +> + +I'm not sure what the implications would be of charging coins for moving +based on their value times how long since they last moved would be (I +*think* that's what you're suggesting). It isn't obviously bad, but feels +weird to me. + +That said, a scheme which would work would be to have a fixed minimum fee +of satoshis/vbyte which is required to be repaid out by the miner into a +pool and they get back a fixed fraction of what was in that pool. The pool +could simply be a rolling coin which keeps the balance. That's still a bit +ugly but doesn't lessen block size significantly, is fairly coherent, and +is a soft fork. It's the best emergency measure I'm aware of. + +--000000000000021ea305e392b212 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Jul 11, 2022 at 2:53 PM Peter Tod= +d <<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>> wrot= +e:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st= +yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd= +ing-left:1ex"><br> +The only type of fee-smoothing scheme that is feasible is to smooth an enti= +rely<br> +separate category of fees that are made mandatory. For example, you could<b= +r> +achieve the economic impact of inflation by having a fixed value*time based= + fee<br> +that goes to timelocked anyone-can-spend outputs in the coinbase to push th= +e<br> +fee forward to other miners.<br></blockquote><div><br></div><div>I'm no= +t sure what the implications would be of charging coins for moving based on= + their value times how long since they last moved would be (I *think* that&= +#39;s what you're suggesting). It isn't obviously bad, but feels we= +ird to me.</div><div><br></div><div>That said, a scheme which would work wo= +uld be to have a fixed minimum fee of satoshis/vbyte which is required to b= +e repaid out by the miner into a pool and they get back a fixed fraction of= + what was in that pool. The pool could simply be a rolling coin which keeps= + the balance. That's still a bit ugly but doesn't lessen block size= + significantly, is fairly coherent, and is a soft fork. It's the best e= +mergency measure I'm aware of.</div></div></div> + +--000000000000021ea305e392b212-- + |