Hi Michael, Sorry, if my critique of your opinions feels too personal to you. This is nothing personal. As you probably know, one of the most effective attack vectors on Bitcoin is to target the social layer by sabotaging the protocol development[1]. Bike shedding is an easy way to cause a lot of harm. This is why it is hard to distinguish your radical opinions from an (unintended) attack. So, we cannot simply trust you. In particular because you contribute so much time criticising the activation of CTV, while you also refuse to spend any time working on activating covenants. You just want to stall the activation of covenants indefinitely. An attacker would act the same. Another red flag is that you are trying to downplay how many reputable community members have already signalled their support for CTV https://utxos.org/signals/ . You keep framing it as if there was only that one crazy guy trying to push an immature and risky consensus change. In fact, it is well reviewed and many people support CTV because it is the most conservative step forwards and it is ready for activation now. You are alarmed by what you call a "contentious" soft fork while actually you are yourself by far the most vocal opponent of this fork. You are even threatening to cause a chain split while you're also warning others that your chain split would become a big issue. Since we're talking about a soft fork here you're basically saying that you want to make your node reject valid blocks. I doubt that anyone opposes CTV as extremely as you do. In particular because your strongest argument is that CTV might not be ideal for all use cases, which is trivially true for every protocol upgrade. An attacker would act the same. All in all, it is very hard to distinguish your strong desire to stall the development from an attack. This is why we have to question your motives thoroughly. Again, this is nothing personal. It's just that you are very critical of people who support activation of CTV and thus, you should expect others to be just as critical of your opinions. Isn't that fair? Regards, Robin [1] https://twitter.com/peterktodd/status/1495796670440919056 ------- Original Message ------- On Thursday, April 21st, 2022 at 12:04 AM, Michael Folkson wrote: > Ok last one. Whatever you say and whatever personal attacks you come up with I'm not responding after this one :) > >> Where can I see the use cases you have built out in recent years? Do you have a writeup in which you compare CTV to existing covenant enabling proposals? Do you have a strong reason to favour a different proposal? Have you written any code? > > You don't seem to quite understand the asymmetry here. I (and the rest of the community excluding Jeremy) am not a full time CTV developer or full time CTV advocate. There are a number of soft fork proposals I am interested in and attempting to follow in addition to all the work that is going around Taproot etc. But if you/Jeremy want to make a change to the consensus rules the onus is on you to get community review and community consensus. I am not demanding the consensus rules be changed. I am quite happy to wait until there is community consensus over a particular soft fork like there was with Taproot. > > I have looked into CTV a considerable number of times now. I have asked 5 of the 6 CTV related questions on Bitcoin StackExchange at the time of writing [1], 2 of which I have attempted to answer. Does this mean I understand as much about Jeremy about CTV? Of course not. But if you believe that soft forks should have community consensus it is up to you/Jeremy to address concerns from curious, relatively informed, skeptical people like me. I am not convinced at the time of writing that CTV is the best tool for the job on any of its intended use cases. On this I don't think even Jeremy is convinced as when asked to compare CTV to alternatives he often just says it is ready and other proposals aren't. > >> In contrast, Jeremy has been doing exactly what you are proposing. He wrote the BIP, implemented it, explained use cases in detail, spoke at conferences, organised workshops, and built the Sapio framework for the community to experiment with covenants. He even puts his money where his mouth is and offers a bug bounty for any security flaw in the code. > > I'm not entirely sure where you are going with this. That because Jeremy has worked really hard on it for a long time we should activate it without community consensus? I'm sorry that's not how consensus changes work or how they should work. Personally I very much doubt I will ever attempt to change the consensus rules with one of my proposals. I struggle to follow all of the work and the proposals others work on and at least for now believe others are much more qualified than me to design and code up consensus code changes. So again there is an 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 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