Re: [bitcoin-dev] What to expect in the next few weeks

[Melvin Carvalho <melvincarvalho@gmail.com>]

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

On Fri, Apr 22, 2022 at 7:33 PM Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If the next few weeks go how I fear they will it could get messy. If you
> care about Bitcoin's consensus rules I'd request you pay attention so you
> can make an informed view on what to run and what to support. For those of
> you who were around in 2015-2017 you'll know what to expect. The right
> outcome endured in 2017 and I'm sure the right outcome will endure here
> assuming people pay attention and listen to the individuals who were
> trusted during that period. There are always a large number of motivated
> parties who are incentivized to break nodes off from Bitcoin and may seek
> to take advantage of a contentious soft fork activation attempt.
>
> Remember that if all the information is presented to users in a clear way
> well ahead of time then they can make their own mind up. I fear that things
> will be made as convoluted as possible in a way intended to confuse and
> information will be withheld until the last minute. When in doubt it is
> generally better to rely on the status quo and tried and trusted. In this
> case that would be Bitcoin Core. Alternative releases such as those seeking
> to attempt to activate CTV or indeed those seeking to resist the activation
> of CTV really should only be considered if you are informed on exactly what
> you are running.
>
> If you are interested in the effort to resist the contentious soft fork
> activation attempt of CTV please join ##ursf on Libera IRC.
>
> Have a good weekend. Hopefully those behind this contentious soft fork
> activation attempt will see sense and we can go back to more productive
> things than resisting contentious soft forks.
>

Thanks for raising this

Remembering 2017 quite well, it's often characterized as small block(ers)
vs big block(ers).  While that was certainly the case, I see it slightly
differently.

I think the bigger argument of 2017 was around a network split.  Splitting
the network is problematic because one or other of the split chains may
experience a hash death (without mitigating difficulty adjustment
algorithms), or the so-called "famine and feast" minority hash behaviour,
experienced on testnet, and disruptive to users

Any proposed changes should factor in network splits as a potential risk.
Or perhaps through another lens, you could see a network split as an
attack, on a par with a 51% attack, in terms of user disruption.  It may in
fact, be more potent, since we've never had a serious 51% attack, but we
have had network splits

I do think the conversation here is MUCH better tempered than 2017.
Hopefully we can try and avoid perceptions of gate keeping and railroading,
and keep the network together, as we did back then


>
> --
> 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: 6249 bytes --]