Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5A683C0001 for ; Thu, 4 Mar 2021 16:00:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 4E25D4326E for ; Thu, 4 Mar 2021 16:00:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUDIxpzorvP6 for ; Thu, 4 Mar 2021 16:00:27 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by smtp2.osuosl.org (Postfix) with ESMTPS id 3B7594326C for ; Thu, 4 Mar 2021 16:00:27 +0000 (UTC) Received: by mail-ej1-x62f.google.com with SMTP id mm21so50041771ejb.12 for ; Thu, 04 Mar 2021 08:00:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/6RSmVL5bVDc6fuzuCi7pMSukvMKpnlNWSVHqVCUFrc=; b=CfV4vF+Rd6FCp2lDFbW1ruMiHGV50hv6iWQHqIVM9oPO6Imjt6L8Yue1oVL70dUy9j KmcIhnO9HRt/I5sM84G3ejWecO2rXiH6Y4zAFczMb2daCHb0WkbteUt2DgXxUWBpXoA6 7S3Yt2diBLFaYzza4m780umICEWuIrXcfglDlBUO903IRRIPQaV8Ga2kG0dp7EB4Qp4P AEUnqz6BYDF6JVxlTgwfXg0zRnGADSJj5rITWL56LRz0d8oK7YguIiFLGW4i7THSRRWl +ju/gPD4GbUirrtUrAaArAf1U/P6MSIQNMtWQUuyrb9Jh/kjJ+OeYeuQUxvs4U6HDds9 ELfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/6RSmVL5bVDc6fuzuCi7pMSukvMKpnlNWSVHqVCUFrc=; b=ZkM9EJx35XjYaa4FlWMeRk3LvHqKswafYM6jO2N921sEmQpPcEynamQE5WeQ/5B3S7 8LA/OYJ3JkJVDmWUnvpIEcdEOtfLVzuNDfM6ukWpQvhsyUycMhxbIBodfXziBy7HyiBH Q6ZqgvP+xfWxMgkjIiYN7XIHq04jUDNbGJqEWV5M537PdtIpLvPAE+FZ1WSiZUgBhudZ J3e/L936zCGcMiTvbhOg0k99Ns8sq/q8KmegLog07eacYd6lLbRsf7LDR3iUCe0g4auS icZuUjvnn8REzjye/NqIBkRkkmltL2Mv3oPmlYCLAJXJYr4lPUZgWksZSG/CV4Ie9yGS yXkg== X-Gm-Message-State: AOAM531gPnsG5X3qOG5bkgHJwZ9cP1xPtIklIgM4J9jGdVohAqayDxmJ smI0nHkiDy2QCmXEcyMyt4h8GeRv6vUIIBEkwJSNTH6i X-Google-Smtp-Source: ABdhPJxh9GNgU2mkbU693gPpbWw+dy6wugSG8lJv2FY0aNKRnhmNfLGjsANTsmld6d2/DQ0fEQzlV6ow43I8JRPPHQc= X-Received: by 2002:a17:906:a016:: with SMTP id p22mr4934732ejy.456.1614873620027; Thu, 04 Mar 2021 08:00:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Steve Lee Date: Thu, 4 Mar 2021 08:00:08 -0800 Message-ID: To: Bitcoin Protocol Discussion , Melvin Carvalho Content-Type: multipart/alternative; boundary="0000000000007a9d0205bcb810b1" X-Mailman-Approved-At: Thu, 04 Mar 2021 18:15:21 +0000 Subject: Re: [bitcoin-dev] activation mechanism considerations 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: Thu, 04 Mar 2021 16:00:30 -0000 --0000000000007a9d0205bcb810b1 Content-Type: text/plain; charset="UTF-8" +1 for calm and patience as we navigate the activation mechanism. On Thu, Mar 4, 2021 at 3:24 AM Melvin Carvalho via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On Thu, 4 Mar 2021 at 10:07, John Rand via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Consensus is important for both taproot and separately for the activation >> mechanism. There are more soft-forks that Bitcoin will need, so it is >> important to achieve positive progress on the activation topic also, not >> get impatient and rush something ill-considered. Not all future soft-forks >> maybe as widely supported as taproot, and yet it could become existentially >> critical that Bitcoin prevails in achieving a future upgrade in dramatic >> circumstances, even against powerful interests counter to Bitcoin user and >> investors interests. We should treat the activation topic in a considered >> way and with decorum, provide tight non-emotive reasoning devoid of >> frustration and impatience. This is a low drama and convenient time to >> incrementally improve activation. People have varied views about the >> deciding factor, or even which factors resulted in segwit activating after >> BIP 141 failed using BIP 9. We do not have to solve everything in one >> step, incremental improvement is good, for complex unintuitive topics, to >> learn as we go - and it should not be hard to do less badly than what >> transpired leading up to BIP 148 and BIP 91. Failure to upgrade if >> permanent, or demoralizing to protocol researchers could be a systemic risk >> in itself as there are more upgrades Bitcoin will need. We are not Ents >> but we should use our collective ingenuity to find an incremental >> improvement for activation. >> > > Great high level thoughts > > The Ents themselves were created in Tolkien's fork of Shakespeare, when he > was frustrated to learn that trees didnt actually march :) > > Having followed standards for 10+ years consensus can be tricky > > IIRC last time with segwit there was a straw poll in the wiki where devs > could express leanings in an informal, async way. Something like that > could be of value. > > There's an insightful spec written at the IETF "On Consensus and Humming > in the IETF", then IMHO is worth reading > > https://tools.ietf.org/html/rfc7282 > > That said, if we could find an incorruptible machine that could gather the > highest fee tx from the mempool and post it every 10 minutes, bitcoin would > largely run itself. So, while understanding the gravity of each change, we > could perhaps have the mindset that there are a finite number, such that > when complete bitcoin will move to an endgame where for the user it 'just > works', much like the internet. If devs and changes are needed less, that > could be viewed as a sign of success. This is a hand wavy way of saying > that forks could potentially be a diminishing issue over time > > Just my 2 satoshis > > >> >> John R >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000007a9d0205bcb810b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for calm and patience as we navigate the activation me= chanism.=C2=A0

