From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 687EBC002D for ; Tue, 26 Apr 2022 06:39:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 47B4E41776 for ; Tue, 26 Apr 2022 06:39:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5hS6kzHkZSa for ; Tue, 26 Apr 2022 06:39:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by smtp4.osuosl.org (Postfix) with ESMTPS id 1207241778 for ; Tue, 26 Apr 2022 06:39:47 +0000 (UTC) Received: by mail-pl1-x636.google.com with SMTP id c12so29322670plr.6 for ; Mon, 25 Apr 2022 23:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=i+0jT8N69/pTvQ5mlBCAlemHUSU+ChBlyDZotZBOfbM=; b=ieKkPBheDU6nE40+Rw4G56ZWQhnDlcqXOKQnztQgC8M1dizaX1SpKRd+ZjWYein2Ah tONASlq5cd2z1YewMw9M4J7ojm4kbuWzITbhp0i+0yEQZMcOqms4ohQa4wQa/AvI1jsc bTJm++ecd18xojpkcY5LiUsoaJjTZq1wANLV65OxhpuyNEGS/xo4Ji+uPETNdrGfIS5U N7TNTmfeUvZPQ3ENxtn54sqKOeho+8snY6PIhpPgFbF3M8/+sT4Jmds0WL2VP8OFTXTG Gnb5/lKYL7I3y7YqveqxeNMKHcgSG3nd0t6lJ+5EpeP/fI+pnCjh2JhDO9w+339eAbQs Ifbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=i+0jT8N69/pTvQ5mlBCAlemHUSU+ChBlyDZotZBOfbM=; b=eTS2itPK0xnfurS75ET2hKhOwRhWGVM/GZE6OrPzF2WhvoQn5HcMTgxd1W5gf5jGE0 CPYW7W9YtGgj94p8CK9j4x93C2sWc2LrGc0l1hy/NA6HJm+hfZ5eBeaf8uBc6VSxWyW8 MtUjE5cNL7dCJZUG39/7ttZR6PIMHvq8Af1CwGfzP7P6LqYNhLX9MGqR+PzYAImFT8Ge jBLRReLVLzxSLuHEFicyd40lQYYDDlXCjYhpfEFFSxScK87TwifxRnTZtreaevRJ/njV QfzVwL9oySo1J6LF2xyuw7yvEacSwMe5t5NxXOoI0sqZGEVyvdGntD5419pWx8jDW8E0 lNMg== X-Gm-Message-State: AOAM5338MHKHIHOcwGRbdv+ak72ga/GayQDjwygjiIH7+FEczVD4Cxdq QD9D+34Q2vIxJbzgDitGTcTPKfZ6MohgK6QlI03bGQsW X-Google-Smtp-Source: ABdhPJwy+hJ5viPl1VruMw2x3PfauLeU2IIpuhnmE6HwrLL09T38bTqCOrjUBFYqUXadxYKQkR0tHJG/Rt1S/A4QD7U= X-Received: by 2002:a17:902:ba8e:b0:151:ed65:fda4 with SMTP id k14-20020a170902ba8e00b00151ed65fda4mr21954650pls.127.1650955187404; Mon, 25 Apr 2022 23:39:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Melvin Carvalho Date: Tue, 26 Apr 2022 08:39:36 +0200 Message-ID: To: Michael Folkson , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000007c453905dd88f5df" X-Mailman-Approved-At: Tue, 26 Apr 2022 10:53:11 +0000 Subject: Re: [bitcoin-dev] What to expect in the next few weeks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2022 06:39:50 -0000 --0000000000007c453905dd88f5df Content-Type: text/plain; charset="UTF-8" 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 > --0000000000007c453905dd88f5df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Apr 22, 2022 at 7:33 PM Micha= el Folkson via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
=
If the next few weeks go how I fear they will it cou= ld get messy. If you care about Bitcoin's consensus rules I'd reque= st you pay attention so you can make an informed view on what to run and wh= at to support. For those of you who were around in 2015-2017 you'll kno= w what to expect. The right outcome endured in 2017 and I'm sure the ri= ght outcome will endure here assuming people pay attention and listen to th= e individuals who were trusted during that period. There are always a large= number of motivated parties who are incentivized to break nodes off from B= itcoin and may seek to take advantage of a contentious soft fork activation= attempt.

Remember that if all the info= rmation is presented to users in a clear way well ahead of time then they c= an 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 unt= il the last minute. When in doubt it is generally better to rely on the sta= tus quo and tried and trusted. In this case that would be Bitcoin Core. Alt= ernative releases such as those seeking to attempt to activate CTV or indee= d those seeking to resist the activation of CTV really should only be consi= dered if you are informed on exactly what you are running.

If you are interested in the effort to resist the cont= entious soft fork activation attempt of CTV please join ##ursf on Libera IR= C.

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 fork= s.

Thanks for raising this
=
Remembering 2017 quite well, it's often characterized as= small block(ers) vs big block(ers).=C2=A0 While that was certainly the cas= e, I see it slightly differently.=C2=A0

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

Any prop= osed changes should factor in network splits as a potential risk.=C2=A0 Or = perhaps through another lens, you could see a network split as an attack, o= n a par with a 51% attack, in terms of user disruption.=C2=A0 It may in fac= t, be more potent, since we've never had a serious 51% attack, but we h= ave had network splits

I do think the conversation here is MUCH better tempered t= han 2017.=C2=A0 Hopefully we can try and avoid perceptions of gate keeping = and railroading, and keep the network together, as we did back then
=C2=A0
--0000000000007c453905dd88f5df--