public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd•org>
To: Prayank <prayank@tutanota•de>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt
Date: Fri, 18 Feb 2022 18:41:02 -0500	[thread overview]
Message-ID: <YhAujmus3z69cUl7@petertodd.org> (raw)
In-Reply-To: <MtetoOZ--3-2@tutanota.de>

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

On Tue, Jan 18, 2022 at 02:57:30AM +0100, Prayank wrote:
> Hi Peter,
> 
> > that current lacks compelling use-cases clearly beneficial to all users
> 
> All the use cases shared in below links look compelling enough to me and we can do anything that a programmer could think of using such restrictions:
> 
>  https://utxos.org/uses/
> 
> https://rubin.io/archive/

Again, what I said was "compelling use-cases _clearly_ beneficial to _all_
users", not just a small subset. I neither think the use-cases in those links
are clearly compelling in the current form, and they of course, don't benefit
all users. Indeed, the Drivechains use-case arguably *harms* all users, as
Drivechains is arguably harmful to the security of Bitcoin as a whole.
Similarly, the various new uses for on-chain transactions mentioned as a
use-case arguably harms all existing users by competing for scarce blockchain
space - note how ETH has quite high on chain fees for basic transactions,
because there are so many use-cases where the per-tx value can afford much
higher fees. That kind of expansion of use-case also arguably harms Bitcoin as
a whole by providing more fuel for a future contentious blocksize debate.

Bitcoin is an almost $1 trillion dollar system. We have to very carefully weigh
the benefits of making core consensus changes to that system against the risks.
Both for each proposal in isolation, as well as the precedent making that
change sets.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2022-02-18 23:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-18  1:57 Prayank
2022-02-18 23:41 ` Peter Todd [this message]
2022-02-20 18:35   ` Erik Aronesty
2022-02-21  3:03     ` Prayank
2022-02-21  9:02       ` ZmnSCPxj
2022-02-21  9:11         ` ZmnSCPxj
2022-02-21  9:48         ` Prayank
2022-02-22 12:57           ` Billy Tetrud
2022-02-21  9:09       ` ZmnSCPxj
  -- strict thread matches above, loose matches on Subject: below --
2022-01-04 11:53 Prayank
2022-01-04 14:15 ` Michael Folkson
2022-01-04 15:06   ` Prayank
2022-01-04 16:48     ` Michael Folkson
2022-01-04 17:07       ` Prayank
2022-01-04 14:42 ` Christian Decker
2022-01-04 15:45   ` Prayank
2022-01-03  2:05 Michael Folkson
2022-01-09 11:38 ` Peter Todd
2022-01-11  3:42   ` Jeremy
2022-01-11  4:38     ` Jeremy

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=YhAujmus3z69cUl7@petertodd.org \
    --to=pete@petertodd$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=prayank@tutanota$(echo .)de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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