path: root/48/d1c6b478bfd4ef5dfde86808ab32d5fb7312c1

Return-Path: <mercedes.catherine.salazar@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 350F8C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 19 Jun 2022 18:26:33 +0000 (UTC)
Received: by mail-yw1-x1134.google.com with SMTP id
 00721157ae682-3176b6ed923so81149297b3.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <mailman.9.1654344003.14400.bitcoin-dev@lists.linuxfoundation.org>
 <CAHTn92zw_MaSKWiZGhGFqFYXJxv6kQ+7=XCHbRLim1jhtEsVVQ@mail.gmail.com>
 <CAJowKgJ8GP4Ykzn5dMHZ7wsE04YmpOLgTpdc9tgfVng0qB0Jjg@mail.gmail.com>
 <YqVfTU0M7XN8+Ybu@petertodd.org>
 <Pwr9EFLSv2rU7nXRzqFuw2LPxpFo22g_qYy4reQzpMuSlgRzTG536uLjZCc9sI43olReGMA7BFgjnxJGKtZNtxU7qRy_-YYOnz6TeMy4h8Q=@protonmail.com>
 <Yq77CnxOhr615ip8@petertodd.org>
 <CAAxiura7-TTUOg=vuH8q+orX+LVED74f+NvaYqVve3j--CjTMQ@mail.gmail.com>
In-Reply-To: <CAAxiura7-TTUOg=vuH8q+orX+LVED74f+NvaYqVve3j--CjTMQ@mail.gmail.com>
From: Kate Salazar <mercedes.catherine.salazar@gmail.com>
Date: Sun, 19 Jun 2022 20:26:21 +0200
Message-ID: <CAHiDt8AqMY7gZoW2QMwX_qtMqpN9Fv2UcG=JMs5px-JPy+91Vg@mail.gmail.com>
To: Manuel Costa <manecosta@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <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 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

<div dir=3D"ltr"><div>Hey</div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Sun, Jun 19, 2022 at 8:04 PM Manuel Costa via b=
itcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bit=
coin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr">&quot;Long time listener=
, first time caller&quot;. Just sharing my 2 sats:<br><br>While I find it s=
timulating, I think this discussion (and other similar doom-like scenarios)=
 is somewhat irrelevant in practice.<div><br></div><div>When the time comes=
 and if we start seeing issues with block rewards being too low to maintain=
 acceptable security, we&#39;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.<br>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.</div><div><br></div><div>I feel lik=
e people sometimes think of these systems as when they fail there&#39;s a f=
ull loss, but that&#39;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.<br>The genie is out of the box, and some chain whose history is prefi=
xed by Bitcoin&#39;s current chain history will always exist.<br></div></di=
v></blockquote><div><br></div><div>I think you are right, the keywords mayb=
e being consensus eventually coalesces in the most viable chain.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div>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 &quot;anyone can spend&quot;.<br></div></div></blockquote><=
div><br></div><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.</div><div><br></div><div>More generally, circu=
lating supply is circulating supply, to all effect, outcome is desirable or=
 not.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div>Transitions might be disorderly and filled with dr=
ama and discussion as the &quot;block size wars&quot; in 2017, but anyone w=
ho doesn&#39;t want to &quot;vote&quot;, 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.</div></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Peter Todd via bit=
coin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; escreveu no dia =
domingo, 19/06/2022 =C3=A0(s) 11:32:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">On Sun, Jun 12, 2022 at 07:16:49PM +0000, alicexbt wro=
te:<br>
&gt; Hi Peter,<br>
&gt; <br>
&gt; &gt; Only because the block reward goes away. If it was made to contin=
ue<br>
&gt; &gt; indefinitely - most likely with an inflation hard fork - demand f=
or block space<br>
&gt; &gt; would not be critical to Bitcoin&#39;s security.<br>
&gt; <br>
&gt; <br>
&gt; I am not completely against your proposal although 100% sure this will=
 not have &quot;consensus&quot; to be implemented. I think if bitcoin doesn=
&#39;t have enough demand for block space, it should die. I will be sad if =
bitcoin doesn&#39;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.<br=
>
&gt; <br>
&gt; I don&#39;t see anything wrong with users paying 100x fees for opening=
 and closing LN channels.<br>
<br>
The PoW security of Bitcoin benefits all Bitcoin users, proportional to the=
<br>
value of BTC they hold; if Bitcoin blocks aren&#39;t reliably created the v=
alue of<br>
*all* BTC goes down. It doesn&#39;t make sense for the entire cost of that =
security<br>
to be paid for on a per-tx basis. And there&#39;s a high chance paying for =
it on a<br>
per-tx basis won&#39;t work anyway due to lack of consistent demand.<br>
<br>
It would be extremely unfortunate if one of the very few decentralized ways=
 to<br>
store value died simply because we couldn&#39;t find a way to pay to keep i=
t<br>
secure.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--00000000000073739a05e1d12022--