Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
3 messages, 14 to 26 Feb 2022. Started by Lucky Star.
Lucky Star, Prayank, Billy Tetrud
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
Quoted text (30 lines)
> 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
Good morning ZmnSCPxj,
Quoted text (1 line)
> Of course, I know of no such technique, but given that a technique (Drivechains) which before would have required its own consensus change, turns out to be implementable inside recursive covenants, then I wonder if there are other things that would have required their own consensus change that are now *also* implementable purely in recursive covenants.
Agree. I would be interested to know what is NOT possible once we have recursive covenants.
Quoted text (1 line)
> if there is *now* consensus that Drivechains are not bad, go ahead, add recursive covenants (but please can we add `SIGHASH_NOINPUT` and `OP_CTV` first?)
Agree and I think everything can be done in separate soft forks.
Quoted text (1 line)
> If Drivechains are bad for whatever reason, we should not add recursive
covenants.
Bad "for who" was the crux of my question to you. Even if drivechains are always bad for their users, I don't think that's a good enough reason to block things that could allow people to build user-space drivechains, as long as it doesn't negatively affect normal Bitcoin users.
Quoted text (1 line)
> Drivechains are not a scaling solution
I generally agree, more of a laboratory where many things (including scaling solutions) can be tested.
Quoted text (1 line)
> Principle of Least Power.
A concern is that, since it turns out recursive covenants are sufficient to implement Drivechains, recursive covenants may also enable *other* techniques, currently unknown, which may have negative effects on Bitcoin, or which would be considered undesirable by a significant section of the userbase.
I think the principle of least power is a good one, but it cannot be dogma. I think your point about unknown consequences is reasonable and a study on that kind of thing would be quite valuable. The community has discussed it multiple times in the past, and so at least some thought has gone into it, with nothing very strong in opposition that I know of. Has anyone made a good summary/study of the kinds of things recursive covenants allows?
On Sat, Feb 26, 2022, 02:35 Prayank via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (31 lines)
> Good morning ZmnSCPxj, > > > Of course, I know of no such technique, but given that a technique > (Drivechains) which before would have required its own consensus change, > turns out to be implementable inside recursive covenants, then I wonder if > there are other things that would have required their own consensus change > that are now *also* implementable purely in recursive covenants. > > > Agree. I would be interested to know what is NOT possible once we have > recursive covenants. > > > if there is *now* consensus that Drivechains are not bad, go ahead, add > recursive covenants (but please can we add `SIGHASH_NOINPUT` and `OP_CTV` > first?) > > > Agree and I think everything can be done in separate soft forks. > > > > > -- > Prayank > > A3B1 E430 2298 178F > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >