Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 350F8C002D for ; Sun, 19 Jun 2022 18:26:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 014EF60E8D for ; Sun, 19 Jun 2022 18:26:35 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 014EF60E8D Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=YWJUZP8y 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 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 axAm6C_uusrZ for ; Sun, 19 Jun 2022 18:26:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org A554360E84 Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) by smtp3.osuosl.org (Postfix) with ESMTPS id A554360E84 for ; Sun, 19 Jun 2022 18:26:33 +0000 (UTC) Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-3176b6ed923so81149297b3.11 for ; Sun, 19 Jun 2022 11:26:33 -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=aXhSJHrzsKvhfgxxYK15qKKEPvfSyR1SUWmnHIwhsJ0=; b=YWJUZP8y13DfBHb3XkLQSY0M+ZXKcM3oQZz96je4MiBgUGg4XyQtzE01rfGE2Im3Qf oaBYWfubQQozGboncyqUEl1AAKwdcM/BCf7XEMPj6dXdxuxxyXj+5vad9zgsHARHfTB3 XAu3fKJeYAKTkcB5b3IjKU/vPPx5GNKVA085r2DEZ6dpKaJKBRrntft/3PiZeUUEu3Qq HIkk05AU87Ypk+nQbc4GOUTdbWGZ4IqKrTglN8ErNL/r4WhkQcax9nhmo57jYPdSga3z yNQWq85Z4eErkshKGjaqbtHgm4FCyMvu6vc5TIeX0njynKJbMtdK0RrHDPfIxGWfZZTd jQhQ== 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=aXhSJHrzsKvhfgxxYK15qKKEPvfSyR1SUWmnHIwhsJ0=; b=CGj+4amvyinTAc4ptChD9LJ6X8pCa8/KOUKhMvIvC73J08kLZK3jXVXCEx4kX0jocx pHLryFkYKn/M7FHOUk6GA9dqaDCsD4gZsICRn8k80d1xLBSDt8tyzMUeKB2I4td22n3X Mc2/BAM6Hp6lEQykfDebLu59UjB5yUBgU+noewYCAZEat0rHndBud3zv/PRopY3Fz8Ue NLrdO+d4AnMSwvE9IVoWcR9Yrx3c81z18/xsOnI//Gh0Ym7AX/Gw035GBcnDVOqOBCqX 0uz2MTaN7bR2f52C2YqSW47P1ElWtiq0j/ppIKrDr0lD9FD5/Nw1t0X1J//t5BXZTEpl QCtQ== X-Gm-Message-State: AJIora9EO8E2PYsiV+Bblrx4VdX+mbIt4bZP+UyCJhkaSBfptIMyKdyJ NgywiJNNuM4200PpL3NFIqHJKtWwCBsotlISlrFSV87TOGKEww== X-Google-Smtp-Source: AGRyM1u/uLtX1iUTtjTGh+hBuWnELSqyb/y0La7zGf7fr3EwDlCzFNglHA5FGOETTV57jXen1MdVcKdGZyeZryk5Yao= X-Received: by 2002:a81:1494:0:b0:317:7fe7:f0e2 with SMTP id 142-20020a811494000000b003177fe7f0e2mr15123370ywu.426.1655663192403; Sun, 19 Jun 2022 11:26:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kate Salazar Date: Sun, 19 Jun 2022 20:26:21 +0200 Message-ID: To: Manuel Costa , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000073739a05e1d12022" X-Mailman-Approved-At: Sun, 19 Jun 2022 21:01:27 +0000 Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable 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: Sun, 19 Jun 2022 18:26:35 -0000 --00000000000073739a05e1d12022 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey On Sun, Jun 19, 2022 at 8:04 PM Manuel Costa via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > "Long time listener, first time caller". Just sharing my 2 sats: > > While I find it stimulating, I think this discussion (and other similar > doom-like scenarios) is somewhat irrelevant in practice. > > When the time comes and if we start seeing issues with block rewards bein= g > too low to maintain acceptable security, we're going to have multiple > solutions being implemented for it, and definitely a hard fork to > indefinitely maintain some degree of block subsidy is going to be within > them. > If it is indeed confirmed that the original chain is now insecure, > consensus should eventually coalesce in one of the hard forks that can > actually keep moving forward with some degree of security assurance. > > I feel like people sometimes think of these systems as when they fail > there's a full loss, but that's not the case as the history is not lost, > and so we can move forward from that history with multiple alternatives a= nd > allow the social/economic consensus to dictate which one becomes the new > accepted chain. > The genie is out of the box, and some chain whose history is prefixed by > Bitcoin's current chain history will always exist. > I think you are right, the keywords maybe being consensus eventually coalesces in the most viable chain. > The only type of problems we should truly be worrying about are ones that > might invalidate the security of the history itself, like a cryptographic > breakthrough (quantum computing for example) that would turn some or all > utxos into "anyone can spend". > I think this is wrong. An entity investing in quantum power and letting their chop onto some particular utxos is a reasonable outcome. It parallels a tangible scenario: gang somehow getting a bulldozer and driving it into some particular safe. Being able to rewind such events is the only security issue here. More generally, circulating supply is circulating supply, to all effect, outcome is desirable or not. > Transitions might be disorderly and filled with drama and discussion as > the "block size wars" in 2017, but anyone who doesn't want to "vote", can > always just keep their utxos frozen in place while the drama sorts itself > out, and maintain whatever holdings they previously had on the new accept= ed > chain. > > Peter Todd via bitcoin-dev > escreveu no dia domingo, 19/06/2022 =C3=A0(s) 11:32: > >> On Sun, Jun 12, 2022 at 07:16:49PM +0000, alicexbt wrote: >> > Hi Peter, >> > >> > > Only because the block reward goes away. If it was made to continue >> > > indefinitely - most likely with an inflation hard fork - demand for >> block space >> > > would not be critical to Bitcoin's security. >> > >> > >> > I am not completely against your proposal although 100% sure this will >> not have "consensus" to be implemented. I think if bitcoin doesn't have >> enough demand for block space, it should die. I will be sad if bitcoin >> doesn't exist but it should be a lesson for all the people opposing soft >> forks based on drama and politics instead of technical review. >> > >> > I don't see anything wrong with users paying 100x fees for opening and >> closing LN channels. >> >> The PoW security of Bitcoin benefits all Bitcoin users, proportional to >> the >> value of BTC they hold; if Bitcoin blocks aren't reliably created the >> value of >> *all* BTC goes down. It doesn't make sense for the entire cost of that >> security >> to be paid for on a per-tx basis. And there's a high chance paying for i= t >> on a >> per-tx basis won't work anyway due to lack of consistent demand. >> >> It would be extremely unfortunate if one of the very few decentralized >> ways to >> store value died simply because we couldn't find a way to pay to keep it >> secure. >> >> -- >> https://petertodd.org 'peter'[:-1]@petertodd.org >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000073739a05e1d12022 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey

