Re: [bitcoin-dev] User Resisted Soft Fork for CTV

["Jorge Timón" <jtimon@jtimon.cc>]

[-- Attachment #1: Type: text/plain, Size: 6480 bytes --]

On Sun, Apr 24, 2022 at 2:17 PM Michael Folkson <
michaelfolkson@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 <jtimon@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
>>
>
>

[-- Attachment #2: Type: text/html, Size: 16521 bytes --]