summaryrefslogtreecommitdiff
path: root/ae/29f2efa15e1f3f6f61b42a13d7a2dc55f1eaa2
blob: ccfa311982bbe0bc7a0fa3620386fd093f00b230 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
Return-Path: <prayank@tutanota.de>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 98D37C0011
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <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"
X-Mailman-Approved-At: Mon, 21 Feb 2022 08:17:47 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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--