From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 74AACC002D for ; Mon, 6 Jun 2022 13:02:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 713EC83F7E for ; Mon, 6 Jun 2022 13:02:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=no autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpoVsZI2w7Bv for ; Mon, 6 Jun 2022 13:02:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by smtp1.osuosl.org (Postfix) with ESMTPS id F2C0983F78 for ; Mon, 6 Jun 2022 13:02:31 +0000 (UTC) Received: by mail-lf1-x134.google.com with SMTP id t25so23159508lfg.7 for ; Mon, 06 Jun 2022 06:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=EEsU2qfSXY1FQPwqT+vYaIzoah4VfEnKs4jftA3bbgA=; b=FxKBRnAFjm+HnXsoeeIMIHW/AYFQGuDJjQ2Ui9NlHTtuKnE56qG7AOBnAh8lWBszUB ip/kvJMeU5vltjUUpMmvcaI1PZu02WB29jNU34U2MHOikFgNxnsmskknq4tlmRdnmAbd zQLtMI67dVvbX+hHJEeHi82Q4hbDnJBtxQf5SxZgfKXBvsMuffVNMbewLCRIUTxaCSsj hTbaxpXYNZycF6GBwEZSwkdlJvYMhxjEU4RLFcYcmmtm7oKh8h6OG+X2M6qEeJDqSO0/ lA2xfdTW5RR2JHjLY5eNJ0of2mEFr7UYlk5D/rtr7lmREuOYqmLuuaaR8jBz3t/ZEeT0 IMHQ== 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=EEsU2qfSXY1FQPwqT+vYaIzoah4VfEnKs4jftA3bbgA=; b=G+4/z7Vk0936mrEocZRE0fiqCClgsMWVbrrq8y5Dqsmi9j69Y/n3yPEcHZIxlr9izR AmKDlOuvi6jpBk+cQcCrENi0OKSSBWOZS9Wjk8e1nGPGQqSy9A1qigSFZRWa204l845S 6PdTzpsptgyEbMbXtRSkwPGmzHW6iYl3H34PBj7LZK0yFD25lxNt+qcwkgcZy+LH5Db/ gc4igXFghhNhwfyucEa5/RbNDjoE30gQyl72CZayuhcapzbi1e8ztktdUDn6KqkPeIhP hK9VhozBgFwzRj1d5KYhKQJwzJdXrqrETM4g9uFcthSbBsq73KkvVoEhKJzvrcg/oqog 5v2w== X-Gm-Message-State: AOAM532UHKD1o/Fmz8gAj8/ttiGpj/oBNRhZk9YcNgfCh0C0stQSMI7x 0iFcVMkYJ1+v5G0clTKLMm19KkauMLXkCVtcGoPK5cQ= X-Google-Smtp-Source: ABdhPJwWK+gz5xMNt2w1TkXQ9THrw2IJlZSksuZwliddIgjt0ooXNPkCdrDTs01qxpogmxg9mcw2F/CZJfNq5Xsni6g= X-Received: by 2002:a05:6512:3f01:b0:46b:a5ba:3b89 with SMTP id y1-20020a0565123f0100b0046ba5ba3b89mr15279917lfa.28.1654520549541; Mon, 06 Jun 2022 06:02:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Mon, 6 Jun 2022 09:02:18 -0400 Message-ID: To: John Carvalho , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000a10a2905e0c7156e" X-Mailman-Approved-At: Mon, 06 Jun 2022 15:26:34 +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: Mon, 06 Jun 2022 13:02:33 -0000 --000000000000a10a2905e0c7156e Content-Type: text/plain; charset="UTF-8" Maintaining the security of the protocol is squarely the responsibility of the Bitcoin software and the core developers Continued demand for block space is critical for Bitcoin's security. Therefore it *is* the responsibility of Bitcoin software and core developers to maintain a continued demand for block space - which underpins the game-theoretical security of the protocol. While I'm personally confident that demand is still high, enough to reasonably secure the protocol, I do think that this is a matter not best left up to stern opinions. Whether covenant tech is essential for that security or not is a matter for simulations and proofs, not hype and speculation - on either side of the issue. On Sat, Jun 4, 2022 at 8:36 AM John Carvalho via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Core development is not a hackathon project. > > None of the quoted following items are features or responsibilities of the > Bitcoin software, nor Core developers. > > Quoted: > "- Developers can build interesting projects with real demand in market. > - Students learn Sapio and not just solidity. > - Better tooling could be available for application developers. > - Maybe we see bitcoin developer hackathons in different countries. > - Demand for block space might increase, it wont be just exchanges and > coinjoin. > - Funding of bitcoin developers and projects might improve. Wont need to > convince a few people for grants." > > Whether you are a child or an attacker, none of us should care, but CTV, > nor any change to Bitcoin software, will never be justifiable simply > because you and some of your friends think it is totally cool and might > make more people like you or give your friends funding. > > Please stop making noise about CTV, this is not a place for spamming. > > -- > John Carvalho > > > > On Sat, Jun 4, 2022 at 1:00 PM < > bitcoin-dev-request@lists.linuxfoundation.org> wrote: > >> >> Date: Fri, 03 Jun 2022 18:39:34 +0000 >> From: alicexbt >> To: Bitcoin Protocol Discussion >> >> Subject: [bitcoin-dev] Bitcoin covenants are inevitable >> Message-ID: >> >> > protonmail.com> >> >> Content-Type: text/plain; charset=utf-8 >> >> Note: This email is an opinion and not an attack on bitcoin >> >> Covenants on bitcoin will eventually be implemented with a soft fork. CTV >> is the easiest and best possible way OP_TX looks good as well. Apart from >> the technical merits, covenants will improve a few other things: >> >> - Developers can build interesting projects with real demand in market. >> - Students learn Sapio and not just solidity. >> - Better tooling could be available for application developers. >> - Maybe we see bitcoin developer hackathons in different countries. >> - Demand for block space might increase, it wont be just exchanges and >> coinjoin. >> - Funding of bitcoin developers and projects might improve. Wont need to >> convince a few people for grants. >> >> **Why covenants are not contentious?** >> >> Some people may write paragraphs about CTV being contentious, spread >> misinformation and do all types of drama, politics etc. on social media but >> there are zero technical NACKs for CTV. We have discussed other covenant >> proposals in detail on mailing list and IRC meetings with an open minded >> approach. >> >> All the developers that participated in the discussion are either okay >> with CTV or OP_TX or covenants in general. >> >> **How and when should covenants be implemented in Bitcoin?** >> >> I don't think we should wait for years anticipating a proposal that >> everyone will agree on or argue for years to pretend changes are hard in >> Bitcoin. We should improve the review process for soft fork BIPs and share >> honest opinions with agreement, disagreement on technical merits. >> >> I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything >> else being used if that improves Bitcoin. Covenants implemented in Bitcoin >> before the next cycle would provide opportunity for developers to build >> interesting things during the bear market. Ossification supporters also >> believe there is some window that will close soon, maybe doing changes >> considering each case individually will be a better approach. CTV is not a >> rushed soft fork, less people followed the research and it was not >> mentioned on social media repeatedly by the respected developers like other >> soft forks. >> >> /dev/fd0 >> >> >> Sent with Proton Mail secure email. >> >> >> ------------------------------ >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000a10a2905e0c7156e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Maintaining the=C2=A0security of the protocol is squa= rely the responsibility of the Bitcoin=C2=A0software and the core developer= s

