Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt
> You are working on a use case of OP_CTV now? I think I mentioned clearly what I would be doing: 1. Review pull request 2. Create contracts with Sapio. This would help me review OP_CTV and learn new things. > Cool, you only recently announced you were working on Bitcoin Knots (and I > think Wasabi before that) so I'm losing track of all the announcements. You can read more about my involvement in Bitcoin Knots here: https://github.com/bitcoinknots/bitcoin/discussions/39 I started working for zkSNACKs Wasabi 2 months back which can be confirmed with the team. There are no announcements and humans can work on multiple things. You might want to check my next project which involves discreet log contracts as I have learnt a few things in bitcoin-s slack as well: https://gok.one/ For my involvement in other projects you can email me privately and I can share my resume. -- Prayank A3B1 E430 2298 178F Jan 4, 2022, 22:18 by michaelfolk...@protonmail.com: > You are working on a use case of OP_CTV now? Cool, you only recently > announced you were working on Bitcoin Knots (and I think Wasabi before that) > so I'm losing track of all the announcements. Regardless stick with it and > build out more than a rudimentary proof of concept. That is one of the things > that is severely lacking at this point for OP_CTV. > > > TBH I am not against Miniscript and still waiting for its support in Core > >which might take another few years. I would love to have multiple > >programming languages so that application developers can decide what works > >best for them. > > I would hope you weren't against Miniscript because Sapio is built on top of > it :) But whatever have fun, I can't do this all day. > > > --> Michael FolksonEmail: michaelfolkson at protonmail.comKeybase: > michaelfolksonPGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, January 4th, 2022 at 3:06 PM, Prayank > wrote: > > >> What I have done related to OP_CTV? >> >> https://twitter.com/prayankgahlot/status/1456643891885592579 >> >> What am I currently working on that is not shared publicly and will do in >> next few weeks? >> >> Review pull request 21702 and write contracts using Sapio based on few ideas >> that I already have. >> >> What is this assessment based on? >> >> A few months are enough for the recent bounty to find bugs if possible and >> other things pending to be completed. >> >> > you haven't thought about alternative proposals for any particular use >> > case (vaults for example have multiple current alternative proposals and >> > most likely many future ones) >> >> I have read enough about alternative proposals and some of them don't even >> compete with OP_CTV, they can all be implemented and complement each other. >> Vaults is not the only thing that I care about and it would be better if we >> don't assume about research done by others. >> >> > A new programming language (Sapio) sounds great but do you you need it for >> > your use case rather than an alternative high level language like Minsc? >> > Sapio makes use of Miniscript which hasn't been finalized yet or updated >> > for Taproot. Surely that needs to be done first otherwise Sapio is built >> > on top of something that isn't ready? When you make the claims such as a >> > consensus change is ready to go the burden is on you to convince me and >> > other skeptics why. The status quo is the default. "I think it is ready or >> > will be ready" doesn't mean much unless you have done the work. >> >> TBH I am not against Miniscript and still waiting for its support in Core >> which might take another few years. I would love to have multiple >> programming languages so that application developers can decide what works >> best for them. >> >> I don't understand what work are you expecting me to do in this case to >> share my opinion about a soft fork. >> >> > It is not enough for one individual to say it is ready to be activated, >> > anyone who is expressing that view should understand why the opcode has >> > been designed in the way it has and why it is so important that we should >> > dedicate months of community time to getting a single opcode activated >> > this year. >> >> I have dedicated enough time reading everything related to OP_CTV and >> discuss things that were posted earlier here by Jeremy Rubin. Not sure how >> many skeptics did the same or even tried to discuss anything until recent >> bounty was announced. >> >> > You regularly NACK Core PRs yet you seem willing to wave a consensus >> > change through with no outstanding questions and zero skepticism. >> >> I would NACK and write the reasons in this pull request as well if I find >> any issues and PR author is not addressing them. I had lots of questions at >> conceptual level which have been answered on different platforms and I >> cannot document each conversation. Its a Concept ACK from me and none of the >>
Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt
You are working on a use case of OP_CTV now? Cool, you only recently announced you were working on Bitcoin Knots (and I think Wasabi before that) so I'm losing track of all the announcements. Regardless stick with it and build out more than a rudimentary proof of concept. That is one of the things that is severely lacking at this point for OP_CTV. > TBH I am not against Miniscript and still waiting for its support in Core > which might take another few years. I would love to have multiple programming > languages so that application developers can decide what works best for them. I would hope you weren't against Miniscript because Sapio is built on top of it :) But whatever have fun, I can't do this all day. -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ‐‐‐ Original Message ‐‐‐ On Tuesday, January 4th, 2022 at 3:06 PM, Prayank wrote: > What I have done related to OP_CTV? > > https://twitter.com/prayankgahlot/status/1456643891885592579 > > What am I currently working on that is not shared publicly and will do in > next few weeks? > > Review pull request 21702 and write contracts using Sapio based on few ideas > that I already have. > > What is this assessment based on? > > A few months are enough for the recent bounty to find bugs if possible and > other things pending to be completed. > >> you haven't thought about alternative proposals for any particular use case >> (vaults for example have multiple current alternative proposals and most >> likely many future ones) > > I have read enough about alternative proposals and some of them don't even > compete with OP_CTV, they can all be implemented and complement each other. > Vaults is not the only thing that I care about and it would be better if we > don't assume about research done by others. > >> A new programming language (Sapio) sounds great but do you you need it for >> your use case rather than an alternative high level language like Minsc? >> Sapio makes use of Miniscript which hasn't been finalized yet or updated for >> Taproot. Surely that needs to be done first otherwise Sapio is built on top >> of something that isn't ready? When you make the claims such as a consensus >> change is ready to go the burden is on you to convince me and other skeptics >> why. The status quo is the default. "I think it is ready or will be ready" >> doesn't mean much unless you have done the work. > > TBH I am not against Miniscript and still waiting for its support in Core > which might take another few years. I would love to have multiple programming > languages so that application developers can decide what works best for them. > > I don't understand what work are you expecting me to do in this case to share > my opinion about a soft fork. > >> It is not enough for one individual to say it is ready to be activated, >> anyone who is expressing that view should understand why the opcode has been >> designed in the way it has and why it is so important that we should >> dedicate months of community time to getting a single opcode activated this >> year. > > I have dedicated enough time reading everything related to OP_CTV and discuss > things that were posted earlier here by Jeremy Rubin. Not sure how many > skeptics did the same or even tried to discuss anything until recent bounty > was announced. > >> You regularly NACK Core PRs yet you seem willing to wave a consensus change >> through with no outstanding questions and zero skepticism. > > I would NACK and write the reasons in this pull request as well if I find any > issues and PR author is not addressing them. I had lots of questions at > conceptual level which have been answered on different platforms and I cannot > document each conversation. Its a Concept ACK from me and none of the > contributors could find any issues with PR right now so I don't want to stop > people from improving Bitcoin. > >> As I understand there are IRC workshops next week on BIP 119 [1] that I'd >> encourage you to join so you can start getting into a position where you can >> engage with the skeptics on technical concerns. Regrettably (as I said I >> find this work interesting) I don't feel like I can participate because >> deployment and activation is being included and I think it is irresponsible >> to be discussing those at this point. In my view activation should not even >> be speculated upon until it is clear there is overwhelming community support >> for a soft fork being activated. > > I would be attending the workshops and had even requested Jeremy to use > Twitch because it would help more people understand things with audio, screen > sharing etc. I would love to see skeptics participate and discuss technical > things. > >> I don't feel like I can participate because deployment and activation is >> being included and I think it is irresponsible to be discussing those at >>
Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt
What I have done related to OP_CTV? https://twitter.com/prayankgahlot/status/1456643891885592579 What am I currently working on that is not shared publicly and will do in next few weeks? Review pull request 21702 and write contracts using Sapio based on few ideas that I already have. What is this assessment based on? A few months are enough for the recent bounty to find bugs if possible and other things pending to be completed. > you haven't thought about alternative proposals for any particular use case > (vaults for example have multiple current alternative proposals and most > likely many future ones) I have read enough about alternative proposals and some of them don't even compete with OP_CTV, they can all be implemented and complement each other. Vaults is not the only thing that I care about and it would be better if we don't assume about research done by others. > A new programming language (Sapio) sounds great but do you you need it for > your use case rather than an alternative high level language like Minsc? > Sapio makes use of Miniscript which hasn't been finalized yet or updated for > Taproot. Surely that needs to be done first otherwise Sapio is built on top > of something that isn't ready? When you make the claims such as a consensus > change is ready to go the burden is on you to convince me and other skeptics > why. The status quo is the default. "I think it is ready or will be ready" > doesn't mean much unless you have done the work. TBH I am not against Miniscript and still waiting for its support in Core which might take another few years. I would love to have multiple programming languages so that application developers can decide what works best for them. I don't understand what work are you expecting me to do in this case to share my opinion about a soft fork. > It is not enough for one individual to say it is ready to be activated, > anyone who is expressing that view should understand why the opcode has been > designed in the way it has and why it is so important that we should dedicate > months of community time to getting a single opcode activated this year. I have dedicated enough time reading everything related to OP_CTV and discuss things that were posted earlier here by Jeremy Rubin. Not sure how many skeptics did the same or even tried to discuss anything until recent bounty was announced. > You regularly NACK Core PRs yet you seem willing to wave a consensus change > through with no outstanding questions and zero skepticism. I would NACK and write the reasons in this pull request as well if I find any issues and PR author is not addressing them. I had lots of questions at conceptual level which have been answered on different platforms and I cannot document each conversation. Its a Concept ACK from me and none of the contributors could find any issues with PR right now so I don't want to stop people from improving Bitcoin. > As I understand there are IRC workshops next week on BIP 119 [1] that I'd > encourage you to join so you can start getting into a position where you can > engage with the skeptics on technical concerns. Regrettably (as I said I find > this work interesting) I don't feel like I can participate because deployment > and activation is being included and I think it is irresponsible to be > discussing those at this point. In my view activation should not even be > speculated upon until it is clear there is overwhelming community support for > a soft fork being activated. I would be attending the workshops and had even requested Jeremy to use Twitch because it would help more people understand things with audio, screen sharing etc. I would love to see skeptics participate and discuss technical things. > I don't feel like I can participate because deployment and activation is > being included and I think it is irresponsible to be discussing those at this > point. If you don't participate in the workshops you might miss few things. However, either Jeremy or one of the participants will ensure they share the summary here or even logs would be available. -- Prayank A3B1 E430 2298 178F Jan 4, 2022, 19:45 by michaelfolk...@protonmail.com: > > > It should be ready to go in a few months IMO > > What is this assessment based on? I am assuming you haven't done a code > review of the opcode, you haven't coded up a real world use case of OP_CTV > (or even a primitive proof of concept), you haven't thought about alternative > proposals for any particular use case (vaults for example have multiple > current alternative proposals and most likely many future ones). A new > programming language (Sapio) sounds great but do you you need it for your use > case rather than an alternative high level language like Minsc? Sapio makes > use of Miniscript which hasn't been finalized yet or updated for Taproot. > Surely that needs to be done first otherwise Sapio is built on top of > something that isn't ready
Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt
Hi Christian, A few things are mentioned in these threads including unsolved research issues in which you were tagged and Richard Myers had even replied so I am assuming this is known: https://twitter.com/JeremyRubin/status/1460349481518465025 https://twitter.com/ajtowns/status/1477586002252238850 > I also see people comparing OP_CTV with APO, which may or may not work out in the end. Michael Folkson did in the first email for this thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html > I therefore consider the two proposals complementary Agree > I'm also happy to go wih OP_CTV if only one gets activated (But then why > would we? We've done much more obscure things to save bytes in a TX). Maybe we can activate one that does more than just eltoo and see how things work. If APO is still required for eltoo, there would be clear consensus for APO. -- Prayank A3B1 E430 2298 178F Jan 4, 2022, 20:12 by decker.christ...@gmail.com: > Prayank via bitcoin-dev writes: > >>> To contrast with his approach, the authors and contributors of >>> another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) >>> aren’t promoting an imminent soft fork activation attempt and instead >>> are building out and testing one of the speculated use cases, eltoo >>> payment channels [4]. >>> >> >> Because its not ready? >> > > Could you elaborate on this point? I keep seeing people mentioning this, > but I, as BIP co-author, have not seen any real pushback. For context > BIP118 was initially called `sighash_noinput` and it was mentioned at > least as far back as 2015 when Joseph and Tadje wrote about its > applications in the LN protocol. While writing eltoo we stumbled over an > alternative use, and decided to draft the formal proposal. > > Once we saw that Taproot is likely to activate next, AJ started adapting > it to integrate nicely with Taproot, and renamed it to anyprevout. > > I'd like to point out that the original noinput could be implemented > with as little as 3-5 lines of code in Bitcoin Core, and there are > experimental branches implementing APO, which isn't significantly more > complex than the original proposal. > > In addition Richard Myers has implemented a PoC of eltoo on top of one > of these experimental branches. So with all this I don't see how APO > could be considered "not ready". > > The reason that neither noinput nor APO have a section on activation is > that we want to allow bundling with other soft-forks, and we want to > minimize the surface for potential conflicts. Also as the Taproot > activation has shown activation is a whole another discussion, that is > mostly unrelated to the soft-fork being activated. > > Why aren't we yelling about the advantages of APO over other soft-forks > or asking for immediate activation? Because we want to be respectful of > everyone's time. We know review capacity is very limited, and developer > time expensive. By now most devs will be aware of the many improvements > (on LN, eltoo, MPC, channel factories, statechains, spacechains, etc) > anyprevout would enable, so there is little point in annoying everyone > by constantly talking about it. The people interested in exploring this > venue are already working on it, and we just need to wait for an > opportune moment to start the activation discussion with other > soft-forks. > > I also see people comparing OP_CTV with APO, which may or may not work > out in the end. It seems possible to emulate APO using OP_CTV, but at > what cost? APO does not have any overhead in the transaction size, which > is not the case for OP_CTV, and I therefore consider the two proposals > complementary, and not competing (APO does best what APO does best, > while OP_CTV enables use-cases beyond APO's scope). While I'd prefer APO > for eltoo, due to its lack of overhead, I'm also happy to go wih OP_CTV > if only one gets activated (But then why would we? We've done much more > obscure things to save bytes in a TX). > > Finally I see people mentioning that APO is insufficient to get > eltoo. That's also not true, since in fact we can implement a poor-man's > version of eltoo right now: > > - When updating: > - Iterate through all prior update TXs > - Bind the new update TX to each of the prior ones > - Sign using `sighash_all` > - Collect all sinatures and send to peer (message size O(n), but > semantics are preserved, while APO enable O(1) making it actually > reasonable to implement). > > There may be some extensions, such as layered commitments that may be > added at a later stage, but they are not required to get the first > versions off the ground. Pretending that they're required would be like > saying that the protocol in the LN paper hasn't changed since it was > first written (definitely not the case). > > Overall I agree with Michael's sentiment that soft-fork activations have > to be carefully planned, and kept at a reasonable pace. This is in order > to ensure th
Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt
> It should be ready to go in a few months IMO What is this assessment based on? I am assuming you haven't done a code review of the opcode, you haven't coded up a real world use case of OP_CTV (or even a primitive proof of concept), you haven't thought about alternative proposals for any particular use case (vaults for example have multiple current alternative proposals and most likely many future ones). A new programming language (Sapio) sounds great but do you you need it for your use case rather than an alternative high level language like Minsc? Sapio makes use of Miniscript which hasn't been finalized yet or updated for Taproot. Surely that needs to be done first otherwise Sapio is built on top of something that isn't ready? When you make the claims such as a consensus change is ready to go the burden is on you to convince me and other skeptics why. The status quo is the default. "I think it is ready or will be ready" doesn't mean much unless you have done the work. You are well aware of the review process in Core for non-consensus changes. For consensus changes you really should be digging even deeper, the bar should be higher and all questions you and others have should be explored in depth. It is not enough for one individual to say it is ready to be activated, anyone who is expressing that view should understand why the opcode has been designed in the way it has and why it is so important that we should dedicate months of community time to getting a single opcode activated this year. I have more sympathy for those who don't follow Bitcoin Core development and Bitcoin Core review on an ongoing basis (note as I said that the bar for consensus changes should be significantly higher than a non-consensus PR). The use cases sound cool and the work is genuinely interesting. But honestly for someone who has followed Bitcoin Core development, review for a while now you really should know better than bandy around statements like "it should be ready to go in a few months" when you currently haven't scratched the surface on the utility and safety of this opcode. You regularly NACK Core PRs yet you seem willing to wave a consensus change through with no outstanding questions and zero skepticism. > If I had to select between a soft fork without any use cases and one with use > cases, I would go with the one that has some use cases with code, > documentation etc. You should propose a new opcode but OP_CTV is not claiming > to cure cancer. Multiple proven built out use cases, sure. Multiple is better than single when you have done the work to ensure they are actually the right tool for those multiple use cases. This work hasn't been done on any of these use cases. The curing cancer analogy was used to elucidate the point that claims should be deeply explored rather than just accepted as true. >> To contrast with his approach, the authors and contributors of another >> future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting >> an imminent soft fork activation attempt and instead are building out and >> testing one of the speculated use cases, eltoo payment channels [4]. > Because its not ready? As I said it is not ready because the ANYPREVOUT contributors are building out and testing a use case. The high bar on readiness should be applied to all proposals not merely the ones where the authors/contributors decide to impose a high bar themselves. I don't really want to spend my year imploring people to dig deeper on this before indicating they support an imminent activation attempt. Some people don't have the understanding to dig deeper, some people don't have the time and some don't have either. However, if an activation of OP_CTV is attempted this year I am sure it will be contentious [0]. Anyone who cares about Bitcoin development and the ongoing technical work in a multitude of areas should be strongly against a contentious soft fork activation attempt wasting the time of developers and the entire ecosystem even if they don't have the understanding or time to appreciate the reasons why it is contentious. As I understand there are IRC workshops next week on BIP 119 [1] that I'd encourage you to join so you can start getting into a position where you can engage with the skeptics on technical concerns. Regrettably (as I said I find this work interesting) I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point. In my view activation should not even be speculated upon until it is clear there is overwhelming community support for a soft fork being activated. [0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718 [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019719.html -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4
Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt
Prayank via bitcoin-dev writes: >> To contrast with his approach, the authors and contributors of >> another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) >> aren’t promoting an imminent soft fork activation attempt and instead >> are building out and testing one of the speculated use cases, eltoo >> payment channels [4]. > > Because its not ready? Could you elaborate on this point? I keep seeing people mentioning this, but I, as BIP co-author, have not seen any real pushback. For context BIP118 was initially called `sighash_noinput` and it was mentioned at least as far back as 2015 when Joseph and Tadje wrote about its applications in the LN protocol. While writing eltoo we stumbled over an alternative use, and decided to draft the formal proposal. Once we saw that Taproot is likely to activate next, AJ started adapting it to integrate nicely with Taproot, and renamed it to anyprevout. I'd like to point out that the original noinput could be implemented with as little as 3-5 lines of code in Bitcoin Core, and there are experimental branches implementing APO, which isn't significantly more complex than the original proposal. In addition Richard Myers has implemented a PoC of eltoo on top of one of these experimental branches. So with all this I don't see how APO could be considered "not ready". The reason that neither noinput nor APO have a section on activation is that we want to allow bundling with other soft-forks, and we want to minimize the surface for potential conflicts. Also as the Taproot activation has shown activation is a whole another discussion, that is mostly unrelated to the soft-fork being activated. Why aren't we yelling about the advantages of APO over other soft-forks or asking for immediate activation? Because we want to be respectful of everyone's time. We know review capacity is very limited, and developer time expensive. By now most devs will be aware of the many improvements (on LN, eltoo, MPC, channel factories, statechains, spacechains, etc) anyprevout would enable, so there is little point in annoying everyone by constantly talking about it. The people interested in exploring this venue are already working on it, and we just need to wait for an opportune moment to start the activation discussion with other soft-forks. I also see people comparing OP_CTV with APO, which may or may not work out in the end. It seems possible to emulate APO using OP_CTV, but at what cost? APO does not have any overhead in the transaction size, which is not the case for OP_CTV, and I therefore consider the two proposals complementary, and not competing (APO does best what APO does best, while OP_CTV enables use-cases beyond APO's scope). While I'd prefer APO for eltoo, due to its lack of overhead, I'm also happy to go wih OP_CTV if only one gets activated (But then why would we? We've done much more obscure things to save bytes in a TX). Finally I see people mentioning that APO is insufficient to get eltoo. That's also not true, since in fact we can implement a poor-man's version of eltoo right now: - When updating: - Iterate through all prior update TXs - Bind the new update TX to each of the prior ones - Sign using `sighash_all` - Collect all sinatures and send to peer (message size O(n), but semantics are preserved, while APO enable O(1) making it actually reasonable to implement). There may be some extensions, such as layered commitments that may be added at a later stage, but they are not required to get the first versions off the ground. Pretending that they're required would be like saying that the protocol in the LN paper hasn't changed since it was first written (definitely not the case). Overall I agree with Michael's sentiment that soft-fork activations have to be carefully planned, and kept at a reasonable pace. This is in order to ensure that the activated features will work as expected (building PoCs is important here) and that review time is kept efficient (bundling may help here). For these reasons we omitted the activation discussion in BIP118 and have trimmed the proposal to the bare minimum. Sorry for the longish rant, but I felt I needed to clarify this situation a bit. Cheers, Christian ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt
Hi Michael, > If OP_CTV is ready to go now and has overwhelming community support (I don’t > think either is true) it should surely have been included in the Taproot soft > fork (perhaps delayed) rather than going through the months of activation > wrangling and community outreach twice. It should be ready to go in a few months IMO and makes no sense to bundle everything with Taproot soft fork. Things can remain separate and still considered good enough based on the changes proposed. > It should be made clear to any individual(s) that attempt this of the knock > on impacts and potential short term damage they are inflicting on the entire > ecosystem. I don't see any damage with a soft fork that is being discussed since years, documented properly, includes code for implementation and examples, recently got crowdfunding to incentivize review process and improve security. > It seems to me like the author and primary promoter of this proposal (Jeremy > Rubin) is pushing for an imminent attempted activation of a soft fork > containing exclusively OP_CTV [2]. He is doing nothing unexpected and got reasons to support OP_CTV being implemented soon. > To contrast with his approach, the authors and contributors of another future > soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an > imminent soft fork activation attempt and instead are building out and > testing one of the speculated use cases, eltoo payment channels [4]. Because its not ready? > Similar work has not been done for any of the speculated use cases of OP_CTV. There is no comparison between the two. If someone has worked on one of the speculated uses cases, it makes no difference. If we still compare something because of our bias, maybe Sapio is something that would be more helpful for Bitcoin developers. > Instead Jeremy is encouraging people to “soft signal” for soft fork > activation of OP_CTV presumably in the hope that the building out and testing > of use cases can be completed post activation. We had soft signals from mining pools for Taproot as well and still waiting for projects to use Taproot. Even miners signaling with speedy trial was not a guarantee they would follow new consensus rules later. I don't see anything wrong in looking for people who support a proposal and documenting it. > This is totally irresponsible in my view. A long list of speculated use cases > means nothing on its own. I can propose a new opcode OP_MAGIC and claim it > will cure cancer with no potential downsides and hence we should have a soft > fork activating it as soon as possible. If I had to select between a soft fork without any use cases and one with use cases, I would go with the one that has some use cases with code, documentation etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer. > I would hope there would be sufficient skepticism that this proposal wouldn’t > see the light of day. I am confident this proposal will be used by lot of Bitcoin projects and improve privacy, security, decentralization, demand for block space etc. > I feel the top priority is to bring some attention to the danger of us > stumbling into an attempted contentious soft fork activation attempt. I feel the danger is a few people able to stop soft forks that improve Bitcoin because of their bias and opinions which are mostly non-technical. > Enabling covenants on Bitcoin is a big step change with barely any existing > research on the topic and attempting to rush it through by the back door so > soon after Taproot activation should be resisted. Nobody has stopped anyone from doing research. There is no backdoor and everything is public. So soon? I am not sure if there are any issues with a soft fork in next few months if its ready. -- Prayank A3B1 E430 2298 178F ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
