From: Erik Aronesty <erik@q32.com>
To: John Carvalho <john@synonym.to>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
Date: Mon, 6 Jun 2022 09:02:18 -0400 [thread overview]
Message-ID: <CAJowKgJ8GP4Ykzn5dMHZ7wsE04YmpOLgTpdc9tgfVng0qB0Jjg@mail.gmail.com> (raw)
In-Reply-To: <CAHTn92zw_MaSKWiZGhGFqFYXJxv6kQ+7=XCHbRLim1jhtEsVVQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4878 bytes --]
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 <alicexbt@protonmail.com>
>> To: Bitcoin Protocol Discussion
>> <bitcoin-dev@lists.linuxfoundation.org>
>> Subject: [bitcoin-dev] Bitcoin covenants are inevitable
>> Message-ID:
>>
>> <QOWIpROGDv5HHP2GsDiSOsTJ9TVZhFeSP3C03_e2Z3XtOKC_4N5GJtxbdlxuhErvhLZXo1Rn_7SWAQ9XRPwHFuYyArZryTVENefDZuGTAYA=@
>> 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
>
[-- Attachment #2: Type: text/html, Size: 6450 bytes --]
next prev parent reply other threads:[~2022-06-06 13:02 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.9.1654344003.14400.bitcoin-dev@lists.linuxfoundation.org>
2022-06-04 12:27 ` [bitcoin-dev] Bitcoin covenants are inevitable John Carvalho
2022-06-04 13:48 ` Keagan McClelland
2022-06-04 16:12 ` alicexbt
2022-06-06 13:02 ` Erik Aronesty [this message]
2022-06-12 3:36 ` Peter Todd
2022-06-12 13:02 ` Erik Aronesty
2022-06-12 16:35 ` Corey Haddad
2022-06-12 19:16 ` alicexbt
2022-06-19 10:31 ` Peter Todd
2022-06-19 15:54 ` Manuel Costa
2022-06-19 18:26 ` Kate Salazar
2022-06-19 22:35 ` Erik Aronesty
2022-06-21 19:00 ` Keagan McClelland
2022-06-21 20:10 ` Eric Voskuil
2022-06-23 19:17 ` Peter Todd
2022-06-28 3:55 ` Billy Tetrud
2022-06-28 16:23 ` Alex Lee
2022-06-28 23:22 ` Peter Todd
2022-06-29 5:02 ` Alex Lee
2022-06-28 23:20 ` Peter Todd
2022-06-29 10:44 ` Kate Salazar
2022-06-30 15:25 ` Billy Tetrud
2022-07-03 9:43 ` Peter Todd
2022-07-03 10:30 ` Giuseppe B
2022-07-06 4:28 ` Corey Haddad
2022-07-06 11:10 ` vjudeu
2022-07-07 0:46 ` Billy Tetrud
2022-07-07 12:15 ` vjudeu
2022-07-07 14:05 ` Erik Aronesty
2022-07-07 14:10 ` Giuseppe B
2022-07-08 5:03 ` Billy Tetrud
2022-06-30 17:04 ` Erik Aronesty
[not found] <mailman.9.1657195203.20624.bitcoin-dev@lists.linuxfoundation.org>
2022-07-07 13:24 ` John Carvalho
2022-07-07 14:12 ` Peter Todd
2022-07-07 16:24 ` Eric Voskuil
2022-07-07 17:37 ` Erik Aronesty
2022-07-07 19:57 ` Eric Voskuil
2022-07-07 21:11 ` Erik Aronesty
2022-07-08 0:28 ` Eric Voskuil
2022-07-08 4:59 ` vjudeu
2022-07-08 7:26 ` John Carvalho
2022-07-08 15:14 ` Erik Aronesty
2022-07-14 4:55 ` Billy Tetrud
2022-07-07 22:06 ` Anthony Towns
2022-07-07 22:02 ` Corey Haddad
2022-06-03 18:39 alicexbt
2022-06-04 0:29 ` micaroni
2022-06-04 18:43 ` Jorge Timón
2022-06-05 4:18 ` alicexbt
2022-06-08 3:51 ` Billy Tetrud
2022-06-08 9:22 ` Jorge Timón
2022-06-09 4:30 ` Billy Tetrud
2022-06-09 0:03 ` Ryan Grant
2022-07-19 4:44 ` Anthony Towns
2022-07-19 14:46 ` alicexbt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJowKgJ8GP4Ykzn5dMHZ7wsE04YmpOLgTpdc9tgfVng0qB0Jjg@mail.gmail.com \
--to=erik@q32.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=john@synonym.to \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox