From: Erik Aronesty <erik@q32.com>
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Cc: Prayank <prayank@tutanota.de>
Subject: Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt
Date: Sun, 20 Feb 2022 13:35:15 -0500 [thread overview]
Message-ID: <CAJowKgKFeDSA5c5ejLyF7R=kEEAY6dtOY1dNV=6eQG2_Dj7eTg@mail.gmail.com> (raw)
In-Reply-To: <YhAujmus3z69cUl7@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 2762 bytes --]
> 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.
i second this argument
ideally, all extensions should be explicit use cases, not generic/implicit
layers that can be exploited for unknown and possibly harmful use cases
also timing is critical for all bitcoin innovation. look at how lightning
ate up fees
to keep bitcoin stable, we can't "scale" too quickly either
i'm a fan of, eventually (timing is critical), a lightning-compatible
mimblewible+dandelion on-chain soft fork can reduce tx size, move us from
l2 to l3, vastly improve privacy, and get more small transactions off-chain.
but it probably shouldn't be released for another 2 years
On Fri, Feb 18, 2022 at 6:41 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3854 bytes --]
next prev parent reply other threads:[~2022-02-20 18:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-18 1:57 [bitcoin-dev] Stumbling into a contentious soft fork activation attempt Prayank
2022-02-18 23:41 ` Peter Todd
2022-02-20 18:35 ` Erik Aronesty [this message]
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='CAJowKgKFeDSA5c5ejLyF7R=kEEAY6dtOY1dNV=6eQG2_Dj7eTg@mail.gmail.com' \
--to=erik@q32.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=pete@petertodd.org \
--cc=prayank@tutanota.de \
/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