Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1491CC002D for ; Sun, 19 Jun 2022 15:54:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id CF3D84092E for ; Sun, 19 Jun 2022 15:54:17 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org CF3D84092E Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=FDDgO84N 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 smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W60870Zoj3W2 for ; Sun, 19 Jun 2022 15:54:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 15A2A4091D Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by smtp4.osuosl.org (Postfix) with ESMTPS id 15A2A4091D for ; Sun, 19 Jun 2022 15:54:15 +0000 (UTC) Received: by mail-wr1-x42f.google.com with SMTP id q9so11566932wrd.8 for ; Sun, 19 Jun 2022 08:54:15 -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 :cc; bh=7puIEwHpIZXgIr6rwO5+NUKo3mFs+LLAS3VXt1R6wTo=; b=FDDgO84NOOf4as3+99m8NnBEKgFi8ckDOWeDscycFJCgXAfnxN9mOAFaV8SYEqeB0j ClDTmZgQqaOGQB605Y21g86QXLbL2rBp9kVE3fwhJu0OFbCQpMY2xyA9AZzlBY98IMBX pu5H/5Gm47uziViutb30MtDyv34jR+BFqzM/DYc+epu8jZJa+SdnfkFl055OfqxVXhlF BNQPOEmRBuB4pBEW1xAxTyw6nNbNqzl0M3hI34svwCJPYkRl8gTCNaQBk3OZurIzWsDW 2IwwiEXVjbbJRUGE+KE+ZcY2xvj8FzqhSAWXnr9MVvfPreK5y9YK1M7bPugWts8dsxt5 OrfQ== 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=7puIEwHpIZXgIr6rwO5+NUKo3mFs+LLAS3VXt1R6wTo=; b=h/6bfExsj2ILFp3DTnzbTuKocJeiS3aa3rOq/pDGgtfh5d2P8oJ2w+WiL2VkqK89In 024XUCZVW0qppBPcY18IrvyRVhkqGofS62Q2L/eMkhEkpFpkExQxTUdtUqj1riKJdLK/ wvh9DJSdpbv5u5ka2ouag0lwgUO6C9cByPcMMSLLQXnAP4RqaQplSu9uSwL8guJmqTt8 tI2EweKjfybSdg1xZkB/d8wz5rRigS8JWLKJNKxuozcj0hzoDDvd71zLrFupUdDUwbrP 2iztksWX+a4rOOdrLThp4iO7cer3InhOZitXNF2Pur8pfmZlfzlART9X5LwBdn+dVwOq ELkw== X-Gm-Message-State: AJIora/YzHJ9/Sr29LoYajY8ummHy+C02Q/Zhqk+uPpmDIEGeia7xqUA E9EWlDHs8LHzvT1ANS2YEeErmqsnorr9za2DCQw= X-Google-Smtp-Source: AGRyM1v2kpk8NFzYpn/aQDSYqDT1ceq/vn/jZtGJIycWIzIHOzWsFas7aiONkidXPB2JuZ/Sugl12/JoZFmH60rqvCA= X-Received: by 2002:a5d:6608:0:b0:21a:374d:786a with SMTP id n8-20020a5d6608000000b0021a374d786amr16682579wru.418.1655654054171; Sun, 19 Jun 2022 08:54:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Manuel Costa Date: Sun, 19 Jun 2022 16:54:03 +0100 Message-ID: To: Peter Todd , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000c517b805e1ceff11" X-Mailman-Approved-At: Sun, 19 Jun 2022 18:04:19 +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 15:54:18 -0000 --000000000000c517b805e1ceff11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "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 being 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 and 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. 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". 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 accepted 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 t= he > 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 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 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 > --000000000000c517b805e1ceff11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"Long time listener, first time caller". Just sh= aring my 2 sats:

While I find it stimulating, I think this discussio= n (and other similar doom-like scenarios) is somewhat irrelevant in practic= e.

When the time comes and if we start seeing issues wit= h block rewards being too low to maintain acceptable security, we're go= ing to have multiple solutions being implemented for it, and definitely a h= ard 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=C2=A0in one of the hard for= ks that can actually keep moving forward with some degree of security assur= ance.

I feel like people sometimes think of these = systems as when they fail there's a full loss, but that's not the c= ase as the history is not lost, and so we can move forward from that histor= y with multiple alternatives and allow the social/economic consensus to dic= tate which one becomes the new accepted chain.
The genie is out of the b= ox, and some chain whose history is prefixed by Bitcoin's current chain= history will always exist.
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) t= hat would turn some or all utxos into "anyone can spend".

= Transitions might be disorderly and filled with drama and discussion as the= "block size wars" in 2017, but anyone who doesn't want to &q= uot;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 accepted chain.

Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundat= ion.org> escreveu no dia domingo, 19/06/2022 =C3=A0(s) 11:32:
On Sun, Jun 12, 2022 a= t 07:16:49PM +0000, alicexbt wrote:
> 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
--000000000000c517b805e1ceff11--