📅 Original date posted:2022-04-26
📝 Original message:On Fri, Apr 22, 2022 at 7:33 PM Michael Folkson via bitcoin-dev <
bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220426/1c0c7197/attachment-0001.html>;
Melvin Carvalho [ARCHIVE] /
npub1uv…saxrt
2023-06-07 23:08:15
in reply to nevent1q…5xnm
Author Public Key
npub1uvtfvcegcn9kds68r8he57emc480vqtx8t22kpsctxgjxae44gvsksaxrtPublished at
2023-06-07 23:08:15Event JSON
{
"id": "37d95530a008215d03842e07a464db77a9e491abf273acea27fd83cf690f8f03",
"pubkey": "e316966328c4cb66c34719ef9a7b3bc54ef601663ad4ab06185991237735aa19",
"created_at": 1686179295,
"kind": 1,
"tags": [
[
"e",
"3dffc8c13f3b9b12f1185a7d930397986c136e11bc8baf2ee43157edc17ffd82",
"",
"root"
],
[
"e",
"0a34b0fc0cf4380fbea7d41f5280a90954f8615702e8ea29722276de4c184925",
"",
"reply"
],
[
"p",
"22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa"
]
],
"content": "📅 Original date posted:2022-04-26\n📝 Original message:On Fri, Apr 22, 2022 at 7:33 PM Michael Folkson via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e If the next few weeks go how I fear they will it could get messy. If you\n\u003e care about Bitcoin's consensus rules I'd request you pay attention so you\n\u003e can make an informed view on what to run and what to support. For those of\n\u003e you who were around in 2015-2017 you'll know what to expect. The right\n\u003e outcome endured in 2017 and I'm sure the right outcome will endure here\n\u003e assuming people pay attention and listen to the individuals who were\n\u003e trusted during that period. There are always a large number of motivated\n\u003e parties who are incentivized to break nodes off from Bitcoin and may seek\n\u003e to take advantage of a contentious soft fork activation attempt.\n\u003e\n\u003e Remember that if all the information is presented to users in a clear way\n\u003e well ahead of time then they can make their own mind up. I fear that things\n\u003e will be made as convoluted as possible in a way intended to confuse and\n\u003e information will be withheld until the last minute. When in doubt it is\n\u003e generally better to rely on the status quo and tried and trusted. In this\n\u003e case that would be Bitcoin Core. Alternative releases such as those seeking\n\u003e to attempt to activate CTV or indeed those seeking to resist the activation\n\u003e of CTV really should only be considered if you are informed on exactly what\n\u003e you are running.\n\u003e\n\u003e If you are interested in the effort to resist the contentious soft fork\n\u003e activation attempt of CTV please join ##ursf on Libera IRC.\n\u003e\n\u003e Have a good weekend. Hopefully those behind this contentious soft fork\n\u003e activation attempt will see sense and we can go back to more productive\n\u003e things than resisting contentious soft forks.\n\u003e\n\nThanks for raising this\n\nRemembering 2017 quite well, it's often characterized as small block(ers)\nvs big block(ers). While that was certainly the case, I see it slightly\ndifferently.\n\nI think the bigger argument of 2017 was around a network split. Splitting\nthe network is problematic because one or other of the split chains may\nexperience a hash death (without mitigating difficulty adjustment\nalgorithms), or the so-called \"famine and feast\" minority hash behaviour,\nexperienced on testnet, and disruptive to users\n\nAny proposed changes should factor in network splits as a potential risk.\nOr perhaps through another lens, you could see a network split as an\nattack, on a par with a 51% attack, in terms of user disruption. It may in\nfact, be more potent, since we've never had a serious 51% attack, but we\nhave had network splits\n\nI do think the conversation here is MUCH better tempered than 2017.\nHopefully we can try and avoid perceptions of gate keeping and railroading,\nand keep the network together, as we did back then\n\n\n\u003e\n\u003e --\n\u003e Michael Folkson\n\u003e Email: michaelfolkson at protonmail.com\n\u003e Keybase: michaelfolkson\n\u003e PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220426/1c0c7197/attachment-0001.html\u003e",
"sig": "f3852299466a08e0b5785ea57afee1f9f95eb63e93801b5c3228695d4bccbd59a328409d745d0f1c25045f11638c6ad5474be259b9110653aa2f00b8fb6d1020"
}