From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 98D37C0011 for ; Mon, 21 Feb 2022 03:03:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 7E77D60C2D for ; Mon, 21 Feb 2022 03:03:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=tutanota.de Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWjKtTNAPA1K for ; Mon, 21 Feb 2022 03:03:10 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) by smtp3.osuosl.org (Postfix) with ESMTPS id 1559E60B99 for ; Mon, 21 Feb 2022 03:03:09 +0000 (UTC) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id 39550FBF76D; Mon, 21 Feb 2022 03:03:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1645412587; s=s1; d=tutanota.de; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=/adTnA7S/y/IpLC00tRFL/VAwwfbjGLsVfOH54t+OnM=; b=lPaM2sbo1zg/suwt3rkzHbNT+hm0no+s4JGQ428AeEbwyBZ1WqRiOGfuszzXMZcY /JanXF+xFEhbIsrOysixu4iWdxXoKgwtROT7WBxOP6AB7lNP/kxu1JAcyj/kKSi2JSa 0omx+8O7zOh0ZghSMilcyOFThmvTy8FrD3Vuhnwx37sh5XusOd7LZgLgpz3Fw9Rtja5 3F42YJRWNdezwpTIbZybjseztIDFLIsuKcsgAmDkpz4lgR9iJJoyahoXLs69AjXb7Zm +hV8HBGzYdlLabBp0kD0w+Q4OU+TYzP31ES33Lq77IgH0KAzsvufvE+wlwfN+5EGpvg YFB2O2UvfQ== Date: Mon, 21 Feb 2022 04:03:07 +0100 (CET) From: Prayank To: Erik Aronesty Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_259118_578656824.1645412587218" X-Mailman-Approved-At: Mon, 21 Feb 2022 08:17:47 +0000 Cc: Bitcoin Protocol Discussion 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: Mon, 21 Feb 2022 03:03:11 -0000 ------=_Part_259118_578656824.1645412587218 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > note how ETH has quite high on chain fees for basic transactions,> becaus= e there are so many use-cases where the per-tx value can afford much> highe= r 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 I disagree with this argument, Satoshi won't agree with it either if still = active and it make no sense. Fees will be the incentives for miners as subs= idy decreases after every 210,000 blocks and it will depend on demand for b= lock space. There is nothing harmful in it just because something similar is happening = in an altcoin which has several other issues. Example: if a user has to pay= fees with 100 sat/vbyte fee rate to open and close channels it will be goo= d for Bitcoin in long term. If this is the reason to stop/delay improvements in bitcoin, maybe it appli= es for Taproot as well although I don't remember reading such things in you= r posts or maybe missed it. --=20 Prayank A3B1 E430 2298 178F Feb 21, 2022, 00:05 by erik@q32.com: > > 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 m= uch > > higher fees. That kind of expansion of use-case also arguably harms Bit= coin as > > a whole by providing more fuel for a future contentious blocksize debat= e. > > i second this argument > > ideally, all extensions should be explicit use cases, not generic/implici= t layers that can be exploited for unknown and possibly harmful use cases > > also timing is critical for all bitcoin innovation.=C2=A0 =C2=A0look at h= ow 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 mim= blewible+dandelion=C2=A0on-chain soft fork can reduce tx size, move us from= l2 to l3, vastly improve privacy, and get more small transactions off-chai= n. > > 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, >> >=20 >> > > that current lacks compelling use-cases clearly beneficial to all u= sers >> >=20 >> > 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 restrict= ions: >> >=20 >> >=C2=A0 >> https://utxos.org/uses/ >> >=20 >> > >> https://rubin.io/archive/ >> =20 >> Again, what I said was "compelling use-cases _clearly_ beneficial to _a= ll_ >> 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 b= enefit >> 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 bloc= kchain >> space - note how ETH has quite high on chain fees for basic transaction= s, >> because there are so many use-cases where the per-tx value can afford m= uch >> higher fees. That kind of expansion of use-case also arguably harms Bit= coin as >> a whole by providing more fuel for a future contentious blocksize debat= e. >> =20 >> Bitcoin is an almost $1 trillion dollar system. We have to very careful= ly weigh >> the benefits of making core consensus changes to that system against th= e risks. >> Both for each proposal in isolation, as well as the precedent making th= at >> change sets. >> =20 >> --=20 >> >> https://petertodd.org>> 'peter'[:-1]@>> petertodd.org >> _______________________________________________ >> bitcoin-dev mailing list >> >> bitcoin-dev@lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> ------=_Part_259118_578656824.1645412587218 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> 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-c= ase also arguably harms Bitcoin as
> a whole by providing more= fuel for a future contentious blocksize debate.

&= gt;i second this argument


<= div dir=3D"auto">I disagree with this argument, Satoshi won't agree with it= either if still active and it make no sense. Fees will be the incentives f= or miners as subsidy decreases after every 210,000 blocks and it will depen= d on demand for block space.

There is nothing harmful in it just because something similar is = happening in an altcoin which has several other issues. Example: if a user = has to pay fees with 100 sat/vbyte fee rate to open and close channels it w= ill be good for Bitcoin in long term.

=
If this is the reason to stop/delay improvements in bitco= in, maybe it applies for Taproot as well although I don't remember reading = such things in your posts or maybe missed it.


--
Prayank

A3B1 E430 2298 178F

<= div>

Feb 21, 2022, 00:05 by erik@q32.com:
<= /div>
> n= ote how ETH has quite high on chain fees for basic transactions,
<= div>> because there are so many use-cases where the per-tx value can aff= ord much
> higher fees. That kind of expansion of use-case= also arguably harms Bitcoin as
> a whole by providing mor= e fuel for a future contentious blocksize debate.

<= div>i second this argument

ideally, all e= xtensions should be explicit use cases, not generic/implicit layers that ca= n 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 bit= coin stable, we can't "scale" too quickly either

i'm a fan of, eventually (timing is critical), a lightning-compati= ble mimblewible+dandelion on-chain soft fork can reduce tx size, move = us from l2 to l3, vastly improve privacy, and get more small transactions o= ff-chain.

but it probably shouldn't be release= d for another 2 years


On Fri, Feb 18, 2022 at 6:41 PM Peter T= odd via bitcoin-dev <bitcoin-dev@lists.linux= foundation.org> wrote:
On Tue, Jan 18, 2022 at 02:57:30AM +0100, Prayank wrote:
<= div> > Hi Peter,
>
> > that curr= ent lacks compelling use-cases clearly beneficial to all users
>
> All the use cases shared in below links look c= ompelling enough to me and we can do anything that a programmer could think= of using such restrictions:
>
>

Aga= in, 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, a= nd they of course, don't benefit
all users. Indeed, the Driv= echains use-case arguably *harms* all users, as
Drivechains = is arguably harmful to the security of Bitcoin as a whole.
S= imilarly, the various new uses for on-chain transactions mentioned as a
=
use-case arguably harms all existing users by competing for sca= rce blockchain
space - note how ETH has quite high on chain = fees for basic transactions,
because there are so many use-c= ases where the per-tx value can afford much
higher fees. Tha= t 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 sy= stem. We have to very carefully weigh
the benefits of making= core consensus changes to that system against the risks.
Bo= th for each proposal in isolation, as well as the precedent making that
=
change sets.

--
=
_______________________________________________
bitcoi= n-dev mailing list
------=_Part_259118_578656824.1645412587218--