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