On Thu, Mar 4, 2021 at 3:24 AM Melvin Carvalho via bitco= in-dev <bitcoin= -dev@lists.linuxfoundation.org> wrote:


On Thu, 4 Mar 2021 at 10:07, John Rand v= ia bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
=
Consensus is important for both tap= root and separately for the activation mechanism.=C2=A0 There are more soft= -forks that Bitcoin will need, so it is important to achieve positive progr= ess on the activation topic also, not get impatient and rush something ill-= considered.=C2=A0 Not all future soft-forks maybe as widely supported as ta= proot, and yet it could become existentially critical that Bitcoin prevails= in achieving a future upgrade in dramatic circumstances, even against powe= rful interests counter to Bitcoin user and investors interests.=C2=A0 We sh= ould treat the activation topic in a considered way and with decorum, provi= de tight non-emotive reasoning devoid of frustration and impatience.=C2=A0 = This is a low drama and convenient time to incrementally improve activation= .=C2=A0 People have varied views about the deciding factor, or even which f= actors resulted in segwit activating after BIP 141 failed using BIP 9.=C2= =A0 We do not have to solve everything in one step, incremental improvement= is good, for complex unintuitive topics, to learn as we go - and it should= not be hard to do less badly than what transpired leading up to BIP 148 an= d BIP 91.=C2=A0 Failure to upgrade if permanent, or demoralizing to protoco= l researchers could be a systemic risk in itself as there are more upgrades= Bitcoin will need.=C2=A0 We are not Ents but we should use our collective = ingenuity to find an incremental improvement for activation.

Great high level thoughts

= The Ents themselves were created in Tolkien's fork of Shakespeare, when= he was frustrated to learn that trees didnt actually march :)

Having followed standards for 10+ years consensus can be t= ricky

IIRC last time with segwit there was a straw= poll in the wiki where devs could express leanings in an informal, async w= ay.=C2=A0 Something like that could be of value.

There's an insightful spec written at the IETF "On Consensus an= d Humming in the IETF", then IMHO is worth reading

<= /div>

That said= , if we could find an incorruptible machine that could gather the highest f= ee tx from the mempool and post it every 10 minutes, bitcoin would largely = run itself.=C2=A0 So, while understanding the gravity of each change, we co= uld perhaps have the mindset that there are a finite number, such that when= complete bitcoin will move to an endgame where for the user it 'just w= orks', much like the internet.=C2=A0 If devs and changes are needed les= s, that could be viewed as a sign of success.=C2=A0 This is a hand wavy way= of saying that forks could potentially be a diminishing issue over time

Just my 2 satoshis
=C2=A0

John R
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000007a9d0205bcb810b1--