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
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
|
Return-Path: <shymaa.arafat@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id DBC64C002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Feb 2023 10:03:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id A956D81235
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Feb 2023 10:03:01 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org A956D81235
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=Ur5b758X
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 1EFa7-9ovA2E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Feb 2023 10:03:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 339D581232
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com
[IPv6:2607:f8b0:4864:20::1036])
by smtp1.osuosl.org (Postfix) with ESMTPS id 339D581232
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Feb 2023 10:03:00 +0000 (UTC)
Received: by mail-pj1-x1036.google.com with SMTP id
m8-20020a17090a4d8800b002377bced051so13155016pjh.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Feb 2023 02:03:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=0/RB/+dOalrxuHp6pH8yXJYclbeA9AOAAyj2wXfl43U=;
b=Ur5b758X4GKXcDN05h9M7ksPWiQpD4k58bitllzJYxUW9czh0iCmTQo7ZtLATMEPsj
C4mPaVjClKfW1EOtF9BQ3CLqCsxbVXKC+teemehmwlesjMPmL8vOK4VnD7ihUEabcXoI
OJqgd/d+bOWeUJ3qE5LYW6kIPy82XXPbnA/JoeWcOVyp0+DjNS6l8XkmC0oNszuxZuIJ
JQ3IdK3hpeWJX8yaIkwGJRud8f5EfXg0LQ3Gdx1lcGzGihHj+rYITegC+EC8WqWrZsmf
4RNO8eiDFkQAgQNe/UMUJoVMSXOrzR6Uksj6t64fPo3InF1DysvrC+Jz/XcRdCmhcnAm
kAIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=0/RB/+dOalrxuHp6pH8yXJYclbeA9AOAAyj2wXfl43U=;
b=FdWkBNCng3soHwdkEeXNMZ59eC4SsHrNcDcdy2y+S/KJc8ziPu6S0LP1YnMLfzVsaY
KEzTAw2ywN109zu2ED5XJTCHVNaJDKH2uLBLBuFn2xGiUnL8R8mXcqbCpBUEWY9v39tt
oCzeYz5tF/KhbzMtaff9xXPEFF5P7TLMnWBy3lWm4xkhnPqD2jE6HW41czVxn1J47HkI
/JrqOjFUiwRzELBInNkZbt8wRZGYUZlVNCPUVCZ88I4cJRnRse3d+r6QpWxlrFgRYccW
5Fc+2DbpbUMgHcLpaoqqZyTRPFlW25+/qvRRSNj6CLnpfs8YI78tn1tr17Ge9LAGB3C/
WwBw==
X-Gm-Message-State: AO0yUKVN3v5T39fZiVtqSUNJ506mIuHjl7/pgYHMTnLitfBn0INAgD7K
OPWcYSjI566dr9dbHujfSUrsf9+X7NvSNa6xXdo=
X-Google-Smtp-Source: AK7set/juHV5yDta9zTgse3uSdDaGqLMNFuFdB4gwcM4EQt6q6dnT5Ip0132XxMxzf6hKOjBuE+V/enJXH9GLAD16mU=
X-Received: by 2002:a17:90a:5783:b0:237:3d0c:8d58 with SMTP id
g3-20020a17090a578300b002373d0c8d58mr940512pji.5.1677578578361; Tue, 28 Feb
2023 02:02:58 -0800 (PST)
MIME-Version: 1.0
References: <CACVgDWbZKzmq+j0Hu-k5fW3J+ni-nasq74Ad+a0mkZJE_mPwSQ@mail.gmail.com>
<6OFVqxYXytFKbCYhzK7GjtrkWA0IuRRXaiWuH9mwPuNPMw3LOtC_1c-txfamKNO9XfNvWmRbVDev_FBmUsjpoYgRcGIxi486sYVJRNQjtb8=@protonmail.com>
In-Reply-To: <6OFVqxYXytFKbCYhzK7GjtrkWA0IuRRXaiWuH9mwPuNPMw3LOtC_1c-txfamKNO9XfNvWmRbVDev_FBmUsjpoYgRcGIxi486sYVJRNQjtb8=@protonmail.com>
From: shymaa arafat <shymaa.arafat@gmail.com>
Date: Tue, 28 Feb 2023 12:02:47 +0200
Message-ID: <CAM98U8mxLsbMcaEY7PHUSeRNBQgUA4bs9-L=e80wk=M97MXmBg@mail.gmail.com>
To: HcaFc_jbe <HcaFc_jbe@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003f00ef05f5bfb385"
X-Mailman-Approved-At: Tue, 28 Feb 2023 16:36:13 +0000
Subject: Re: [bitcoin-dev] BIP proposal: Fee-redistribution contracts
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: Tue, 28 Feb 2023 10:03:02 -0000
--0000000000003f00ef05f5bfb385
Content-Type: text/plain; charset="UTF-8"
If you allow me to comment (just with a bird eye, have not read the paper
only the abstract)
I think the Bitcoin community may consider the intuition of somewhat
"Future Saving" through TX fees:
ie, the idea of saving a ratio of the fees (say half to be decreased to
half with each reward halving)is worth thinking of:
Keep in mind that the block reward problem will not start only in 2140, but
when the mining cost becomes comparable to the reward value (could this be
as near as 2040?I don't know, you know the answer better than me)
.
-So, why not start a fee splitting mechanism in analogy to reward
splitting mechanism
*(the saved ratio is half the total now, and to be halved with every
Bitcoin reward halving until a threshold is reached where the saved amounts
gets added to the low block reward)*
Ofcourse this is very rough, a game theoritic model has to be built with
the appropriate incentives and costs to get the exact numbers
.
Thank you for letting me comment in your list
.
Regards
.
Shymaa M Arafat
On Tue, Feb 28, 2023, 02:18 HcaFc_jbe via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Greetings, Brno is a beautiful city.
>
>
>
>
> Long term miner incentives remain an open question, and this is an
> interesting proposal, but it has flaws.
>
>
>
>
> -----To intervene or not intervene
>
> --No intervention: When block subsidies do run out, years from now, it's
> possible that we live in a world where ordinals, LN-settlements, and
> on-chain transactions will be filling block space to the extent that miners
> are incentivized to continue mining.
>
> --Intervention: Tail-emissions? Demurrage?
> Fee-redistribution schemes like this one?
>
> Really, it is too early to say whether mining incentives _will even_ be a
> problem, let alone _what_ the solution(s) should be.
>
> This fee-redistribution scheme aims to solve
>
> 1. Undercutting attacks [which have been precluded AFAIK with anti
> fee-sniping
>
> nLocktime since Core 0.11]
>
> 2. Fee-variance between blocks, whether due to the mining gap or
> variance in block
>
> demand.
>
>
>
> --Flaws
>
> 0. A miner in this world could be more aggressive in excluding certain
> blocks to the detriment of their counter parties. I.e. If a miner can
> ignore high-fee transactions, knowing they won't receive the _benefits_ of
> mining them [or less benefit], they can exclude these transactions without
> losing fees. E.g. if a miner is or represents a counterparty in a LN
> commitment transaction, and this counter party prefers that a time
> threshold is reached [so that they can mine a different version of the
> commitment transaction] then under this scheme they can avoid mining the
> first commitment transaction without really losing its fee, since it's fee
> is socialized anyway. This attack then becomes free or very cheap.
>
> 1. How would this smart-contract actually be constructed? The paper
> contains no references to op_codes or implementations. You do mention that
> you are not a bitcoin dev, so that's fair. AFAIK this isn't even _possible_
> with the current Script, and could remain impossible. Maybe DLCs could be
> applied somehow. IDK.
>
> 2.0. I think it will be difficult to convince the ecosystem that the
> mining incentive structure should be changed from competitive to
> cooperative. This effectively changes the mining ecosystem into one giant
> mining pool. How would this affect mining centralization?
>
> 2.1. How do we achieve miner consensus in implementing the
> fee-redistribution scheme? And what is the consensus for updating?
>
> ---Paper-nits:
>
> I believe the distribution in block creation is not exponential, but
> poisson -> on page two it's described as exponential.
>
> Cheers,
>
> -Paul
>
> ------- Original Message -------
> On Monday, February 27th, 2023 at 8:32 AM, Rastislav Budinsky via
> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hello,
>
> I am working on my Bachelor's thesis, in which a new way of collecting
> transaction fees is introduced or rather how they are distributed.
>
> When a miner mines a block he takes all the fees currently. However with
> the proposed solution he takes only fraction M and remaining fraction C is
> sent to one of more contracts. One contract at its simplest collects fees
> from the miner and at the same time redistributes it back to the miner.
>
> This means no new Bitcoins are introduced, only the one collected from
> fees are collected, averaged and rewarded back to the miner in a "smarter"
> way.
>
> We can have multiple such contracts, where each averages the collected
> fees over different time frames. I would like to refer you to our paper for
> more details [1], which is not yet in the final form.
>
> Benefits are discussed in the paper [1] as well, mainly it should make
> mining more secure and predictable against drastic fluctuations in fees. I
> personally do not think miners should oppose this solution as for most
> miners it should make a better mining environment. Similarly in a sense to
> what mining pools bring.
>
> I would like to know your opinions about this proposal and we can also
> discuss the needed parameters introduced with such a solution if you are in
> favor of it or think it might be interesting.
>
> Introducing this solution soon enough will not make a great difference to
> miners with current block rewards and at the same time the contracts will
> be adapted before transaction fees become the main source of income for
> miners.
>
> As I have very little to none developer experience from blockchain's point
> (especially on Bitcoin), I am not sure if this would be possible as
> soft-fork as scripts in Bitcoin are stateless I suppose.
> However maybe a generally spendable script by anyone holding the funds is
> created, which a miner of the block would be the one spending it, and the
> correct logic of following the contracts is embedded into consensus nodes
> themselves. Thus perhaps a less disruptive solution to hard-fork.
>
> Once again, I would love to know your opinions about this & I apologize
> for making this a bit less conventional BIP proposal.
>
> [1] https://arxiv.org/abs/2302.04910
>
> Best regards.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000003f00ef05f5bfb385
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">If you allow me to comment (just with a bird eye, have no=
t read the paper only the abstract)<div dir=3D"auto"><br></div><div dir=3D"=
auto">I think the Bitcoin community may consider the intuition of somewhat =
"Future Saving" through TX fees:</div><div dir=3D"auto">ie, the i=
dea of saving a ratio of the fees (say half to be decreased to half with ea=
ch reward halving)is worth thinking of:</div><div dir=3D"auto">Keep in mind=
that the block reward problem will not start only in 2140, but when the mi=
ning cost becomes comparable to the reward value (could this be as near as =
2040?I don't know, you know the answer better than me)</div><div dir=3D=
"auto">.</div><div dir=3D"auto">-So, why not start a fee splitting=C2=A0 me=
chanism in analogy to reward splitting mechanism=C2=A0</div><div dir=3D"aut=
o"><u>(<i>the saved ratio is half the total now, and to be halved with ever=
y Bitcoin reward halving until a threshold is reached where the saved amoun=
ts gets added to the low block reward)</i></u></div><div dir=3D"auto"><u><i=
><br></i></u></div><div dir=3D"auto">Ofcourse this is very rough, a game th=
eoritic model has to be built with the appropriate incentives and costs to =
get the exact numbers</div><div dir=3D"auto">.</div><div dir=3D"auto">Thank=
you for letting me comment in your list</div><div dir=3D"auto">.</div><div=
dir=3D"auto">Regards</div><div dir=3D"auto">.</div><div dir=3D"auto">Shyma=
a M Arafat=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
class=3D"gmail_attr">On Tue, Feb 28, 2023, 02:18 HcaFc_jbe via bitcoin-dev=
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div style=3D"font-family:Arial,sans-serif;font-size:14px"></div><div =
style=3D"font-family:Arial,sans-serif;font-size:14px"><p dir=3D"ltr" style=
=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-=
size:11pt;font-family:Arial;color:#000000;white-space:pre-wrap">Greetings, =
Brno is a beautiful city.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"font-size:11pt;font-family:A=
rial;color:#000000;white-space:pre-wrap"><span style=3D"white-space:pre-wra=
p"> </span></span><span style=3D"font-size:11pt;font-family:Arial;color:#00=
0000;white-space:pre-wrap">=C2=A0</span></p><p dir=3D"ltr" style=3D"line-he=
ight:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;f=
ont-family:Arial;color:#000000;white-space:pre-wrap">=C2=A0</span></p><p di=
r=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span=
style=3D"font-size:11pt;font-family:Arial;color:#000000;white-space:pre-wr=
ap">Long term miner incentives remain an open question, and this is an inte=
resting proposal, but it has flaws.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"font-size:11pt;font-famil=
y:Arial;color:#000000;white-space:pre-wrap"><span style=3D"white-space:pre-=
wrap"> </span></span><span style=3D"font-size:11pt;font-family:Arial;color:=
#000000;white-space:pre-wrap">=C2=A0</span></p><p dir=3D"ltr" style=3D"line=
-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11p=
t;font-family:Arial;color:#000000;white-space:pre-wrap">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</span><span style=3D"font-size:11pt;fo=
nt-family:Arial;color:#000000;white-space:pre-wrap"><span style=3D"white-sp=
ace:pre-wrap"> </span></span><span style=3D"font-size:11pt;font-family:Aria=
l;color:#000000;white-space:pre-wrap">=C2=A0</span></p><p dir=3D"ltr" style=
=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-=
size:11pt;font-family:Arial;color:#000000;white-space:pre-wrap">-----To int=
ervene or not intervene</span></p><p dir=3D"ltr" style=3D"line-height:1.38;=
margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family=
:Arial;color:#000000;white-space:pre-wrap">--No intervention:=C2=A0 When bl=
ock subsidies do run out, years from now, it's possible that we live in=
a world where ordinals, LN-settlements, and on-chain transactions will be =
filling block space to the extent that miners are incentivized to continue =
mining.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --Intervention: Tail-emiss=
ions? Demurrage? Fee-redistribution schemes like this one?</span></p><br><p=
dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><s=
pan style=3D"font-size:11pt;font-family:Arial;color:#000000;white-space:pre=
-wrap">Really, it is too early to say whether mining incentives _will even_=
be a problem, let alone _what_ the solution(s) should be.</span></p><br><p=
dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><s=
pan style=3D"font-size:11pt;font-family:Arial;color:#000000;white-space:pre=
-wrap">This fee-redistribution scheme aims to solve=C2=A0=C2=A0=C2=A0</span=
></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:=
0pt"><span style=3D"font-size:11pt;font-family:Arial;color:#000000;white-sp=
ace:pre-wrap">=C2=A0=C2=A0=C2=A0=C2=A0</span><span style=3D"font-size:11pt;=
font-family:Arial;color:#000000;white-space:pre-wrap"><span style=3D"white-=
space:pre-wrap"> </span></span><span style=3D"font-size:11pt;font-family:Ar=
ial;color:#000000;white-space:pre-wrap">1. Undercutting attacks [which have=
been precluded AFAIK with anti fee-sniping=C2=A0</span></p><p dir=3D"ltr" =
style=3D"line-height:1.38;margin-left:36pt;text-indent:36pt;margin-top:0pt;=
margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:#0=
00000;white-space:pre-wrap">nLocktime since Core 0.11]</span></p><p dir=3D"=
ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:11pt;font-family:Arial;color:#000000;white-space:pre-wrap">=
=C2=A0=C2=A0=C2=A0=C2=A0</span><span style=3D"font-size:11pt;font-family:Ar=
ial;color:#000000;white-space:pre-wrap"><span style=3D"white-space:pre-wrap=
"> </span></span><span style=3D"font-size:11pt;font-family:Arial;color:#000=
000;white-space:pre-wrap">2. Fee-variance between blocks, whether due to th=
e mining gap or variance in block=C2=A0</span></p><p dir=3D"ltr" style=3D"l=
ine-height:1.38;margin-left:36pt;text-indent:36pt;margin-top:0pt;margin-bot=
tom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:#000000;whit=
e-space:pre-wrap">demand.</span></p><p dir=3D"ltr" style=3D"line-height:1.3=
8;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-fami=
ly:Arial;color:#000000;white-space:pre-wrap">=C2=A0</span></p><br><p dir=3D=
"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span sty=
le=3D"font-size:11pt;font-family:Arial;color:#000000;white-space:pre-wrap">=
--Flaws</span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;m=
argin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:#00=
0000;white-space:pre-wrap">0. A miner in this world could be more aggressiv=
e in excluding certain blocks to the detriment of their counter parties. I.=
e. If a miner can ignore high-fee transactions, knowing they won't rece=
ive the _benefits_ of mining them [or less benefit], they can exclude these=
transactions without losing fees. E.g. if a miner is or represents a count=
erparty in a LN commitment transaction, and this counter party prefers that=
a time threshold is reached [so that they can mine a different version of =
the commitment transaction] then under this scheme they can avoid mining th=
e first commitment transaction without really losing its fee, since it'=
s fee is socialized anyway. This attack then becomes free or very cheap.=C2=
=A0</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;m=
argin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:#00=
0000;white-space:pre-wrap">1. How would this smart-contract actually be con=
structed? The paper contains no references to op_codes or implementations. =
You do mention that you are not a bitcoin dev, so that's fair. AFAIK th=
is isn't even _possible_ with the current Script, and could remain impo=
ssible. Maybe DLCs could be applied somehow. IDK.</span></p><br><p dir=3D"l=
tr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=
=3D"font-size:11pt;font-family:Arial;color:#000000;white-space:pre-wrap">2.=
0. I think it will be difficult to convince the ecosystem that the mining i=
ncentive structure should be changed from competitive to cooperative. This =
effectively changes the mining ecosystem into one giant mining pool. How wo=
uld this affect mining centralization?</span></p><p dir=3D"ltr" style=3D"li=
ne-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:1=
1pt;font-family:Arial;color:#000000;white-space:pre-wrap">2.1. How do we ac=
hieve miner consensus in implementing the fee-redistribution scheme? And wh=
at is the consensus for updating?=C2=A0</span></p><br><p dir=3D"ltr" style=
=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-=
size:11pt;font-family:Arial;color:#000000;white-space:pre-wrap">---Paper-ni=
ts:</span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margi=
n-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:#000000=
;white-space:pre-wrap">I believe the distribution in block creation is not =
exponential, but poisson -> on page two it's described as exponentia=
l.</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;ma=
rgin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:#000=
000;white-space:pre-wrap">Cheers,=C2=A0=C2=A0=C2=A0=C2=A0</span></p><p dir=
=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:11pt;font-family:Arial;color:#000000;white-space:pre-wra=
p">-Paul</span></p><br></div><div>
------- Original Message -------<br>
On Monday, February 27th, 2023 at 8:32 AM, Rastislav Budinsky via b=
itcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" tar=
get=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>=
> wrote:<br><br>
<blockquote type=3D"cite">
<div dir=3D"ltr">Hello,<div><br></div><div>I am working on my B=
achelor's thesis, in which a new way of collecting transaction fees is =
introduced or rather how they are distributed.</div><div><br></div><div>Whe=
n a miner mines a block he takes all the fees currently. However with the p=
roposed solution he takes only fraction M and remaining fraction C is sent =
to one of more contracts. One contract at its simplest collects fees from t=
he miner and at the same time redistributes it back to the miner.</div><div=
><br></div><div><div>This means no new Bitcoins are introduced, only the on=
e collected from fees are collected, averaged and rewarded back to the mine=
r in a "smarter" way.</div></div><div><br></div><div>We can have =
multiple such contracts, where each averages the collected fees over differ=
ent time frames. I would like to refer you to our paper for more details [1=
], which is not yet in the final form.<br></div><div><br></div><div>Benefit=
s are discussed in the paper [1] as well, mainly it should make mining more=
secure and predictable against drastic fluctuations in fees. I personally =
do not think miners should oppose this solution as for most miners it shoul=
d make a better mining environment. Similarly in a sense to what mining poo=
ls bring.</div><div><br></div><div>I would like to know your opinions about=
this proposal and we can also discuss the needed parameters introduced wit=
h such a solution if you are in favor of it or think it might be interestin=
g.</div><div><br></div><div>Introducing this solution soon enough will not =
make a great difference to miners with current block rewards and at the sam=
e time the contracts will be adapted before transaction fees become the mai=
n source of income for miners.</div><div><br></div><div>As I have very litt=
le to none developer experience from blockchain's point (especially on =
Bitcoin), I am not sure if this would be possible as soft-fork as scripts i=
n Bitcoin are stateless I suppose.</div><div>However maybe a generally spen=
dable script by anyone holding the funds is created, which a miner of the b=
lock would be the one spending it, and the correct logic of following the c=
ontracts is embedded into consensus nodes themselves. Thus perhaps a less d=
isruptive solution to hard-fork.</div><div><br></div><div>Once again, I wou=
ld love to know your opinions about this & I apologize for making this =
a bit less conventional BIP proposal.</div><div><br></div><div>[1] <a href=
=3D"https://arxiv.org/abs/2302.04910" rel=3D"noreferrer nofollow noopener n=
oreferrer" target=3D"_blank">https://arxiv.org/abs/2302.04910</a></div><div=
><br></div><div>Best regards.</div></div>
</blockquote><br>
</div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--0000000000003f00ef05f5bfb385--
|