public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Lucky Star <lucky.star.shines@protonmail•com>
To: "bitcoin-dev@lists•linuxfoundation.org"
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
Date: Mon, 14 Feb 2022 02:40:52 +0000	[thread overview]
Message-ID: <Rd1DAa50Zv6-lDMdPIioT91d0ObBy8rEpWVEDxA0uFReDsx7FzYMqCnllMSSwJ7I4Y8m6u-WaQBT0IcwGQcB-ytjNxZOoqcr4JohISchxX0=@protonmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2198 bytes --]

Hello,

I'm opposed to recursive covenants because they allow the government to _gradually_ restrict all bitcoins.

Without covenants, other miners can fork to a free blockchain, if the government tells miners each transaction to be added in the block. Thus the government cannot impose desires on the Bitcoin community. With covenants, the government gradually forces all companies to use the permissible covenants. There is no free blockchain, and the government controls more bitcoins each day.

Bitcoin experts Greg Maxwell and Peter Todd explained this reason and many others on the forum.[1] More experts also agreed, and it's common knowledge. I strongly recommend to support the OP_CHECKTEMPLATEVERIFY. It is well reviewed, and it protects the Bitcoin community from the bad effects of covenants. With OP_CHECKTEMPLATEVERIFY, we achieve the best of both worlds.

With best regards,
Lucky Star

[1] Maxwell, Greg. "CoinCovenants using SCIP signatures, an amusingly bad idea." https://bitcointalk.org/index.php?topic=278122.0;all

> On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev wrote:
> > Whether [recursive covenants] is an issue or not precluding this sort
> > of design or not, I defer to others.
>
>
> For reference, I believe the last time the merits of allowing recursive
> covenants was discussed at length on this list[1], not a single person
> replied to say that they were opposed to the idea.
>
>
> I would like to suggest that anyone opposed to recursive covenants speak
> for themselves (if any intelligent such people exist). Citing the risk
> of recursive covenants without presenting a credible argument for the
> source of that risk feels to me like (at best) stop energy[2] and (at
> worst) FUD.
>
>
> -Dave
>
>
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html
> [2] http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html
> (thanks to AJ who told me about stop energy one time when I was
> producing it)
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 5765 bytes --]

             reply	other threads:[~2022-02-14  2:41 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-14  2:40 Lucky Star [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-02-26  7:47 Prayank
2022-02-26 16:18 ` Billy Tetrud
2022-01-26 17:20 [bitcoin-dev] " Russell O'Connor
2022-02-08  3:40 ` Rusty Russell
2022-02-08  4:34   ` Jeremy Rubin
2022-02-11  0:55     ` [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was " David A. Harding
2022-02-11  3:42       ` Jeremy Rubin
2022-02-11 17:42       ` James O'Beirne
2022-02-11 18:12         ` digital vagabond
2022-02-12 10:54           ` darosior
2022-02-12 15:59             ` Billy Tetrud
2022-02-17 15:15           ` Anthony Towns
2022-02-18  7:34       ` ZmnSCPxj
2022-02-23 11:28       ` ZmnSCPxj
2022-02-23 18:14         ` Paul Sztorc
2022-02-24  2:20           ` ZmnSCPxj
2022-02-24  6:53         ` Anthony Towns
2022-02-24 12:03           ` ZmnSCPxj
2022-02-26  5:38             ` Billy Tetrud
2022-02-26  6:43               ` ZmnSCPxj
2022-02-27  0:58                 ` Paul Sztorc
2022-02-27  2:00                   ` ZmnSCPxj
2022-02-27  7:25                     ` ZmnSCPxj
2022-02-27 16:59                       ` Billy Tetrud
2022-02-27 23:50                         ` Paul Sztorc
2022-02-28  0:20                     ` Paul Sztorc
2022-02-28  6:49                       ` ZmnSCPxj
2022-02-28  7:55                         ` vjudeu
2022-03-04  8:42                           ` ZmnSCPxj
2022-03-04 13:43                             ` vjudeu
2022-02-28 22:54                         ` Paul Sztorc
2022-03-01  5:39                           ` Billy Tetrud
2022-03-02  0:00                             ` Paul Sztorc
2022-03-04 12:35                               ` Billy Tetrud
2022-03-04 20:06                                 ` Paul Sztorc
2022-02-26  6:00             ` Anthony Towns

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='Rd1DAa50Zv6-lDMdPIioT91d0ObBy8rEpWVEDxA0uFReDsx7FzYMqCnllMSSwJ7I4Y8m6u-WaQBT0IcwGQcB-ytjNxZOoqcr4JohISchxX0=@protonmail.com' \
    --to=lucky.star.shines@protonmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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