Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[Greg Sanders via bitcoin-dev]

Ironically assumptions of bad faith are going to kill any proposal,
resulting in the status quo.

Let's keep the assumption of good faith, unless you are actually accusing
people of being a NSA-adjacent asset.

On Thu, Apr 21, 2022 at 10:08 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There are a number of individuals who have stated opposition to attempting
> to activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
>
> sheshek found some issues with the list and some of them are not really an
> opposition for CTV. Others do not have any technical details to consider.
>
> The saddest thing is that if Jeremy's soft fork activation attempt causes
> the uncertainty, confusion and disruption I fear it could it will make
> future soft forks that do have community consensus orders of magnitude
> harder to pull off.
>
>
>
> Calling CTV an attack on bitcoin or doing personal attacks on Jeremy and
> other developers on social media that support CTV won't help. Developers
> should be free to propose improvements and write code. Users can decide if
> they want to run this code. Just because someone is opposing a change and
> prefers status quo does not mean it is better for Bitcoin. Attackers have
> used such things in past for many open source projects.
>
> Example: Someone signed up on the Tor Project mailing list and then
> participated in discussions to advocate against the removal of malicious
> servers
>
> https://nitter.net/campuscodi/status/1466748897003544579
>
>
> dev/fd0
>
> Sent with ProtonMail  secure email.
>
> --- Original Message ---
> On Wednesday, April 20th, 2022 at 6:54 PM, Michael Folkson via bitcoin-dev
>  wrote:
>
> > The client has a Speedy trial release similar to Taproots with
> parameters proposed to be
>
> As I've said before I was hoping we'd avoid this exercise. Best case, it
> wastes the time of people who could be working on all sorts of valuable
> projects for the ecosystem. Worst case, we take a Russian roulette style
> gamble with a chain split.
>
> But here's a summary of the basic facts:
>
> The latest Bitcoin Core release candidate (23.0) does not contain any new
> soft fork code, either CTV code or any new activation code. Running Bitcoin
> Core 23.0 out the box will not signal for any new soft fork and will not
> enforce any new soft fork rules (CTV or otherwise). Of course it will
> continue to enforce Taproot rules as Taproot activated last year.
>
> There are a number of individuals who have stated opposition to attempting
> to activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> Most of those individuals haven't logged their opposition on Jeremy's site:
> https://utxos.org/signals/
>
> Hence their views haven't been included or discussed in Jeremy's latest
> blog post.
>
> Chain split risk
>
> I can't predict how many full nodes and miners will run Jeremy's client
> attempting to activate CTV. One would expect that many will continue to run
> versions of Bitcoin Core that will not enforce CTV rules and will not
> activate it. But whether Jeremy's client will be a majority, significant
> minority, insignificant minority of full nodes and miners would be
> speculation on my part. (Personally I highly doubt those running Jeremy's
> client will be a majority which leaves a significant minority and
> insignificant minority as the most likely options).
>
> Jeremy's client is intending to use Speedy Trial presumably with similar
> parameters to that used for Taproot. That would mean seeking 90 percent of
> miners to signal for this CTV soft fork activation attempt.
>
> Assuming 90 percent of miners don't signal for it in one of the Speedy
> Trial windows then the activation attempt will have failed and it will be
> back in Jeremy's court whether he tries again with a different activation
> attempt.
>
> Assuming 90 percent of miners do signal for it (unlikely in my opinion but
> presumably still a possibility) then the CTV soft fork could activate
> unless full nodes resist it. This resistance would most likely be in the
> form of a UASF style client which rejects blocks that apply the CTV rules
> and/or includes transactions that don't meet the CTV rules post activation.
> We would now be in chain split territory with two different assets and
> blockchains like we had with BTC and BCH.
>
> If I oppose this activation attempt and the associated chain split risk
> what should I do?
>
> Firstly, you can register your opposition to this soft fork activation
> attempt on Jeremy's site: https://utxos.org/signals/
>
> It seems Jeremy will continue this activation attempt regardless but it
> will be useful for others to see clearly that this a contentious soft fork
> activation attempt and act accordingly. So far only 3 individuals'
> opposition is registered on his site.
>
> 

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[alicexbt via bitcoin-dev]

> There are a number of individuals who have stated opposition to attempting to 
> activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718

sheshek found some issues with the list and some of them are not really an 
opposition for CTV. Others do not have any technical details to consider.

> The saddest thing is that if Jeremy's soft fork activation attempt causes the 
> uncertainty, confusion and disruption I fear it could it will make future 
> soft forks that do have community consensus orders of magnitude harder to 
> pull off.

