From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 88010C0011 for ; Sun, 20 Feb 2022 18:35:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 6FBFB407D7 for ; Sun, 20 Feb 2022 18:35:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id In8N4EOIpATz for ; Sun, 20 Feb 2022 18:35:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by smtp4.osuosl.org (Postfix) with ESMTPS id 22F204071E for ; Sun, 20 Feb 2022 18:35:30 +0000 (UTC) Received: by mail-lf1-x12e.google.com with SMTP id p22so14709810lfu.5 for ; Sun, 20 Feb 2022 10:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ck7lzrwsawM+BwR7fPgQu2dVHDcEf9VXFT56BNCtVJ8=; b=QlOx994KDKonDmAVwygHRnN65/TcDch6/p4GrMmT1wAwTXThhYEHym2gvyImJeVFjT +vmlbFJVpIIjBihsCtglYPCbmQrzNFKbUlDBr6UuhzPVpbkSf3pt7ZZoyzJnoslo8RJ2 zVymGkOzwsrqbhMwwdBQUzpTwBxnx3+FgDh1CGpnTMw8cV31vtA87FTfW3KabrEYr49A +2Ze6Ntd1dMV/cBia4hR1PoTyP1wHIhHj8/cA+aqFvV+u10z1z2UFGApFOS2aeRipHfS sry+SdHZkC5qfCRfFnxoU4Y0e1r8Fcxv5raZ9IDahdRCQBMCnkvgvgCuzrEGozyteEqc an9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ck7lzrwsawM+BwR7fPgQu2dVHDcEf9VXFT56BNCtVJ8=; b=Rw9uL2SH6t583v54qT7errzv/DPMTBpv40Mjs8mSfdU3268KFYWyb+92JDyNAcF0rL /ILiPwBfKtstgmvi1LOMsMJKwF2bUnsDYbPOYNAV77+78NEbisJ1v9aT9xw8g37t18E3 30yLV6OYQkZdl6rBB+8sB0euALI2LVGHnD9BjGSE7+AE3xD2tblzTXfuTeMJ5R5cULha jnpixcFBdZuHQ+IVz8s87Jtu5hTX5gmd8L/YVfYfMhfLmSS4ZOMeCWTWb0B66UkPCXr1 f4bASlJEZOISQ1x1peunLezYapg6l88GJqpR5mbo0fiKiNgxoiZpSW2GWiUptstIawmT zbrg== X-Gm-Message-State: AOAM532tQjwHzfFGauh4Z0kHI180utfUwqDEfPDZEn4zjWHHoPfr3ZT2 QuvjhxEZLtTUaszTTU4jiK9Bq7/LzoDkjm28IVpt0Bw= X-Google-Smtp-Source: ABdhPJzgRdVsSHcAbIh8kpLHmpKfEVbUdWyqMa5SIAgtGiNqQkPQFPQ1hEwQdgxj3xyLNAB4p2pbhg/hwBMGlZm0780= X-Received: by 2002:ac2:4835:0:b0:443:5db5:9332 with SMTP id 21-20020ac24835000000b004435db59332mr11420448lft.308.1645382127721; Sun, 20 Feb 2022 10:35:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Sun, 20 Feb 2022 13:35:15 -0500 Message-ID: To: Peter Todd , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000003e228805d87761a4" X-Mailman-Approved-At: Sun, 20 Feb 2022 18:38:54 +0000 Cc: Prayank Subject: Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2022 18:35:31 -0000 --0000000000003e228805d87761a4 Content-Type: text/plain; charset="UTF-8" > 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 > --0000000000003e228805d87761a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> note how ETH has quite high on chain fees for basic t= ransactions,
> because there are so many use-cases where the per-tx v= alue can afford much
> higher fees. That kind of expansion of use-cas= e also arguably harms Bitcoin as
> a whole by providing more fuel for= a future contentious blocksize debate.

i second this argument
<= br>ideally, all extensions should be explicit use cases, not generic/implic= it layers that can be exploited for unknown and possibly harmful use cases<= br>

also timing is critical for all bitcoin innovation.= =C2=A0 =C2=A0look 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=C2=A0on-chain soft fork can= reduce tx size, move us from l2 to l3, vastly improve privacy, and get mor= e small transactions off-chain.

but it probabl= y shouldn't be released for another 2 years

<= br>
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 a= nd we can do anything that a programmer could think of using such restricti= ons:
>
>=C2=A0 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 thos= e links
are clearly compelling in the current form, and they of course, don't b= enefit
all users. Indeed, the Drivechains use-case arguably *harms* all users, as<= br> 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 blockcha= in
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<= br> 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 w= eigh
the benefits of making core consensus changes to that system against the ri= sks.
Both for each proposal in isolation, as well as the precedent making that change sets.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000003e228805d87761a4--