On Sun, Apr 24, 2022 at 2:17 PM Michael Folkson < michaelfolk...@protonmail.com> wrote:
> Hi Jorge > > > Can we agree now that resisting a bip8 proposal is simpler and cleaner > than resisting a speedy trial proposal? > > Personally I'd rather stick to one challenge at a time :) Currently we are > facing a contentious soft fork activation attempt of CTV using an > alternative client which we expect [1] to be a Speedy Trial deployment. > Once this is resolved we can discuss the lessons and observations that come > out of this. > That sounds reasonable to me. Fair enough. > > Is there any PR to actively resist the proposal on bitcoin core? > > Not currently. Unless this becomes really, really messy and starts to pose > a true existential threat to Bitcoin itself I think it best that attempts > to actively resist the proposal are done outside of Bitcoin Core in an > alternative client(s). Contrary to what some CTV proponents say getting > anything consensus related into Bitcoin Core is extremely difficult > (especially at short notice). There is no BDFL or Linus Torvalds like > figure, there are a large number of contributors (and maintainers) who all > have differing personal views. Hence directing people to have this > discussion on a particular PR in the Bitcoin Core repo seems to me to be > counterproductive and a massive distraction to other work that is going on > on Bitcoin Core. We've already started to see online attacks on Bitcoin > Core by CTV proponents [2] claiming an "old guard trying to assert > dictatorship over the Bitcoin protocol". It is nonsense of course but > directing that nonsense to the Bitcoin Core repo is surely not the right > way to go. > > As I've said in previous emails there is a Libera (and Freenode now) IRC > channel ##ursf that has been set up to discuss an alternative client. We'll > get a conversation log up too. And of course we wait for confirmation on > what the Speedy Trial deployment parameters for this attempted CTV soft > fork are going to be. > > [1]: https://blog.bitmex.com/op_ctv-summer-softfork-shenanigans/ > [2]: > https://twitter.com/ProofOfKeags/status/1517574210691887105?s=20&t=_jgRh3kkYP3kn1qLuzGXrQ > > I disagree that it shouldn't be on bitcoin core, but I guess such a proposal would get many nacks. But if there are no speedy trial parameters yet, I guess we need to wait for that; whether the code for resisting it ends up in bitcoin core or not. Thanks for the clarifications. -- > Michael Folkson > Email: michaelfolkson at protonmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > ------- Original Message ------- > On Saturday, April 23rd, 2022 at 21:40, Jorge Timón <jti...@jtimon.cc> > wrote: > > I've been calling them "controversial softforks" for long. > I hate to be right some times, but I guess I'm happy that I'm not the only > one who distrusts jeremy rubin anymore. > > Can we agree now that resisting a bip8 proposal is simpler and cleaner > than resisting a speedy trial proposal? > I guess now we don't need to discuss it in hypothetical terms anymore, do > we? > > Is there any PR to actively resist the proposal on bitcoin core? > > > > > > > On Thu, Apr 21, 2022 at 8:16 PM Michael Folkson via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Ok so we've had to scramble a bit as I don't think anyone except perhaps >> Jeremy thought that there would be a Speedy Trial signaling period for a >> CTV soft fork planned to start on May 5th [1]. That is two weeks away. >> >> (I have to take what he says at face value. I can understand why one >> would be skeptical.) >> >> Understandably this has angered and surprised a few people including some >> of those who have voiced opposition to a CTV soft fork activation being >> attempted in the first place [2]. >> >> As I've said in a previous post [3] the Bitcoin Core 23.0 release >> candidate (and older versions) does not include any CTV code or CTV >> activation code. If a miner runs Bitcoin Core 23.0 out the box it will not >> signal for CTV. If by some chance CTV was to activate through some other >> software release Bitcoin Core releases would not apply CTV rules but they >> also wouldn't reject blocks that apply CTV rules. Hence it is prudent to >> prepare for an eventuality where the miner signaling threshold might be >> reached but the community wants to prevent the attempted soft fork from >> activating. (I personally don't think a 90 percent miner signaling >> threshold will be reached but I wouldn't want to bet Bitcoin's future on >> it.) >> >> I've tentatively labelled this effort a User Resisted Soft Fork (URSF) >> but I'm open to better names. I certainly don't want to discourage those >> who dislike or oppose UASFs from contributing to this effort and >> potentially ultimately running a URSF release. If you don't want this >> rushed CTV soft fork to activate we are all on the same side whatever we >> call it. >> >> For now I've set up a ##ursf channel on Libera IRC to monitor >> developments and discuss working on an additional release that if run may >> ultimately reject blocks that signal for CTV. >> >> The intention of this would be to provide additional direction and >> incentive to miners that the community does not want this soft fork to be >> activated. To repeat running a Bitcoin Core release will not signal for a >> CTV soft fork out the box. If a miner runs a Bitcoin Core release it will >> not signal for CTV. >> >> Apologies that this is rushed. But as always with Jeremy caution and >> conservatism seems to be thrown out the window and we have to react to >> that. It goes without saying that this is not how Bitcoin consensus changes >> should be attempted. >> >> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/ >> [2]: >> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718 >> [3]: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html >> >> -- >> Michael Folkson >> Email: michaelfolkson at protonmail.com >> Keybase: michaelfolkson >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
