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

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

[Jeremy Rubin]

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

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/

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

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

[Michael Folkson]

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

> 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 <bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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/

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

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

[Robin Linus]

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

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 <bitcoin-dev@lists.linuxfoundation.org> 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 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 <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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/

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

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

[Michael Folkson]

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

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 <bitcoin-dev@lists.linuxfoundation.org> 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 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 <bitcoin-dev@lists.linuxfoundation.org> 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 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 <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> 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/

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

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

[Robin Linus]

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

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

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

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

[Michael Folkson]

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

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

------- Original Message -------
On Wednesday, April 20th, 2022 at 20:46, Robin Linus via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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

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

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

[Billy Tetrud]

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

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
<https://www.coindesk.com/tech/2021/01/14/bitcoin-cores-latest-release-is-out-heres-whats-in-it/>
before
consensus developed <https://gnusha.org/taproot-activation/2021-02-16.log>
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
<https://twitter.com/bramcohen/status/1224823869933899776> and a Corenell
paper <https://arxiv.org/abs/2005.11776>. But there's clearly been quite a
bit of review on the PR <https://github.com/bitcoin/bitcoin/pull/21702> 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
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>
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 covenant opcode, CTV can provide a LOT of value in a number of ways
until that point (which will likely be at least 4 years). And its also
likely that a more full featured covenant opcode will take *longer* if CTV
doesn't get out there and show the uninformed why covenants are important.

As far as I can tell, its uncontroversial that CTV is the simplest and
safest of all the covenant proposals. Do you disagree?

> Taproot had overwhelming community consensus so it had much less chain
split risk

IMO this is a completely invalid argument. If a speedy trial is done and
90% miner activation happens, that is quite a high supermajority
percentage. If such a thing happens, there is basically 0 chance of any
chain split happening directly from activation. The only chain split risk,
then, would be from anyone who thinks it would be then worth it to hard
fork away from that chain, which you have already said you wouldn't be one
of. So I have to say, this additional chain split risk you speak of sounds
completely imaginary to me.

~BT

On Wed, Apr 20, 2022 at 8:49 AM Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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 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
> 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 <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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
>

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

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

[Robin Linus]

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

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 <michaelfolkson@protonmail.com> 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 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
>
> ------- Original Message -------
> On Wednesday, April 20th, 2022 at 20:46, Robin Linus via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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

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

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

[Zac Greenwood]

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

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

>

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

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

[alicexbt]

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

> 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 <bitcoin-dev@lists.linuxfoundation.org> 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 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 <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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/

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

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

[Greg Sanders]

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

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 <https://protonmail.com/> secure email.
>
> ------- Original Message -------
> On Wednesday, April 20th, 2022 at 6:54 PM, Michael Folkson via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> 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 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
> 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 <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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
>

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