Calling CTV an attack on bitcoin or doing personal attacks on Jeremy and other 
developers on social media that support CTV won't help. Developers should be 
free to propose improvements and write code. Users can decide if they want to 
run this code. Just because someone is opposing a change and prefers status quo 
does not mean it is better for Bitcoin. Attackers have used such things in past 
for many open source projects.

Example: Someone signed up on the Tor Project mailing list and then 
participated in discussions to advocate against the removal of malicious servers

https://nitter.net/campuscodi/status/1466748897003544579

dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.

--- Original Message ---
On Wednesday, April 20th, 2022 at 6:54 PM, Michael Folkson via bitcoin-dev 
 wrote:

>> The client has a Speedy trial release similar to Taproots with parameters 
>> proposed to be
>
> As I've said before I was hoping we'd avoid this exercise. Best case, it 
> wastes the time of people who could be working on all sorts of valuable 
> projects for the ecosystem. Worst case, we take a Russian roulette style 
> gamble with a chain split.
>
> But here's a summary of the basic facts:
>
> The latest Bitcoin Core release candidate (23.0) does not contain any new 
> soft fork code, either CTV code or any new activation code. Running Bitcoin 
> Core 23.0 out the box will not signal for any new soft fork and will not 
> enforce any new soft fork rules (CTV or otherwise). Of course it will 
> continue to enforce Taproot rules as Taproot activated last year.
>
> There are a number of individuals who have stated opposition to attempting to 
> activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> Most of those individuals haven't logged their opposition on Jeremy's site:
> https://utxos.org/signals/
>
> Hence their views haven't been included or discussed in Jeremy's latest blog 
> post.
>
> Chain split risk
>
> I can't predict how many full nodes and miners will run Jeremy's client 
> attempting to activate CTV. One would expect that many will continue to run 
> versions of Bitcoin Core that will not enforce CTV rules and will not 
> activate it. But whether Jeremy's client will be a majority, significant 
> minority, insignificant minority of full nodes and miners would be 
> speculation on my part. (Personally I highly doubt those running Jeremy's 
> client will be a majority which leaves a significant minority and 
> insignificant minority as the most likely options).
>
> Jeremy's client is intending to use Speedy Trial presumably with similar 
> parameters to that used for Taproot. That would mean seeking 90 percent of 
> miners to signal for this CTV soft fork activation attempt.
>
> Assuming 90 percent of miners don't signal for it in one of the Speedy Trial 
> windows then the activation attempt will have failed and it will be back in 
> Jeremy's court whether he tries again with a different activation attempt.
>
> Assuming 90 percent of miners do signal for it (unlikely in my opinion but 
> presumably still a possibility) then the CTV soft fork could activate unless 
> full nodes resist it. This resistance would most likely be in the form of a 
> UASF style client which rejects blocks that apply the CTV rules and/or 
> includes transactions that don't meet the CTV rules post activation. We would 
> now be in chain split territory with two different assets and blockchains 
> like we had with BTC and BCH.
>
> If I oppose this activation attempt and the associated chain split risk what 
> should I do?
>
> Firstly, you can register your opposition to this soft fork activation 
> attempt on Jeremy's site: https://utxos.org/signals/
>
> It seems Jeremy will continue this activation attempt regardless but it will 
> be useful for others to see clearly that this a contentious soft fork 
> activation attempt and act accordingly. So far only 3 individuals' opposition 
> is registered on his site.
>
> Secondly, if it is looking like 90 percent (or whatever percentage Jeremy 
> uses) of miners are going to signal for a CTV soft fork then you can consider 
> joining a UASF style effort to resist the soft fork activation attempt. I 
> will certainly seek to participate and will continue to inform this list of 
> efforts in this 

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[Zac Greenwood via bitcoin-dev]

On Wed, 20 Apr 2022 at 15:49, Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

Assuming 90 percent of miners don't signal for it in one of the Speedy
> Trial windows then the activation attempt will have failed and it will be
> back in Jeremy's court whether he tries again with a different activation
> attempt.
>
> Assuming 90 percent of miners do signal for it (unlikely in my opinion but
> presumably still a possibility) then the CTV soft fork could activate
> unless full nodes resist it.
>

This is wrong. Miners do not have the mandate to decide the faith of
softforks. The MO of softforks is that once a softfork has been merged, it
already has consensus and must be activated by miners eventually. The
various activation methods exist to ensure miners cannot sabotage a
softfork that has consensus.

The way you phrase it, makes it sound like miners have any say over
softforks. This is not the case.

Zac

>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[Robin Linus via bitcoin-dev]

Hi Michael,

Sorry, if my critique of your opinions feels too personal to you. This is 
nothing personal. As you probably know, one of the most effective attack 
vectors on Bitcoin is to target the social layer by sabotaging the protocol 
development[1]. Bike shedding is an easy way to cause a lot of harm.
This is why it is hard to distinguish your radical opinions from an 
(unintended) attack. So, we cannot simply trust you. In particular because you 
contribute so much time criticising the activation of CTV, while you also 
refuse to spend any time working on activating covenants. You just want to 
stall the activation of covenants indefinitely. An attacker would act the same.
Another red flag is that you are trying to downplay how many reputable 
community members have already signalled their support for CTV 
https://utxos.org/signals/ . You keep framing it as if there was only that one 
crazy guy trying to push an immature and risky consensus change. In fact, it is 
well reviewed and many people support CTV because it is the most conservative 
step forwards and it is ready for activation now.
You are alarmed by what you call a "contentious" soft fork while actually you 
are yourself by far the most vocal opponent of this fork. You are even 
threatening to cause a chain split while you're also warning others that your 
chain split would become a big issue. Since we're talking about a soft fork 
here you're basically saying that you want to make your node reject valid 
blocks. I doubt that anyone opposes CTV as extremely as you do. In particular 
because your strongest argument is that CTV might not be ideal for all use 
cases, which is trivially true for every protocol upgrade. An attacker would 
act the same.

All in all, it is very hard to distinguish your strong desire to stall the 
development from an attack. This is why we have to question your motives 
thoroughly. Again, this is nothing personal. It's just that you are very 
critical of people who support activation of CTV and thus, you should expect 
others to be just as critical of your opinions. Isn't that fair?

Regards,
Robin

[1] https://twitter.com/peterktodd/status/1495796670440919056

--- Original Message ---
On Thursday, April 21st, 2022 at 12:04 AM, Michael Folkson 
 wrote:

> Ok last one. Whatever you say and whatever personal attacks you come up with 
> I'm not responding after this one :)
>
>> Where can I see the use cases you have built out in recent years? Do you 
>> have a writeup in which you compare CTV to existing covenant enabling 
>> proposals? Do you have a strong reason to favour a different proposal? Have 
>> you written any code?
>
> You don't seem to quite understand the asymmetry here. I (and the rest of the 
> community excluding Jeremy) am not a full time CTV developer or full time CTV 
> advocate. There are a number of soft fork proposals I am interested in and 
> attempting to follow in addition to all the work that is going around Taproot 
> etc. But if you/Jeremy want to make a change to the consensus rules the onus 
> is on you to get community review and community consensus. I am not demanding 
> the consensus rules be changed. I am quite happy to wait until there is 
> community consensus over a particular soft fork like there was with Taproot.
>
> I have looked into CTV a considerable number of times now. I have asked 5 of 
> the 6 CTV related questions on Bitcoin StackExchange at the time of writing 
> [1], 2 of which I have attempted to answer. Does this mean I understand as 
> much about Jeremy about CTV? Of course not. But if you believe that soft 
> forks should have community consensus it is up to you/Jeremy to address 
> concerns from curious, relatively informed, skeptical people like me. I am 
> not convinced at the time of writing that CTV is the best tool for the job on 
> any of its intended use cases. On this I don't think even Jeremy is convinced 
> as when asked to compare CTV to alternatives he often just says it is ready 
> and other proposals aren't.
>
>> In contrast, Jeremy has been doing exactly what you are proposing. He wrote 
>> the BIP, implemented it, explained use cases in detail, spoke at 
>> conferences, organised workshops, and built the Sapio framework for the 
>> community to experiment with covenants. He even puts his money where his 
>> mouth is and offers a bug bounty for any security flaw in the code.
>
> I'm not entirely sure where you are going with this. That because Jeremy has 
> worked really hard on it for a long time we should activate it without 
> community consensus? I'm sorry that's not how consensus changes work or how 
> they should work. Personally I very much doubt I will ever attempt to change 
> the consensus rules with one of my proposals. I struggle to follow all of the 
> work and the proposals others work on and at least for now believe others are 
> much more qualified than me to design and code up consensus code changes. So 
> again there is an 

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[Billy Tetrud via bitcoin-dev]

Hi Michael,

