+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
>