Subject: Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

From: Jorge Timón <[email-masked]>
Date: Sun, 1 May 2022 13:47:54 +0100

On Sun, May 1, 2022, 09:22 alicexbt via bitcoin-dev <
[email-masked]> wrote:

> Hi Michael,
>
> Maybe the whole thing worked as designed. Some users identified what was
> going on, well known Bitcoin educators such as Andreas Antonopoulos, Jimmy
> Song etc brought additional attention to the dangers, a URSF movement
> started to gain momentum and those attempting a contentious soft fork
> activation backed off. (Disappointingly Bitcoin Optech didn't cover my
> previous posts to this mailing list 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-April/020235.html>
> highlighting the dangers many months ago or recent posts. Normally Optech
> is very high signal.)
>
>
> Some users have been misled and there is nothing great being achieved by
> doing this on social media. Andreas is clueless about BIP 119 and other
> covenant proposals. He is spreading misinformation and some of the URSF
> enthusiasts do not understand what are they even opposing or going to run
> with risks involved.
>
Clueless and spreading disinformation, you say? What misinformation, could
you explain?

> - Avoid personal attacks
Could accusing someone of apreading misinformation without prove and
calling him clueless be considered a personal attack?
What do we do with hypocrites and liars?
People who knowingly lie to push their own agenda, how do we protect
against those?

> /dev/fd0
>
> Sent with ProtonMail <https://protonmail.com/> secure email.
>
> ------- Original Message -------
> On Saturday, April 30th, 2022 at 3:23 PM, Michael Folkson via bitcoin-dev
> [email-masked] wrote:
>
>
> I’ve been in two minds on whether to completely move on to other topics or
> to formulate some thoughts on the recent attempt to activate a contentious
> soft fork. In the interests of those of us who have wasted
> days/weeks/months of our time on this (with no personal upside) and who
> don’t want to repeat this exercise again I thought I should at least raise
> the issue for discussion of what should be done differently if this is
> tried again in future.
>
> This could be Jeremy with OP_CTV at a later point (assuming it is still
> contentious) or anyone who wants to pick up a single opcode that is not yet
> activated on Bitcoin and try to get miners to signal for it bypassing
> technical concerns from many developers, bypassing Bitcoin Core and
> bypassing users.
>
> Maybe the whole thing worked as designed. Some users identified what was
> going on, well known Bitcoin educators such as Andreas Antonopoulos, Jimmy
> Song etc brought additional attention to the dangers, a URSF movement
> started to gain momentum and those attempting a contentious soft fork
> activation backed off. (Disappointingly Bitcoin Optech didn't cover my
> previous posts to this mailing list 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-April/020235.html>
> highlighting the dangers many months ago or recent posts. Normally Optech
> is very high signal.)
>
> Alternatively this was the first time a contentious soft fork activation
> was attempted, we were all woefully unprepared for it and none of us knew
> what we were doing.
>
> I’m unsure on the above. I’d be interested to hear thoughts. What I am
> sure of is that it is totally unacceptable for one individual to bring the
> entire Bitcoin network to the brink of a chain split. There has to be a
> personal cost to that individual dissuading them from trying it again
> otherwise they’re motivated to try it again every week/month. Perhaps the
> personal cost that the community is now prepared if that individual tries
> it again is sufficient. I’m not sure. Obviously Bitcoin is a permissionless
> network, Bitcoin Core and other open source projects are easily forked and
> no authority (I’m certainly no authority) can stop things like this
> happening again.
>
> I’ll follow the responses if people have thoughts (I won't be responding
> to the instigators of this contentious soft fork activation attempt) but
> other than that I’d like to move on to other things than contentious soft
> fork activations. Thanks to those who have expressed concerns publicly (too
> many to name, Bob McElrath was often wording arguments better than I could)
> and who were willing to engage with the URSF conversation. If an individual
> can go directly to miners to get soft forks activated bypassing technical
> concerns from many developers, bypassing Bitcoin Core and bypassing users
> Bitcoin is fundamentally broken. The reason I still have hope that it isn't
> is that during a period of general apathy some people were willing to stand
> up and actively resist it.
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> _______________________________________________
> bitcoin-dev mailing list
> [email-masked]
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>