On Sun, Jun 19, 2022 at 8:04 PM Manuel Costa via b= itcoin-dev <bit= coin-dev@lists.linuxfoundation.org> wrote:
"Long time listener= , first time caller". Just sharing my 2 sats:

While I find it s= timulating, I think this discussion (and other similar doom-like scenarios)= is somewhat irrelevant in practice.

When the time comes= and if we start seeing issues with block rewards being too low to maintain= acceptable security, we're going to have multiple solutions being impl= emented for it, and definitely a hard fork to indefinitely maintain some de= gree of block subsidy is going to be within them.
If it is indeed confir= med that the original chain is now insecure, consensus should eventually co= alesce=C2=A0in one of the hard forks that can actually keep moving forward = with some degree of security assurance.

I feel lik= e people sometimes think of these systems as when they fail there's a f= ull loss, but that's not the case as the history is not lost, and so we= can move forward from that history with multiple alternatives and allow th= e social/economic consensus to dictate which one becomes the new accepted c= hain.
The genie is out of the box, and some chain whose history is prefi= xed by Bitcoin's current chain history will always exist.

I think you are right, the keywords mayb= e being consensus eventually coalesces in the most viable chain.
= =C2=A0
The only type of problems we should truly be worrying about are on= es that might invalidate the security of the history itself, like a cryptog= raphic breakthrough (quantum computing for example) that would turn some or= all utxos into "anyone can spend".
<= div>
I think this is wrong. An entity investing in quantum po= wer and letting their chop onto some particular utxos is a reasonable outco= me. It parallels a tangible scenario: gang somehow getting a bulldozer and = driving it into some particular safe. Being able to rewind such events is t= he only security issue here.

More generally, circu= lating supply is circulating supply, to all effect, outcome is desirable or= not.
=C2=A0
Transitions might be disorderly and filled with dr= ama and discussion as the "block size wars" in 2017, but anyone w= ho doesn't want to "vote", can always just keep their utxos f= rozen in place while the drama sorts itself out, and maintain whatever hold= ings they previously had on the new accepted chain.

Peter Todd via bit= coin-dev <bitcoin-dev@lists.linuxfoundation.org> escreveu no dia = domingo, 19/06/2022 =C3=A0(s) 11:32:
On Sun, Jun 12, 2022 at 07:16:49PM +0000, alicexbt wro= te:
> Hi Peter,
>
> > Only because the block reward goes away. If it was made to contin= ue
> > indefinitely - most likely with an inflation hard fork - demand f= or block space
> > would not be critical to Bitcoin's security.
>
>
> I am not completely against your proposal although 100% sure this will= not have "consensus" to be implemented. I think if bitcoin doesn= 't have enough demand for block space, it should die. I will be sad if = bitcoin doesn't exist but it should be a lesson for all the people oppo= sing soft forks based on drama and politics instead of technical review. >
> I don't see anything wrong with users paying 100x fees for opening= and closing LN channels.

The PoW security of Bitcoin benefits all Bitcoin users, proportional to the=
value of BTC they hold; if Bitcoin blocks aren't reliably created the v= alue of
*all* BTC goes down. It doesn't make sense for the entire cost of that = security
to be paid for on a per-tx basis. And there's a high chance paying for = it on a
per-tx basis won't work anyway due to lack of consistent demand.

It would be extremely unfortunate if one of the very few decentralized ways= to
store value died simply because we couldn't find a way to pay to keep i= t
secure.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000073739a05e1d12022--