7 Theses on a next step for BIP-119

7 Theses on a next step for BIP-119
2022-04-20 13:24 ` Michael Folkson
  
From: Jeremy Rubin @ 2022-04-19 17:31 UTC (permalink / raw)
  To: Bitcoin development mailing list

[-- 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 --]

 permalink raw reply	[|nested]
2022-04-19 17:31 [bitcoin-dev] 7 Theses on a next step for BIP-119 Jeremy Rubin

  2022-04-20 17:13   ` Robin Linus
                     ` (3 more replies)
  
From: Michael Folkson @ 2022-04-20 13:24 UTC (permalink / raw)
  To: Jeremy Rubin, Bitcoin Protocol Discussion

[-- 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 --]

 permalink raw reply	[|nested]
2022-04-19 17:31 [bitcoin-dev] 7 Theses on a next step for BIP-119 Jeremy Rubin

  2022-04-20 17:13   ` 
                     ` 
  
From: Michael Folkson @ 2022-04-20 13:24 UTC (permalink / raw)
  To: Jeremy Rubin, Bitcoin Protocol Discussion

[-- 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 --]

 permalink raw reply	[|nested]
2022-04-20 17:13   ` Robin Linus

  2022-04-20 19:46       ` Robin Linus
  
From: Michael Folkson @ 2022-04-20 18:19 UTC (permalink / raw)
  To: Robin Linus, Bitcoin Protocol Discussion

[-- 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 --]

 permalink raw reply	[|nested]
2022-04-20 18:19     ` Michael Folkson

  2022-04-20 22:04         ` Michael Folkson
  
From: Robin Linus @ 2022-04-20 19:46 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- 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 --]

 permalink raw reply	[|nested]
2022-04-20 19:46       ` Robin Linus

  2022-04-21  9:05           ` Robin Linus
  
From: Michael Folkson @ 2022-04-20 22:04 UTC (permalink / raw)
  To: Robin Linus, Bitcoin Protocol Discussion

[-- 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 --]

 permalink raw reply	[|nested]
* 
  2022-04-20 13:24 ` Michael Folkson

  2022-04-20 18:19     ` Michael Folkson
  2022-04-21  4:03   ` 
                     ` 
  3 siblings, 1 reply; 11+ messages in thread
From: Robin Linus @ 2022-04-20 17:13 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- 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 --]

^ permalink raw reply	[|nested] 11+ messages in thread
2022-04-20 22:04         ` Michael Folkson

  
From: Robin Linus @ 2022-04-21  9:05 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- 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 --]

 permalink raw reply	[|nested]
2022-04-20 13:24 ` Michael Folkson
  2022-04-20 17:13   ` Robin Linus
  2022-04-21  4:03   ` Billy Tetrud

  2022-04-21 13:40   ` alicexbt
  
From: Zac Greenwood @ 2022-04-21 12:49 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion, Michael Folkson

[-- 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 --]

 permalink raw reply	[|nested]
2022-04-20 13:24 ` Michael Folkson
                     ` (2 preceding siblings ...)
  2022-04-21 12:49   ` Zac Greenwood

  2022-04-21 14:16     ` Greg Sanders
  
From: alicexbt @ 2022-04-21 13:40 UTC (permalink / raw)
  To: Michael Folkson;  Bitcoin Protocol Discussion

[-- 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 --]

 permalink raw reply	[|nested]
2022-04-21 13:40   ` alicexbt

  
From: Greg Sanders @ 2022-04-21 14:16 UTC (permalink / raw)
  To: alicexbt, Bitcoin Protocol Discussion

[-- 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 --]

 permalink raw reply	[|nested]