I'm sympathetic to the idea of allowing time for the community to absorb,
review, analyze, discuss, etc any new substantial change to bitcoin,
especially consensus changes. I certainly think that over time the
frequency of soft forks should generally go down on average, with
ossification at some point being the ideal endpoint (perhaps in the next
10-20 years).

However, many of the messages of opposition/caution seem to imply that
analysis of a consensus change can't begin until the last change has been
completed. This is quite clearly not the case. And as far as I can tell the
CTV spec was functionally completed *before* the taproot spec was (sometime
in early 2020).

Jeremy included a nice list of "ticked boxes" that are all indicators of
maturity of not only the spec but implementations and testing. I would
expect any considered opposition to CTV to at least address that checklist,
but you did not.

I think it would be interesting to compare the state of CTV now with the
state of taproot when activation. One example is that Taproot had been on
Signet for about 1 month

before
consensus developed 
in support of pulling the trigger on a softfork for taproot. CTV has had a
signet running for almost twice that long already if not longer. So
Michael, what do you think is missing from Jeremy's checklist? Where do you
think the checklist fails to meet your ideal bar of acceptance?

Not only that but CTV is a simpler change than taproot. I assume you'd
agree that a simpler change should require correspondingly less
review/analysis/etc, right? If not, I'd appreciate it if you could comment
as to why.

> There are a number of individuals who have stated opposition to
attempting to activate a CTV soft fork in the near term

As Jeremy has noted, none of these indicate or suspect any technical issues
in CTV. Basically all of them are basically saying "too soon" without much
concrete reasons. I believe in consensus weighted by quality-of-logic, and
most of the ones in your list do not contain any supported logic at all.
Many are borderline ad hominems at Jeremy. So to me, most hold little
weight. The ones with some logic included seem to basically be "I'm not
involved enough to know or knowledgeable enough to review, and therefore
I'm hesitant". Now to be fair, many of the acks listed in Jeremy's also
hold little weight to me for the same reasons, with a few exceptions like Bram
Cohen's discussion
 and a Corenell
paper . But there's clearly been quite a
bit of review on the PR  as
well. By contrast I've seen literally no opposition to CTV based on the
proposal at all.

With regards to the idea that more time is needed to review/discuss. I
wonder if any of those opposed to near term speedy trial of CTV plan on
doing a deeper review/exploration of it in the next year? If not, then what
will delaying do? Are these people simply waiting to see more people in
their social bubble becomes familiar and comfortable with CTV?

> I have a better (and safer) way forward which is to continue to build out
use cases of CTV, convince the community it is the best tool for the job
(whatever use case(s) that is), compare it to other existing covenant
enabling proposals

While I think this is a more valid position to take than your other points,
I disagree with it. I am also sympathetic to the idea that alternatives
should be evaluated and the best one at hand should be chosen. However, it
is a simple fact that the "best" solution possible is almost never going to
be found or created, even after absurd amounts of time (eg millenia). We
live in a time bound world, with time bound human lives. I assume you've
heard of the phrase "don't let the perfect become the enemy of the good". I
assert that your argument is to do just that: to make the perfect become
the enemy of the good.

There is some trade off between time to usage (think time to market) and
the quality of the solution. We didn't choose taproot because it was the
best possible solution, we chose it because it was a pretty good solution
and the solution we had. Yes alternatives have been discussed (at least
since 2013), but alternatives to CTV have also been discussed (eg OP_CAT)
for probably just as long. There have been a number of random
back-of-the-napkin alternative proposals to CTV. None have gained anything
resembling support. I proposed one of them

myself. And I certainly agree that CTV isn't perfect and doesn't do
everything I want it to do. But despite this, I think having CTV is better
than not having it. Even if its eventually mostly replaced by some more
complex 

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[Michael Folkson via bitcoin-dev]

Ok last one. Whatever you say and whatever personal attacks you come up with 
I'm not responding after this one :)

> Where can I see the use cases you have built out in recent years? Do you have 
> a writeup in which you compare CTV to existing covenant enabling proposals? 
> Do you have a strong reason to favour a different proposal? Have you written 
> any code?

You don't seem to quite understand the asymmetry here. I (and the rest of the 
community excluding Jeremy) am not a full time CTV developer or full time CTV 
advocate. There are a number of soft fork proposals I am interested in and 
attempting to follow in addition to all the work that is going around Taproot 
etc. But if you/Jeremy want to make a change to the consensus rules the onus is 
on you to get community review and community consensus. I am not demanding the 
consensus rules be changed. I am quite happy to wait until there is community 
consensus over a particular soft fork like there was with Taproot.

