public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Prayank <prayank@tutanota.de>
To: Billy Tetrud <billy.tetrud@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] On the regularity of soft forks
Date: Tue, 18 Jan 2022 18:22:05 +0100 (CET)	[thread overview]
Message-ID: <MtiCR2x--7-2@tutanota.de> (raw)

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]

> We should strive to one day get to a point where the bitcoin consensus isn't updating at all.

That day is nowhere near IMO and maybe we won't see it in my lifetime.

> Perhaps we should come to a consensus as a consensus as a community what the minimum time between soft forks should be, and just as importantly, what the minimum time between finalized consensus-change implementation and when we decide community consensus has been achieved.

This is not possible in a decentralized network like Bitcoin and makes no sense. Soft forks can/should be done as and when required. This does not mean we do them often but if a change makes sense, looks ready, got enough consensus, reviewed properly etc. then timing doesn't really matter in every case.

> Activating multiple consensus changes in a bundle is far safer than having multiple separate in-flight soft forks at once.

This is not true. More changes bundled require more review and still more probability to have bugs. Security is always about keeping things simple.

> One solution is that we could be a lot more direct about how decisions are made. There's been a lot of rhetoric around UASF and how the economic majority is really who's running the show.

BIP 8 with LOT=TRUE was a better activation mechanism option in Taproot but some influential developers wrote its misleading, unsafe etc. on social media so you can call me negative at this moment however I have realized the truth is really sad and we can't blindly follow some people. There are lot of people who will tell you bad things about UASF and how speedy trial is the best thing Bitcoin has ever experienced.

Michael Folkson also had some opinion in activation mechanism IIRC,


-- 
Prayank

A3B1 E430 2298 178F

[-- Attachment #2: Type: text/html, Size: 2406 bytes --]

             reply	other threads:[~2022-01-18 17:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-18 17:22 Prayank [this message]
2022-01-19  2:26 ` [bitcoin-dev] On the regularity of soft forks Billy Tetrud
  -- strict thread matches above, loose matches on Subject: below --
2022-01-01 15:45 vjudeu
2022-01-18 16:00 ` Billy Tetrud
2021-10-11 16:03 Prayank
2021-10-12 19:04 ` Jorge Timón
2021-10-11 12:24 Michael Folkson
2021-10-11 19:12 ` Jeremy
2021-10-11 19:53   ` ZmnSCPxj
2021-10-14 23:52   ` Anthony Towns
2021-10-15  0:43     ` micaroni
2021-10-16 11:02       ` Michael Folkson
2021-12-31  3:10         ` Keagan McClelland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MtiCR2x--7-2@tutanota.de \
    --to=prayank@tutanota.de \
    --cc=billy.tetrud@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox