+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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