I have looked into CTV a considerable number of times now. I have asked 5 of 
the 6 CTV related questions on Bitcoin StackExchange at the time of writing 
[1], 2 of which I have attempted to answer. Does this mean I understand as much 
about Jeremy about CTV? Of course not. But if you believe that soft forks 
should have community consensus it is up to you/Jeremy to address concerns from 
curious, relatively informed, skeptical people like me. I am not convinced at 
the time of writing that CTV is the best tool for the job on any of its 
intended use cases. On this I don't think even Jeremy is convinced as when 
asked to compare CTV to alternatives he often just says it is ready and other 
proposals aren't.

> In contrast, Jeremy has been doing exactly what you are proposing. He wrote 
> the BIP, implemented it, explained use cases in detail, spoke at conferences, 
> organised workshops, and built the Sapio framework for the community to 
> experiment with covenants. He even puts his money where his mouth is and 
> offers a bug bounty for any security flaw in the code.

I'm not entirely sure where you are going with this. That because Jeremy has 
worked really hard on it for a long time we should activate it without 
community consensus? I'm sorry that's not how consensus changes work or how 
they should work. Personally I very much doubt I will ever attempt to change 
the consensus rules with one of my proposals. I struggle to follow all of the 
work and the proposals others work on and at least for now believe others are 
much more qualified than me to design and code up consensus code changes. So 
again there is an asymmetry if you are going down the comparing Jeremy's goals 
with my own.

> I think by framing his contributions as "immature" you are disrespecting all 
> the work he put into BIP-119.

I think CTV is an immature proposal given what I've said already about it not 
being at all clear it is the best tool for any of its intended use cases.

> If you are not willing to do what you are suggesting for years why should 
> anybody else do it? Should the entire community stall progress on covenants 
> until somebody else works on what you think is ideal?

Others are currently working on alternative proposals to CTV (CAT, CSFS, TLUV, 
Simplicity, arguably APO depending on the use case etc). I haven't asked them 
to, they already are. As far as I know (they can correct me if wrong) those 
working on alternative proposals don't support an upcoming activation of CTV. 
You can try to make this personal all you want and write snide comments if it 
makes you feel better. But I doubt it is the right approach to getting more 
review of a soft fork proposal.

> Bike shedding is just as big of an issue as "contentious soft forks". 
> Pointless activation drama is a huge issue of bitcoin protocol development 
> because it is so draining. Some of the most respected devs do not participate 
> in activation politics anymore because it harms their health. That's nuts. If 
> you really want to be of service to the Bitcoin community you should work on 
> what you think is the right path forward and not just criticise Jeremy for 
> progressing with his excellent work.

If you have a magic wand to wave away activation drama and create an activation 
method that the entire community is happy with I'd love to see it. That magic 
wand would have got a few months of my life back in 2021 that I'll never get 
back.

As I said no more responses from me. I am going to go back to a transcript on 
FROST, one of the many exciting things people are working on that is Taproot 
related and what I believe the focus should be on at least until there is clear 
community consensus for a future soft fork.

[1]: 
https://bitcoin.stackexchange.com/questions/tagged/bip119-checktemplateverify

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

--- 

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[Robin Linus via bitcoin-dev]

Hi Michael,

Thank you for your reply. You wrote:

> I have a better (and safer) way forward which is to continue to build out use 
> cases of CTV, convince the community it is the best tool for the job 
> (whatever use case(s) that is), compare it to other existing covenant 
> enabling proposals on those use cases and then get to a point where the 
> community is confident that it is activating a proposal(s) that will stand 
> the test of time.

Where can I see the use cases you have built out in recent years? Do you have a 
writeup in which you compare CTV to existing covenant enabling proposals? Do 
you have a strong reason to favour a different proposal? Have you written any 
code?

I've seen pages of text of you complaining about details of CTV activation but 
nothing tangible that would prove that you are actually interested in real 
progress on covenants.
In contrast, Jeremy has been doing exactly what you are proposing. He wrote the 
BIP, implemented it, explained use cases in detail, spoke at conferences, 
organised workshops, and built the Sapio framework for the community to 
experiment with covenants. He even puts his money where his mouth is and offers 
a bug bounty for any security flaw in the code.

> You may not like that way forward because it requires a lot of work, a lot of 
> time and a lot of patience.

