Date: Mon, 21 Feb 2022 04:03:07 +0100 (CET)
From: Prayank <prayank@tutanota.de>
To: Erik Aronesty <erik@q32.com>
Message-ID: <MwPDtAD--3-2@tutanota.de>
In-Reply-To: <CAJowKgKFeDSA5c5ejLyF7R=kEEAY6dtOY1dNV=6eQG2_Dj7eTg@mail.gmail.com>
References: <MtetoOZ--3-2@tutanota.de> <YhAujmus3z69cUl7@petertodd.org>
 <CAJowKgKFeDSA5c5ejLyF7R=kEEAY6dtOY1dNV=6eQG2_Dj7eTg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_259118_578656824.1645412587218"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Stumbling into a contentious soft fork activation
 attempt
Precedence: list

------=_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 <http://peter=
todd.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

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div>&gt; note how ETH has quite high on chain fees for basic transactions,=
</div><div>&gt; because there are so many use-cases where the per-tx value =
can afford much</div><div>&gt; higher fees. That kind of expansion of use-c=
ase also arguably harms Bitcoin as</div><div>&gt; a whole by providing more=
 fuel for a future contentious blocksize debate.</div><div><br></div><div>&=
gt;i second this argument</div><div><br></div><div dir=3D"auto"><br></div><=
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.<br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">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.<br></div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">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.</div><div dir=3D"auto"><br></=
div><div dir=3D"auto"><br></div><div>-- <br></div><div>Prayank<br></div><di=
v><br></div><div dir=3D"auto">A3B1 E430 2298 178F<br></div><div><br></div><=
div><br></div><div><br></div><div>Feb 21, 2022, 00:05 by erik@q32.com:<br><=
/div><blockquote class=3D"tutanota_quote" style=3D"border-left: 1px solid #=
93A3B8; padding-left: 10px; margin-left: 5px;"><div dir=3D"ltr"><div>&gt; n=
ote how ETH has quite high on chain fees for basic transactions,<br></div><=
div>&gt; because there are so many use-cases where the per-tx value can aff=
ord much<br></div><div>&gt; higher fees. That kind of expansion of use-case=
 also arguably harms Bitcoin as<br></div><div>&gt; a whole by providing mor=
e fuel for a future contentious blocksize debate.<br></div><div><br></div><=
div>i second this argument<br></div><div><div><br></div><div>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<br></div><div><br=
></div><div>also timing is critical for all bitcoin innovation.&nbsp; &nbsp=
;look at how lightning ate up fees<br></div><div><br></div><div>to keep bit=
coin stable, we can't "scale" too quickly either<br></div></div><div><br></=
div><div>i'm a fan of, eventually (timing is critical), a lightning-compati=
ble mimblewible+dandelion&nbsp;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.<br></div><div><br></div><div>but it probably shouldn't be release=
d for another 2 years<br></div><div><br></div></div><div><br></div><div cla=
ss=3D""><div class=3D"" dir=3D"ltr">On Fri, Feb 18, 2022 at 6:41 PM Peter T=
odd via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org" rel=3D"noopener noreferrer" target=3D"_blank">bitcoin-dev@lists.linux=
foundation.org</a>&gt; wrote:<br></div><blockquote style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D=
""><div>On Tue, Jan 18, 2022 at 02:57:30AM +0100, Prayank wrote:<br></div><=
div> &gt; Hi Peter,<br></div><div> &gt; <br></div><div> &gt; &gt; that curr=
ent lacks compelling use-cases clearly beneficial to all users<br></div><di=
v> &gt; <br></div><div> &gt; 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:<br></div><div> &gt; <br></div><div> &gt;&nbsp;=
 <a target=3D"_blank" rel=3D"noopener noreferrer" href=3D"https://utxos.org=
/uses/">https://utxos.org/uses/</a><br></div><div> &gt; <br></div><div> &gt=
; <a target=3D"_blank" rel=3D"noopener noreferrer" href=3D"https://rubin.io=
/archive/">https://rubin.io/archive/</a><br></div><div> <br></div><div> Aga=
in, what I said was "compelling use-cases _clearly_ beneficial to _all_<br>=
</div><div> users", not just a small subset. I neither think the use-cases =
in those links<br></div><div> are clearly compelling in the current form, a=
nd they of course, don't benefit<br></div><div> all users. Indeed, the Driv=
echains use-case arguably *harms* all users, as<br></div><div> Drivechains =
is arguably harmful to the security of Bitcoin as a whole.<br></div><div> S=
imilarly, the various new uses for on-chain transactions mentioned as a<br>=
</div><div> use-case arguably harms all existing users by competing for sca=
rce blockchain<br></div><div> space - note how ETH has quite high on chain =
fees for basic transactions,<br></div><div> because there are so many use-c=
ases where the per-tx value can afford much<br></div><div> higher fees. Tha=
t kind of expansion of use-case also arguably harms Bitcoin as<br></div><di=
v> a whole by providing more fuel for a future contentious blocksize debate=
.<br></div><div> <br></div><div> Bitcoin is an almost $1 trillion dollar sy=
stem. We have to very carefully weigh<br></div><div> the benefits of making=
 core consensus changes to that system against the risks.<br></div><div> Bo=
th for each proposal in isolation, as well as the precedent making that<br>=
</div><div> change sets.<br></div><div> <br></div><div> -- <br></div><div> =
<a target=3D"_blank" rel=3D"noopener noreferrer" href=3D"https://petertodd.=
org">https://petertodd.org</a> 'peter'[:-1]@<a target=3D"_blank" rel=3D"noo=
pener noreferrer" href=3D"http://petertodd.org">petertodd.org</a><br></div>=
<div> _______________________________________________<br></div><div> bitcoi=
n-dev mailing list<br></div><div> <a target=3D"_blank" href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" rel=3D"noopener noreferrer">bitcoin-dev@l=
ists.linuxfoundation.org</a><br></div><div> <a target=3D"_blank" rel=3D"noo=
pener noreferrer" href=3D"https://lists.linuxfoundation.org/mailman/listinf=
o/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev</a><br></div></blockquote></div></blockquote>  </body>
</html>

------=_Part_259118_578656824.1645412587218--