Continued demand for block space is critical= for Bitcoin's security.=C2=A0 =C2=A0

Therefore=C2=A0= it *is* the responsibility of Bitcoin software and core developers to maint= ain a continued demand for block space - which underpins the game-theoretic= al security of the protocol.

While I'm personally con= fident that demand is still high, enough to reasonably secure the protocol,= I do think that this is a matter not best left up to stern opinions.=C2=A0= =C2=A0Whether covenant tech is essential for that security or not is a mat= ter for simulations and proofs, not hype and speculation - on either side o= f the issue.


On Sat, Jun 4, 2022 at 8:36 AM John Carval= ho via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Core development is not a hackathon project.

= None of the quoted following items are features=C2=A0or responsibilities=C2= =A0of the Bitcoin software, nor Core developers.=C2=A0

=
Quoted:
"- Developers can build interesting projects wi= th real demand in market.
- Students learn Sapio and not just solidity.<= br>- Better tooling could be available for application developers.
- May= be we see bitcoin developer hackathons in different countries.
- Demand = for block space might increase, it wont be just exchanges and coinjoin.
= - Funding of bitcoin developers and projects might improve. Wont need to co= nvince a few people for grants."

<= div>Whether you are a child or an attacker, none of us should care, but CTV= , nor any change to Bitcoin software, will never be justifiable=C2=A0simply= because you and some of your friends think it is totally cool and might ma= ke more people like you or give your friends funding.

<= div>Please stop making noise about CTV, this is not a place for spamming.

--
John= Carvalho



On Sa= t, Jun 4, 2022 at 1:00 PM <bitcoin-dev-request@lists.linuxfounda= tion.org> wrote:

Date: Fri, 03 Jun 2022 18:39:34 +0000
From: alicexbt <alicexbt@protonmail.com>
To: Bitcoin Protocol Discussion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <bitcoin-dev@lists.linuxfoundation.org&g= t;
Subject: [bitcoin-dev] Bitcoin covenants are inevitable
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <QOWIpROGDv5HHP2GsDiSOsTJ9TVZhFeSP3C03_e2Z3X= tOKC_4N5GJtxbdlxuhErvhLZXo1Rn_7SWAQ9XRPwHFuYyArZryTVENefDZuGTAYA=3D@protonmail.= com>

Content-Type: text/plain; charset=3Dutf-8

Note: This email is an opinion and not an attack on bitcoin

Covenants on bitcoin will eventually be implemented with a soft fork. CTV i= s the easiest and best possible way OP_TX looks good as well. Apart from th= e technical merits, covenants will improve a few other things:

- Developers can build interesting projects with real demand in market.
- Students learn Sapio and not just solidity.
- Better tooling could be available for application developers.
- Maybe we see bitcoin developer hackathons in different countries.
- Demand for block space might increase, it wont be just exchanges and coin= join.
- Funding of bitcoin developers and projects might improve. Wont need to co= nvince a few people for grants.

**Why covenants are not contentious?**

Some people may write paragraphs about CTV being contentious, spread misinf= ormation and do all types of drama, politics etc. on social media but there= are zero technical NACKs for CTV. We have discussed other covenant proposa= ls in detail on mailing list and IRC meetings with an open minded approach.=

All the developers that participated in the discussion are either okay with= CTV or OP_TX or covenants in general.

**How and when should covenants be implemented in Bitcoin?**

I don't think we should wait for years anticipating a proposal that eve= ryone will agree on or argue for years to pretend changes are hard in Bitco= in. We should improve the review process for soft fork BIPs and share hones= t opinions with agreement, disagreement on technical merits.

I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anythin= g else being used if that improves Bitcoin. Covenants implemented in Bitcoi= n before the next cycle would provide opportunity for developers to build i= nteresting things during the bear market. Ossification supporters also beli= eve there is some window that will close soon, maybe doing changes consider= ing each case individually will be a better approach. CTV is not a rushed s= oft fork, less people followed the research and it was not mentioned on soc= ial media repeatedly by the respected developers like other soft forks.

/dev/fd0


Sent with Proton Mail secure email.


------------------------------
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000a10a2905e0c7156e--