A lot of work, a lot of time and a lot of patience is exactly what Jeremy has 
been investing for years. I think by framing his contributions as "immature" 
you are disrespecting all the work he put into BIP-119. If you could point me 
to essays of you thoughtfully comparing various covenant proposals then I could 
see your point, but you're only ranting on other people's work which requires 
no real effort and it doesn't contribute much. If you are not willing to do 
what you are suggesting for years why should anybody else do it? Should the 
entire community stall progress on covenants until somebody else works on what 
you think is ideal?
Bike shedding is just as big of an issue as "contentious soft forks". Pointless 
activation drama is a huge issue of bitcoin protocol development because it is 
so draining. Some of the most respected devs do not participate in activation 
politics anymore because it harms their health. That's nuts. If you really want 
to be of service to the Bitcoin community you should work on what you think is 
the right path forward and not just criticise Jeremy for progressing with his 
excellent work.

Looking forward to check out your contributions!

Regards,
Robin___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[Michael Folkson via bitcoin-dev]

Hi Robin

I was in two minds to respond because I feel I am just repeating myself from 
previous emails to this list [1], [2], [3]. I'm not sure whether you have read 
those posts or are just blocking them out because you disagree with them. I 
also don't think much (anything?) has changed since I wrote those emails a few 
months ago.

> Honestly, the reasons you mentioned here [1] do not make much sense to me and 
> it feels like your attitude is not very constructive as you do not suggest a 
> better way forward.

I have a better (and safer) way forward which is to continue to build out use 
cases of CTV, convince the community it is the best tool for the job (whatever 
use case(s) that is), compare it to other existing covenant enabling proposals 
on those use cases and then get to a point where the community is confident 
that it is activating a proposal(s) that will stand the test of time.

You may not like that way forward because it requires a lot of work, a lot of 
time and a lot of patience. It is certainly easier to agitate for a soft fork 
on a mailing list. But that would be "my" and other people's way forward who 
think only the best proposals should get into Bitcoin consensus rules and those 
worthy of taking on the chain split risk.

> It's not clear to me what you want because you just keep opposing CTV without 
> trying to make better suggestions. What do you want?

There are a number of competing covenant enabling proposals out there. I don't 
know if they are better or not for specific use cases. I also don't think there 
is consensus on that yet. Mainnet should not be treated like testnet, signet or 
an altcoin. It isn't for experimenting with new consensus rules or proving that 
something is useful. That should be done elsewhere.

> Your other arguments mostly discuss soft forks in general. This is a 
> different topic though. I think it is not a good idea to mix that up.

Any soft fork introduces chain split risk into the equation. Taproot had 
overwhelming community consensus so it had much less chain split risk. A 
contentious soft fork activation attempt contains a lot more chain split risk. 
When discussing whether to attempt to activate soft forks you have to 
appreciate that important fact. To ignore that seems bizarre to me.

But as I said I'm repeating myself. If we have to do this contentious soft fork 
activation attempt exercise we have to do it and get it over with. The kind of 
work and progress I was hoping to see on CTV use cases over many months (and/or 
years) doesn't seem to be happening. Instead we just have a flame war every 
couple of months on the mailing list over whether CTV should be activated or 
not and rehash all the same arguments in an environment in which nothing 
(anything?) has moved forward.

[1]: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html
[2]: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html
[3]: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019731.html

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

--- Original Message ---
On Wednesday, April 20th, 2022 at 18:13, Robin Linus via bitcoin-dev 
 wrote:

> Dear Michael,
>
> Firstly, I think it is great that you do share enthusiasm for "vaults, eltoo 
> constructions, payment pools etc". Many people see covenants (or 
> covenant-like features) as one of the most important upgrades currently in 
> the pipe line because it enables so many important use cases and interesting 
> areas of research. In particular vaults and scalability solutions.
>
> However, I have tried to figure out why you invest so much time and effort to 
> oppose CTV. Honestly, the reasons you mentioned here [1] do not make much 
> sense to me and it feels like your attitude is not very constructive as you 
> do not suggest a better way forward.
> You wrote "This research and experimentation should mature before considering 
> activation" even though you know that BIP-119 has been finalised more than 
> two years ago. Also the implementation has been reviewed extensively and it 
> has matured for years. So, your framing of "experimentation" and "premature 
> activation" just doesn't reflect the truth here. Even your argument is 
> already more than a year old...
>
> Additionally, you do not address that CTV is intentionally designed to be the 
> most simple and conservative upgrade towards full-featured covenants. CTV 
> only enables a feature that is already possible today using a trusted party. 
> Opposing this conservative approach means you are either in favour of 
> activating a more powerful feature or you do not want covenants at all. It's 
> not clear to me what you want because you just keep opposing CTV without 
> trying to make better suggestions. What do you want?
> Your other arguments mostly discuss 

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[Robin Linus via bitcoin-dev]

Dear Michael,

Firstly, I think it is great that you do share enthusiasm for "vaults, eltoo 
constructions, payment pools etc". Many people see covenants (or covenant-like 
features) as one of the most important upgrades currently in the pipe line 
because it enables so many important use cases and interesting areas of 
research. In particular vaults and scalability solutions.

However, I have tried to figure out why you invest so much time and effort to 
oppose CTV. Honestly, the reasons you mentioned here [1] do not make much sense 
to me and it feels like your attitude is not very constructive as you do not 
suggest a better way forward.
You wrote "This research and experimentation should mature before considering 
activation" even though you know that BIP-119 has been finalised more than two 
years ago. Also the implementation has been reviewed extensively and it has 
matured for years. So, your framing of "experimentation" and "premature 
activation" just doesn't reflect the truth here. Even your argument is already 
more than a year old...

Additionally, you do not address that CTV is intentionally designed to be the 
most simple and conservative upgrade towards full-featured covenants. CTV only 
enables a feature that is already possible today using a trusted party. 
Opposing this conservative approach means you are either in favour of 
activating a more powerful feature or you do not want covenants at all. It's 
not clear to me what you want because you just keep opposing CTV without trying 
to make better suggestions. What do you want?
Your other arguments mostly discuss soft forks in general. This is a different 
topic though. I think it is not a good idea to mix that up. And claiming that 
CTV implies continuous soft forks is again dishonest framing. It suggests that 
covenants were just a random idea of Jeremy even though you know that many 
reputable bitcoin developers have been researching this topic for years. Truth 
is Jeremy does a great service to the community by facing this draining 
activation drama to make trustless covenants possible.

Now, in your most recent email your main concern seems to be a potential chain 
split. This is again a weak argument against CTV because your concerns apply to 
any upgrade. Furthermore, you are increasing this risk by opposing CTV without 
trying to find a common way forward to activate covenants. This doesn't serve 
bitcoin. I think it would be better for everyone if you would invest your time 
in trying to formulate a better solution. Covenants are too important to just 
oppose them because of inaccurate framing or because of opposition to soft 
forks in general.

Regards,
Robin

[1] https://github.com/JeremyRubin/utxos.org/issues/27

--- Original Message ---
On Wednesday, April 20th, 2022 at 3:24 PM, Michael Folkson via bitcoin-dev 
 wrote:

>> The client has a Speedy trial release similar to Taproots with parameters 
>> proposed to be
>
> As I've said before I was hoping we'd avoid this exercise. Best case, it 
> wastes the time of people who could be working on all sorts of valuable 
> projects for the ecosystem. Worst case, we take a Russian roulette style 
> gamble with a chain split.
>
> But here's a summary of the basic facts:
>
> The latest Bitcoin Core release candidate (23.0) does not contain any new 
> soft fork code, either CTV code or any new activation code. Running Bitcoin 
> Core 23.0 out the box will not signal for any new soft fork and will not 
> enforce any new soft fork rules (CTV or otherwise). Of course it will 
> continue to enforce Taproot rules as Taproot activated last year.
>
> There are a number of individuals who have stated opposition to attempting to 
> activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> Most of those individuals haven't logged their opposition on Jeremy's site:
> https://utxos.org/signals/
>
> Hence their views haven't been included or discussed in Jeremy's latest blog 
> post.
>
> Chain split risk
>
> I can't predict how many full nodes and miners will run Jeremy's client 
> attempting to activate CTV. One would expect that many will continue to run 
> versions of Bitcoin Core that will not enforce CTV rules and will not 
> activate it. But whether Jeremy's client will be a majority, significant 
> minority, insignificant minority of full nodes and miners would be 
> speculation on my part. (Personally I highly doubt those running Jeremy's 
> client will be a majority which leaves a significant minority and 
> insignificant minority as the most likely options).
>
> Jeremy's client is intending to use Speedy Trial presumably with similar 
> parameters to that used for Taproot. That would mean seeking 90 percent of 
> miners to signal for this CTV soft fork activation attempt.
>
> Assuming 90 percent of miners don't signal for it in one of the Speedy Trial 
> windows then the activation attempt will have failed and it 

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[Michael Folkson via bitcoin-dev]

> The client has a Speedy trial release similar to Taproots with parameters 
> proposed to be

As I've said before I was hoping we'd avoid this exercise. Best case, it wastes 
the time of people who could be working on all sorts of valuable projects for 
the ecosystem. Worst case, we take a Russian roulette style gamble with a chain 
split.

But here's a summary of the basic facts:

The latest Bitcoin Core release candidate (23.0) does not contain any new soft 
fork code, either CTV code or any new activation code. Running Bitcoin Core 
23.0 out the box will not signal for any new soft fork and will not enforce any 
new soft fork rules (CTV or otherwise). Of course it will continue to enforce 
Taproot rules as Taproot activated last year.

There are a number of individuals who have stated opposition to attempting to 
activate a CTV soft fork in the near term:

https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718

Most of those individuals haven't logged their opposition on Jeremy's site:
https://utxos.org/signals/

Hence their views haven't been included or discussed in Jeremy's latest blog 
post.

Chain split risk

I can't predict how many full nodes and miners will run Jeremy's client 
attempting to activate CTV. One would expect that many will continue to run 
versions of Bitcoin Core that will not enforce CTV rules and will not activate 
it. But whether Jeremy's client will be a majority, significant minority, 
insignificant minority of full nodes and miners would be speculation on my 
part. (Personally I highly doubt those running Jeremy's client will be a 
majority which leaves a significant minority and insignificant minority as the 
most likely options).

Jeremy's client is intending to use Speedy Trial presumably with similar 
parameters to that used for Taproot. That would mean seeking 90 percent of 
miners to signal for this CTV soft fork activation attempt.

Assuming 90 percent of miners don't signal for it in one of the Speedy Trial 
windows then the activation attempt will have failed and it will be back in 
Jeremy's court whether he tries again with a different activation attempt.

Assuming 90 percent of miners do signal for it (unlikely in my opinion but 
presumably still a possibility) then the CTV soft fork could activate unless 
full nodes resist it. This resistance would most likely be in the form of a 
UASF style client which rejects blocks that apply the CTV rules and/or includes 
transactions that don't meet the CTV rules post activation. We would now be in 
chain split territory with two different assets and blockchains like we had 
with BTC and BCH.

If I oppose this activation attempt and the associated chain split risk what 
should I do?

Firstly, you can register your opposition to this soft fork activation attempt 
on Jeremy's site: https://utxos.org/signals/

It seems Jeremy will continue this activation attempt regardless but it will be 
useful for others to see clearly that this a contentious soft fork activation 
attempt and act accordingly. So far only 3 individuals' opposition is 
registered on his site.

Secondly, if it is looking like 90 percent (or whatever percentage Jeremy uses) 
of miners are going to signal for a CTV soft fork then you can consider joining 
a UASF style effort to resist the soft fork activation attempt. I will 
certainly seek to participate and will continue to inform this list of efforts 
in this direction.

The saddest thing is that if Jeremy's soft fork activation attempt causes the 
uncertainty, confusion and disruption I fear it could it will make future soft 
forks that do have community consensus orders of magnitude harder to pull off. 
There are a number of soft fork proposals that I'm personally excited about 
(enabling covenants, eltoo, Simplicity, CISA etc) that long term we might get 
with a sensible approach to only activating soft forks that have community 
consensus. But the more uncertainty, confusion and disruption we create over 
contentious soft forks the more dangerous any soft fork of any form will 
appear. The primary focus will need to be resisting soft forks that don't have 
community consensus and ensuring Bitcoin doesn't splinter into a large number 
of different assets/blockchains with different combinations of soft forks 
active.

So if you oppose this soft fork activation attempt please voice your 
opposition, run full node software that doesn't include CTV and CTV activation 
code such as Bitcoin Core and if/when necessary and available run full node 
software that proactively rejects application of the CTV rules.

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

--- Original Message ---
On Tuesday, April 19th, 2022 at 18:31, Jeremy Rubin via bitcoin-dev 
 wrote:

> Devs,
>
> In advance of the CTV meeting today, I wanted to share what my next step is 
> in advocating for 

[bitcoin-dev] 7 Theses on a next step for BIP-119

[Jeremy Rubin via bitcoin-dev]

Devs,

In advance of the CTV meeting today, I wanted to share what my next step is
in advocating for CTV, as well as 7 theses for why I believe it to be the
right course of action to take at this time.

Please see the post at
https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/.

As always, open to hear any and all feedback,

Jeremy


archived at:
https://web.archive.org/web/20220419172825/https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev